Olá amigos do PTI,
Dando continuidade a série de artigos sobre Agile Think® Business Framework, uma proposta para auxiliar Product Owners, Business Owners, analistas de negócios, gerentes de produtos e afins no design e gestão de produtos.
Relembrando os artigos anteriores:
- Parte 1 – Apresentação geral e histórico do framework
- Parte 2 – Apresentação dos processos envolvidos no planejamento estratégico dos produtos
- Parte 3 – Apresentação dos processos de descoberta do produto utilizando Design Thinking
- Parte 4 – Apresentação dos processos de definição do produto utilizando Design Thinking
- Parte 5 – Apresentação dos processos de desenvolvimento do produto através de técnicas de Inception
- Parte 6 – Agile Think® Business Framework: Uma proposta para o design e gestão de produtos englobando do estratégico ao operacional
Neste artigo, vamos entender os processos para transformar este backlog de produto em um plano de entregas na linha do tempo, através da etapa Planning.
A etapa de Planning é composta por quatro processos:
- Priorização: A priorização do Backlog do Produto é fundamental para garantir que “as coisas certas sejam feitas no momento certo”, garantindo que todo o esforço e custo sejam dispendidos em itens que realmente agreguem valor ao produto. Mas o que seria “agregar valor ao produto”? Alguns itens que devem ser levados em consideração: Garante retorno financeiro? Garante melhoria de processo? Garante facilidade de uso? Garante melhor experiência do usuário? Mitiga ou elimina uma ameaça ou oportunidade de alto impacto para o produto? Garante time-to-market ou restrição de tempo? Resolve um grande problema complexo ou incerteza crítica? Gera dependência para a conclusão de outros itens?
- Estimativa: Uma vez que o Backlog do Produto está priorizado, o time de desenvolvimento deve avaliar o esforço necessário para cada item do Backlog do Produto. Todo o grupo de trabalho deve determinar qual a métrica mais aderente: story points, T-Shirt sizing, horas ideais, APF. Cada técnica tem seus prós e seus contras e você pode entender em maiores detalhes como estas técnicas funcionam nos outros livros dos autores: Gerenciamento Ágil de Projetos, Agile Scrum Master no Gerenciamento Avançado de Projetos e Agile Think® Canvas.
- Definição de Releases: Uma vez que temos um Backlog do Produto priorizado e estimado precisamos definir quantas versões de lançamento faremos na linha do tempo. Para isto algumas perguntas precisam ser respondidas: Qual o objetivo de negócio a ser atingido com a Release? Quais funcionalidades, processos e histórias que farão parte desta Release? Quais as condições de satisfação ou critérios de aceite da Release? Quais as restrições existentes (prazo, custo, processos, pessoas, skills, recursos, disponibilidade, dependência externa)? Segundo Massari (2017), deve haver um equilíbrio entre a tríade Objetivos (definidos no processo OKR da etapa Visão Estratégica), Valor Percebido (definido no processo Problematização da etapa Design Thinking) e Restrições: “Quanto maiores as restrições, menores serão os objetivos atingidos e valores percebidos na linha do tempo. Uma vez que não temos como eliminar todas as restrições, precisamos entender quais conseguimos adequar e otimizar, e trabalhar para diminuí-las ou mesmo elimina-las, garantindo assim o aumento dos outros dois fatores”.
- Definição de Roadmap: Uma vez planejado os Releases do produto, precisamos identificar quantas Sprints serão necessárias para a conclusão dos Releases, desta forma validando nossas premissas e restrições iniciais. Para isto é fundamental conhecer qual a capacidade produtiva do time de projetopor Sprint, determinar a duração das Sprints (entre 1 a 4 semanas). O Roadmap do produto lista as funcionalidades/processos na linha do tempo alocadas em Sprints. Ao tornar o Roadmap do projeto visual e transparente a todos os envolvidos as estimativas de término dos releases é possível revisitar priorizações, estimativas, trade-offs e restrições.
Conclusões Finais
O conceito do Agile Think® Business Framework foi concebido para ser uma alternativa estruturada para as empresas planejarem seus produtos de forma enxuta e colaborativa, entendendo as necessidades e expectativas de seus clientes-alvo e, principalmente, conectando o produto diretamente com os objetivos estratégicos da empresa.
O framework é baseado em relações de causa e efeito entre todos os seus processos, onde estabelecemos uma trilha lógica, e com rastreabilidade, desde a benefício gerado para a empresa até o planejamento operacional de releases/cronogramas.
Embora o termo feature tenha sido usado algumas vezes neste framework, ele não se destina apenas a produtos de Tecnologia de Informação, mas também a produtos físicos, plataformas, processos e serviços, onde pode-se considerar características, processos e fluxo ao invés de features.
O propósito do framework é realizar o planejamento robusto de grandes soluções complexas em, no máximo, duas semanas e evitando o desperdício de longas reuniões realizadas em meses e hand-offs desnecessários de comunicação.
Também foi utilizado o termo “representante do cliente” para identificar o papel responsável por prover as informações necessárias que irão trafegar no framework. O papel responsável por ser o “representante do cliente” atualmente vem sendo denominado como Product Owner. O Product Owner deve enxergar a estrutura analítica do produto (PBS) e priorizá-la muito bem. No entanto, para formar Product Owners e levá-los a entender como chegar à melhor priorização e às estruturas analíticas de produto confiáveis, cerimônias importantes não devem ser negligenciadas. A formação do Product Owner passa por ele descobrir, conceber, explorar e priorizar produtos. Um produto é gerado durante a execução desse processo, permitindo ao Product Owner planejar aquilo que realmente faz sentido para stakeholders, times e ao negócio.
Para maior aprofundamento do framework, recomenda-se a leitura do livro Gestão Ágil de Produtos com Agile Think® Business Framework dos autores André Vidal e Vitor Massari, disponível pela Editora Brasport.
Forte abraço e até o próximo artigo! 😉
