5 Porquês: como chegar à causa raiz sem parar na primeira explicação

Um incidente derruba o serviço, e a ata registra: “uma pessoa esqueceu de executar a migração”. Combina-se mais atenção, e o assunto termina. Dois meses depois, o problema volta com outra pessoa.

A primeira explicação costuma ser verdadeira e insuficiente. Ela descreve o que aconteceu, mas não por que o sistema permitiu que acontecesse. Perguntar “por quê?” algumas vezes seguidas é uma forma simples de sair dessa superfície, desde que cada resposta seja verificada.

O que são os 5 Porquês#

A técnica investiga um problema por meio de perguntas encadeadas: cada resposta vira o objeto da pergunta seguinte, até chegar a um mecanismo que possa ser corrigido e testado.

O método está ligado ao Sistema Toyota de Produção. Taiichi Ohno o descreveu como a base da abordagem científica da Toyota, na qual repetir o porquê cinco vezes deixa claros o problema e a solução (Ohno, 1988). As fontes divergem sobre a origem exata, e parte delas a atribui a Sakichi Toyoda.

Quando usar e quando evitar#

Como aplicar#

Exemplo: as contas conectam dados, mas não geram resultado#

Depois do lançamento de um assistente de IA, a ativação de uma plataforma SaaS caiu de 40% para 30%. A divisão do funil mostrou que a perda está nas contas que conectam os dados, mas não geram o primeiro resultado. O diagrama de Ishikawa apontou duas hipóteses principais, e cada uma virou uma cadeia.

Cadeia A: lentidão na primeira geração

Cadeia B: tela vazia

A segunda cadeia parou em três porquês, porque já chegou a um processo corrigível. Forçar mais dois níveis só produziria respostas inventadas.

Teste da leitura inversa na cadeia A: “Não havia requisito de latência, portanto indexar depois pareceu aceitável, portanto a primeira geração ficou lenta, portanto as contas abandonam”. A frase se sustenta.

Das duas cadeias saem as ações:

• Indexar os dados em segundo plano, logo após a conexão.
• Criar um requisito de latência para a primeira geração e testar com contas grandes.
• Incluir a ativação como critério obrigatório na revisão de mudanças de onboarding.
• Criar um alerta para detectar a recorrência da lentidão.

As causas continuam sendo hipóteses bem sustentadas. Um teste de hipótese mostrará se as correções recuperam a ativação.

Evite procurar culpados#

Quando uma cadeia termina em “a pessoa errou”, ela costuma ter parado cedo. A pergunta útil é o que tornou aquele erro possível e fácil de cometer. A cultura de postmortem do Google segue essa linha: a análise busca as causas que contribuíram para o incidente, sem acusar pessoas ou equipes, e parte do princípio de que todos agiram de boa-fé com a informação que tinham (Google SRE).

Além de ser mais justo, isso melhora a análise, porque pessoas que temem punição escondem informações.

Os limites da técnica#

Os 5 Porquês têm críticos sérios. Card (2017), escrevendo sobre segurança do paciente, argumenta que uma cadeia única oferece uma visão estreita de um caminho causal complexo, que o quinto porquê é um ponto de parada arbitrário e que a popularidade da técnica não vem de evidências de eficácia. Sua conclusão é que ela não deveria ser usada em análises de causa raiz na saúde, um contexto de alta complexidade. Também é comum que pessoas diferentes cheguem a causas diferentes para o mesmo problema.

Essas críticas não anulam a técnica, mas delimitam seu uso: serve bem para problemas contidos e para disciplinar a conversa, especialmente com cadeias paralelas, evidência em cada elo e apoio de um mapa mais amplo. Em sistemas críticos, ela não substitui uma investigação técnica completa.

Como usar uma LLM#

Uma LLM ajuda a organizar um relato de incidente, sugerir perguntas, apontar saltos lógicos e abrir cadeias alternativas. Ela não sabe o que aconteceu no seu sistema, e por isso tende a completar a cadeia com respostas plausíveis. Exija evidência em cada elo.

Ajude a investigar a causa raiz de [problema observável].
Métrica, período e magnitude: [informar].
Dados, logs, entrevistas e alterações recentes: [descrever].

Conduza uma análise dos 5 Porquês, mas não force exatamente cinco
etapas se a evidência pedir mais ou menos. Se existirem causas
paralelas, crie cadeias distintas.

Para cada elo causal, indique a evidência, as dúvidas e como poderíamos
verificar a hipótese. Se não houver evidência, escreva "hipótese não
verificada" em vez de completar a cadeia.

Encerre com ações corretivas de sistema ou processo, responsáveis e
medidas para detectar recorrência. Não transforme a análise em culpa.

Saída esperada: cadeias causais verificáveis, com ações corretivas e sinais de recorrência.

Antes de confiar na resposta:

• Cheque cada elo. Confirme se a evidência citada existe e se realmente sustenta a resposta.
• Peça uma cadeia alternativa. Pergunte que outra explicação se encaixaria nos mesmos dados.
• Faça a leitura inversa. Leia a cadeia de baixo para cima com “portanto”.
• Sanitize o contexto. Tire nomes, dados de clientes e segredos dos logs antes de colar.

Combine com outros frameworks#

• Diagrama de Ishikawa: mapeia as hipóteses em amplitude antes de aprofundar cada cadeia.
• Teste de hipótese: verifica se a correção realmente resolve o problema.
• Análise pré-mortem: antecipa falhas plausíveis antes da execução, enquanto os 5 Porquês investigam problemas observados.
• Matriz de decisão: compara as ações corretivas quando há mais de uma candidata.

Referências#

1. Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Portland, OR: Productivity Press.
2. Card, A. J. (2017). The problem with ‘5 whys’. BMJ Quality & Safety, 26(8), 671–677. DOI
3. Google. Site Reliability Engineering, capítulo “Postmortem Culture”. O’Reilly Media. Link
4. Wikipedia. Five whys. Link