Pare de Fazer um Tour pelos Seus Tickets

A demonstração começa em seis minutos. Alguém está procurando uma conta de teste. Outra pessoa está perguntando qual ambiente tem a versão mais recente. A pessoa que vai apresentar abriu o Jira e filtrou por Concluído, que agora parece ser a agenda. São quatorze tickets, três apresentadores diferentes e nenhuma resposta óbvia para a pergunta que um stakeholder está prestes a fazer: "O que nossos usuários podem fazer agora que não podiam fazer antes?"

É assim que uma boa engenharia acaba em uma demonstração ruim. Um desenvolvedor explica uma implementação complicada, clica em uma nova tela e passa para a próxima pessoa. Todos trabalharam duro. Todos são educados. No final, a audiência sabe que as coisas foram concluídas, mas ainda pode estar fazendo o trabalho de descobrir por que alguma delas importa.

Uma preparação melhor começa antes de verificar o compartilhamento de tela. Significa conectar o trabalho concluído a um problema que as pessoas reconhecem, mostrar o que mudou e abrir espaço para uma resposta útil. Um ensaio mais longo da lista de tickets não vai te levar até lá.

Comece com a mudança que alguém pode reconhecer

Um título de ticket faz sentido para as pessoas que passaram duas semanas discutindo-o. Os stakeholders podem não ter esse contexto. "Adicionar endpoint de aprovação em lote" diz a eles o que a equipe construiu. Não explica o dia de quem estava difícil, qual parte agora está diferente ou o que permanece não resolvido.

Imagine uma equipe construindo uma ferramenta de compras para gerentes de departamento. A demonstração antiga abre com um número de ticket, menciona o novo endpoint e mostra uma caixa de seleção. O apresentador aprova três solicitações. Funciona. "Alguma pergunta?" é recebido com o tipo de silêncio que faz as pessoas verificarem se ainda estão no mudo.

O mesmo trabalho poderia ser introduzido de forma diferente: "Um gerente revisando um lote de solicitações de rotina atualmente tem que abrir e aprovar cada uma separadamente. Adicionamos uma maneira de aprovar solicitações elegíveis juntas. Vou mostrar esse caminho, depois o que acontece quando uma solicitação precisa de uma revisão individual. Gostaríamos da sua ajuda verificando se as regras de elegibilidade se encaixam em como vocês realmente trabalham."

Agora os cliques têm um propósito. A audiência pode inspecionar o comportamento em relação a uma situação que entende. Alguém pode apontar que solicitações de um novo fornecedor sempre precisam de uma verificação separada. Essa é uma descoberta útil, mesmo que torne a demonstração menos organizada.

A equipe também deve ser precisa sobre suas evidências. Mostrar uma ação em lote funcionando estabelece que a capacidade existe. Não estabelece quanto tempo os gerentes vão economizar, se eles vão usá-la ou se as aprovações vão melhorar. Essas são coisas para investigar após o uso. "Esperamos que isso reduza etapas repetitivas" é uma explicação honesta de intenção. "Tornamos os gerentes mais produtivos" precisa de evidências que a demonstração sozinha não pode fornecer.

O trabalho técnico merece a mesma clareza

Essa abordagem não deve transformar uma revisão em um concurso de beleza para recursos visíveis. Um sprint gasto melhorando recuperação, segurança ou manutenibilidade pode importar enormemente. Ninguém precisa inventar um novo botão para justificá-lo.

Para uma mudança de recuperação, mostre o cenário de falha, como o sistema agora responde e o que o teste demonstra. Para uma atualização de dependência, explique qual risco ela aborda e como a compatibilidade foi verificada. Conecte o trabalho de engenharia à consequência que ele pretende mudar, usando as evidências disponíveis e sendo claro sobre seus limites.

Prepare-se para uma conversa

Saiba quem está ouvindo. Uma audiência de negócios pode precisar do impacto em um fluxo de trabalho e da decisão que ele permite. Uma audiência técnica pode precisar inspecionar escolhas de implementação e trade-offs. Com ambos na sala, comece com por que a mudança importa, depois forneça a profundidade necessária para examiná-la.

Se você só tem dez minutos, decida qual valor de negócio a audiência mais precisa entender. No exemplo de compras, isso pode significar mostrar o caminho de aprovação em lote e verificar as regras de exceção, em vez de percorrer cada ticket concluído. Escolha o que ajuda as pessoas a tomar uma decisão útil. Mantenha a Meta do Sprint à vista, incluindo onde o resultado fica aquém; uma demonstração mais curta não deve esconder um resultado desconfortável.

Para cada item, a equipe deve ser capaz de explicar o problema, o comportamento alterado e as evidências por trás de suas afirmações. Então pergunte qual resposta seria útil. Você está verificando uma suposição sobre um fluxo de trabalho? Escolhendo entre dois próximos passos? Testando se uma limitação é aceitável? Uma pergunta específica dá às pessoas uma forma de entrar na discussão que "Algum feedback?" raramente oferece.

A preparação prática ainda importa. Confirme o que atende à Definição de Pronto, o que está implantado onde e o que pode realmente ser demonstrado. Configure dados representativos e verifique o caminho que você planeja mostrar. Deixe tempo para as pessoas interromperem. No Scrum, a demonstração é apenas parte da Revisão do Sprint, onde a equipe e os stakeholders inspecionam o resultado e descobrem o que fazer a seguir. Ela deve apoiar essa colaboração, não consumir todo o evento.

Onde o Flow ajuda

As notas de demonstração do Simyl Flow podem ser ajustadas para uma audiência de negócios, técnica ou mista. Além de sugerir itens concluídos dignos de demonstração, suas notas conectam o trabalho ao valor de negócio e fornecem pontos de discussão, perguntas antecipadas de stakeholders e respostas sugeridas. A equipe tem um ponto de partida para explicar por que uma mudança importa e se preparar para a conversa que ela pode provocar. No exemplo de compras, isso poderia significar se preparar para perguntas sobre exceções, com respostas verificadas em relação ao comportamento real.

Quando a agenda fica apertada, as notas também incluem um resumo "Se o tempo for curto, enfatize:", reunindo pontos de valor de negócio dos itens do apresentador. A equipe ainda decide a ordem e as prioridades, verifica o que está pronto para demonstrar e verifica as afirmações. O Flow ajuda a manter a explicação focada; a equipe permanece responsável pelo que diz.

O tempo de preparação se acumula em toda a equipe. Como exemplo ilustrativo, se o Flow economizar quinze minutos de quatro desenvolvedores antes de uma demonstração, isso retorna uma hora-equipe. A um custo carregado assumido de US$ 75 por hora, isso é US$ 75 de capacidade, mais do que o preço mensal de US$ 49 do Growth por equipe. Uma demonstração pode cobrir o mês nessas suposições, e a preparação de demonstração é apenas uma das cerimônias que o Flow suporta. Este é tempo disponível para outro trabalho, não uma economia garantida ou dinheiro removido da folha de pagamento. Pular a preparação também tem um custo: deixa todos na reunião para desembaraçar o que deveria ter sido explicado antes.

A conversa também precisa de algum lugar para ir depois. O Flow pode transformar feedback de demonstração em cards de retrospectiva e ações, ajudando a equipe a levar o aprendizado para seu trabalho de melhoria. O feedback do produto também deve informar as decisões relevantes do Backlog do Produto. Uma solicitação de uma regra de fornecedor ausente e um problema recorrente com ambientes de demonstração precisam de acompanhamentos diferentes, mesmo quando ambos vieram da mesma revisão. Combine quem vai levar cada acompanhamento adiante e quando a equipe vai verificar o que aconteceu.

Antes da próxima demonstração, olhe para o primeiro item que você planeja mostrar. Alguém fora da equipe pode entender quem ele ajuda, o que mudou e o que você ainda precisa aprender? Se não, continue preparando a explicação, não adicionando mais tickets. Dê às pessoas o suficiente para questionar, não apenas o suficiente para aplaudir. Então use o que você ouve para decidir o que acontece a seguir.