Ferramentas de gestão ágil de produtos de Roman Pichler

Recentemente, a equipe do Lucidspark teve a oportunidade de trabalhar com Roman Pichler e recriar duas de suas ferramentas mais usadas, o vision board de produtos e o roadmap de produto GO, como modelos do Lucidspark.

Antes de apresentar esses modelos, gostaria de falar um pouco sobre Roman e sua importância para a comunidade Ágil.

Roman Pichler e o Ágil Scrum

No início do Ágil, a comunidade Scrum contava com um pequeno grupo de pessoas comprometidas e entusiasmadas. Foi lá que conheci Roman — éramos membros da mesma comunidade profissional, e às vezes palestrávamos ou organizávamos eventos voltados para o setor. A comunidade Scrum sempre ficava empolgada quando Roman compartilhava suas ideias e visões privilegiadas sobre o gerenciamento de produtos.

Roman foi um dos primeiros praticantes de Scrum na Siemens e, a partir dessa experiência, contribuiu muito para a nossa comunidade. Roman trouxe novas perspectivas para o papel do proprietário do produto do Scrum, uma função com pouco protagonismo na época. É uma função-chave que aproxima os lados comerciais (solicitante) e de entregas do desenvolvimento de produtos. 

A liderança de pensamento de Roman ensinou nossa comunidade a entender melhor os processos, pontos problemáticos e a vida profissional cotidiana do proprietário do produto. Com esse alto nível de entendimento, criamos programas e materiais para essa função crítica do Scrum.

Roman rapidamente criou uma reputação de especialista e líder de pensamento no espaço Ágil. Ele formalizou algumas de suas ferramentas (como o vision board de produtos e o roadmap de produto GO) e compartilhou informações nas comunidades Ágil e de gerenciamento de produtos. Em 2010, toda a comunidade Ágil passou a conhecer Roman quando ele publicou Agile Product Management with Scrum: Creating Products that Customers Love.

O gerenciamento de produtos e o Scrum

Para entender melhor essas contribuições para a comunidade Ágil, é importante observar e conhecer o contexto das mudanças no local de trabalho que praticantes do Ágil, como Roman Pichler, sempre defenderam. 

A essência do Ágil é o desejo de remediar a divisão entre o lado comercial e o lado de entregas das organizações. Resumindo, antes da chegada do Ágil, as empresas priorizavam o gerenciamento da produção em vez dos resultados, com um foco único na eficiência. 

A metáfora de uma corrida de revezamento é um bom exemplo de como o trabalho dos tecnólogos foi gerenciado. Os gerentes focaram nos atletas e debateram problemas como: todos os atletas estavam na pista? Quais atletas estavam à frente, quais estavam fazendo uma corrida em ritmo estável e quais estavam ficando para trás? Como otimizar o desempenho do atleta e melhorar a produção? 

No meio de todas essas gestões, perdemos de vista o objetivo final: ultrapassar a linha de chegada com o bastão. Ou seja, sacrificamos o resultado em favor da produção.

Esse processo de desenvolvimento de produtos sofreu com transferências, documentos formais, revisões e aprovações. Ao tentar se comunicar com tanta precisão, ficou difícil estabelecer um alinhamento entre os principais fatores que orientam o desenvolvimento. 

Qual foi o resultado de todos esses documentos e revisões? Um produto projetado e específico muito distante das pessoas que o construíram, e muitos meses passados antes de conseguir iniciar processos de desenvolvimento de verdade.  

O Manifesto Ágil e seus princípios forneceram uma intervenção bastante necessária para esse processo de desenvolvimento de produtos complexo, e destacaram a importância de:

• Colaborar e satisfazer o cliente 
• Fazer iterações de um produto em plena evolução e funcionamento em vez de obter documentos desnecessariamente exaustivos antes de iniciar
• Funções de desenvolvedor e de negócios trabalhando juntas diariamente
• Lidar com mudanças inevitáveis em vez de avançar de forma intransigente e seguir o plano original 

Uma equipe Ágil liderada por um proprietário do produto sério não precisa de um design inicial completo e um plano de projeto preditivo e documentado. Em vez disso, essas equipes trabalham com uma estrutura iterativa e incremental onde o planejamento e a execução ocorrem em uma série de breves iterações (sprints). 

Nesse modelo, as conversas de planejamento acontecem apenas um dia e pouco antes de iniciar o trabalho, e a presença de um proprietário do produto garante o alinhamento enquanto as equipes participam de checagens verbais frequentes para avaliar a compreensão e obter opiniões sobre como estão implementando o trabalho. Roman e outros colaboradores foram fundamentais na criação dos objetivos de aprendizagem dos primeiros programas de treinamento para proprietários do produto do Scrum. Esses programas ensinaram muito sobre essa nova função.

Inicialmente, era difícil convencer a empresa de que ela precisava de um proprietário do produto, já que pessoas em funções comerciais não estavam acostumadas a se envolver nesse nível. No entanto, devido à influência de profissionais como Roman, a função de proprietário do produto passou a ser bastante valorizada.

Ferramentas visuais para proprietários do produto

Como parte de suas ferramentas para proprietários do produto e gerentes de produtos, Roman criou o vision board de produtos e o roadmap de produto GO. Esses recursos visuais oferecem uma estrutura prática em favor de processos colaborativos e entregas importantes.

O vision board de produtos ou painel de visão de produtos

O vision board de produtos orienta o desenvolvimento inicial dos produtos ao solicitar aos membros da equipe que respondam a perguntas importantes em cinco categorias: visão, grupo-alvo, necessidades, produto e objetivos comerciais.

Visão

• Qual é seu objetivo ao criar o produto?
• Quais mudanças positivas ele apresenta?

Grupo-alvo

• Qual mercado ou segmento de mercado o produto atende?
• Quem são os clientes e usuários-alvo?

Necessidades

• Qual problema o produto soluciona?
• Qual benefício ele oferece?

Produto

• O que é esse produto?
• Qual é o seu diferencial?
• É viável desenvolver o produto?

Objetivos comerciais

• Como o produto vai beneficiar a empresa?
• Quais são os objetivos da empresa?

A cada informação adicionada ao vision board, a visão da equipe em relação ao produto se torna mais clara. Este modelo do Lucidspark incentiva a pesquisa e a iteração, além de enfatizar a importância de desenvolver um entendimento claro do que precisa ser criado, em vez de basear decisões críticas em impulsos momentâneos.

O vision board de produtos também foca no usuário final de cada produto. As perguntas orientadoras do vision board ajudam as equipes a ter empatia com as perguntas, necessidades e expectativas dos usuários. Resumindo: fazer todo o processo de desenvolvimento de um vision board de produtos gera uma compreensão aprofundada do contexto e das metas envolvendo as decisões de desenvolvimento de produtos. 

Roadmap de produto GO

Depois de a equipe desenvolver seu painel de visão de produtos, é hora de elaborar o roadmap de produto GO ("Goal-oriented" ou orientado por metas, em português) de Roman. O roadmap mostra como uma equipe planeja atingir objetivos específicos ao longo de um período de tempo definido, e oferece uma estrutura sólida para o planejamento de projetos de uma equipe. O processo de desenvolver o roadmap de produto GO ajuda a criar responsabilização, definir métricas e estabelecer um cronograma. 

O roadmap de produto GO é feito para a colaboração. Antigamente, as equipes imprimiam o roadmap em um papel grande, colavam-no na parede de uma sala de reunião e trabalhavam juntas para cobrir o roadmap com ideias e notas adesivas. No final da reunião, um colega tirava uma foto do roadmap, digitalizava-o e compartilhava-o com a empresa. 

Com quadros brancos virtuais como o Lucidspark, as equipes podem trabalhar juntas em tempo real em um roadmap compartilhado que oferece todas as notas adesivas digitais e ferramentas de opiniões necessárias para fazer um planejamento colaborativo prático. 

Em vez de focar nos detalhes e vantagens de recursos isolados do produto, o roadmap de produto GO exige que as equipes organizem seu planejamento em torno das principais metas e dos objetivos do produto. Com isso, aumenta a probabilidade de que os planos finais sejam alinhados aos objetivos estratégicos e obtenham o apoio da diretoria.

Adotando a natureza iterativa do Ágil

Ferramentas de gerenciamento de produtos, como o vision board de produtos e o roadmap de produto GO, facilitam a colaboração e a geração de ideias no Ágil. 

Com o Ágil, as equipes começam com um produto mínimo viável e o lançam no mercado. Pense nele como se fosse a evolução do transporte pessoal. Henrik Kniberg, um dos primeiros membros da comunidade Scrum, explicou muito bem esse conceito, sugerindo que um produto mínimo viável para o transporte pessoal poderia ser um skate. Com o tempo, uma equipe Ágil obtém opiniões dos usuários e faz melhorias no skate. Ao aprender com o desenvolvimento das primeiras iterações, a equipe aprimora seu “skate” e ele se torna uma scooter, depois uma moto e, por fim, um carro repleto de funcionalidades. 

O Ágil nos ajuda a gerar ideias com mais confiança para produtos testáveis disponíveis no mercado, em vez de desenvolvê-los por completo e depois lançá-los como produtos finalizados. Essa abordagem iterativa permite melhores ciclos de respostas e opiniões com os usuários. O produto resultante é construído sobre uma base sólida de experiência do usuário no mundo real. 

Embora possa parecer confuso lançar um mero esboço do que uma equipe espera que seu produto seja um dia, o processo de desenvolvimento excepcionalmente ágil resulta em um produto acabado muito melhor no final das contas. 

Graças a inovadores como Roman Pichler, o gerenciamento de produtos e, mais especificamente, o papel do proprietário do produto, agora são fundamentais para o Ágil e o Scrum, principalmente. E as equipes e organizações terão mais benefícios com isso.