Pré-mortem de projetos: roteiro de reunião e exemplo preenchido

Um pré-mortem é uma reunião em que a equipe imagina que um projeto já fracassou e procura explicar o que levou ao resultado. Ele usa a inversão: partir da falha para investigar as condições que poderiam produzi-la antes de executar o plano.

Uma empresa fictícia vai trocar a plataforma de atendimento. A demonstração funcionou, houve treinamento e a data foi comunicada. Falta verificar se os pedidos em andamento conservarão histórico, responsável e próxima ação após a mudança.

Escolha um fracasso que possa ser examinado

A AHRQ descreve o pré-mortem como recurso para antecipar obstáculos à implementação. As causas levantadas são hipóteses que precisam de verificação.

Defina qual resultado indesejado está sendo examinado. Na troca de plataforma, poderia ser perder a continuidade dos pedidos já abertos. Dizer apenas que a mudança foi um desastre deixa espaço para receios que não tratam do mesmo problema.

Combine também o período. Uma interrupção no primeiro dia pede perguntas diferentes de uma dificuldade que aparece após meses de uso. Se ambos importam, faça registros separados para não misturar causas e medidas.

Roteiro sugerido para uma reunião de 45 minutos

Convide quem atende clientes, quem configura o sistema e quem decide sobre a transição. Envie antes o plano e o critério de fracasso. A divisão de tempo a seguir é uma proposta de facilitação para esse caso, não uma duração exigida pela técnica.

Se a discussão revelar que ninguém consegue descrever o percurso de um pedido, interrompa a seleção de riscos e reconstrua esse percurso. Votar numa lista pouco compreendida apenas organiza a dúvida.

Escrever individualmente antes da conversa pode dar espaço a uma observação que não surgiria depois de ouvir a liderança. Para isso funcionar, quem conduz precisa receber dúvidas sem exigir que o participante prove imediatamente toda a hipótese.

Troque receios amplos por mecanismos

“A equipe vai resistir” atribui uma disposição geral às pessoas. Uma formulação mais útil seria: quem recebe um pedido não saberá em qual sistema atualizá-lo porque as regras da transição não foram definidas.

Pergunte que condição conecta a causa proposta ao fracasso. Há uma limitação da ferramenta? Falta uma decisão? O problema depende de um caso excepcional ou pode ocorrer no uso comum? Procure registros, demonstrações e pessoas que ajudem a conferir a relação.

Uma lista longa de riscos não informa sua frequência nem sua gravidade. Diferencie evidência de possibilidade e anote as incertezas. A técnica pode deixar um receio mais visível sem torná-lo mais provável.

Escolha verificações que mudem o plano

A empresa poderia migrar um conjunto de pedidos em aberto e conferir histórico, responsável e próxima ação. Também poderia simular uma mensagem recebida durante a transição e seguir seu percurso até o atendimento.

Cada verificação precisa de alguém responsável e de uma consequência para o plano. Se o histórico essencial não for preservado, a equipe talvez deva adiar a mudança ou manter uma consulta segura ao sistema anterior. O resultado depende do que for encontrado.

Compare o custo dessas medidas com as alternativas. Manter dois sistemas pode preservar acesso e gerar atualizações conflitantes. Como na escolha de ferramentas, acompanhe o processo completo e o esforço necessário para sair de cada opção.

Quadro preenchido para a troca de plataforma

O último risco distingue a presença de dados da capacidade de continuar o trabalho. Um arquivo exportado pode existir e ainda exigir uma busca manual que a operação não consegue sustentar.

Para priorizar, comece por falhas que impedem atender um pedido essencial e que não têm recuperação demonstrada. Depois examine consequências relevantes que possam ser verificadas antes da mudança com pouco esforço. Incômodos reversíveis podem ficar no acompanhamento, com responsável definido. Essa ordem é um critério de trabalho para o exemplo, não uma escala validada de probabilidade.

Ao copiar o quadro para seu projeto, mantenha quatro campos: falha observável; verificação que falta; responsável e prazo; decisão se o teste falhar. O roteiro de investigação pode guardar as observações e separar fatos de interpretações.

Registre o que o exercício não resolveu

Um pré-mortem depende do conhecimento e da disposição de quem participa. Pode deixar problemas de fora, repetir crenças do grupo ou concentrar atenção numa história marcante. Convide alguém a procurar uma explicação diferente para o mesmo resultado.

Depois de corrigir uma fragilidade, examine o que a correção acrescentou. Uma aprovação extra pode reduzir um erro e criar demora. O plano revisado também precisa de responsáveis, limites e condições de acompanhamento.

Ao terminar a reunião, cada item que bloqueia a transição precisa ter uma verificação marcada. Se a resposta não chegar antes da data de mudança, alguém terá de assumir explicitamente a decisão de adiar ou aceitar a exposição restante. Uma lista de receios sem essa consequência não oferece um critério para autorizar a virada.