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 what when where how why — o básico
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.
👉 Clique no botão abaixo para saber mais sobre o assunto!
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.
Como aplicar na prática sem perder tempo
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.
