Roadmap do Produto – Como construir dar visibilidade

A ideia de que o desenvolvimento ágil descarta o planejamento a longo prazo pode ser o maior mito desde o monstro do lago Ness. A definição de um Roadmap do Produto é tão importante para uma equipe ágil quanto para uma equipe em cascata, pois fornece contexto ao trabalho diário da equipe e responde a mudanças no cenário competitivo.

Mas, ao contrário de uma certa besta aquática escocesa lendária, o Roadmap do Produto Ágil é feito da maneira certa, fácil de encontrar e entender.

Roadmap do Produto

O Roadmap do Produto Ágil é um plano de ação sobre como um produto ou solução evoluirá com o tempo. O Product Owner utiliza o Roadmap para descrever as funcionalidades futuras do produto e quando novos recursos serão lançados.

Quando usado no desenvolvimento ágil de software, um roteiro fornece um contexto crucial para o trabalho diário da equipe e deve responder às mudanças no cenário competitivo.

Várias equipes ágeis podem compartilhar um único roteiro de produto.

Construindo o Roadmap do Produto

Para criar Roadmap do Produto, os proprietários ou Product Owners do produto levam em consideração trajetórias de mercado, proposições de valor e restrições. Uma vez que esses fatores são razoavelmente bem compreendidos, eles são expressos em um Roadmap como iniciativas e cronogramas.

Abaixo está um roteiro muito simples para uma equipe de produtos. As iniciativas são em azul e os cronogramas são indicados pelos marcos em vermelho.

Compartilhando o Roadmap do Produto

Depois que o Roadmap do Produto Ágil é construído, ele precisa ser compartilhado com toda a equipe do produto para que todos entendam a visão almejada pelo produto e a direção almejada.

Em muitas organizações, os proprietários do produto criam seus Roadmaps no PowerPoint e nas planilhas enviando-os posteriormente por e-mail à equipe. Embora bem-intencionada, essa estratégia é falha desde o início.

Cada membro da equipe tem sua própria cópia do Roadma do Produto Ágil e mantém todos atualizados quando o mesmo é alterado.

Então, como o Product Owner pode manter a equipe melhor informada?

A maioria das ferramentas de colaboração criadas para tais situações notificará automaticamente todos os participantes de um projeto, informando que o Roadmap do Produto foi alterado.

Ao adicionar uma nova iniciativa, considere as seguintes perguntas:

• Quais são as prioridades relativas de cada iniciativa?
• Quando pretendemos trabalhar em cada iniciativa?
• Existem datas específicas em que a equipe do projeto precisa chegar?
• Quais dependências o programa possui – interno ou em outras equipes;
• Quais equipes estão trabalhando em cada iniciativa?
• As equipes atuais têm disponibilidade nos horários e capacidade suficiente?
• Podemos manter as atuais equipes ágeis estáveis?
• Se não… Como as equipes serão reorganizadas?
• Estamos respondendo às novas equipes formadas no cronograma do projeto?

Utilizando o Roadmap

É importante vincular o trabalho de sua equipe ao roteiro para que você entenda todo o “contexto” mencionado acima.

Uma maneira comprovada de fazer isso é dividir as iniciativas em épicos no Backlog do produto e depois decompô-las em requisitos e histórias de usuários.

A união de todas essas informações facilita os proprietários de produtos e a equipe de desenvolvimento a tomar decisões de curto prazo que não comprometam o trabalho futuro.

Vejamos um exemplo para ver como isso acontece.

Digamos, por exemplo, que lançamos um amplo recurso de perfil de usuário em nosso site. Se descobrirmos que nossos clientes não se envolvem com o recurso, devemos continuar investindo nele? Talvez talvez não.

Precisamos entender por que o engajamento é baixo antes de tomarmos essa decisão.

Portanto, em vez de avançar, podemos optar por implementar alguns testes A / B, na esperança de obter algumas informações sobre a baixa taxa de engajamento – o que pode nos indicar uma direção que seria muito mais difícil (ou impossível) se simplesmente seguiu em frente adicionando mais sinos e assobios.

A capacidade de dar um passo atrás e pesquisar antes de tomarmos uma decisão crucial é a essência de um roteiro ágil.

Dá à equipe a capacidade de desenvolver recursos à medida que aprendem mais sobre um produto e o mercado.

A evolulção do Roadmap

Os projetos em cascata exigem um enorme investimento inicial.

Como resultado, os membros da equipe se apegam emocionalmente ao roteiro e sacrificam a decisão certa, porque é muito doloroso desfazer o trabalho que eles fizeram – um pecado “humano”, se é que houve algum.

Por seu lado, o desenvolvimento ágil corre em três riscos diferentes:

• A equipe pode perder a confiança na capacidade da liderança de tomar decisões estratégicas se o roteiro for atualizado com muita frequência;
• O produto pode chegar tarde demais ao mercado e perder a demanda reprimida se o roteiro não for atualizado com frequência suficiente;
  
• Esforços de longo prazo podem parecer “grandes e difíceis demais” para iterações mais curtas. A equipe compensa demais ao dividir o trabalho em granularidade fina e acaba se concentrando demais nos resultados a curto prazo.

Para combater a “debulha”, a rigidez e a miopia, mantenha o roteiro uniformemente focado em táticas de curto prazo e objetivos estratégicos de longo prazo. Uma ótima maneira de fazer isso é revisar os roteiros trimestralmente, ajustar conforme necessário e compartilhar.

Isso funciona bem em qualquer organização de qualquer tamanho, mas lembre-se:

Referência

• https://www.atlassian.com/agile/product-management/roadmaps