Modelo de Post-Mortem de Projeto

Formato de retrospectiva post-mortem

Visão geral, objetivos e escopo do projeto

O que o projeto se propôs a fazer, e até quando?

Este tópico define o contexto antes que alguém julgue qualquer coisa. Peça o objetivo original, o escopo acordado, o cronograma e os critérios de sucesso, além do que foi de fato entregue em relação a eles. Em uma revisão de incidente, use-o para a linha do tempo: o que quebrou, quando foi detectado, quem esteve envolvido e como foi resolvido. Mantenha interpretações fora desta coluna e guarde as opiniões para os tópicos seguintes. Se as pessoas discordarem sobre quais eram os objetivos ou os critérios de sucesso, essa discordância é um achado que vale registrar.

O que deu certo

Quais conquistas e processos valem a pena repetir?

Os times passam correndo por este tópico, principalmente depois de um projeto difícil ou de um incidente estressante, então reserve tempo para ele. Você está buscando práticas que valham a pena repetir, não elogios; os reconhecimentos têm um tópico próprio mais adiante. Quando alguém postar um elogio, pergunte o que exatamente fez aquilo funcionar, para que a resposta possa ser reaproveitada. Fique atento a conquistas que vieram de heroísmo individual e aponte-as como riscos.

O que não deu certo

Onde travamos, quebramos ou erramos as metas?

É aqui que está a maior parte do aprendizado, então diga em voz alta a regra de não buscar culpados antes de começar: vocês estão examinando sistemas e decisões, não pessoas. Peça especificidade em vez de reclamações vagas. "A comunicação foi ruim" não gera ação, mas "ficamos sabendo da mudança de prazo numa conversa de corredor" gera. Use a votação para que a discussão não se espalhe por todas as irritações dos últimos três meses.

Análise de causa-raiz

Por que deu errado, e não apenas o que deu errado?

Opcional em uma revisão de projeto tranquila, essencial em um incidente. Pegue os problemas mais votados do tópico anterior e continue perguntando por quê até chegar a uma condição, não a uma pessoa: uma proteção ausente, um responsável indefinido, pressão de prazo, uma premissa que ninguém testou. Os Cinco Porquês funcionam bem aqui, assim como perguntar o que fez a ação errada parecer razoável naquele momento. Pare quando chegar a algo que vocês realmente possam mudar e registre os fatores contribuintes separadamente do gatilho.

Lições aprendidas

Que lições levamos adiante?

Este é o "e daí?" que transforma observações em conhecimento reaproveitável. Insista em cada ideia até que ela nomeie um comportamento, um gatilho ou uma proteção que ainda faça sentido no próximo projeto. Separe o que este time pode mudar sozinho do que precisa ir para um gestor ou outro grupo, e seja honesto sobre a segunda lista. Escreva cada lição de forma que alguém de fora da sala consiga lê-la no relatório exportado e entendê-la sem você ali para explicar.

Ações, responsáveis e prazos

Quem vai fazer o quê, e até quando?

Um post-mortem sem ações atribuídas não conta, então reserve tempo de verdade para isso em vez de espremer nos últimos dois minutos. Transforme as lições mais votadas em um número pequeno de ações específicas, cada uma com um responsável nomeado e um prazo registrados no TeamRetro, para que voltem à pauta na próxima sessão. Duas ou três ações com donos claros valem mais que dez aspiracionais. Se uma ação depende de alguém de fora da sala, combinem quem vai levá-la até essa pessoa e até quando.

Reconhecimento e kudos ao time

Quem merece reconhecimento antes de encerrarmos?

Encerre com as pessoas, não com os problemas. Peça que cada um cite uma pessoa específica e algo específico que ela fez; isso significa muito mais do que um agradecimento genérico e funciona mesmo depois de um projeto difícil. Isso importa ainda mais quando a revisão foi pesada, porque lembra ao time que examinar uma falha não é o mesmo que culpar uns aos outros. Seja rápido, leia alguns em voz alta e deixe o relatório exportado cuidar do resto.

Quando utilizar esta análise retrospectiva

• Um projeto, entrega, migração ou campanha acabou de terminar e você quer uma revisão estruturada, não uma conversa informal que acaba se perdendo
• Um incidente, queda ou release com falha precisa de um post-mortem sem culpados que cubra a linha do tempo, as causas-raiz e as ações preventivas
• Um programa de longa duração concluiu uma fase e você quer registrar as lições aprendidas enquanto os detalhes ainda estão frescos
• Um grupo multifuncional está se desfazendo, e esta é a última chance de fazer um debrief e reconhecer quem contribuiu antes que as pessoas partam para outros trabalhos
• Algo deu inesperadamente certo e você quer entender por quê, para poder repetir em vez de atribuir à sorte

Perguntas sugeridas para quebra-gelo

• Em uma palavra, como foi este projeto ou incidente enquanto você estava no meio dele?
• Se você pudesse mandar uma frase de conselho para você mesmo no primeiro dia, o que ela diria?

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

• Faça a sessão em até uma ou duas semanas após o encerramento do projeto ou a resolução do incidente. A memória se apaga rápido, e os detalhes úteis vão junto
• Declare a regra de não buscar culpados logo no início. Vocês estão olhando para decisões, sistemas e pressões, não procurando alguém para responsabilizar
• Passe alguns minutos alinhando a visão geral do projeto antes das opiniões. Um contexto compartilhado evita que a sessão vire um debate sobre qual era, afinal, o objetivo
• Pule ou encurte a análise de causa-raiz em uma revisão de projeto sem grandes problemas, e dedique mais tempo a ela em incidentes, em que a prevenção é o objetivo
• Priorize com votação e não deixe a reunião terminar sem responsáveis e prazos para as principais ações, senão as lições aprendidas ficam só na teoria
• Traga as ações do post-mortem anterior para a sala e revise-as primeiro. Nada melhora tanto o acompanhamento quanto saber que ele será verificado

Perguntas frequentes