Apenas com a visão clara do seu produto, com os olhos de seus clientes, é que você conseguirá priorizar as suas histórias e definir seu mínimo produto viável.
As dinâmicas propostas nos capítulos 17 e 18 devem ter permitido que as equipes participantes tenham um bom conjunto de histórias candidatas ao desenvolvimento. Ainda com todos imbuídos de seu papel como membros da equipe de produto, peça que coloquem as notas adesivas com as histórias em ordem de prioridade.
Você já foi apresentado, no Capítulo 5, à técnica do Poker do Planejamento usada na priorização das histórias: lembre-se que o agilista Lasse Ziegler sugere multiplicar por mil o valor de cada carta do Poker e dizer que seu valor passa a ser em dólares. Dessa forma, os membros da equipe “pagarão” mais por histórias que acreditam ter mais valor. Eu gosto de uma variação dessa dinâmica, na qual cada participante recebe cem notas representando 100 dólares e cada um vai “depositando” nas histórias o que acredita que deve e pode gastar, considerando o seu limite de notas. É muito comum, nessa dinâmica, que o dinheiro acabe antes de acabar o número de histórias a serem avaliadas e que, com isso, o dinheiro seja realocado entre as histórias. Os participantes também tendem a convencer os demais a colocar mais dinheiro nas histórias que acreditam ter mais valor e, assim, a discussão sobre o produto fica mais esclarecedora e interessante. Em vários grupos nos quais introduzi essa dinâmica, antes de seu final, os participantes decidiram por cortar ao meio as notas de cem para ficar com notas de cinquenta, facilitando a distribuição do dinheiro depositado nas várias histórias.
Uma dinâmica que funciona bem, especialmente nas oficinas de introdução aos métodos ágeis, é o de comparação direta entre as histórias. Nela, o membro da equipe eleito como Product Owner selecionará qualquer uma das histórias a serem desenvolvidas, fará a sua leitura e a colará no centro de um quadro branco. Em seguida, selecionará uma outra história qualquer, fará sua leitura e perguntará: “Com relação a história lida anteriormente, essa tem maior ou menor valor para o cliente?”. Se a história tiver mais valor, será posicionada acima da anterior, caso contrário, ficará abaixo. O exercício progride com a leitura de todas as histórias e seu posicionamento relativo às demais. Você deve usar notas adesivas de boa qualidade, pois elas serão grudadas e desgrudadas muitas vezes até chegarem na ordem final de priorização.
Terminada essa priorização, agora cada equipe tem a sua primeira versão do Product Backlog para seu produto.
Independente da dinâmica que você usar para priorizar as histórias, o importante é fomentar a discussão e o acordo. Esse processo aumenta a compreensão do produto e já prepara mentalmente os participantes para a criação do quadro de visão do produto, o Product Vision Board proposto por Roman Pichler (Figura 19.1).
Figura 19.1 – O Product Vision Board, traduzido para o português. Obtenha a sua cópia aqui).
Distribua o Product Vision Board (que você convenientemente já baixou de https://goo.gl/CrQfxJ e tem impresso em folhas A3), um para cada uma de suas equipes. Peça que elas preencham o topo do quadro: Modelado para [nome do produto]; modelado por [nome da equipe ou de seus membros], a data e o número da iteração, já que esse quadro poderá ser feito outras vezes na medida em que o produto evolui. Permita que, durante 15 minutos, elas discutam as duas primeiras colunas do quadro: Grupo Alvo e Necessidades. As perguntas colocadas em cada coluna irão ajudá-lo.
Tabela 19.1 – As duas primeiras colunas do Product Vision Board
| Grupo Alvo
Quem são os usuários alvo para seu produto? (usam) Quem são os clientes potenciais? (pagam) |
Que problema você quer resolver? Que objetivo deseja atingir? Como seu produto cria valor para os usuários? Que emoções ele evoca? |
Necessidades Para responder às perguntas dessas duas primeiras colunas (Tabela 19.1), a equipe deve se colocar no lugar dos usuários. O mapa de empatia ou outras técnicas para a definição das personas (os atores que irão interagir com seu produto), deve dar uma boa ideia para as respostas. Note que nem sempre as pessoas que utilizarão seu produto são aquelas que pagarão por ele. Como exemplo, uma das equipes de uma oficina que conduzi para o grupo de desenvolvedores da Arpen de São Paulo (Associação dos Registradores de Pessoas Naturais) desenvolveu um jogo que servia para engajar os consumidores de uma grande produtora de laticínios. A produtora pagaria pelo produto que foi desenvolvido para promover um novo leite fermentado.
As perguntas da coluna Necessidades são bem claras, mas não subvalorize a pergunta “Que emoções ele evoca?”. Se um produto não evocar emoção alguma ele não será utilizado. Pense no produto fictício (ao menos até que alguém o desenvolva) Pega-Totó. Há muitos sentimentos que podem ser evocados ou ampliados pelo produto: o amor que uma pessoa tem por seu pet, a sensação de segurança em saber que vai para um lugar onde o animalzinho será bem acolhido, a satisfação em ter um lugar para passear com ele.
A seguir, pule para as duas últimas colunas (Tabela 19.2) e permita mais 15 minutos para discussões e preenchimento das mesmas.
Tabela 19.2 – As duas últimas colunas do Product Vision Board
 Valor
Quais são seus objetivos de negócio? Qual o valor de seu produto para a sua empresa? (aumentará lucros? diminuirá custos? permitirá a entrada em novos mercados? |  Concorrência
Quem são seus concorrentes? Quais as alternativas para o seu produto? |
Aqui, para responder às perguntas, a equipe deve colocar-se no lugar dos patrocinadores, donos da empresa que irá desenvolver o produto e quer ter algum benefício dele. Chame a atenção para o fato de que as alternativas para o produto podem ser, simplesmente, ferramentas já existentes por meio das quais os usuários podem se organizar sem usar seu produto. O aplicativo Barriga Cheia e Bolso Vazio tem suas funções já em uso em qualquer outra forma de comunicação entre os estudantes universitários, como grupos em redes sociais, por exemplo.
Como em outras ocasiões, as discussões podem gerar novas histórias de usuário ou o aprimoramento de histórias existentes. Caso isso aconteça, as novas histórias devem passar pelo exercício de priorização.
Antes de preencher a coluna do meio, Produto, a equipe desenvolverá a sua declaração de visão, no bom e velho formato da “conquista do elevador”: uma frase que deve servir para convencer um investidor a colocar dinheiro em seu produto, que pode ser dita entre um andar e outro no trajeto do elevador. O formato dessa conquista é o seguinte:
Para [o cliente] que tem [a necessidade], o [produto] é do tipo [categoria] que oferece [o benefício infinitamente desejável]. Ao contrário daquele [outro muito ruim], nosso produto se diferencia [por uma coisa muito boa].
A equipe deve trocar as palavras [entre chaves] pelas suas próprias palavras. Caso o produto tenha mais de um grupo de usuários ou clientes, deve ser escrita uma frase para cada um desses grupos. A frase (ou frases) resultantes irão entrar na Declaração de Visão do Product Vision Board. Permita mais quinze minutos para esse exercício.
A última fase dessa dinâmica é a descoberta do Mínimo Produto Viável, que é feita na coluna Produto. Quais as principais (três a cinco) funcionalidades que você deseja oferecer? O que torna o seu produto único? Permita mais quinze minutos para esse exercício.
O Product Backlog, a lista de histórias priorizadas, já deve apontar, intuitivamente, que as histórias em seu topo são as candidatas a entrar na coluna Produto. Ao limitar a escolha entre três e cinco histórias, porém, a equipe costuma perceber de maneira ainda mais clara o que pode entregar para seus usuários como o mínimo produto viável.
Você pode avançar nessa dinâmica pedindo que a equipe imagine quais são as funcionalidades que antevê entregar em uma próxima versão do produto e na seguinte, criando ao menos um cenário inicial de futuros desenvolvimentos que terá que ser checado frente a contribuição dos usuários que experimentam o mínimo produto viável.
