O nome assusta: post-mortem, 'depois da morte'. Na prática, é uma reunião ou documento para entender o que aconteceu depois que um projeto terminou ou algo deu errado. Seu primo mais suave, lessons learned, as lições aprendidas, tem o mesmo objetivo: não repetir os erros nem esquecer os acertos.
O que é um post-mortem
É uma análise estruturada de um evento, geralmente um problema, uma falha ou um projeto concluído. Busca responder o que aconteceu, por que aconteceu e o que fazer diferente da próxima vez.
O termo vem da medicina, da investigação das causas de uma morte, e foi adotado por equipes de tecnologia e gestão de projetos.
Lessons learned: o parente mais leve
Lições aprendidas é a versão que cobre qualquer projeto, inclusive os bem-sucedidos. Além de listar o que deu errado, registra o que funcionou e deve ser repetido.
A diferença prática: post-mortem costuma ser acionado por um incidente; lessons learned faz parte do encerramento normal de um projeto.
- O que funcionou bem e deve ser repetido?
- O que não funcionou?
- O que nos surpreendeu?
- O que faremos diferente na próxima vez?
A regra de ouro: foco no processo, não na pessoa
Um post-mortem eficaz é sem culpa. Se as pessoas temem ser punidas, escondem informações e a análise perde valor. O foco deve estar em falhas de processo, comunicação ou ferramenta, e não em quem errou.
Perguntas como 'por que o sistema permitiu isso?' revelam mais que 'quem fez isso?'.
Como conduzir passo a passo
Reúna os envolvidos logo depois do fim do evento, enquanto os detalhes estão frescos. Monte uma linha do tempo dos fatos, identifique causas e transforme as conclusões em ações.
- Defina um facilitador neutro.
- Reconstrua a linha do tempo com fatos.
- Procure as causas, perguntando 'por quê?' várias vezes.
- Liste ações com responsável e prazo.
- Compartilhe o documento com quem pode se beneficiar.
Exemplo fictício: o site que saiu do ar
Uma loja virtual fictícia ficou duas horas fora do ar durante uma promoção. No post-mortem, a equipe reconstrói os fatos: o tráfego foi maior que o previsto, e ninguém havia testado a capacidade do servidor. A ação definida é criar um teste de carga antes de campanhas. Ninguém é culpado, mas o processo melhora.
O que acontece depois
O erro mais comum é fazer uma excelente análise e nunca executar as ações. Acompanhe os itens definidos em reuniões seguintes e verifique se foram concluídos. Guarde os documentos em um local acessível: o conhecimento registrado evita que novas pessoas repitam os mesmos tropeços.
Erros caros só são caros de verdade quando não ensinam nada. Agende uma conversa de lições aprendidas ao fim do seu próximo projeto, mantenha o foco no processo e transforme cada conclusão em uma ação com dono e prazo.