Em um OKR (Objective and Key Result) a letra “O” de ‘Objetivo” é a bussola, e as letras “KR” de “Resultado Chave” são o painel de controle do barco.
Garantindo um objetivo plausível e aderente à estratégia e ficando de olho nos resultados chaves combinados para não perder o foco, o jogo fica muito favorável para o sucesso do time.
Medição e Gestão
Não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende e não há sucesso no que não se gerencia.
A citação acima é atribuída a William Edwards Deming, popularmente chamado aqui no Brasil de Deming.
Deming foi um estudioso/consultor/professor que contribuiu muito para a visão de qualidade nas empresas, do ponto de vista de produto, processo e pessoas.
Nascimento do OKR
OKR = Objective and Key Results – em português = Objetivo e Resultados Chave.
Atribui-se a Andy Grove (Intel) a criação do conceito por volta de 1983 ou (a depender da fonte) a John Doerr (Capitalista de Risco – investidor da Netscape, Symantec, Amazon, Google etc.) quando era funcionário da Intel, por volta de 1975.
O fato é que o conceito foi empregado em várias empresas de tecnologia do Vale do Silício e foi se espalhando ao redor do mundo principalmente após os anos 2000 em função dos resultados que sua aplicação tem gerado em empresas como Google, por exemplo.
Finalidade de Uso
OKRs são métricas (há quem diga que não são métricas) para dar direção a um produto e consequentemente ao time que desenvolve/evolui este produto.
Ha partir da aplicação do OKR o time persegue um objetivo, que é desdobrado em metas quantitativas e assim, pilota os trabalhos orientado a isso.
É uma forma muito eficaz de garantir que o time envolvido esteja indo na direção certa e assim foque no valor pretendido pela estratégia do produto e da empresa.
Estrutura de um OKR
Um OKR é estruturado em:
- Objetivo: deve ser um objetivo qualitativo, de curto prazo (a boa prática para isso é focar em trimestre/quartil). Deve ser claro, curto, sem ambiguidade e desafiador. Um OKR deve possuir apenas um objetivo. Ha partir do objetivo é que se derivam os KRs.
- Key Result: um objetivo pode ter um ou mais resultados chave amarrados nele, porém mais de quatro KRs tendencia o time a perder o foco (minha opinião). Devem ser métricas quantitativas. As metas estabelecidas nos KRs, se realizadas, realizam o Objetivo ao qual os KRs estão amarrados.
Onde nascem os OKRs?
As empresas com uma gestão profissional devem ter sua missão e visão claras. Isso geralmente é o que norteia o futuro (curto/médio/longo prazo) da organização.
Ano a ano as empresas constroem planos anuais para definirem como realizarão essa Visão, seguindo com a Missão definida.
Neste momento os OKRs começam a ser decompostos, nascendo para serem planos para atingimento das ambições da organização.
Vejamos o desenho abaixo.
Uma premissa fundamental: os OKRs nascem top-down (“de cima para baixo”), ha partir da estratégia do negócio. Não nascem bottom-up (“de baixo para cima”), emergindo do operacional para então sensibilizar o estratégico.
Concebidos os OKRs do planejamento estratégico, que nortearão a realização da estratégia no ano corrente, deriva-se deles os OKRs trimestrais (planejamento orientado a quartil) e os KRs destes objetivos serão a meta dos times que trabalham no contexto de negócio inerente, materializando os resultados.
A estratégia nasce na camada estratégica da organização com os OKRs anuais. Mas os OKRs trimestrais podem (acho que devem) ser definidos (principalmente os KRs) com o time estratégico/tático/operacional juntos – é uma meta do time todo, que deve estar engajado na busca dos resultados.
Cada KR de objetivos trimestrais será materializado através de ações específicas.
No contexto de projetos digitais estas ações são materializadas através de entregas de software como Histórias de Usuário, por exemplo.
Esta histórias estarão amarradas a suas Features, que realizarão seus Épicos. Veja mais sobre isso aqui.
Importante lembrar que as ações citadas, mesmo no contexto de produtos digitais, também podem ser ações que não demandem desenvolvimento de software, como campanhas publicitárias, atividades operacionais diversas, contratação de fornecedores etc.
Ainda, no que refere-se a desenvolvimento de software, importante lembrar que podemos ter Débitos Técnicos, Refatoração, Provas de Conceito, Hipóteses etc. como ações derivadas de KRs.
Exemplos de OKR
Abaixo temos um exemplo de OKRs da Intel, definido (provavelmente) ao final da década de 1970/início da década de 1980.
Perceba que está muito voltado para entrega, e não para valor.
Como podemos ter OKR para a estratégia (nível estratégico) e times (níveis tático e operacional), na minha opinião não tem problema em termos KR mais orientados a entrega do que a valor.
Mas quando falamos de produtos digitais o ideal é dar foco no valor, e não na entrega (que é caminho natural para ativação de valor para o cliente; passa a ser o meio, e não o fim).
Como garantir que os times estão seguindo a direção certa?
Essa pergunta vale meio milhão de dólares! 🙂
Os times que trabalharão orientados aos OKRs devem, obviamente, produzir coisas que estejam diretamente ligadas aos objetivos e resultados chave ambicionados.
Produzir coisas que não estejam ligadas aos OKRs pode significar duas coisas:
- Os times estão indo na direção errada e não sabem que estão equivocados.
- A direção estabelecida está errada e os times estão pivotando para a direção certa.
Uma forma de mitigar os riscos de desvio é garantindo que todos os itens de trabalho produzidos estejam sistemicamente ligados aos OKRs definidos (usando algum sistema para isso) e sistematicamente ligados (usando disciplina e organização).
Essa rastreabilidade pode ser favorecida garantindo uma estrutura como a de Épicos, Features e Histórias (veja mais sobre isso aqui) onde os Épicos ficam amarrados aos OKRs e as Features derivando deles (e Histórias derivando das Features).
Quem deve governar os OKRs?
Todo OKR deve ter um governante, alguém responsável por mantê-lo vivo, atualizado e relevante.
Tem que ser um “CPF”, não um papel! 😉
Os OKRs geralmente ficam sob a governança de um profissional de produtos como o Gerente de Produtos (Product Manager) ou Business Owner (Dono do Negócio).
Em algumas startups com estruturas mais enxutas o Product Owner (Dono do Produto) fica responsável por isso.
O governante do OKR tem que zelar não apenas pela saúde dos objetivos e resultados chave, mas também pela melhor comunicação das metas, plano etc.
A sugestão é ter muita gestão a vista para isso, colocando os OKRs visíveis na salas, boards etc. para todos envolvidos no produto perceberem a todo momento onde estão, para onde estão indo, e se estão indo bem para onde devem ir.
Uma boa prática é ter ritos em que o governante do OKR possa mostrar a evolução dos números e trocar ideias com o time sobre isso.
Em grupos que rodam Scrum o rito de Sprint Review é um excelente momento para isso.
Como exemplo, a imagem abaixo mostra uma visão de gestão à vista de um OKR.
É isso, espero que o post tenha sido útil, e qualquer dúvida fico à disposição nos comentários! 😉
Abraços!