Medir o que importa — Considerações sobre o uso de OKRs (intermediário)
OKR é uma metodologia não prescritiva e evolutiva. Normalmente quando começamos a usar OKRs, usamos de forma "errada", começamos com o que temos. Isso não é ruim, OKRs, como Kanban, ficam bons com consistência de uso, são processos de difícil domínio. Só que isso não é uma justificativa de não buscarmos o principal dessa metodologia — O acompanhamento de resultados que fazem a empresa avançar dentro de um timebox (curto).
Output x Outcome (Entrega x Resultado)
Há algum tempo atrás, empresas eram desenvolvidas em contextos de poucas mudanças, modelos de negócio mais estáveis, e com menos possibilidade de disrupção. Nesse período, os processos eram em geral mais prescritivos, focavam na produtividade em contrapartida à eficácia.
Então era comum projetos super longos, metodologias inspiradas na engenharia, metas de "longo prazo" (3 à 5 anos), Balance scorecard, etc. Nesse momento, os direcionamentos em geral eram top-down.
Quando a incerteza virou o padrão, os métodos mudaram. O custo e o tempo para se colocar um negócio no ar diminuiu drasticamente, então os métodos mais prescritivos começaram a falhar (mais). Dois conceitos de mundo ajudam a entender o cenário que vivemos hoje — Mundo VUCA, Mundo BANI. Era o fim de olhar entrega como resultado.
A mudança para a visão de resultados
Resultados sempre foram o principal aspecto em uma empresa, mas por uma visão fabril, ou taylorizada, a gestão por um tempo passou a considerar entregas (de projetos por exemplo) como resultado. A menos que o seu negócio seja entregar projetos, esse tipo de entrega não é um resultado.
Era comum ver lugares onde o engenheiro de software não tinha que pensar, só fazer o que estava especificado pelo analista de negócios. Era mais comum ainda ver que isso não funcionava.
Hoje, em uma visão de empresa (não operacional) não importa o quanto você entrega de projetos, de tarefas, de ações ou o quanto você está ocupado, importa o quanto isso gera de resultados, o quanto ajuda a empresa ir pro caminho que ela deseja (alinhamento com a estratégia).
É nesse contexto que entram os OKRs. Pelo título do livro do John Doerr você pode começar a entender o que ele quer dizer com isso.
Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs
Então, a pergunta que você deve sempre se fazer quando está escrevendo OKRs é "Isso aqui realmente importa pro meu time, empresa, cliente?".
Entregas importam
Quando um método emerge, ele normalmente não mata todas as coisas que existiam antes, ou seja, projetos importam. Projetos são a base do que fazemos, os métodos ajudam a gente a se planejar, estimar, definir custo, alinhamento, gerenciar os riscos no momento certo, etc.
Então quanto mais arriscado, mais gestão de projetos você tem que aplicar. Mais método, mais processo, etc. Imagine construir uma aeronave só aplicando Scrum. Pois é, não dá.
O risco não é algo absoluto, ele depende do contexto. Se eu tenho 1000 reais e quero construir algo que eu acho que custa 800 pra fazer, pode ser que seja considerado muito arriscado. Pessoas sem experiência relevante costumas substimar seus riscos.
Então, a base de qualquer construção que envolva risco (de qualquer natureza) e trabalho em time, necessita de uma visão de projeto.
Nessa dimensão houve uma mudança substancial, a maioria dos projetos podem ser considerados como apostas relacionadas a hipóteses de negócio(a menos que seu resultado seja o projeto). Portanto, a todo tempo você deve considerar o custo-benefício e pode abandonar um projeto. A tendência é que o gerenciamento de risco seja tão ou mais importante que o controle do fluxo.
Trabalha em uma empresa de tecnologia e não sabe métodos de gestão de projetos. Diria pra você correr pra aprender independentemente de seu papel. Sem isso você não tem a base para liderar nenhuma frente pequena.
A estrutura de um ciclo estratégico de curto-prazo — usando OKRs
Depois de passada a primeira fase de uso de OKRs, normalmente uns dois ciclos (6 meses). Passamos a usar melhor o método para medir somente o que importa. Para que isso aconteça, você vai depender da evolução do time ou da organização, do time entender sua missão, suas relações com outros times, com o negócio da empresa, com o produto, etc. Você depende também da construção de uma cultura de métricas e KPIs. Sem uma observabilidade de negócio, não há como medir resultados.
Premissas básicas
- Você tem recursos limitados
Portanto, se você tem que acertar o máximo de apostas em um período limitado de tempo, caso contrário o modelo de negócio falha.
2. Nove mulheres não dão a luz a uma criança em um mês
Temos limitações para paralelizar projetos, não conseguimos "agilizar" frentes simplesmente paralelizando e contratando mais gente. Respeite e gerencie o caminho crítico.
3. Se você quer mais resultados, limite o WIP
Por isso OKRs tem limites de objetivos e KRs. Veja mais em Teoria das restrições e Limite de WIP. Os dois maiores erros de gestão (de jr àsr) são paralelizar coisas e aumentar escopo (escopos grandes).
Como estruturar um processo estratégico de curto prazo
No começo, faça como puder fazer. Veja esse site que há uma diversidade de dicas de como fazer e não fazer.
Aqui, o foco é para times mais maduros que já rodaram pelo menos dois ciclos de OKRs.
- Definir OKRs
Diferente de outros métodos, OKRs não são definidos somente Top-down, ou seja, por uma definição do management da empresa. Normalmente times stream-aligned têm uma dependência maior do management (perdão pelo inglês), mas outros não. A maioria dos times em uma empresa acabam sendo diferentes de stream-aligned.
Há diversas fontes para essa definição. Recomendo as seguintes perguntas para essa construção:
- O que precisamos alcançar para que a empresa avance?
- O que nossos clientes precisam para terem maior valor?
- O que precisamos melhorar para evoluir na nossa missão de time?
- O que nossos parceiros precisam para terem melhores resultados?
Os KRs são resultados geralmente com métricas para alcançar o objetivo. O objetivo é o alvo com a estratégia específica que leva a empresa para um outro patamar. Não colocar projetos em KRs, entregar projetos não são resultados. O impacto do projeto é o resultado.
Não adianta nada construir um site que ninguém usa, não vai ajudar a empresa, pelo contrário vai atrapalhar pois o custo de manutenção da empresa vai aumentar.
Sempre bom citar Ash Maurya:
A vida é muito curta pra construirmos algo que ninguém quer.
2. Definir Entregas Não-Estratégicas
Mas nem tudo que entregamos dentro de um ciclo estratégico se enquadra no framework de OKRs. É normal que tenhamos compromissos, tarefas, e outras coisas que são importantes, mas não estratégicos. Normalmente essas entregas são pequenas, não relacionadas diretamente a um resultado, estão no controle da empresa ou de pessoas — não relacionadas a time, e tem um custo de atraso de médio à alto.
Exemplo, a empresa acha que se não contratar um Principal Software Engineer ela vai travar seu crescimento, ou se ela não formalizar seu Stock Option Plan ela vai perder competitividade de contratação. Nesse caso, a recomendação é criar uma seção no seu planejamento e adicionar as Entregas Não Estratégicas Importantes.
Atenção: Se não tem um custo de atraso médio/alto ou se não é importante pra empresa/time, não adicione. Aqui não é pra colocar tudo que o time tá fazendo. Lembrem que não compartilhamos com a empresa coisas que não importam. Estar ocupado não é sinônimo de eficácia.
3. Definir Projetos ou Milestones Entregues no Ciclo
Times de tecnologia, principalmente de plataforma, têm dificuldade de adicionar o que está fazendo no framework de OKRs. Isso se deve por conta de que o software demora a ser construído, portanto, se começar a ser feito em um ciclo, o seu impacto só vai ser sentido no próximo ou, às vezes, muito depois.
Por conta disso, não usamos somente a visão de OKRs para alinhar o que está sendo feito na empresa, usamos roadmaps, programas, projetos, etc. Não tem problema não ter um objetivo ou KR relacionado à entregas que estão sendo feitas. Problema é se o time, já maduro, continuar ajustando projetos para que eles apareçam como KRs.
Nesses casos, a recomendação é criar uma nova seção e adicionar alguns pontos que serão entregues no ciclo:
- Adicionar projetos;
- Adicionar milestones;
- Adicionar processos, procedimentos, etc.;
Normalmente o impacto destes será sentido em outros ciclos, e provavelmente no futuro o que vai fazer a diferença são os ajustes e iterações que serão feitas em cima das primeiras entregas, por exemplo, as mudanças feitas em um MVP.
Qualquer item acima que tem seu impacto sentido no próprio ciclo, não deve ser adicionado nessa seção. Aqui, apenas os itens que não terão impacto no próprio ciclo ou que não é possível medir o impacto. Existem alguns problemas nessa seção, exploraremos mais abaixo.
Alternativas
- OKR não se enquadra
Não existe bala de prata, nem sempre OKR é a metodologia mais adequada. Nesse caso, uma alternativa é usar um roadmap e um acompanhamento de métricas importantes e goals de médio prazo (6 meses ou mais). Normalmente times de plataforma tendem a usar esse tipo de processo.
2. O timebox de 3 meses é pouco
Muitas vezes a velocidade da empresa começa a baixar (metabolismo de produto lento), nesses casos pode ser importante aumentar o tempo do timebox para 4 ou 6 meses. Mais do que isso, não é recomendado usar OKRs, use um método prescritivo. Você tem sinais desse problema quando muitas ou a maioria das suas apostas não geram impacto no timebox definido (3 meses).
Um algoritmo para ajudar a criação de OKRs — bottom up
Disclaimer: Isso aqui tá errado. Como um método não prescritivo, não deve existir um algoritmo para definição de OKRs. O ideal é entender o porquê da metodologia e aplicar de acordo com o seu contexto/maturidade. Não existe um jeito de fazer OKRs, existem jeitos melhores e piores pro seu contexto.
Problemas comum em times maduros
- Não saber as métricas principais e o direcionamento de time/empresa/clientes
Se o time não conhece suas métricas vai ter muita dificuldade de usar OKRs em médio prazo. O mais importante é entender suas North Star Metrics (métricas relacionadas à sua missão). É responsabilidade do time entender a empresa como da empresa a dar contexto ao time.
2. Ficar usando OKR como se fosse BSC (quebrar entregas e milestones de projetos — ir até o micro — OKR "pessoal")
No início, é até ok colocar um ou outro OKR booleano relacionado à uma entrega de projeto (ex. MVP). Depois de 6 meses rodando dentro de um time, não é. Bom buscar a diferença entre Balance scorecard e OKR.
3. Ter mais projetos do que OKRs e nunca evoluir isso
Se a sua seção de projetos for maior que a de OKRs depois de 6 meses é, provavelmente, por conta da falta de clareza do seu time, das relações do seu time, ou das métricas importantes do seu time. Você deve resolver isso o mais rápido possível. Às vezes você resolve isso deixando claro o quão ruim tá seu processo, gerando incômodo e criando um movimento de mudança. Você não resolve isso continuando a fazer "gambiarra" nos OKRs.
4. Achar que todo time tem que ter uma entrada nos OKRs
Muitos times acham que todo mundo tem que ter uma entrada no OKR. Nem sempre isso é possível e tá tudo bem, é sobre isso. Estar ocupado não é ser eficaz. (Sidenote — muitas vezes isso é o mesmo problema de não entender os pontos fortes de um time remoto maduro).
OKRs são realmente difíceis de aplicar, essas dificuldade não podem ser justificativas de não tentar. No fim, usar OKRs errados é melhor que usar qualquer metodologia que foca em entregas. Desde a década de 70 já está claro os problemas de métodos prescritivos, não espere chegar no centenário da crise do software pra mudar isso.
Minha perspectiva totalmente pessoal é que startups que não trabalham com outcome como metas não sobrevivem mais nesse novo contexto.
