Faça um pré-mortem no Jira: encontre riscos da versão antes que aconteçam

Uma versão pode parecer pronta no Jira enquanto a equipe ainda tem preocupações que ninguém registrou. A implementação está quase concluída, os testes estão em andamento e a data de lançamento se aproxima. Alguém suspeita que contas antigas de clientes se comportam de forma diferente. Outra pessoa teme que o suporte explique os novos controles incorretamente.

Um pré-mortem dá a essas preocupações um ponto de partida útil: imagine que o lançamento já deu errado e descreva o que o causou. O exercício facilita discutir falhas plausíveis antes que a equipe esteja ocupada respondendo a elas.

Neste guia, faremos um pré-mortem prático para uma versão fictícia de portal do cliente e organizaremos os resultados no Risk & Pre-Mortem Grid do Power Pack. O resultado é um conjunto curto de riscos com responsáveis claros, sinais de alerta e trabalho de mitigação.

Escolha um resultado específico para a versão

Nossa equipe está adicionando preferências de e-mail a um portal do cliente. Os clientes poderão ativar ou desativar e-mails opcionais da conta e continuar recebendo mensagens essenciais. Maya responde pelo resultado de produto, Leo implementa a alteração, Priya lidera os testes e Sam prepara o suporte.

Eles escolhem o item do Jira que descreve o resultado compartilhado da versão como o lugar para o pré-mortem. Tickets relacionados de implementação e testes continuam vinculados pelo processo normal do Jira. Manter a discussão junto ao item da versão dá às pessoas um lugar óbvio para revisitá-la.

Antes da sessão, Maya escreve uma declaração simples de escopo: revisar a experiência do cliente, o comportamento dos e-mails e a preparação do suporte para a primeira versão dos controles de preferências. A equipe considerará o lançamento e a primeira semana de uso. Esse limite evita que a discussão se torne uma revisão de todos os problemas possíveis do portal.

Imagine uma falha antes de discutir soluções

Comece com uma proposta concreta: “Estamos uma semana após o lançamento. Os clientes estão confusos, as solicitações de suporte aumentaram e tivemos que pausar a disponibilização. O que aconteceu?” O resultado imaginado deve ser desconfortável o suficiente para estimular a reflexão, sem sugerir que a falha é inevitável.

Dê a todos alguns minutos de silêncio para escrever possíveis causas individualmente. Isso permite que uma preocupação dos testes ou uma observação de suporte entre na discussão antes que a primeira explicação confiante domine a conversa. Peça causas que as pessoas consigam descrever, em vez de afirmações gerais como “a qualidade era ruim”.

Depois, compartilhem os cenários em sequência. Nessa primeira rodada, registre a preocupação e esclareça seu significado. Deixe os argumentos sobre a melhor solução para depois. Um participante deve poder levantar uma possibilidade incômoda sem precisar defender imediatamente um plano completo de correção.

• Clientes existentes veem preferências que não correspondem às suas configurações atuais de e-mail.
• A interface sugere que e-mails essenciais podem ser desativados.
• As instruções de suporte descrevem controles que mudaram antes do lançamento.
• A atualização da preferência parece bem-sucedida mesmo quando a alteração subjacente falha.

Esses são cenários fictícios do nosso exemplo. Sua própria lista deve vir das pessoas que entendem o trabalho, as dependências e a experiência do cliente. O Power Pack registra a discussão; a equipe fornece a avaliação sobre o que pode acontecer.

Transforme preocupações em descrições reconhecíveis de risco

Um risco útil descreve um possível evento e sua consequência. “Migração” é um tema. “Os valores existentes de preferências são mapeados incorretamente, então alguns clientes recebem e-mails opcionais que esperavam deixar de receber” é um cenário que as pessoas podem investigar.

Combine duplicatas sem perder consequências distintas. Várias preocupações com contas antigas podem compartilhar uma causa. Um rótulo enganoso e uma falha ao salvar podem confundir clientes, mas exigem verificações diferentes e normalmente devem continuar como riscos separados.

Para cada cenário, pergunte o que a equipe perceberia cedo. Um gatilho de alerta antecipado é um sinal observável que merece atenção. Em nosso exemplo, uma divergência entre as configurações existentes da conta e os valores propostos após a migração é mais útil do que “os clientes podem reclamar”. Ela pode ser verificada antes do lançamento.

Combine o que probabilidade e impacto significam

O Power Pack oferece matrizes 3×3 ou 5×5 e calcula uma pontuação de severidade multiplicando probabilidade por impacto. Use essa pontuação para apoiar a discussão e a ordenação. Ela é uma avaliação subjetiva, não uma previsão da frequência de uma falha nem um cálculo de perda esperada.

Para uma primeira sessão, nossa equipe escolhe 3×3 e combina significados simples para as notas. Probabilidade um significa que atualmente há poucas evidências de apoio; dois significa que o cenário é plausível e precisa de investigação; três significa que há fortes motivos para esperá-lo sem alguma ação. Essas são as definições de trabalho da equipe.

Eles definem o impacto em torno das consequências para o cliente e a versão. Um significa um inconveniente limitado; dois, uma interrupção significativa que exige acompanhamento; e três, um problema sério para o cliente ou um motivo para pausar o lançamento. Outra equipe pode precisar de definições diferentes para seu ambiente.

Priya atribui probabilidade dois e impacto três à migração incorreta, resultando em seis. A equipe discute as suposições por trás da nota: o novo mapeamento ainda não foi ensaiado com contas antigas representativas. A evidência ausente importa mais do que a aparente precisão do número.

Mantenha a mesma escala ao comparar os riscos iniciais. Alternar entre tamanhos de matriz redimensiona as notas existentes, então revise as posições resultantes se mudar a resolução. Uma nova posição não deve ser confundida com evidência recém-descoberta sobre a versão.

Adicione os riscos ao Power Pack

Abra o Power Pack no item escolhido do Jira e selecione Risk & Pre-Mortem Grid. Use o mapa de calor para ver a distribuição das notas e o registro de riscos para revisar as entradas. Você pode adicionar um risco a partir de uma célula da matriz quando já souber sua probabilidade e seu impacto iniciais.

Em cada entrada, registre o título, o cenário de falha, o gatilho de alerta antecipado e a categoria. Adicione as notas combinadas, um plano de mitigação e uma pessoa responsável. O Power Pack também aceita pontos de verificação da mitigação, status e uma referência opcional a um item do Jira.

A pessoa responsável pode ser um usuário do Jira ou um registro de pessoa externa. Escolha alguém que coordene a resposta e traga as evidências ausentes para a equipe. Nomear essa pessoa na matriz não cria uma tarefa no Jira, não atribui uma tarefa existente nem concede acesso ao item.

Revise o estado de salvamento antes de tratar a matriz atualizada como compartilhada. As alterações são armazenadas no item, e um estado local ou de nova tentativa não deve ser interpretado como confirmação de que outro colega já consegue ver a entrada mais recente.

Dê uma resposta prática a cada risco importante

“Testar minuciosamente” é difícil de acompanhar. Para o risco de migração, Priya propõe um ensaio usando estados representativos de contas existentes, seguido de uma comparação das preferências resultantes e do comportamento esperado dos e-mails. Leo investigará qualquer divergência. Priya continua responsável pelo risco e leva o resultado à revisão da versão.

Divida a resposta em pontos de verificação que tornem o progresso visível. A equipe pode selecionar casos representativos, executar o ensaio, revisar divergências e registrar a incerteza restante. Os pontos de verificação ajudam a organizar a resposta, enquanto as evidências reais ficam no trabalho relevante de testes ou entrega.

Se a mitigação precisar de seu próprio ticket no Jira, crie-o e atribua-o pelo fluxo normal; depois, adicione sua chave como referência no risco. Uma referência facilita acompanhar a relação; ela não cria o trabalho automaticamente nem gerencia sua entrega.

Revisite o status quando as evidências mudarem

O Power Pack oferece os status Identified, In Progress, Mitigated e Accepted. Use Identified quando o cenário tiver sido registrado e In Progress quando alguém estiver trabalhando ativamente na resposta. Combine quais evidências a equipe espera antes de descrever um risco como Mitigated.

Accepted pode descrever uma decisão consciente de seguir com uma exposição restante. Por exemplo, Maya pode aceitar uma pequena lacuna na documentação de suporte depois que Sam confirmar uma resposta temporária disponível. Registre o raciocínio e revisite-o se as suposições mudarem. A aceitação deve ser uma decisão compreendida, não uma forma de arrumar a matriz.

Na revisão da versão, pergunte aos responsáveis sobre gatilhos de alerta, resultados de mitigação e incerteza restante. Revise de forma independente qualquer alteração significativa de escopo, nova dependência ou resultado inesperado de teste. Atualize as notas quando as evidências justificarem e explique por que a avaliação mudou.

Você pode exportar a matriz em Markdown ou CSV para uma discussão de planejamento. Indique o item do Jira como o local para consultar o registro atual. Uma exportação compartilhada é um retrato de um momento e pode não refletir a avaliação mais recente da equipe.

Use a sessão para mudar o que acontece depois

Uma matriz preenchida é útil quando influencia a preparação. Para nossa equipe do portal, o pré-mortem leva a um ensaio de migração, uma redação mais clara e uma verificação de que o guia de suporte corresponde à versão candidata. Cada ação trata um cenário específico de falha levantado pelas pessoas que executam o trabalho.

Comece com uma versão, uma conversa breve facilitada e um pequeno conjunto de riscos significativos. Use o Power Pack para manter cenários, responsáveis e respostas visíveis junto ao item do Jira. Depois, traga o registro à próxima conversa sobre a versão, na qual a equipe poderá avaliar o que realmente mudou.