“Planejamento Estático” é como eu chamo o tradicional processo de planejamento anual. Todos nós sabemos como funciona: há um retreat corporativo no qual o “planejamento estratégico” acontece e as metas da companhia são definidas. Então, nas próximas semanas, as metas são cascateadas pela organização, criando um plano detalhado – e fixo – para o ano para a companhia como um todo.
É comum a previsão de revisar o plano em seis meses, mas a maioria das empresas não o faz, pois levaria tempo demais.
Se os seus times estão trabalhando em iterações (ou sprints) de uma a quatro semanas, “saindo do prédio” para falar com clientes, testando hipóteses e aprendendo o que funciona e o que não funciona, como você pode usar um conjunto estático de metas?
A resposta é: você não pode.
Nassim Taleb, autor do The Black Swan, compara esse modelo com os planejadores centrais do Kremlin, que criavam planos quinquenais acreditando que eles podiam prever o futuro. Tem que haver outro caminho.
No artigo para a MITSloan Management Review “Should You Build Strategy Like You Build Software?”, Keith R. McFarland escreveu (minha tradução): Como a estratégia só pode capturar o melhor pensamento da companhia em um determinado ponto no tempo, ela (assim como um software) precisa ser refinada e melhorada na medida em que as pessoas ganham e distribuem novas experiências e conhecimento. Dada essa realidade, um processo sólido de desenvolvimento de estratégia deveria permitir que uma companhia crie e adapte a estratégia rapidamente e iterativamente… e aloque recursos em ambientes em mutação.
OKR: um framework para Agile Goal Setting
OKR (Objectives and Key Results) é um framework para definição de metas criado pela Intel e adotado por Google, Oracle, Twitter, LinkedIn and Dropbox, entre outros.
Um OKR possui dois componentes: o Objetivo (o que queremos atingir) e um conjunto de Key Results (como sabemos se estamos chegando lá):
Objetivo: Encantar os clientes
Key Results:
- Visitas Recorrentes: média de 3.3 visitas por semana por usuário ativo.
- Alcançar um Net Promoter Score de 90%.
- Tráfego não pago (orgânico) de 80%.
- Engajamento: 75% dos usuários possui um perfil completo.
Em vez de planejamento estático com metas fixas anuais, OKR trabalha em ciclos de definição de metas trimestrais (ou menores), permitindo uma abordagem ágil e iterativa.
Se você quer saber mais sobre OKR, leia o artigo “Como o Silicon Valley define metas: uma introdução à OKR“.
Critérios de sucesso compartilhados
O que é sucesso? Todo o grupo deve responder a esta questão. Como nós, como um grupo, vamos nos considerar bem-sucedidos?
Para alguns, o sucesso pode ser criar a próxima empresa bilionária. Para outros, é deixar sua marca no universo. Pode ser uma grande contribuição técnica ou simplesmente um projeto que os realiza.
De fato, cada projeto, empreendimento ou iniciativa precisa responder a esta pergunta. É crucial para criar o alinhamento necessário.
É por isso que uma das coisas que eu mais gosto em OKR é que ele permite a criação de critérios de sucesso compartilhados. Em um processo muito simples, OKR gera alinhamento sobre o que é esperado e sobre onde queremos ir.
Como OKR complementa Lean e Agile
OKR traz disciplina para o aprendizado validado
Steve Blank escreveu em um de seus artigos (minha tradução):
Use o Business Model Canvas para definir hipóteses, Customer Development para sair do prédio e testar hipóteses e Engenharia Ágil para construir o produto de maneira iterativa e incremental
Mas como você sabe se você está tendo sucesso? O que você considera uma “hipótese validada”? Nós precisamos de claros critérios de sucesso compartilhados para aprendizado validado. Então, eu adicionaria: …e OKR para acompanhar se você está indo na direção certa.
OKR define critérios de sucesso além de features
Projetos ágeis são normalmente avaliados pela velocidade com a qual eles entregam features (com “qualidade”). Mas um time que entrega features e falha em alcançar os resultados de negócio desejados nunca será considerado bem-sucedido.
A coach de OKR Christina Wodtke tem um tweet excelente sobre sucesso: (minha tradução)
Sucesso não é marcar uma caixinha.
Sucesso é ter impacto.
Se você completa todas as tarefas e nada melhora, isso não é sucesso.
De fato, entregar features que não afetam positivamente as métricas selecionadas (os Key Results em OKR) pode gerar resultados negativos. O novo código pode ter bugs, terá que ser mantido e o produto nem será mais complexo.
Marty Cagan tem um post obrigatório sobre o assunto (assim como diversos outros), do qual destaco o trecho abaixo (minha tradução). Se você não leu o livro e o blog dele, você deve.
É por isso que estou tão feliz em ver o retorno dos OKRs. Quando utilizados apropriadamente, eles ajudam a reestruturar a situação de output (features em um roadmap) para outcome (resultados de negócios).
OKR pode ajudar a evoluir o Manifesto Ágil
14 anos depois do Manifesto Ágil, acredito que é hora de evoluir em um dos seus princípios:
Software funcional é a medida primária de progresso.
A medida primária de progresso deve ser resultado de negócios, e não somente software funcional. E OKR é o framework certo para isso.
OKR ajuda a evitar o problema da “temperatura do chuveiro”
Se você ficar rodando a torneira do chuveiro, a água nunca ficará na temperatura que você quer. Você precisa esperar para que a mudança tenha efeito. A mesma coisa acontece com inovação: se você continua pivotando o tempo todo, nunca chegará aonde quer.
O uso de ciclos de metas mais curtos ajuda a evitar esse problema. Claro que coisas darão errado, mas como o ex-VP de Produto da Zynga Jon Tien disse em um vídeo muito bom da Spark Capital sobre OKR:
Problemas acontecem, mas isso não quer dizer que você não deve usar a mesma disciplina.
OKR permite times autogerenciados
Para ter uma organização horizontal, com alto alinhamento e alta autonomia, formada por times autogerenciados, você tem que definir um “norte” para a organização. Você tem que dar para os times um direcionamento claro.
Um conjunto de OKRs para cada time fará exatamente isso.
OKR conecta o time ao negócio e seus clientes
É muito fácil para os times se perderem em tecnicalidades para escrever código ou design. Mas quando você começa a falar de resultados de negócios em um processo bottom-up, você faz com que os membros do time comecem a se perguntar por que eles estão fazendo o que eles estão fazendo.
Se você continua falando sobre entregar features, como você espera que o time pense no usuário? Ou no negócio?
OKR e Scrum
OKR também pode complementar Scrum. Especificamente:
OKR acaba com o problema do “Proxy Owner”
Em algumas empresas, o Product Owner é chamado de “Proxy Owner”, uma vez que ele/ela simplesmente leva e traz a lista de features que foi priorizada pela diretoria. Como podemos dar para ele/ela o mandato para gerenciar o produto? Como podemos ter certeza de que o time tem autonomia?
Se o papel do time é “entregar as features que o cliente/diretoria quer”, isso nunca vai acontecer. A mentalidade tem que ser “o papel do time é alcançar os critérios de sucesso como descritos pelos Key Results e acordados com o cliente/diretoria. Vamos dar autonomia a ele para fazer isto”.
OKR ajuda a priorizar o backlog de produto
Ainda que você deva focar em entregar resultados de negócios, você ainda precisa priorizar o backlog de produto.
Mas como esperamos que o Product Owner faça isso? É esperado que ela/ele use “valor percebido” como o critério, mas isso ainda é subjetivo. OKR pode ser a peça que falta, um framework simples e claro para decidir em quais features trabalhar.
Como Cagan escreveu sobre “product scorecards“, que ele mesmo substituiu por OKRs (minha tradução):
Um dos meus benefícios favoritos é que eles podem usualmente ajudar a eliminar boa parte do seu backlog/roadmap. Se uma feature não afeta diretamente um dos principais KPIs [Key Results] no product scorecard [OKRs], geralmente está fora da lista.
Ficou alguma dúvida, tem alguma sugestão ou contribuição para o texto? Deixe seu comentário.
*Este artigo foi originalmente publicado em Português no blog da Lean Performance.