Desenvolvimento

3 jul, 2015

Usando OKR para conectar engenharia ágil, customer development e lean startup às metas da empresa

Publicidade

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