Precisam ser exatamente cinco perguntas?

Não. Cinco é uma referência prática, não uma regra. Você para quando chegar a uma causa sobre a qual tem controle e cuja correção impede a repetição, às vezes no terceiro porquê, às vezes no sétimo.

Qual a diferença entre 5 porquês e Ishikawa?

O Ishikawa (espinha de peixe) abre o leque de causas possíveis por categoria; os 5 porquês aprofundam uma linha causal específica. Usar os dois juntos funciona bem: o Ishikawa levanta hipóteses, os 5 porquês investigam a mais provável.

A técnica serve para incidente de produção?

Serve, e é onde mais rende. A condição é fazer a análise com dados do incidente (logs, horários, mudanças recentes) e sem buscar culpado, senão as respostas param na primeira pessoa citada.

Os 5 porquês aplicados a problema de sistema

Os 5 porquês são uma sequência de perguntas encadeadas que leva do sintoma visível até a causa que, se corrigida, impede a falha de voltar. A técnica é simples e o erro de aplicação é sempre o mesmo: parar cedo, na primeira explicação técnica que parece suficiente.

Em problema de sistema, a primeira explicação quase nunca é a causa. É o último elo antes do sintoma.

Como a técnica funciona na prática

Um exemplo real de operação, com o encadeamento completo:

Problema: o faturamento parou por três horas na segunda-feira.

Por quê? O sistema recusou todos os pedidos com erro de validação.

Por quê? Uma regra nova de CNPJ passou a rejeitar cadastros antigos com formatação diferente.

Por quê? A regra foi publicada sem teste com dados reais da base.

Por quê? O ambiente de homologação tem uma base sintética, com todos os cadastros no formato novo.

Por quê? Nunca foi definido quem mantém a massa de teste atualizada com casos históricos.

Repare no caminho. Se a análise parasse no segundo porquê, a ação seria "corrigir a regra de CNPJ", e o mesmo tipo de falha voltaria em três meses com outra validação. A causa raiz é a ausência de massa de teste representativa, e a ação corretiva é outra: definir responsável e rotina de atualização da base de homologação.

Onde a análise costuma parar cedo demais

Três pontos de parada prematura aparecem sempre:

Parou na linha de código. "A causa foi um null não tratado." Isso é a descrição do defeito, não a causa. A pergunta seguinte é: por que esse caso não estava previsto?

Parou na pessoa. "O desenvolvedor esqueceu de testar." Se a resposta é o nome de alguém, a análise acabou e o problema continua. Pessoas erram; o que se investiga é por que o erro chegou ao cliente sem ser barrado.

Parou no fornecedor. "A API do parceiro caiu." Verdade, e fora do seu controle. Mas a pergunta continua: por que a queda de uma dependência externa derruba o seu fluxo inteiro em vez de degradar?

O critério de parada é objetivo: você chegou à causa raiz quando a correção proposta está sob o seu controle e impede a classe inteira de falha, não só aquele caso.

Um erro de encadeamento que invalida a análise

Cada porquê precisa ser consequência direta do anterior. Um teste rápido: leia a cadeia de trás para a frente usando "portanto".

Não existe rotina de atualização da massa de teste, portanto a base de homologação tem só dados sintéticos, portanto a regra nova não foi testada com cadastros antigos, portanto ela rejeitou pedidos válidos, portanto o faturamento parou.

Se alguma frase soar forçada nessa leitura invertida, há um salto lógico, normalmente uma suposição que ninguém verificou.

Quando usar Ishikawa antes

Os 5 porquês seguem uma única linha causal. Quando o problema tem várias causas plausíveis, comece com o diagrama de Ishikawa para levantar hipóteses por categoria e só depois aprofunde a mais provável. Em contexto de software, as categorias tradicionais de manufatura se traduzem assim:

Categoria original	Equivalente em sistema	Exemplo de causa
Método	Processo de desenvolvimento	Ausência de revisão de código
Máquina	Infraestrutura	Servidor sem monitoramento de memória
Material	Dados	Cadastro com formato inconsistente
Mão de obra	Pessoas e treinamento	Operador não sabe o que o campo significa
Medição	Observabilidade	Falha não gerava alerta
Meio ambiente	Contexto de uso	Rede instável na filial

A linha Medição merece atenção especial. Quando a resposta a "por que ninguém percebeu antes?" é "não havia alerta", você encontrou uma causa raiz paralela, tão importante quanto a que gerou a falha. Um incidente costuma render duas ações: uma que impede a falha e outra que a detecta mais rápido caso volte.

Como conduzir a conversa sem virar caça às bruxas

A técnica falha por dinâmica de reunião, não por método. Quatro cuidados:

Convide quem viu o problema acontecer, não só quem responde por ele. O operador que recebeu o erro tem informação que o gestor não tem.
Combine no início que não se procura culpado. Diga isso em voz alta. Sem essa combinação, cada participante responde defendendo a própria área e a cadeia trava no segundo porquê.
Trabalhe com evidência. Log, horário, registro de alteração, print da tela. "Acho que foi o deploy" vira "o deploy foi às 14h02 e o primeiro erro às 14h04".
Escreva a cadeia num lugar visível. Quadro ou tela compartilhada. Cadeia falada se perde; cadeia escrita se corrige em grupo.

O que fazer com o resultado

Uma análise sem ação registrada é conversa. Feche sempre com três campos:

Ação corretiva, o que impede a repetição, com responsável e prazo
Ação de detecção, o alerta ou verificação que reduz o tempo até perceber
Data de revisão, quando alguém vai conferir se a falha voltou

E acompanhe a reincidência. Se o mesmo tipo de problema aparece de novo depois da ação, a análise parou antes da hora, o que é informação válida, não fracasso. Refaça a cadeia a partir do ponto onde ela parou.

Na Retti Tech, esse fechamento em três campos é o que impede que a reunião de incidente vire ritual. O valor da técnica não está em perguntar cinco vezes. Está em aceitar a resposta desconfortável que aparece no quarto porquê, quando fica claro que o defeito era só o sintoma de uma decisão tomada meses antes.