Faça um pré-mortem de projeto

Autor: AILesson7 min de configuraçãoTestado com:ChatGPTRevisado em: 2026-08-28

Resposta rápida

Imagine um resultado fracassado para revelar causas plausíveis, sinais fracos, testes e ações preventivas. Forneça: Projeto e data do fracasso, Evidências e suposições, Participantes e autoridade para agir. Resultado esperado: Um mapa priorizado de cenários de fracasso, com evidências, indicadores, responsáveis e experimentos imediatos.

1

Adicione seu contexto

Seu texto permanece neste navegador. O AILesson Prompts não o envia para um modelo ou servidor.

2

Seu prompt

Campos não preenchidos permanecem visíveis como marcadores de posição, para que você ainda possa copiar e editar o prompt

Faça um pré-mortem de projeto usando o contexto fornecido.

Projeto, pessoas usuárias, plano, meta e definição concreta de fracasso:
[project]

Restrições, dependências, incidentes, estimativas, divergências e aspectos desconhecidos:
[assumptions]

Perspectivas das pessoas participantes, autoridade, capacidade de mitigação e momento da revisão:
[participants]

Suponha que o projeto fracassou no ponto futuro indicado e, em seguida, gere explicações distintas e plausíveis sobre valor para a pessoa usuária, escopo, entrega, qualidade, operações, pessoas, fornecedor, governança, segurança, acessibilidade, dados e contexto externo, somente quando forem relevantes. Separe preocupações sustentadas por evidências de hipóteses. Evite catástrofes genéricas, atribuição de culpa e certeza retrospectiva. Agrupe as causas em cadeias causais, identifique os primeiros indicadores observáveis e classifique-as por plausibilidade e dano, com uma justificativa declarada — não precisão inventada. Para os principais cenários, forneça um teste barato, prevenção, gatilho de contingência, resposta, pessoa responsável explícita ou Não atribuída e prazo de decisão. Inclua cenários contrários à intuição e pontos fortes que reduzam o risco.
Experimente no Playground
Privado por padrãoA montagem do prompt acontece localmente no seu navegador. Evite colocar informações confidenciais em qualquer serviço de IA, a menos que sua organização permita.

Da entrada ao resultado

Um exemplo prático

Veja como um contexto concreto transforma esta receita em um resultado útil

Entrada real

Projeto e data do fracasso
Em março, uma instituição beneficente regional lança um portal on-line de escalas para 600 pessoas voluntárias e 40 coordenadoras. Fracasso em 30 de junho significa que as pessoas coordenadoras ainda mantêm planilhas paralelas, mais de 10% dos turnos programados são contestados ou menos de 50% das pessoas voluntárias ativas usam o portal mensalmente. O piloto começa com duas equipes em fevereiro.
Evidências e suposições
Muitas pessoas voluntárias usam celulares; 18% dos registros atuais não têm um e-mail exclusivo. As pessoas coordenadoras usam nomes diferentes para os turnos. O fornecedor afirma que há compatibilidade com importação de CSV, mas não testou nosso arquivo. O orçamento de treinamento cobre duas sessões ao vivo. Uma pessoa coordenadora teme que as pessoas voluntárias não vejam os avisos de cancelamento. A autenticação usa links por e-mail. Ainda não existem teste de acessibilidade, escala de suporte nem regra para desativar as planilhas.
Participantes e autoridade para agir
A oficina inclui uma pessoa coordenadora de voluntariado, uma representante das pessoas voluntárias, uma gerente de operações com autoridade para o lançamento, uma responsável pelos dados, uma liderança de comunicação e uma especialista do fornecedor. Restam duas semanas-pessoa para mitigação. As decisões serão analisadas na próxima terça-feira.

Exemplo de saída

História de fracasso A — identidade e importação fragmentadas: 18% sem e-mail exclusivo, somados à importação de CSV não testada, geram contas duplicadas/ausentes; as pessoas voluntárias não conseguem se autenticar; as pessoas coordenadoras mantêm planilhas; as contestações aumentam. Sustentada por evidências. Primeiros indicadores: taxa de exceções na importação, contas duplicadas, falhas de acesso. Teste barato: importar um arquivo representativo sem identificação pessoal e tentar o acesso por celular com registros que tenham e-mail ausente/duplicado. Prevenção: definir a correção das identidades e conciliar as contagens antes do piloto. Responsável: pessoa encarregada dos dados pelo teste; responsável pela política de identidade Não atribuída. Decisão até a próxima terça-feira.

B — definições de turno incoerentes: nomes diferentes são mapeados incorretamente, criando escalas contestadas e registros paralelos. Sustentada por evidências. Testar uma taxonomia compartilhada nas duas equipes-piloto e conciliar cada turno importado. C — cancelamentos falham operacionalmente: pessoas que usam links por e-mail podem não ver os avisos; não há escala de suporte nem regra de confirmação de aviso. A preocupação é explícita, o mecanismo do resultado é parcialmente hipotético. Testar a entrega/abertura e cinco percursos de tarefa com pessoas voluntárias; definir alternativa urgente e responsável. D — a adoção parece aceitável enquanto as pessoas coordenadoras mantêm planilhas paralelas; fracasso de governança contrário à intuição. Indicador: as edições continuam após a transição. Definir critério de desativação e registro de exceções antes do lançamento.

Outras hipóteses: a acessibilidade móvel impede a conclusão das tarefas; duas sessões não alcançam quem trabalha em turnos; os defeitos do fornecedor perduram além das duas semanas-pessoa. Pontos fortes: piloto gradual com duas equipes, autoridade de lançamento identificada, perspectiva das pessoas voluntárias e limites mensuráveis de fracasso. Priorize A/B antes do piloto porque compartilham uma base de dados, mas exigem verificações de aceitação separadas.

Por que isso funciona

  1. 1

    A retrospectiva prospectiva ajuda as equipes a nomear causas de fracasso que o planejamento otimista costuma suprimir.

  2. 2

    Indicadores e testes baratos transformam o fracasso imaginado em evidências capazes de mudar o plano.

Verifique o resultado

  • Os cenários são específicos deste projeto e estão vinculados às evidências fornecidas ou identificados como hipóteses?

  • Os principais cenários têm indicadores iniciais, testes baratos, gatilhos e respostas acionáveis?

  • O resultado evita culpa, probabilidades falsas e formulações duplicadas da mesma cadeia causal?

Use com confiança

Perguntas frequentes

Respostas práticas sobre quando usar esta receita, o que fornecer e onde a revisão humana ainda é importante

O que devo preparar antes de usar “Faça um pré-mortem de projeto”?

Para usar “Faça um pré-mortem de projeto”, prepare o Projeto e data do fracasso, as Evidências e suposições e os Participantes e autoridade para agir. Substitua os espaços reservados apenas por informações que você possa verificar. Se algum detalhe for desconhecido, preserve explicitamente essa incerteza em vez de pedir ao modelo que o infira.

Quando o resultado de “Faça um pré-mortem de projeto” ainda não está pronto para uso?

O resultado não está pronto se ainda não entregar o resultado declarado — um mapa priorizado de cenários de fracasso, com evidências, indicadores, responsáveis e experimentos imediatos — com base nas evidências fornecidas, ou se depender de suposições não resolvidas, aprovações ausentes ou detalhes inventados. Use as verificações como critérios de liberação: revise as informações de origem ou designe uma pessoa revisora identificada e autorizada, em vez de aprimorar um resultado sem sustentação.

Quais ferramentas de IA têm testes registrados para “Faça um pré-mortem de projeto”?

O registro de testes publicado para “Faça um pré-mortem de projeto” inclui o ChatGPT em 2026-08-28. Isso confirma execuções registradas, não compatibilidade garantida nem resultados idênticos em versões posteriores do produto. Para outra ferramenta ou versão, mantenha todas as restrições visíveis e repita as verificações do resultado antes do uso.

Mais maneiras de explorar

Onde esta receita se encaixa

Mantenha o trabalho em andamento