Who What When Where How Why

O guia prático que ninguém pede sobre o método 5W1H

Você já tentou documentar um problema e percebeu que meia hora depois estava escrevendo um romance em vez de um relatório útil. Isso acontece porque o cérebro humano adora conectar pontos antes de entender o que realmente aconteceu. O método 5W1H existe para impedir isso, e é incrivelmente subestimado. Who — Quem está envolvido? Não apenas nomes. Cargo, equipe, responsável pela decisão, usuário final, o cara que foi omitido de propósito. Em relatórios técnicos eu aprendi a incluir "quem deveria ter sido envolvido e não foi". Isso separa gente competente de gente que só preenche formulário. What — O que aconteceu? Descreva o fato, não a interpretação. "O serviço caiu" é um fato. "O serviço caiu porque o servidor foi mal configurado" é uma conclusão que pode estar errada. Anote o que você tem certeza primeiro. O resto vem depois.

When — Quando aconteceu? Hora exata, fuso horário, duração, frequência. Se for recorrente, anote os horários dos incidents anteriores. Isso vira dado estatístico antes de virar narrativa. Where — Onde? Ambiente (produção, homologação, staging), região geográfica, serviço específico, módulo, tabela no banco. "Onde" em sistema distribuído é tão importante quanto "quando". Eu já perdi horas rastreando um bug que só aparecia num datacenter porque o "where" estava vago num ticket. How — Como? O mecanismo. O passo a passo que levou ao evento. Reposição de dados, comportamento observado, logs relevantes. O "como" é a ponte entre o que aconteceu e por que aconteceu.

Why — Por quê? A causa raiz. Esta é a parte que as pessoas mais estragam. "Why" não é chute. É inferência baseada nos quatro anteriores. Se você ainda não tem who, what, when, where e how documentados, seu why é especulação disfarfada de análise.

Por que a ordem importa e a maioria faz errado

Pessoas tendem a começar pelo why. Querem chegar na causa raiz rápido porque parece produtividade. Na prática, é a forma mais rápida de construir uma teoria da conspiração interna. A sequência correta é who what when where how why. Cada resposta alimenta a próxima. Pular etapas gera lacunas que se tornam mentiras bem-intencionadas nos relatórios de pós-mortem. Também não é regra rígida de linearidade. Às vezes você descobre o "where" enquanto responde o "what" e precisa retroceder. Isso é normal. O método é uma âncora, não uma corrida.

Um problema real que eu tive com isso

Num incident de produção com downtime de 47 minutos, eu fiz a análise usando 5W1H. No "where", annotamos "serviço de pagamento — cluster BR-sul". Dois dias depois, outro time abriu ticket dizendo que o mesmo erro acontecia no cluster LT-américa. O "where" tinha sido incompleto porque só registramos onde a equipe de plantão tinha visto o problema, não onde o problema existia. A correção foi simples: adicionar um campo obrigatório de escopo geográfico nos templates de incident, mas demorei uma semana para perceber a falha no meu próprio trabalho. Crie um template com os seis campos. Use em cada ticket, documento ou mensagem longa que envolva problemas. Não escreva parágrafos. Use bullet points. A economia de tempo é real: replace meia hora de redação livre por cinco minutos de preenchimento estruturado. A qualidade da comunicação sobe porque quem lê já sabe onde procurar cada informação. Se o contexto for muito complexo, divida em sub-itens. Um "what" grande demais vira confusão. Um "how" com trinta linhas é sinal de que alguém não terminou de entender o problema.

O que o método não resolve

5W1H não substitui investigação técnica. Ele organiza o que você já descobriu. Se os dados brutos estão errados, o template vai te dar uma erro bem estruturado, não uma verdade melhor. Ferramenta de estrutura, não de magia. Também não funciona bem em ambientes caóticos onde ninguém sabe ao certo o que está acontecendo — nesse caso, o método vira exercício de inventar respostas plausíveis, o que é pior que não ter método nenhum. Em equipes pequenas e ágeis que comunicam por Slack, o uso rigoroso do 5W1H em tudo pode parecer burocracia excessiva. Aí vale saber quando não usar: conversas informais de alinhamento rápido não precisam dos seis campos. Reserve o método para eventos que merecem registro permanente.

Dica que ninguém ensina

Releia o "why" depois de escrever todo o resto. Se ele depender de alguma afirmação que não está respaldada por who, what, when, where ou how, ele precisa ser reformulado. Causa raiz sem amarração factual é opinião, não análise.