O que é a Retrospectiva Post-Mortem?
A retrospectiva post-mortem é uma análise sem culpados de um incidente, projeto ou release depois que ele termina. O time descobre o que aconteceu, por que aconteceu e o que precisa mudar para que o mesmo problema não volte. Funciona para incidentes e quedas em produção, e também para um prazo perdido ou o encerramento de uma grande iniciativa. O quadro tem quatro colunas. Causas-raiz começa pela linha do tempo: o time organiza o que aconteceu e quando, antes de qualquer análise, para que todos partam dos mesmos fatos. O que deu certo? registra o que ajudou, como alertas que dispararam rápido ou um rollback que funcionou. O que deu errado? trata das lacunas e dos atritos que pioraram a situação. Itens de ação transforma a conversa em correções específicas, com responsável e prazo. No TeamRetro, todos adicionam observações ao mesmo tempo, agrupam as relacionadas, votam nos problemas de maior impacto e atribuem as ações de acompanhamento antes do fim da reunião. Post-mortems sem culpados são prática padrão em engenharia de confiabilidade de sites (SRE) e gestão de incidentes. Quando o time encara uma falha como informação sobre o sistema, e não como culpa de alguém, as pessoas contam o que realmente aconteceu, e é assim que se encontram os pontos fracos de um processo. Guarde o registro e você terá um histórico para consultar da próxima vez que algo parecido quebrar.
Formato de retrospectiva Post-Mortem
Causas-raiz
Como você descreveria a linha do tempo dos eventos?
Comece com um relato factual e compartilhado do incidente ou projeto, antes de qualquer análise. Peça ao time que organize a sequência de eventos em ordem, focando no que aconteceu e quando, e não em quem fez o quê. Alinhar a linha do tempo primeiro evita mal-entendidos e dá a todos o mesmo ponto de partida para encontrar as causas.
O que deu certo?
O que funcionou e nos ajudou a responder bem?
Mesmo um incidente ruim costuma ter coisas que valem a pena manter. Use esta coluna para identificar as ações, ferramentas e decisões que ajudaram, para que o time saiba o que continuar fazendo. Começar pelo que funcionou também alivia um pouco a tensão da conversa que vem depois.
O que deu errado?
Onde as coisas falharam ou ficaram aquém?
Esta coluna trata dos problemas, lacunas e atritos que pioraram o incidente ou o resultado. Mantenha a discussão nos processos e sistemas, não nas pessoas, e lembre o time de que o objetivo é aprender. Procure lacunas que permitiram que várias coisas dessem errado ao mesmo tempo, como falta de monitoramento ou um caminho de escalonamento confuso.
Itens de ação
O que vamos fazer para evitar isso no futuro?
Transforme a discussão em melhorias específicas, cada uma com responsável e prazo. Mantenha-as realistas o bastante para serem concluídas de verdade. Coloque no topo da lista as mudanças com maior chance de evitar que o problema se repita.
Quando utilizar esta análise retrospectiva
- Depois de um incidente ou queda em produção, para entender a causa e evitar que aconteça de novo
- No encerramento de um grande projeto ou release, para registrar as lições enquanto os detalhes ainda estão frescos
- Quando um prazo foi perdido ou uma iniciativa não atingiu o esperado e o time precisa de uma análise honesta
- Quando o mesmo problema continua voltando e você quer encontrar a causa real
- Quando você quer que seus times encarem as falhas como algo com que aprender, e não como motivo para culpar alguém
Perguntas sugeridas para quebra-gelo
- Qual foi o seu momento "ops" mais marcante que acabou virando uma grande lição?
- Se este incidente fosse um filme, qual seria o título?
Quer um exercício de aquecimento que sua equipe faça, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →
Ideias e dicas para sua reunião de retrospectiva
- Deixe claro logo no início que a sessão é sem culpados, para que as pessoas se sintam seguras para contar o que realmente aconteceu
- Monte uma linha do tempo factual e compartilhada antes de qualquer análise
- Use os Cinco Porquês para ir além dos sintomas e chegar à causa de fundo
- Dê a cada item de ação um responsável e um prazo para que ele realmente seja feito
- Convide as pessoas que estiveram envolvidas, mas mantenha o grupo pequeno o bastante para não perder o foco
- Registre o resultado e revise os itens de ação anteriores nas sessões seguintes para confirmar que as correções se mantiveram
Perguntas frequentes
O que é um post-mortem sem culpados?
Quando fazer uma retrospectiva post-mortem?
Quanto tempo dura uma retrospectiva post-mortem?
Qual a diferença entre um post-mortem e uma retrospectiva de sprint?
Quem deve participar de uma retrospectiva post-mortem?
Como evitar que um post-mortem vire uma caça aos culpados?
Modelos relacionados
Converse abertamente sobre o que pesa no seu time e o que ajuda.
Retrospectiva Big Bang Blast
Revisite sua sprint, da primeira faísca às novas galáxias.
Retrospectiva Ada Lovelace
Celebre as vitórias no código e corrija os bugs do seu processo.
Retrospectiva Reddit Rewind
Relembre o ano do seu time em upvotes e downvotes.