Upload
alberto-caeiro-cspo-csm-pmp
View
590
Download
1
Embed Size (px)
Citation preview
OKRs - Definindo Metas como no Silicon Valley
Caso Módulo: Experiências, Lições Aprendidas e Próximos Passos
Alberto A Caeiro Jr., CSM, CSPO, PMP Sr. Development Manager, Módulo [email protected] / t: @aacaeirojr
Agenda
❖ Contexto
❖ 1a "Iteração"
❖ 2a "Iteração"
❖ Lições Aprendidas
❖ Próximos Passos
Disclaimer❖ Esse é um trabalho “on-going”.
❖ Ainda estamos “acertando a mão”.
❖ Diferente de todos os “exemplos”, começamos com uma “implementação local” do método, só para a área de desenvolvimento.
Contexto e Motivação❖ Por que começamos a pensar nisso?
❖ Quais as Alternativas?
❖ Por que OKR?
OKR - O que é e da onde vem?❖ OKR (Objectives and Key Results) é uma metodologia ou
framework para definição de metas e alinhamento para a organização.
❖ Criada pela Intel nos anos 80 e popularizada em 1999 pelo Google, atualmente é utilizada por diversas empresas de tecnologia no Silicon Valley como Twitter, Yahoo!, GoPro, Spotify, Flipboard, LinkedIn e Dropbox.
Material gentilmente cedido pela Lean Performancewww.leanperformance.com.br
OKR - "Componentes"❖ O (“Objectives”): Objetivo
❖ O que queremos atingir.
❖ Aspiracional (recomendado).
❖ KR (“Key Results”): Resultados Chave
❖ Quantitativos.
❖ Critérios de Sucesso que mostram se estamos progredindo.
❖ Podem ser métricas (recomendado) ou milestones.
Material gentilmente cedido pela Lean Performancewww.leanperformance.com.br
OKRs - Exemplos❖ Modelo:
Eu vou [Objetivo] como medido por [este conjunto de Key Results]
❖ Objetivo: Encantar os Clientes
❖ Key Results:
❖ Visitas recorrentes no site: média de 50 visitas mensais.
❖ Atingir um Net Promoter Score de 87%.
❖ Tráfego orgânico (não pago) de 80%.
❖ Engajamento: 75% dos usuários possuem perfis completos no site.Material gentilmente cedido pela Lean Performance
www.leanperformance.com.br
OKR - Características❖ Se utilizam de ciclos curtos.
❖ Devem ser simples, de fácil compreensão e mensuráveis.
❖ Poucos, mas relevantes.
❖ Colaborativos (Top-Down & Botton-Up).
❖ Públicos.
❖ “Streatch Goals”.
Material gentilmente cedido pela Lean Performancewww.leanperformance.com.br
OKR - Principais Benefícios❖ Agilidade
❖ Aumenta o alinhamento.
❖ Facilita a comunicação.
❖ Aumento da cooperação.
❖ Promove foco e disciplina.
❖ Autonomia.
❖ Accountability.
Material gentilmente cedido pela Lean Performancewww.leanperformance.com.br
Contexto - Módulo❖ Sobre a Módulo
❖ Produto / Plataforma Risk Manager
❖ SICC / CICC (Projeto da Copa do Mundo)
Contexto - Módulo❖ Estrutura - Desenvolvimento
❖ Scrum : Dev + SM
❖ PO : "Separado"
Diretor Desenvolvimento
Gerente Desenvolvimento
Administrativo
Coord 1
Coord 2
Integrações
Time 1 Time 2 Time 9
…….
Time 3
Sprint: 15 diasRelease: 3 meses
Regressão: 2 semanas
….
1a Iteração - Abordagem❖ Começamos com o objetivo da área como um todo
❖ Explo: Melhorar a Qualidade do Produto
❖ Descemos até o nível da coordenação.
❖ Estávamos buscando o ideal, com um foco aspiracional bastante forte.
1a Iteração - Exemplos❖ Objetivo: Melhorar a qualidade percebida do software
❖ Key Result 1: Reduzir a quantidade de tickets de suporte classificados como "Very High” em 50%.
❖ Key Result 2: Reduzir a quantidade de tickets de suporte classificados como “High" em 50%.
❖ Key Result 3: Diminuir o tempo de resposta dos tickets “em análise” para no máximo 2 dias.
❖ Objetivo: Melhorar o relacionamento dos times com os seus respectivos POs
❖ Key Result 1: Obter nota “BOA" para o relacionamento PO-Time, medido por pesquisa mensal com os POs.
❖ Key Result 2: Obter nota “BOA" para o relacionamento PO-Time, medido por pesquisa mensal com os Times.
1a Iteração - Exemplos❖ Objetivo: Melhorar a performance percebida do Risk Manager:
❖ Key Result 1: Atender 5 tickets de performance deixando [a performance] dentro do [nível] aceitável.
❖ Key Result 2: Eliminar a sensação de lentidão no primeiro acesso.
❖ Objetivo: Mudar a arquitetura do RM para um modelo SaaS multi-tenant:
❖ Key Result 1: Tornar o Risk Manager multi-tenant.
❖ Key Result 2: Documentar o modelo de dados do RM.
1a Iteração - Resultados❖ Os principais objetivos gerais foram atingidos
❖ Mas….
❖ A maioria dos objetivos das áreas não
❖ Por que?
1a Iteração - Aprendizados❖ Falta de acompanhamento, só fomos ver que muitas coisas a gente
não tinha nem começado quando já não tinha mais tempo para entregar, nem corrigir os rumos.
❖ Objetivos fora da nossa realidade do dia a dia.
❖ Alguns resultados não traduziam os reais critérios de sucesso.
❖ Se você erra muito a mão dos objetivos, as pessoas perdem o interesse.
❖ Não levamos em consideração o perfil [mais resistente a mudanças] das pessoas.
2a Iteração - Abordagem❖ De forma geral, mantivemos os Objetivos principais da Área
❖ A meta era entender como cada coordenador ia contribuir para o objetivo geral (e menos efetivamente medir no detalhe)
❖ Seguimos por uma abordagem diferente:
❖ “O que a gente espera do coordenador de …. ?"
❖ "Como isso que a gente espera, agrega no objetivo geral da área?"
❖ E,
❖ Passamos a acompanhar os OKRs sprint a sprint.
2a Iteração - Exemplos❖ Objetivo: Minimizar o GAP de conhecimento técnico dos times:
❖ Key Result 1: Realizar 6 talks focados em aspectos específicos de arquitetura do RM.
❖ Key Result 2: Realizar 6 talks cobrindo aspectos de arquitetura que estamos buscando para o RM.
❖ Key Result 3: Realizar 5 códigos que possam servir de exemplos de arquitetura.
❖ Objetivo : Garantir a entrega da história de Regra de Objetos:
❖ Key Result: Ajudar o time 3 a entregar a historia de regras de objetos com qualidade.
2a Iteração - Exemplos❖ Objetivo: Participar de forma mais ativa do dia-a-dia dos times:
❖ Key Result 1: Garantir a revisão de pelo menos 80% do código gerado pelas histórias.
❖ Key Result 2: Garantir a revisão de pelo menos 1 check-in de cada time por sprint.
❖ Objetivo: Melhorar a integração com o time de produto:
❖ Key Result 1: Não ter reclamação da área de produto quanto a entrega dos times.
❖ Key Result 2: Não ter surpresas de alinhamento entre desenvolvimento e produto.
2a Iteração - Resultados❖ Além do objetivo geral, a maioria das coordenações tiveram um
bom desempenho (perto dos entre 50 e 75%).
❖ O acompanhamento quinzenal fez diferença.
❖ Maior colaboração.
❖ Como os objetivos estavam “mais perto” das pessoas, o buy-in foi bem maior.
2a Iteração - Aprendizados❖ Não atingir os 100% da meta (apesar de esperado), ainda é uma
quebra de paradigma: causa frustração atingir “só” 70%…
❖ É melhor acompanhar “demais" do que “de menos”
❖ Ajuda as pessoas a olharem suas metas com bem mais regularidade.
❖ Nem sempre se consegue KRs “de livro texto”, mas um KR razoável é “bem melhor do que não ter nenhum".
Lições aprendidas❖ “O diabo mora nos detalhes”
❖ Escolher a métrica certa parece fácil, mas muitas vezes não é.
❖ A forma de medir o resultado é tão importante como o resultado.
❖ Escrever o KR de forma clara ajuda todo mundo.
❖ Dificilmente você vai acertar de primeira, mas isso não é motivo para você desistir
❖ Parte do desafio é manter o engajamento no médio-longo prazo
❖ Implantar sozinho é difícil, então peça ajuda.
Próximos Passos❖ Com a recente mudança na estrutura organizacional, a ideia é
expandir isso para toda a nova diretoria técnica (e não somente no desenvolvimento) e para os times propriamente ditos.
❖ Com isso, ter objetivos mais estratégicos (envolvendo as outras áreas) e menos operacionais.
❖ Melhorar as métricas de negócio, como suporte ao processo de definição dos Objetivos.
❖ Trabalhar com metas “130%” onde o 100% é o que você acha que consegue, mais os 30% adicionais que são o “stretch goal”.
Dúvidas, Perguntas, Comentários?