Case Módulo: Experiências, Lições Aprendidas e Próximos Passos na implantação de OKRs. Apresentação realizada no Scrum Gathering Rio 2015 (#SGRio2015).

1. 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 Solutions
alberto.caeiro@modulo.com / t: @aacaeirojr

2. Agenda
❖ Contexto
❖ 1a "Iteração"
❖ 2a "Iteração"
❖ Lições Aprendidas
❖ Próximos Passos

3. 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.

4. Contexto e Motivação
❖ Por que começamos a pensar nisso?
❖ Quais as Alternativas?
❖ Por que OKR?

5. 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 Performance
www.leanperformance.com.br

6. 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 Performance
www.leanperformance.com.br

7. 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

8. 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 Performance
www.leanperformance.com.br

9. 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 Performance
www.leanperformance.com.br

10. Contexto - Módulo
❖ Sobre a Módulo
❖ Produto / Plataforma Risk Manager
❖ SICC / CICC (Projeto da Copa do Mundo)

11. 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 dias
Release: 3 meses
Regressão: 2 semanas
….

12. 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.

13. 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.

14. 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.

15. 1a Iteração - Resultados
❖ Os principais objetivos gerais foram atingidos
❖ Mas….
❖ A maioria dos objetivos das áreas não
❖ Por que?

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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".

22. 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.

23. 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”.

24. Dúvidas, Perguntas, Comentários?

25. Alberto A Caeiro Jr
alberto.caeiro@modulo.com / t: @aacaeirojr
Obrigado!