Leve um protótipo para o refinamento, não uma descrição maior

Vale levar um protótipo para o refinamento em vez de escrever uma descrição maior? Vale, porque o time deixa de discutir a imagem que cada um tem na cabeça e passa a reagir à mesma tela. Dá para montar um protótipo cru antes da reunião, sem escrever código, e ele costuma se pagar nos primeiros dez minutos.

Por que o refinamento se arrasta

Todo PO já viveu isto: a história entra na reunião, alguém lê o texto em voz alta e começam as perguntas. Pode cancelar depois de enviado? E se o cliente não tiver e-mail cadastrado? Quem enxerga esse botão? Meia hora depois a história continua sem estimativa e ganhou mais três dúvidas.

O problema raramente é a complexidade. É que cada pessoa leu a mesma frase e imaginou uma tela diferente. O dev viu um modal, a designer viu uma página inteira, o gestor viu o que um concorrente tem. Ninguém percebe a diferença até uma pergunta escancarar o buraco, e aí a discussão vira briga de palavras.

Aumentar a descrição não resolve. Já vi história com quatro parágrafos de critérios de aceite que mesmo assim gerou susto na sprint review, porque os critérios falavam de comportamento e ninguém tinha olhado o desenho da tela. Texto longo só dá mais espaço para interpretação.

Com um protótipo na tela a pergunta muda. Em vez de perguntar o que você entendeu por cancelar pedido, você pergunta se isso aqui resolve. As pessoas respondem muito melhor a essa segunda pergunta. Elas apontam, reclamam, notam que falta o estado vazio. Reagir é barato. Imaginar é caro.

Um exemplo do dia a dia

Imagine um time que cuida do portal de uma rede de clínicas pequenas. No backlog está a história: paciente pode remarcar a consulta pelo portal. Ela já passou por dois refinamentos e voltou os dois com pendências. Pode remarcar em cima da hora? Perde o horário original? E se o médico não tiver agenda?

Dessa vez a PO reserva quarenta minutos na véspera e monta uma versão descartável da tela de consultas, com botão Remarcar, lista de horários e uma confirmação. Está feia e os dados são inventados. Na reunião ela abre o link e clica. Em cinco minutos o desenvolvedor diz que a lista precisa mostrar só horários realmente livres, senão o paciente escolhe um que depois dá erro. A recepcionista que entrou de convidada conta que remarcação com menos de duas horas sempre vira ligação telefônica, então esse caso pode ficar de fora. A dúvida sobre aviso ao médico aparece como buraco visível: nada na tela avisa ninguém, e todo mundo vê ao mesmo tempo.

A história que tinha consumido duas reuniões foi dividida em duas menores e estimada antes de fechar a hora. Não houve mágica. O time só tinha algo para apontar.

Uma rotina que dá para repetir

Não trate isso como projeto. Trate como hábito que cabe no dia anterior ao refinamento.

• Escolha uma ou duas histórias que têm mais chance de engolir a reunião. O backlog inteiro não.
• Escreva o objetivo em duas frases: quem é o usuário e o que ele quer concluir.
• Descreva a tela principal e a ação principal em linguagem normal para uma ferramenta de prototipagem e deixe ela gerar a primeira versão.
• Clique você mesmo e corrija as três coisas que estiverem erradas. Pare por aí.
• Coloque dados falsos, mas realistas. Nomes, valores e datas parecidos com os reais fazem o time reagir com honestidade.
• Anote as dúvidas que você espera que o protótipo responda. Isso vira a pauta.
• Mande o link para o time uma hora antes, com uma linha: isto é um rascunho, não uma promessa.

Cada história deve levar menos de uma hora. Se passou disso, você está construindo a funcionalidade, e esse é justamente o primeiro erro da lista mais abaixo.

O StarBuild encaixa bem nessa etapa: você descreve a tela num chat e recebe um app rodando com preview ao vivo, então manda um link em vez de um print. Qualquer ferramenta que gere algo clicável serve.

Conduzindo a reunião com o protótipo aberto

Compartilhe a tela, mas não dirija a sessão inteira. Comece percorrendo o caminho feliz uma vez, em silêncio, por uns dois minutos. Depois passe o controle: peça para um dev tentar quebrar. As pessoas acham mais problemas quando é a mão delas no mouse.

Mantenha uma lista visível do que aparece e vá separando em três grupos: ajustar o protótipo, virar nova história ou ficar para depois. O primeiro grupo muitas vezes dá para resolver ali mesmo. É o melhor momento da reunião, quando alguém pergunta e se o total aparecesse aqui, e trinta segundos depois ele aparece.

A estimativa também muda. Com a tela vista, o número deixa de ser chute sobre uma forma desconhecida. O time consegue dizer que esta parte é uma lista que já existe, esta é um formulário novo com validação e esta exige mudança no backend. A distância entre os votos diminui, e aquela rodada de planning poker em que um vota 2 e outro vota 13 fica mais rara. O protótipo não deixa o trabalho menor. Ele mostra a divergência mais cedo, quando ainda é barato resolver.

Protótipo não é promessa. É um jeito de descobrir o que você está prometendo antes de prometer.

Armadilhas comuns

A primeira é o capricho. Como dá para deixar bonito, você gasta três horas em cores e animações, e a reunião vira uma conversa sobre animação. Mantenha cru de propósito. Se um stakeholder comentar a fonte, seu protótipo está polido demais para o que precisa fazer.

A segunda é o stakeholder tratar o protótipo como compromisso. Ele vê uma tela funcionando e conclui que a entrega está quase pronta. Diga em voz alta, logo no começo, que é rascunho, que os dados são falsos e que quase nada do que aparece existe por trás. Se precisar, ponha um aviso visível na própria tela. E repita no fim da reunião.

A terceira é o dev que desconfia de código gerado. A reação é justa e não vale brigar com ela. O protótipo não foi feito para ir para a main. Diga com clareza que é material de conversa e que o time vai construir a versão real do jeito dele, com os padrões dele. Boa parte da resistência some quando fica claro que ninguém está pedindo para herdar aquilo. Se o protótipo se mostrar sólido o bastante para servir de ponto de partida, quem decide é o time, não o PO.

Quando não vale a pena

Pule o protótipo quando a história é uma mudança pequena em algo que já existe e todo mundo conhece. Pule em trabalho puramente de backend, como migração de dados ou ajuste de fila, onde não há nada para clicar. E pule quando o time já está de acordo e o único atraso é a agenda. Protótipo serve para desfazer dúvida. Sem dúvida, é só mais um artefato para cuidar.

Teste na próxima sprint com uma única história, aquela que você já desconfia que vai se arrastar. Cronometre a reunião e compare com a última vez que uma história parecida apareceu.