Já escrevi vários artigos sobre roadmap:

• O que é um roadmap? Nesse artigo explico que o roadmap é uma ferramenta útil para gestores de produto pois com ele é possível planejar e comunicar a visão de futuro que vc tem para o seu produto.
• Como fazer um roadmap? Nesse artigo conto que para fazer um roadmap é preciso saber bem os objetivos estratégicos da empresa, os problemas e necessidades dos clientes e o que dá para fazer. De posse dessas informações é possível criar um bom roadmap.
• Como priorizar um roadmap? Parte 1 e parte 2. Esses dois artigos contém várias técnicas que ajudam o gestor de produtos a definir as prioridades de seu roadmap.
• Roadmap = motivação + métrica. Nesse artigo da série sobre roadmaps, falo sobre o quão importante é ter em seu roadmap não só o que se quer fazer como também a razão pela qual se quer fazer e quais as métricas que mostram que o que se fez está de fato atendendo a razão pela qual se quer fazer esse item.

Desde 2012 temos na Locaweb uma mecânica de revisar o roadmap a cada trimestre. No início de cada trimestre fazemos uma retrospectiva sobre o que foi feito no trimestre anterior, quais itens foram entregues, quais não foram e quais as razões de sucesso ou insucesso.

Esse último artigo sobre motivação + métrica foi escrito em meados de 2014. Ele foi fruto de várias conversas que tivemos na Locaweb sobre ter o roadmap como uma lista de itens a fazer a cada trimestre mas não estar sempre claro a razão de estarmos fazendo cada um daqueles itens planejados. Desde aquela época começamos experimentar fazer nossos roadmaps onde cada item deveria ser composto de 3 sub-itens, o que fazer, por que aquilo tinha que ser feito e qual a métrica que esperávamos mexer ao fazermos aquele item. Contudo, apesar de tentarmos deixar claro a motivação e a métrica de cada item do roadmap, as discusões acabavam girando mais em torno do “o que fazer” do que sobre a motivação e a métrica.

No primeiro semestre de 2015 ouvimos falar de um framework chamado OKR, que significa Objectives and Key Results. Esse framework é usado no Google desde seu início e foi trazido para lá por John Doerr, um funcionário da Intel, empresa onde esse framework foi criado. John Doerr, após sair da Intel, se tornou investidor em negócios de tecnologia tais como Google, Amazon, Intuit e Zynga e acabou levando esse framework para essas empresas. Várias empresas de tecnologia hoje usam OKRs. Mais alguns exemplos são Linkedin, GoPro, Flipboard, Yahoo!, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix e Spotify.

OKR é um framework derivado de uma ténica de gestão chamada de Administração por Objetivos, termo criado por Peter Drucker em seu livro The Practice of Management, de 1954. A Administração por Objetivos consiste num processo que requer a identificação e descrição precisas de objetivos a atingir e prazos para conclusão e monitorização. Tal processo exige que as pessoas envolvidas concordem com o que se pretende atingir no futuro e que todos desempenharão as suas funções em função dos objetivos.

Como funcionam os OKRs?

Existem vários artigos e vídeos que explicam em detalhes como funcionam os OKRs, por isso farei um explicação sucinta. Os OKRs são compostos de duas partes, um objetivo e de 2 a 5 resultados chave (key results) que indicam que o objetivo foi atingido. Por exemplo:

Objetivo: Ter clientes satisfeitos ao ponto de recomendar nossos serviços aos seus amigos
Key Result 1: Manter 80% das notas de pesquisa de satisfação acima de 8 numa escala de 0 a 10.
Key Result 2: Pelo menos 50% das novas vendas devem vir de recomendações de clientes existentes.

O objetivo não precisa necessariamente ter números. Já os key results devem obrigatoriamente ter algum número, ou seja, devem ser alguma métrica e devem dizer onde se está e onde se quer chegar com a métrica, ou seja, qual é a meta que queremos atingir com aquela métrica.

Recomenda-se ter pelo menos 2 key results pois quando há apenas um key result pode haver o chamado “efeito perverso”. Por exemplo, suponha que o objetivo seja aumentar a produtividade do time de atendimento telefônico e que seja definido um único key result que seria o TMA (tempo médio de atendimento) que hoje está em 8 minutos deve cair para 2 minutos. Uma forma de se atingir esse resultado chave é simplesmente o atendente desligar o telefone quando estiver próximo de dar 2 minutos de ligação. Claro que isso seria péssimo para a qualidade do serviço, mas o key result e o objetivo seriam atingidos. Nesse caso, para balancear o “efeito perverso”, é recomendável ter mais um key result que garanta que a satisfação do cliente que estiver sendo atendido não caia.

Implementando OKRs na Locaweb

Após estudarmos OKR por algum tempo, chegamos à conclusão que ele era muito parecido com o que sempre quisemos fazer, nos focarmos mais nas motivações e métricas do que no “o que fazer” propriamente dito. A grande diferença é que nos OKRs o “o que fazer” simplesmente não entra. Ele pode ser discutido quando se define cada objetivo e seus respectivos resultados chave, mas o “o que fazer” não é documentado e, por isso, não vira um compromisso e pode ser mudado. O que importa é o objetivo e os resultados chave que indicam que o objetivo foi atingido.

Para nos ajudar nessa mudança, chamamos o Felipe Castro, da Lean Performance, consultoria especializada em implementação de OKR. Chamamos ele em junho de 2015 e começamos a implementação no 3º trimestre de 2015, com uma série de treinamentos internos sobre OKR, definicão de objetivos, métricas e metas. Em agosto fizemos uma sessão de planejamento “café-com-leite” para definir OKRs para o mês de setembro. Foi apenas um teste para podermos entender um pouco melhor a mecânica do processo de definição de OKR. No final de setembro fizemos nossa primeira sessão de planejamento de um trimestre completo, onde definimos os OKRs do 4º trimestre de 2015 para os times de desenvolvimento e marketing de produtos da Locaweb. Em paralelo, continuamos com o planejamento trimestral de roadmap de produtos baseado em itens a fazer.

Cada time atualizava seus OKRs semanalmente. Além disso, acompanhávamos a evolução do roadmap mensalmente. Vimos ao longo desses acompanhamentos que os itens do roadmap eram as tarefas que habilitavam o atingimento dos objetivos e dos resultados chave, ou seja, havia um acompanhamento duplo para o mesmo trabalho. Ao longo desse acompanhamento surgiu a ideia: que tal abandonarmos o roadmap tradicional, da lista de tarefas a fazer, e focarmos apenas em definir e acompanhar OKRs?

De tarefeiros a gestores de ponteiros

Foi isso o que fizemos no planejamento de 1º trimestre de 2016. O planejamento foi feito totalmente baseado em objetivos e em métricas que queríamos mexer, ou seja, os ponteiros que queríamos gerir. Deixamos de ser meros tarefeiros, meros executores de tarefas, para nos tornarmos gestores de ponteiros. Dado um objetivo e uma métrica que indica que esse objetivo está sendo atingido, decidimos o que vamos fazer. Na reunião de revisão dos OKRs do 1º trimestre de 2016 e de planejamento dos OKRs do 2º trimestre, ninguém sentiu falta da lista de tarefas a fazer do antigo roadmap. Obviamente que durante a retrospectiva cada time comentou um pouco sobre o que fez para tentar mexer os ponteiros, mas o “o que fazer” passou a ser apenas um meio para se atingir um objetivo, e não mais o objetivo em si. E é claro que em cada sessão de planejamento de OKR os times já têm uma noção de “o que vão fazer” para atingir seus objetivos, mas eles têm autonomia para decidir esse “o que fazer” como quiserem.

Lições aprendidas

Temos aprendido algumas valiosas lições nesse quase um ano em que estamos lidando com OKRs. Essas lições aprendidas são relembradas frequentemente para que possamos constantemente melhorar nossas definiçãoes de OKRs:

• Entregas e medições mais frequentes ajudam a atingir objetivos. Se houver entregas e medições apenas mensais, o time só terá duas chances no trimestre para testar sua ideia de como mexer a métrica. Se houver entregas e medições semanais, são 12 oportunidades de avaliar e mudar o rumo se necessário.
   
• Objetivos técnicos podem e devem entrar se necessário. Alguns times de desenvolvimento de produto podem ter optado por colocar em seus roadmaps apenas tarefas que entregam valor para o cliente e preferem não colocar histórias técnicas como “atualizar versão da linguagem de programação” ou “rever arquitetura para torná-la mais escalável”. Esse era o caso da Locaweb. Ao fazermos a transição de roadmap para OKR, surgiu a dúvida se faria sentido definir objetivos técnicos, já que tarefas técnicas não entravam nos roadmaps. Após algumas conversas, todos concordaram que sim, podemos e devemos colocar objetivos mais técnicos em nossos OKRs. Por exemplo, ter infra mais robusta e escalável é um objetivo técnico que pode ter como métricas MTBF, MTTR, SLA, filas, etc.
   
• Objetivos e KRs podem ser modificados ou mesmo cancelados, desde que isso seja combinado. Algumas vezes, ao começar a trabalhar em alguma métrica nova, que nunca se trabalhou antes, pode-se descobrir que mexer aquela métrica é mais difícil ou mais fácil do que inicialmente imaginado. É possível, nesse caso, mudar a meta daquela resultado chave, desde que todas as pessoas interessadas estejam de acordo. Também pode acontecer de um determinado resultado chave ou mesmo de um determinado objetivo ser menos importante do que algo que surge após o planejamento dos OKRs do trimestre. Também não é problema remover o OKR para colocar um novo, desde que todas as pessoas interessadas estejam de acordo.
   
• Cuidado com interdependências. Tarefas que podem influenciar os KRs e que dependem de outros times que tenham outras prioridades ou mesmo de fornecedor externo têm grande risco de atrasar. O ideal é que sejam feitas no início do trimestre, ou mesmo no trimestre anterior. Em caso de interdependência onde um time precisa fazer A para que outro time possa começar a fazer B, pode-se colocar A nos OKRs do primeiro time em um trimestre e o outro time inclui B como OKR no trimestre seguinte.
   
• Cuidado com métricas muito genéricas. Esse é um dos aprendizados mais recentes. Métricas como NPS e TMA (tempo médio de atendimento) são muito genéricas, ou seja, podem ser impactadas por uma quantidade enorme de fatores. Por exemplo, o TMA pode ser influenciado por razões tão distintas quanto o sistema de atendimento é lento, o produto está com uma usabilidade que deixa o cliente confuso, turn-over de funcionários de atendimento muito alto e assim por diante. Nesses casos é recomendável transformar a métrica em objetivo, por exemplo, “queremos baixar o TMA em 3 minutos” e definir KRs específicos como, por exemplo, “diminuir o tempo de carregamento do sistema de 30 segundos para 3 segundos”.
   
• Cuidado com o excesso de otimismo! Quando se começa a trabalhar com OKRs e se começa a definir metas para as métricas, pode acontecer com muita frequência de as pessoas do time subestimarem o esforço necessário para mover o ponteiro. Existe uma tendência natural a setar metas muito otimistas e, na retrospectiva, perceber que mover o ponteiro é mais difícil do que o imaginado inicialmente. Nesses casos, na próxima sessão de planejamento de OKRs, pode acontecer o contrário, ou seja, após ter exagerado no otimismo, o time pode ficar receoso e acaba colocando metas muito tímidas.
   

Concluindo

Como eu disse acima, em nossas reuniões de retrospectiva e planejamento de OKRs na Locaweb, ninguém sentiu falta da lista de tarefas a fazer do antigo roadmap. Durante a retrospectiva cada time comenta um pouco sobre o que fez para tentar mexer os ponteiros, mas o “o que fazer” passou a ser apenas um meio para se atingir um objetivo, e não mais o objetivo em si. E é claro que em cada sessão de planejamento de OKR os times já têm uma noção de “o que vão fazer” para atingir seus objetivos, mas eles têm autonomia para decidir e mudar o “o que fazer” como quiserem, desde que atinjam seus objetivos.

Por esse motivo, está cada vez mais claro para mim que os OKRs são o futuro dos roadmaps. É uma ferramenta que coloca os objetivos e as métricas no centro da discussão, deixando a decisão do que fazer mais fluída e flexível, dando aos times mais autonomia na decisão sobre o que fazer.