Um dos métodos mais utilizados para correlacionar estratégias de negócio com entregas de funcionalidades/produtos novos são as OKRs (Objectives and Key Results). Basicamente, este método parte da premissa que os desenvolvimentos tecnológicos são um meio, não o fim. Tendencialmente esse ponto é esquecido, nos apegamos a soluções e deixamos de lembrar o porquê de estarmos fazendo aquela determinada ação.
No entanto, muitas vezes as OKRs são vistas como metas booleanas para cobrança quase cega da gestão para seus liderados. Mas efetivamente as OKRs são muito mais do que simplesmente uma métrica para olhar no fim do ciclo e verificar se foram batidas ou não, elas contam uma história.
Como não funcionam as OKRs
A construção de OKRs não deve ser baseada em desenvolvimentos que você e seu time querem fazer. Em vários momentos é possível ver squads multi-disciplinares criando seus OKRs baseados em medidas de sucesso de ações que o time quer fazer e, na minha visão, desta maneira ela não vai funcionar bem.
Como disse anteriormente, os desenvolvimentos são o meio, não o fim. "O fim" deve ser a estratégia de negócio que a empresa precisa alcançar, baseando os dados e suas metas no que o negócio precisa, não necessariamente onde o time consegue alcançar com suas entregas.
Abordagens como esta não fomentam a criatividade do time e, em sua grande maioria, orientam o time a criarem "métricas de vaidade" que não geram impacto para o negócio mas medem o resultado de uma entrega específica.
Como funcionam as OKRs
Para que os OKRs funcionem bem eles têm que nascer a partir de uma necessidade de negócio, não só vista pelo gerente de produtos, mas por toda a equipe. Necessidades que precisam de uma conexão com a estratégia de negócio e isso potencializa a necessidade de uma estratégia de negócios bem definida, seja por um P&L (Demonstrativo de Lucros e perdas) claro, uma North Star Metric, ou qualquer direcional advindo da alta liderança da empresa.
Com essa estratégia bem definida, as OKRs de cada um dos times precisam ser baseadas em um breakdown desta estratégia macro, ou seja, a OKR nasce de maneira top down (não entendam pelo lado pejorativo da palavra), pois vem da macro-estratégia da empresa e se quebram até os objetivos e resultados chaves de um squad.
OKRs não são só para o time de Produto
Uma construção clara e orientada de OKRs permite que todas as suas decisões sejam bem orientadas, principalmente quando estamos falando sobre gestão de expectativas de stakeholders e priorização. Porém, as OKRs tendencialmente são tratadas como responsabilidade do time de gestão de produtos digitais, instigando a famosa "síndrome do super-herói".
Esta síndrome nada mais é do que, dada a cobrança feita das OKRs apenas pela liderança de uma das partes do squad (design, engenharia ou produto), a pessoa cobrada toma para si toda responsabilidade sobre aquela meta, fazendo com que faça tudo o que precisar para alcançá-la. Com isso, tendencialmente os profissionais se sobrecarregam ou começam a se sentir líderes de seus pares, gerando uma cultura quase "autoritária" nos squads que participam.
Por isso, é super importante que as OKRs sejam criadas com a participação de todos que compõem o squad e que tenham o senso de responsabilidade sobre elas. Também é importante que a liderança de cada uma das áreas pertencentes a um squad acompanhe junto aos seus liderados os resultados das OKRs, não apenas uma área ou outra. Desta forma, criando a sensação de responsabilidade múltipla sobre as metas e, de novo, fomentando a criatividade para alcançá-las.
Não é sobre alcançar a meta, mas sim sobre ter controle
A partir do momento que há grande responsabilidade múltipla sobre as OKRs e que elas estão bem construídas, o acompanhamento delas no dia a dia é, na minha percepção, o movimento mais importante para o sucesso das OKRs e do squad. Porém, é importante que tratemos as OKRs de maneira não-booleana.
Sempre que a liderança olha as OKRs como "bateu ou não-bateu" seus liderados começam a gerar resultados chaves muito orientadas as entregas que farão durante o semestre, para evitar parecer que "não estão trabalhando" durante o ciclo, inevitavelmente, retornando ao problema que comentei no tópico "Como não funcionam as OKRs".
Com isso, é importante que as métricas observadas como resultados chave sejam muito mais orientadas ao negócio do que ao produto que estão entregando/melhorando. Sabendo disso, é importante que a liderança entenda que, como o time não estará observando uma métrica que é isolada, ou seja, outros times e outros comportamentos podem influenciá-la, é possível que fatores externos movam aquela métrica, por isso, o crucial é entender a história que aquela KR conta no tempo, não apenas "atingimos ou não atingimos?". Desta maneira, com testes A/B ou com comparativos de tempo, é possível verificar o impacto isolado de novos lançamentos de produto sobre aquela métrica e, mesmo que fatores externos influenciem nela e não seja batida, é possível entender que tudo o que estava dentro do planejado foi feito pelo time.
Conclusão
Contudo, são três pontos importantes que temos para o sucesso do dia a dia da utilização das OKRs: a definição dos objetivos e resultados chaves baseados em necessidades de negócio, a responsabilidade de todo o time para a criação, acompanhamento e sucesso delas e o acompanhamento de perto sobre as métricas que estão observando para entender todos os aspectos que podem estar influenciando este número.
Desta maneira, você dá um passo muito importante para um time saudável que busca resultados relevantes para a companhia e não uma esteira de produção de funcionalidades que mede apenas o impacto do que faz.
