Post-mortem: a retrospectiva de fim de projeto

O que é um post-mortem de projeto

Post-mortem é uma reunião estruturada, feita ao final de um projeto ou depois de um incidente relevante, cujo objetivo é reconstruir o que aconteceu, entender por que aconteceu e registrar os aprendizados por escrito — para que o próximo projeto comece mais inteligente do que o anterior. O nome vem da medicina (a análise feita "depois da morte"), mas aqui ninguém morreu: o "paciente" é o projeto encerrado, e o exame serve para quem continua vivo — o time.

Um bom post-mortem responde a três perguntas em sequência: o que aconteceu de fato (a linha do tempo, sem interpretações), o que sabíamos em cada momento (para julgar decisões pelo contexto da época, não pelo resultado) e quais condições do sistema permitiram os problemas (processo, comunicação, prazos, ferramentas — nunca "fulano errou"). O resultado não é a reunião em si, e sim o documento que sai dela: um registro de lições aprendidas que qualquer pessoa da empresa consegue ler em dez minutos.

O post-mortem não é exclusividade de times de tecnologia. Um time de marketing pode fazer post-mortem do lançamento de campanha que estourou o orçamento; o RH pode fazer do processo seletivo que demorou quatro meses; um time de eventos pode fazer da convenção anual que quase deu errado na véspera. Onde existe projeto com começo, meio e fim, existe matéria-prima para um post-mortem.

Post-mortem não é retro de sprint (e por que você precisa dos dois)

A confusão mais comum é tratar post-mortem e retrospectiva de sprint como sinônimos. São rituais parentes, mas com papéis diferentes — e um não substitui o outro.

A retro de sprint é um ritual de ritmo. Acontece a cada uma ou duas semanas, olha um período curto e recente, e gera ajustes pequenos e rápidos: "vamos combinar o horário da daily", "vamos parar de aceitar tarefa sem critério de aceite". Ela mantém o motor do time regulado enquanto o trabalho acontece. Se a sua retro semanal está tentando resolver problemas de meses, algo está fora do lugar — provavelmente um dos erros clássicos de retrospectiva.

O post-mortem é um ritual de encerramento. Acontece uma vez, quando o projeto termina (ou quando um incidente grave sacode o time), e olha o arco inteiro: da decisão de começar até a entrega final. As perguntas são maiores: por que subestimamos o escopo em três meses? Por que só descobrimos a dependência do jurídico na semana da entrega? Por que a comunicação com o cliente degradou no segundo mês? Esse tipo de causa não aparece — nem se resolve — numa retro de uma hora.

Uma analogia que ajuda: a retro de sprint é a revisão dos 10 mil quilômetros do carro; o post-mortem é a perícia depois que a viagem terminou. Times maduros fazem as duas coisas.

Há ainda um terceiro caso, o post-mortem de incidente: quando algo grave acontece no meio do caminho (o sistema caiu no dia da Black Friday, a gráfica entregou o material errado no dia do evento), vale rodar o mesmo formato sem esperar o projeto acabar. O roteiro é idêntico — muda só o escopo analisado.

A regra de ouro: sem culpados (blameless)

Se você levar uma única coisa deste artigo, que seja esta: post-mortem com caça a culpados não produz aprendizado — produz silêncio.

O raciocínio é simples. Se o time percebe que a reunião existe para descobrir "quem errou", cada pessoa passa a administrar a própria imagem: omite detalhes, suaviza a versão, empurra a responsabilidade para quem não está na sala. A informação mais valiosa — o que realmente aconteceu — desaparece exatamente quando você mais precisa dela. É por isso que a prática consolidada, popularizada por times de engenharia e adotada em qualquer área, é o post-mortem blameless (sem culpados).

Blameless parte de uma premissa: as pessoas agiram de boa-fé, com a informação que tinham naquele momento. A Marina, coordenadora de marketing, aprovou a peça errada? A pergunta não é "por que a Marina não revisou direito", e sim "por que o processo permitia que uma peça fosse ao ar com uma única revisão, feita às 22h de uma sexta-feira". A primeira pergunta encerra a conversa; a segunda revela o sistema.

Isso não significa passar pano para negligência ou má-fé — casos assim se tratam em conversa individual de gestão, nunca num ritual coletivo. Significa reconhecer que, na imensa maioria dos problemas de projeto, a causa está nas condições (prazo irreal, papéis mal definidos, comunicação truncada), não nas pessoas. Punir o indivíduo e manter as condições garante que o erro se repita — com outro nome no crachá.

Na prática, o facilitador abre a reunião declarando a regra em voz alta: "Nesta sala, ninguém é culpado. Vamos entender o sistema, não julgar pessoas." E policia a linguagem durante a conversa: quando alguém diz "o problema foi que o financeiro atrasou a aprovação", reformula para "o que no nosso fluxo fez a aprovação demorar três semanas?". Sem segurança psicológica, o post-mortem vira teatro.

O roteiro do post-mortem em 4 etapas

Reserve de 90 minutos a 2 horas (projetos longos podem pedir uma tarde), chame todos que participaram de verdade do projeto — incluindo áreas de apoio — e escolha um facilitador, idealmente alguém que não seja o dono do projeto. Quem quiser se aprofundar no papel encontra boas práticas em facilitação de cerimônias. O roteiro tem quatro etapas, nesta ordem.

1. Reconstruir a linha do tempo (só fatos)

Antes de qualquer opinião, o grupo monta em conjunto a linha do tempo do projeto: os marcos, as decisões, as viradas. "15/03 — kick-off com escopo X. 02/04 — cliente pediu inclusão do módulo Y. 20/04 — descobrimos que o fornecedor não atenderia o prazo. 10/05 — replanejamento." Vale usar um quadro com post-its em ordem cronológica; no TeamBOX, dá para montar essa linha do tempo num canvas de post-its ao vivo, com o time inteiro adicionando eventos ao mesmo tempo, mesmo remoto.

A regra desta etapa: só fatos, zero interpretação. "O relatório atrasou duas semanas" entra; "o relatório atrasou porque ninguém se importava" não entra (ainda). Um efeito colateral valioso: quase sempre alguém descobre aqui um evento que desconhecia — "espera, o cliente pediu isso em abril? Eu só soube em junho". Esses buracos de informação já são achados por si só.

2. O que sabíamos — e quando

Com a linha do tempo montada, o grupo revisita as decisões-chave perguntando: "com a informação disponível naquele momento, essa decisão fazia sentido?". Essa etapa é o antídoto contra o viés de retrovisor — a tendência de julgar decisões passadas com o conhecimento do presente.

Exemplo: o time de produto decidiu em março não contratar um freelancer de design, porque o cronograma indicava folga. Em maio, o design virou gargalo. Olhando de junho, a decisão parece óbvia e errada; olhando de março, com os dados de março, era razoável. A pergunta certa não é "quem decidiu errado", e sim "que informação nos faltava em março, e como tê-la mais cedo da próxima vez?". Talvez a resposta seja "nosso cronograma não tinha margem para imprevistos" ou "não tínhamos visibilidade da fila do time de design".

É aqui que o post-mortem separa decisão ruim de resultado ruim. Decisões boas podem dar resultado ruim (azar, mudança de contexto) e decisões ruins às vezes dão certo (sorte). O aprendizado está no processo de decidir, não no placar.

3. Buscar as causas sistêmicas

Agora sim: para cada problema relevante da linha do tempo, o grupo cava a causa raiz sistêmica. A técnica mais simples é a dos "5 porquês" — perguntar "por quê?" em cadeia até sair do sintoma e chegar na condição.

Um exemplo fora da TI. Time de RH, projeto de implantação do novo sistema de ponto: o treinamento dos gestores foi mal avaliado. Por quê? Foi feito às pressas na última semana. Por quê? O material só ficou pronto em cima da hora. Por quê? Dependia de telas finais do fornecedor, que chegaram atrasadas. Por quê? O contrato não previa prazo para entrega das telas. Causa sistêmica: nossos contratos com fornecedores não amarram os insumos dos quais nosso cronograma depende. Esse aprendizado serve para todos os próximos projetos — culpar a analista que montou o treinamento não serviria para nenhum.

Sinais de que você chegou numa causa sistêmica de verdade: ela não tem nome de pessoa; ela explicaria o problema mesmo com outro time no lugar; e ela aponta para algo que dá para mudar (um processo, um combinado, um critério, um checklist).

Não colete só problemas: registre também o que funcionou e por quê. O daily de 10 minutos com o cliente evitou retrabalho? Isso vira prática recomendada para o próximo projeto. Repetir acertos de propósito vale tanto quanto evitar erros.

4. Transformar em aprendizados registrados

A última etapa converte a discussão em uma lista curta de aprendizados acionáveis — e é onde a maioria dos post-mortems morre. "Precisamos nos comunicar melhor" não é aprendizado, é desabafo. Aprendizado tem forma: o que faremos diferente + em qual situação + quem garante.

Compare: "melhorar a comunicação com o cliente" versus "todo projeto com cliente externo terá um resumo semanal por escrito de no máximo 10 linhas, enviado às sextas; o gerente do projeto é o responsável". O segundo dá para cobrar; o primeiro, não. Limite a lista a algo entre 5 e 10 itens — post-mortem com 30 aprendizados é post-mortem com nenhum. A mesma lógica que faz ações da retro virarem realidade vale aqui: pouco, claro e com dono.

Como documentar para o próximo projeto começar melhor

O documento é o produto do post-mortem. Se a reunião foi ótima e ninguém escreveu nada, em três meses restará só uma lembrança vaga. Um bom documento de post-mortem tem uma página ou duas, no máximo, com esta estrutura:

• Contexto: o que era o projeto, período, quem participou, qual era o objetivo.
• Resultado: o que foi entregue versus o que foi planejado, em termos objetivos.
• Linha do tempo resumida: os 8 a 15 eventos que contam a história.
• O que funcionou: 3 a 5 acertos, com o porquê de cada um.
• O que não funcionou: os problemas principais e suas causas sistêmicas (não os sintomas).
• Aprendizados: a lista acionável da etapa 4, cada item com responsável.

Três cuidados fazem a diferença entre um documento útil e um enfeite de pasta:

Escreva para quem não estava lá. O leitor do seu post-mortem é o gestor que vai tocar um projeto parecido no ano que vem — talvez de outra área. Evite siglas internas sem explicação e contexto que só o time entende. Um post-mortem do time de engenharia sobre "dependências externas que estouram prazo" pode salvar o time de eventos da mesma armadilha, se estiver legível.

Guarde num lugar único e pesquisável. Post-mortem espalhado por e-mail, drive pessoal e chat é post-mortem perdido. Defina um repositório oficial (uma pasta, uma wiki, um espaço no seu sistema de gestão) com nomenclatura consistente: postmortem-<projeto>-<ano>.

Crie o ritual de releitura. Documento que ninguém relê não muda nada. O hábito que fecha o ciclo é simples: no kick-off de todo projeto novo, alguém traz os post-mortems dos projetos parecidos e o time gasta 20 minutos respondendo "quais desses aprendizados se aplicam aqui?". É esse momento — não a reunião original — que faz o próximo projeto começar melhor. Alguns times vão além e transformam aprendizados recorrentes em checklist de início de projeto: "prazo de insumos amarrado em contrato? margem de imprevisto no cronograma? canal de comunicação com o cliente definido?".

Por fim, conecte os aprendizados à rotina. Se o post-mortem revelou que os problemas se acumulavam em silêncio ao longo do projeto, o remédio pode ser justamente fortalecer os rituais de ritmo — retros mais honestas, perguntas melhores na retrospectiva e conversas 1:1 mais frequentes durante o projeto, não só no fim.

Erros comuns no post-mortem (e como evitar)

• Fazer só quando o projeto fracassa. Post-mortem de projeto bem-sucedido é onde se descobre por que deu certo — e sorte não repetida é acerto desperdiçado. Faça nos dois casos.
• Deixar virar tribunal. Ao primeiro "a culpa foi de...", o facilitador reformula para o sistema. Se a cultura de apontar dedos é forte, comece a reunião relendo a regra blameless em voz alta.
• Pular a linha do tempo e ir direto às opiniões. Sem os fatos ordenados, cada um discute a partir da própria versão da história, e a reunião vira disputa de narrativas.
• Esperar demais para fazer. Três meses depois, ninguém lembra os detalhes. A janela boa é de alguns dias a duas semanas após o encerramento.
• Convidar só o núcleo do time. As causas sistêmicas costumam morar nas fronteiras — com o fornecedor, com o financeiro, com o cliente. Traga as pontas para a sala.
• Gerar um relatório de 15 páginas. Ninguém vai reler. Uma ou duas páginas, com aprendizados acionáveis e donos, valem mais que um dossiê.
• Não reler nunca. Sem o ritual de releitura no kick-off seguinte, o post-mortem vira arquivo morto — e o time paga de novo pelas mesmas lições.