A alternativa aos Roadmaps

A seguinte citação do General George Patton sempre me fascinou:

„Não diga às pessoas como fazer as coisas. Diga a elas o que precisa ser feito e elas vão te surpreender com sua criatividade".

Infelizmente, os roadmaps fazem exatamente aquilo contra o que o General alerta

Roadmaps dizem às equipes o que devem fazer e como. Normalmente, isso acontece na forma de listas priorizadas com features ou projetos, dos quais alguém realmente acredita que resolverão o problema (mesmo que o problema muitas vezes ainda não esteja claro ou não tenha sido realmente compreendido).

Se no seu roadmap constar algo como "adicionar PayPal como opção de pagamento adicional", o motivo é porque você acredita que existem clientes que não conseguem pagar com os outros métodos de pagamento? Ou tem algo a ver com pagamentos internacionais? Ou talvez alguém acredite que seria uma desvantagem competitiva não oferecer essa opção?

Já mencionei em vários artigos que considero os Product Roadmaps clássicos como a fonte de muito desperdício (waste) em equipes de produto. O artigo Produtos que fracassaram trata desse tema e em [Verdades desconfortáveis do desenvolvimento de produtos]/de/product-owner/verdades-desconfortaveis-do-desenvolvimento-de-produtos/ "Unangenehme Wahrheiten der Produktentwicklung") aprofundo mais esse conceito.

Como o problema com os roadmaps está ganhando cada vez mais atenção, tenho sido solicitado com mais frequência ultimamente a falar sobre a alternativa aos roadmaps.

Um tema abrangente

Neste artigo, quero tentar fazer isso. É um tema amplo, que também está relacionado com temas como cultura de produto, empoderamento e autonomia. Normalmente preciso de pelo menos uma hora para explicar tudo isso pessoalmente a alguém, mas espero conseguir resumir a essência aqui.

Antes de nos debruçarmos sobre a alternativa aos roadmaps, precisamos ter em mente que os roadmaps foram usados durante tanto tempo porque atendem a duas necessidades muito específicas – e essas necessidades não vão simplesmente desaparecer.

1) A liderança quer garantir que as equipas trabalhem primeiro nos itens com maior valor para a empresa.

2) Como têm uma empresa para gerir, existem situações em que precisam de prazos e compromissos concretos – e com roadmaps conseguem capturar e acompanhar esses compromissos.

Para que uma alternativa aos roadmaps clássicos seja aceite nas empresas, estes dois pontos precisam de ser abordados pelo menos tão bem como até agora.

Os roadmaps têm as suas raízes no antigo modelo centralizado de Command-and-Control. Alguns stakeholders fazem uma reunião – normalmente trimestral – para pensar nas prioridades e projetos das equipas para o próximo trimestre.

Em contraste, no modelo de equipa de produto, as equipas devem descobrir por si mesmas como vão resolver os respetivos problemas de negócio de que devem cuidar.

Mas para isso não basta simplesmente ter bons colaboradores. A equipa precisa do contexto necessário. Os membros da equipa precisam de ter interiorizado para onde exatamente a empresa quer ir, e precisam de ter compreendido o que a sua própria equipa deve contribuir para esse objetivo maior.

Voltando ao General Patton:

Como você talvez já saiba, os militares também trabalham com o conceito de equipes autônomas. Essas equipes (Squads) são mantidas deliberadamente pequenas e são em grande parte autônomas, sempre mantendo os objetivos comuns em vista, mas podendo decidir por si mesmas qual consideram a melhor forma de resolver um determinado problema.

Esses objetivos comuns são o contexto que mencionei anteriormente. "Através de intenções, os objetivos e propósitos superiores são formulados com precisão…Intenções claras levam a atividades direcionadas nas forças armadas. Elas expressam o que o comandante deseja alcançar e por quê, e geram um senso de conexão nas forças armadas. Normalmente são expressas através de possíveis impactos, objetivos e resultados desejados…Intenções realmente bem formuladas podem ser compreendidas pelos subordinados mesmo sem uma grande quantidade de detalhes adicionais."

Empresas de tecnologia têm diversas possibilidades de fornecer esse contexto ou essas intenções. No entanto, defendo dois componentes específicos:

A visão do produto: ela descreve a perspectiva holística das coisas que a organização como um todo está tentando alcançar.

Os objetivos empresariais: eles descrevem os objetivos empresariais específicos e priorizados para cada equipe de produto individual.

Existem alguns sistemas e metodologias para gerenciar esses objetivos empresariais. Meu favorito atualmente é o sistema OKR (Objectives and Key Results).

A ideia em si é bastante simples: diga aos membros da equipe o que devem alcançar e como os resultados serão medidos. Depois deixe a equipe decidir por si mesma qual consideram a melhor forma de resolver os respectivos problemas.

Suponha, por exemplo, que seu produto atualmente leva 30 dias para o processo de onboarding de novos clientes. No entanto, para escalar efetivamente, isso precisa ser reduzido para 3 horas ou menos. Esse seria então um bom exemplo de objetivo para uma ou mais equipes de produto: "Reduzir drasticamente o tempo até o cliente estar ativo." Um dos principais resultados disso poderia ser: "Tempo médio de onboarding inferior a 3 horas."

Embora o conceito de objetivos de equipe pareça bastante simples, existem muitas formas de institucionalizá-lo em equipes de produto e organizações, e pode levar alguns trimestres até a organização desfrutar dos benefícios desse conceito.

Existem algumas descobertas sobre a visão do produto e especialmente sobre a boa aplicação do sistema OKR, que colocarei em foco nos próximos artigos. Enquanto isso, você pode dar uma olhada no material de Christina Wodtke.

Esse contexto é então muito importante – ou seja, a visão do produto e os objetivos da equipe.

No início, destaquei que precisamos considerar os dois principais motivos para os bons e velhos roadmaps. O primeiro deles era o desejo de trabalhar primeiro nos itens com maior valor para a empresa. Esperamos que esteja claro que a gestão cuida dessa necessidade fornecendo os objetivos específicos para a organização e sua priorização. A diferença, porém, é que agora priorizam a importância dos resultados de negócios em vez do valor subjetivo das features.

O segundo motivo era a necessidade de compromissos, que abordamos com o conceito de compromissos com alta integridade . Isso se refere a situações em que realmente precisamos de um compromisso com uma data ou um resultado específico.

Esta abordagem tem algumas vantagens:

Primeiro, as equipes ficam muito mais motivadas quando podem decidir por si mesmas qual consideram a melhor solução para o problema.

Segundo, a equipe não se safa simplesmente entregando uma feature ou projeto desejado; a feature também precisa realmente funcionar (o que é medido pelos Key Results). Se não funcionar, a equipe precisa experimentar uma abordagem diferente para resolver o problema.

Terceiro – independentemente de onde vem a ideia para uma solução – muito frequentemente a primeira abordagem não funciona e, em vez de negar isso, neste modelo existe uma consciência clara sobre esse fato.

Tudo gira mais em torno de Outcome em vez de Output – ou seja, obter um resultado significativo, em vez de apenas cumprir alguma meta.

Frequentemente peço às equipes que olhem para o ano passado e se avaliem com base na taxa de sucesso do seu roadmap, considerando quantos itens realmente corresponderam aos objetivos da empresa. Se você fizer isso e não se orgulhar do que descobrir, espero que considere esta alternativa. Certifique-se de que sua organização de produto tenha uma visão de produto convincente. Certifique-se de que cada equipe de produto tenha objetivos de negócio claramente definidos e priorizados. Certifique-se de que todos os compromissos que precisam ser assumidos sejam compromissos de alta integridade.
E agora empodere suas equipes de produto para que possam decidir por si mesmas quais soluções consideram mais adequadas para determinados problemas de negócio, e veja quantas das suas equipes vão te surpreender com seus resultados.

Este texto é do blog de Marty Cagan e foi traduzido por nós para o alemão.

Product Owner Seminar

=> Participa agora num Product Owner Seminar da Agile Academy.

O Product Backlog

=> Leia mais sobre o Product Backlog no léxico ágil.

O papel do Product Owner

=> Aprenda mais sobre o papel do Product Owner.