Como usar a técnica de porque pergunta e porque resposta no dia a dia
A técnica de porque pergunta e porque resposta é basicamente uma versão mais estruturada do "cinco porquês" que todo mundo já ouviu falar em alguma reunião de qualidade. A diferença é que ela te obriga a documentar cada eloo da cadeia causal em vez de parar no primeiro motivo que parece óbvio. No começo eu também pensava que era frescura corporativa, até começar a ver padrão nos problemas recorrentes do meu time.
Porque pergunta e porque resposta na prática
A estrutura é simples demais pra assustar anyone. Você pega um problema concreto e faz a pergunta "por que isso aconteceu?" Anota a resposta. Aí pergunta "por que essa resposta aconteceu?" e anota de novo. Repete até chegar numa causa raiz que você consegue agir. O ponto crucial que a maioria erra: você para quando a resposta passar a ser um conselho moral ou algo fora do seu controle, não quando ficar sem ideias. Eu costumava usar isso pra resolver gargalos de deploy que pareciam aparecer do nada. Tipo aquele dia em que o pipeline quebrava toda segunda de manhã e ninguém conseguia encontrar o motivo. Aplicando a técnica, chegamos numa configuração de cronjob que rodava duas tarefas concorrentes num servidor de build compartilhado. A solução foi separar os workers. Levou dois dias pra chegar lá se eu tivesse tentado adivinhar, três horas com o método documentado.
Passo a passo que funciona
Comece escrevendo o problema em uma linha, sem adjetivos. "O relatório financeiro saiu errado" é melhor que "O relatório saiu terrivelmente errado porque tudo tá uma merda." A linguagem emocional contamina as respostas seguintes. Depois, faça a primeira pergunta porque. A resposta precisa ser factual, não interpretativa. Se a sua resposta for "porque a pessoa não se esforçou", você já errou. Troque por "porque o dado de entrada veio de uma planilha desatualizada." Cada nível da sua árvore de porque deve ser verificável com evidência.
O formato que eu acho mais útil é uma tabela com duas colunas: pergunta e resposta. Cada resposta vira a base da próxima pergunta. Visualmente fica claro quando você repetiu uma ideia ou quando começou a divagar. Já vi gente gastar quatro horas num porque pergunta e porque resposta que era basically um parágrafo de 40 linhas disfarçado. A tabela corta isso na hora.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Onde a maioria erra
O erro clássico é confundir correlação com causalidade num dos ramos da árvore. Você pergunta por que o servidor caiu e a resposta é "porque o disco encheu". Aí pergunta por que o disco encheu e responde "porque tem muitos logs." Parece lógico até você perceber que os logs só aumentaram porque um serviço de monitoramento buggado não tava rolando os arquivos corretamente. O disk full era sintoma, não causa. A causa real era a configuração do log rotation. Outro problema comum é parar cedo demais. Chegar num "porque a empresa não investe mais em TI" e achar que chegou na raiz. Isso é um ponto final de conversa, não de análise. Se você não consegue propor uma ação concreta a partir daquela resposta, você ainda não chegou longe o suficiente.
Quando a técnica não serve
porque pergunta e porque resposta é péssimo pra problemas complexos com múltiplas causas interdependentes que acontecem em paralelo. Se o problema é "o sistema ficou lento" e existem cinco variáveis mudando ao mesmo tempo (base de dados, tráfego, cache, API externa, Deploy recente), a árvore linear vai te dar uma visão distorcida. Nesses casos, um diagrama de Ishikawa ou uma análise de sistemas dinâmicos com variáveis múltiplas funciona melhor. Também não funciona bem quando a causa raiz é humana e não documentada. Type de "o desenvolvedor sabia que tinha que fazer X mas fez Y mesmo assim." Sem dados concretos, você vira um investigando motivações alheias em vez de resolver problema técnico.
Um case específico que aprendi da pior forma
Tinha um bug recorrente num serviço de notificação que só acontecia quando o volume de usuários passava de 15 mil. Apliquei o porque pergunta e porque resposta três vezes em semanas diferentes. Cada vez cheguei num lugar diferente. Na quarta vez parei e perguntei: "o que mudou entre as execuções bem-sucedidas e as falhas?" em vez de "por que falhou?". Descobri que o pool de conexões do banco tava configurado pro pico de segunda-feira, mas o serviço de notificação executava em horários espalhados e às vezes batia justo no limite. A configuração de max_connections no PostgreSQL tava em 100. O serviço abria 85 conexões em horários normais, mas o garbage collection do Java entrava junto com a pico de demanda e o timer de idle timeout fechava conexões de forma assíncrona, deixando o pool num estado inconsistente. A solução foi configurar o connection pool com um fator de segurança de 20% e aumentar o timeout. Nada a ver com o código de notificação em si. Se eu tivesse continuado perguntando "por que" sem mudar de ângulo, provavelmente teria gasto mais dois meses refatorando código que não era o problema.
Template pronto pra usar
Se quiser começar hoje, crie um documento com estas colunas: Problema | Pergunta Porque | Resposta | Evidência | Próxima Pergunta Porque. Preencha cada linha antes de avançar. Se a coluna de evidência ficar vazia em algum ponto, você tem um ramo especulativo que precisa ser validado antes de continuar. Isso costuma transformar uma discussão de duas horas em algo que gaba 20 minutos de preenchimento e mais 15 de debate sobre os ramos que divergem. O ganho não é só de tempo, é de clareza. Todo mundo acaba olhando pra mesma árvore em vez de argumentar sobre qual versão da história é a certa.
