No capítulo anterior vimos a diferença entre um time que soluciona problemas e um time que implementa soluções. Enquanto um time que resolve problemas precisa ter um profundo entendimento de cada problema que vai resolver, das pessoas que são afetadas por ele, do contexto onde acontece e da motivação das pessoas para terem esse problema resolvido, o time implementador de soluções se foca em implementar aquilo que lhe é pedido, não se importando se o que está sendo implementado serve para algo.
A medição de entrega de resultado desses dois tipos de times costuma ser bem diferente. Por meio da forma como um time reporta seus resultados conseguimos claramente saber que tipo de time é. Algo como “conte-me sobre seus resultados que lhe direi que tipo de time é!”. Enquanto o time implementador de soluções costuma medir sua entrega de resultado baseado na quantidade de funcionalidades entregues, o time solucionador de problemas mede sua entrega de resultado baseado em quão bem os problemas foram resolvidos.
Os times implementadores de soluções são aquelas “fábricas de funcionalidades” que já mencionamos no capítulo anterior, ou seja, cuja principal métrica é a quantidade e a velocidade de entrega de funcionalidades. Como essa é sua principal métrica, esse time passa a ser medido pelas suas entregas. O time disse que ia entregar tal funcionalidade nesse dia, então é isso que a organização espera e será isso que a organização vai cobrar do time.
Essa situação não é tão incomum quanto se imagina. Na Locaweb, antes de implementarmos OKRs, o time de desenvolvimento de produto era primariamente cobrado por assertividade do planejamento. Se o time disse que ia entregar X no dia Y, era isso que era esperado do time, com nenhuma preocupação se X era a coisa certa a fazer e se ia de fato trazer resultado para a empresa ou para os clientes. Ao implementarmos OKRs, conseguimos fazer o time cada vez mais focado em entender e resolver problemas.
Ao me juntar à Lopes, encontrei algo bastante similar. Um time de portal, outro de CRM e outro de app, todos eles com entregas predefinidas até 6 meses para frente, porque foi isso o que foi acordado com a direção da empresa. Inclusive a Lopes tinha contratado duas empresas de consultoria que, ao apresentarem seu relatório de resultados, mostravam a quantidade de funcionalidades entregues como seu principal resultado, porque foi isso que foi demandado delas, entrega de funcionalidades.
É importante notar que uma situação como essa não acontece exclusivamente por responsabilidade do time de desenvolvimento de produto. É também responsabilidade das pessoas que estão fazendo as demandas. Enquanto o time de desenvolvimento de produto deve sempre perguntar qual o problema que está tentando resolver com aquela demanda, as pessoas que fazem as demandas devem sempre contextualizar essas demandas trazendo o problema que motivou a demanda.
Após meus primeiros 30 dias na Lopes já comecei a trabalhar com o time na definição dos OKRs para o próximo trimestre, o que motivou inclusive o RH a também fazer seu planejamento baseado em OKRs. Depois, esses OKRs foram apresentados para toda a liderança da empresa. Foi a forma que encontrei de provocar a mudança de cultura e de mentalidade tanto no time de desenvolvimento de produto quanto em toda a empresa.
A maioria dos OKRs que definimos são focados em resultados de negócio. Aumento de vendas, aumento da taxa de atendimento e assim por diante. É isso o que importa para o negócio. As funcionalidades são um meio, não um fim em si mesmo, mesmo em empresas 100% digitais, como a Conta Azul e a Locaweb, os produtos digitais são um meio para o fim. A Locaweb inclusive deixa isso bem explícito em sua missão de “fazer negócios nascerem e prosperarem por meio da tecnologia”, enquanto a Conta Azul quer “impulsionar o sucesso dos pequenos empreendedores levando às pequenas empresas mais organização, controle e tempo por meio da tecnologia.” Repare que em ambas a tecnologia, o produto digital é um meio para se atingir um fim.
No próximo capítulo vamos ver o valor de mentalidade de ecossistema.
Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros: