Elaborando a visão e o roadmap do produto: O caminho para o sucesso

Já repararam como a Alice, do livro "Alice no País das Maravilhas", tinha dificuldades em escolher um caminho? Ela perguntou para um gato, mas acabou recebendo uma resposta nada clara: "Depende de onde você quer chegar". E quando Alice disse que não sabia onde queria ir, o gato soltou essa pérola:

"Se você não sabe para onde está indo, qualquer caminho serve!".

Seria melhor que toda essa situação cômica permanecesse no país das maravilhas, mas na verdade este cenário pode acontecer com qualquer time que esteja lançando um produto. Sem uma boa noção de onde ir (visão do produto) e sem um bom mapa de como chegar lá (roadmap do produto) nem o melhor chapeleiro vai poder ajudar.

Um outro dilema ocorre com times preocupados apenas em desenvolver uma hiper, super, ultra tecnologia, mas sem considerar primeiro qual seria a hiper, super, ultra necessidade do cliente. Neste sentindo, vale ressaltar que é mais provável que se alcance o sucesso quando o produto nasce para atender a uma necessidade do mercado, ou do contrário você pode estar tentando vender GPS para gatos. Eles já nasceram sabendo o caminho de casa!

Mas não se preocupem se ficaram agora encucados se estão ou não desenvolvendo o produto certo e de forma certa, pois estamos aqui para ajudar a desenrolar essa história. A visão do produto é como um pin no mapa que mostra o destino final, enquanto o roadmap é o meio de transporte que escolhemos para chegar lá. Seja de bicicleta, de trem ou de foguete, o importante é manter o foco no objetivo e dar prioridade ao usuário.

Então, que tal começarmos falando sobre como elaborar uma boa visão do produto?

Para elaborar uma boa visão precisamos ter alguns pontos chave em mente e expô-los nesse plano. Segue abaixo uma opção:

1. Declarar a necessidade do produto a partir de qual problema ele resolverá;

2. Possuir objetivos futuros claros e mensuráveis que podem ser posteriormente usados em análise de metas e resultados;

3. Ser simples e fácil de entender, nada de floreios desnecessários, garantindo assim a clareza do que está sendo desenvolvido;

4. Deve priorizar o usuário, afinal é para ele que está sendo construída a solução;

5. Manter a flexibilidade, pois a visão não é uma lista de objetivos e requisitos. Além do mais ela pode mudar de acordo com as necessidades do mercado.

O roadmap do produto, como o próprio nome já diz, é um mapa para o produto.

E apesar de serem feitos no início de um projeto, eles também devem ser frequentemente alterados, revisados e atualizados, permitindo sim um desenvolvimento iterativo (ágil), desde o início. Eles geralmente incluem:

1. Um ponto de partida e um ponto de chegada;

2. Metas ou objetivos gerais;

3. Principais marcos (key milestones) ou entregas;

4. Cronogramas e prazos;

5. Visão geral das fases;

6. Informações sobre orçamento e recursos.

E se a dúvida agora é de como apresentar esse roadmap, vale ressaltar que hoje há uma certa discussão sobre como seria o roadmap ideal, com gente se descabelando ao tentar defender o seu próprio reino de copas. Então, nem por isso vão pensando que vamos tomar partido por um modelo específico aqui, pois acima de tudo, e de como este possa parecer eles são na verdade, uma ferramenta vital que indica o desejo e os objetivos a seguir, alinhados com a visão do produto.

Assim, entendemos que independente do formato escolhido para nosso roadmap, o importante é saber se ele realmente atende às necessidades do projeto, mantendo dois dos princípios do ágil como norte: “Indivíduos e interações mais que processos e ferramentas” e “Responder a mudanças mais que seguir um plano”.

Mas como sabemos que em geral somos tão curiosos quanto a Alice, segue abaixo alguns exemplos de Roadmaps e suas aplicabilidades em geral:

• Roadmap orientado à meta: auxilia os stakeholders e outras partes interessadas a entender a visão de produto almejada partindo da ótica de quem lidera o projeto.

• Roadmap orientado ao tema: coloca-se “um objetivo estratégico de alto nível para o produto”, como melhorar a usabilidade, ou concluir mais X% de pedidos mensais.

• Roadmap orientado a features: este visa priorizar a implementação de novas features como o objetivo central da estratégia.

• Roadmap orientado à estratégia: possui informações descritas em termos de alto nível sobe a estratégia do produto e é ideal para ajudar os stakeholders a entender a visão do produto.

• Roadmap orientado ao status: um roadmap simples e sem o peso de informações sobre datas de release por exemplo, mas que permite ao time saber onde se está trabalhando no momento. Geralmente utilizado como roadmap rápido, sem introduzir o nível de esforço com estimativas e recursos.

• Roadmap orientado ao realese: geralmente é usado para apresentações ao cliente, trazendo uma visão estimada de quando aquela feature ou produto será lançado.

Agora que sabemos de tudo isso, a última dica para evitar cair num buraco como a Alice e ir parar num mundo desconhecido, é lembrar que é sábio aplicar o planejamento e os ajustes em qualquer fase do ciclo de vida de desenvolvimento de sistemas, do inglês – SDLC.

Ou seja, na análise, no design, na implementação, e até no suporte/manutenção. Ou pode-se cair no erro de encontrar um coelho dizendo que estamos atrasados.

Planejar reduz as incertezas e o risco de ser atingidos por fatores desconhecidos na fase da construção do roadmap.

Assim, manter um planejamento ativo para cada etapa do projeto também reduz as chances de ser impactados pelas três restrições que mais o afetam, custo, tempo e escopo, o famoso triângulo de ferro, mas isso pode ficar para um próximo artigo.

Enfim, como product owners, nos cabe representar a voz dos nossos clientes e garantir que estão seguindo na direção certa, sem esquecer na verdade que "não importa a cor do gato, desde que ele cace o rato!" E que colaborar e ter acesso a visão e ao roadmap do produto é fundamental para atingir os objetivos de qualquer projeto. Ou vocês preferem ficar perdidos no País das Maravilhas?

Por Por Amaro Filho

Product Owner com grande experiência trabalhando em equipes alocadas em diferentes países, como Índia Brasil e Canadá, trabalhando em ambiente Agile com framework SCRUM e utilizando diferentes tecnologias para gestão. Background em business e segunda formação em tecnologia pela Brigham Young University Idaho. Pai, marido, cozinheiro nas horas livres e rato de academia.