O que é uma retrospectiva pré-mortem?
O pré-mortem é uma sessão de análise de riscos feita no kickoff do projeto, antes de escopo, prazos e orçamento serem fechados. O time imagina um futuro bem específico: daqui a seis meses, o projeto fracassou. Cada pessoa então escreve por que ele fracassou, como se o fracasso já tivesse acontecido. A técnica foi criada pelo psicólogo Gary Klein, que a descreveu em seu artigo de 2007 na Harvard Business Review, "Performing a Project Premortem". Ela se baseia em pesquisas sobre "retrospectiva prospectiva" (prospective hindsight), que mostraram que imaginar que um evento já ocorreu ajuda as pessoas a apontar motivos mais específicos para ele. O segredo está no enquadramento. Pergunte a um time "o que pode dar errado?" e você recebe respostas educadas e genéricas, como "aumento de escopo" ou "problemas de comunicação". Pergunte "por que deu errado?" e as pessoas apontam causas reais: a API do fornecedor que nunca passou por teste de carga, o stakeholder que não foi consultado, o único engenheiro que concentra todo o conhecimento. Tratar o fracasso como fato consumado também torna seguro expressar dúvidas que, em um kickoff otimista, poderiam soar negativas ou desleais. Este template de pré-mortem percorre quatro etapas no TeamRetro. Primeiro, liste os motivos pelos quais o projeto fracassou. Depois, identifique os sinais de alerta, combine as ações de prevenção e termine definindo um responsável e uma data para cada risco principal. Essa última etapa é a mais importante. Um risco sem responsável e sem prazo costuma ser esquecido antes do fim da primeira semana. Use ideias anônimas para que a hierarquia não influencie o que as pessoas escrevem e, em times distribuídos, colete as ideias de forma assíncrona ao longo de um dia e reúna-se apenas para votar e definir os responsáveis.
Formato da retrospectiva pré-mortem
Fracassou. Por quê?
Daqui a seis meses o projeto fracassou. Escreva cada motivo como se já tivesse acontecido.
Esta coluna é o coração do pré-mortem. Descreva bem o cenário: o projeto terminou, fracassou e todo mundo sabe disso. Peça que as pessoas escrevam no passado ("Perdemos o lançamento porque..."), já que esse enquadramento gera causas mais concretas do que especular sobre o que pode dar errado. Mantenha as ideias anônimas para que as vozes mais seniores não ditem o rumo da conversa. Dê de 8 a 10 minutos de escrita em silêncio, incentive um motivo por ideia e depois agrupe as ideias parecidas e vote para encontrar os principais riscos a levar adiante.
Sinais de alerta
O que perceberíamos primeiro se isso começasse a acontecer?
Os sinais de alerta transformam medos vagos em coisas que o time consegue acompanhar. Para cada risco principal da primeira coluna, pergunte qual seria o primeiro sinal observável: uma métrica, um checkpoint perdido, um padrão nas dailies. Insista em sinais específicos e mensuráveis. "A moral cai" é difícil de acompanhar. "Duas sprints seguidas com mais de 30% de itens não concluídos" é fácil de perceber. Esses sinais se tornam os gatilhos que os responsáveis pelos riscos vão monitorar.
Como evitamos isso
O que podemos fazer agora para impedir que isso aconteça?
É aqui que o time passa da preocupação para a ação. Foque apenas nos riscos mais votados, geralmente de três a cinco. Para cada um, pergunte o que o time pode fazer nesta semana ou neste mês para reduzir a probabilidade ou o impacto. Prefira passos pequenos e concretos a grandes mudanças de processo. Se uma ideia de prevenção depender de aprovação ou orçamento, anote a quem é preciso pedir. Mantenha o foco prático; o objetivo é uma lista menor de ações que as pessoas vão de fato executar.
Responsáveis e próximos passos
Quem é responsável por cada risco principal, e até quando?
Esta coluna é a razão de ser da sessão inteira. Cada risco principal precisa de um responsável nomeado e de uma data, senão os medos levantados hoje se perdem antes do fim da primeira semana. O responsável não precisa resolver o risco sozinho; ele cuida de acompanhar os sinais de alerta e garantir que a ação de prevenção aconteça. Registre cada um como uma ação no TeamRetro para que ela siga para as próximas retrospectivas e agende um check-in rápido no primeiro marco para revisar o andamento.
Quando utilizar esta análise retrospectiva
- No kickoff de um novo projeto, lançamento de produto ou grande iniciativa, antes de escopo, prazos e orçamento serem definidos.
- Antes de um marco de alto risco, como uma migração, um go-live ou a assinatura de um contrato, em que uma surpresa de última hora sairia cara.
- Quando o time está otimista demais com um plano e os membros mais calados podem estar guardando dúvidas.
- Ao começar a trabalhar com um novo fornecedor, parceiro ou grupo multifuncional cujas dependências ainda não estão bem compreendidas.
- No início de um novo trimestre ou program increment, para testar o plano a fundo antes de o time se comprometer com ele.
Perguntas sugeridas para quebra-gelo
- Qual foi o plano mais marcante que você viu dar errado, no trabalho ou na vida, e qual foi o primeiro sinal de alerta?
- Se este projeto fosse um filme, qual seria o gênero da versão em que tudo dá errado?
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 o pré-mortem no kickoff do projeto, antes de os compromissos serem fechados. Nunca o faça no meio de uma crise, quando o time precisa resolver problemas e imaginar o fracasso só aumenta a ansiedade.
- Mantenha as ideias anônimas. Se os nomes aparecem, os medos da pessoa mais sênior ditam o rumo da conversa e o resto do time só concorda superficialmente.
- Insista no tempo passado na primeira coluna. "Por que deu errado?" gera riscos mais específicos e realistas do que "O que pode dar errado?", então reformule com delicadeza as ideias que voltarem para o campo das hipóteses.
- Vote para reduzir a lista a três a cinco riscos principais antes de discutir a prevenção. Tentar tratar todas as ideias dispersa o time e nada sai do papel.
- Não encerre a sessão até que cada risco principal tenha um responsável e uma data. Sem isso, os riscos levantados são esquecidos antes do fim da primeira semana.
- Para times distribuídos, trabalhe de forma assíncrona: colete as ideias ao longo de um dia, em diferentes fusos horários, e reúna-se por 30 minutos apenas para agrupar, votar e definir os responsáveis.