5W2H: uma forma simples de organizar problemas e ações

Muitas tarefas começam com frases vagas:

• “O sistema não está funcionando.”
• “Precisamos melhorar o backup.”
• “A impressora parou.”
• “A rede está lenta.”
• “Temos que atualizar o servidor.”

Essas frases mostram que existe uma necessidade, mas ainda não deixam claro o que realmente aconteceu ou o que precisa ser feito.

O 5W2H é uma ferramenta simples para organizar essas informações.

Ele pode ser usado para entender um problema, planejar uma tarefa, dividir responsabilidades ou registrar um plano de ação.

O que significa 5W2H?

O nome vem de sete perguntas em inglês:

São cinco perguntas iniciadas com a letra W e duas com a letra H. Por isso, o nome 5W2H.

Na prática, o nome importa menos do que as perguntas.

What — O que aconteceu?

A primeira pergunta define o problema ou a tarefa.

Evite descrições muito abertas, como:

O computador está com problema.

Uma descrição mais clara seria:

O computador da recepção liga normalmente, mas não consegue acessar o sistema financeiro.

A ideia é identificar exatamente o que não está funcionando ou o que precisa ser feito.

Why — Por que isso precisa ser resolvido?

Aqui é identificado o impacto da situação.

Por exemplo:

O acesso precisa ser restabelecido porque a recepção utiliza o sistema para cadastrar os atendimentos.

Essa pergunta ajuda a entender a importância da tarefa.

Um problema que interrompe o trabalho de várias pessoas normalmente deve receber mais atenção do que uma melhoria que pode ser feita posteriormente.

Where — Onde acontece?

É necessário identificar o local, equipamento ou sistema envolvido.

Alguns exemplos:

• computador da recepção;
• servidor de arquivos;
• impressora do financeiro;
• filial de Curitiba;
• sistema de vendas;
• rede sem fio do estoque;
• ambiente de produção.

Quanto mais preciso for o local, menor será a chance de verificar o equipamento ou ambiente errado.

When — Quando começou?

Saber quando o problema começou pode ajudar a encontrar a causa.

Perguntas úteis:

• Quando aconteceu pela primeira vez?
• Funcionava antes?
• O problema acontece sempre?
• Ocorre em algum horário específico?
• Houve alguma alteração antes da falha?

Exemplo:

O acesso funcionava normalmente até ontem. O problema começou depois da troca da senha do usuário.

Isso não prova que a troca de senha causou a falha, mas fornece uma hipótese para iniciar os testes.

Who — Quem está envolvido?

Essa pergunta identifica as pessoas relacionadas à situação.

Pode incluir:

• quem percebeu o problema;
• quem foi afetado;
• quem fará a correção;
• quem validará o resultado;
• algum fornecedor envolvido.

Exemplo:

O problema afeta somente a usuária do financeiro. Outros usuários conseguem acessar o sistema normalmente.

Essa informação já ajuda no diagnóstico. Se somente uma pessoa é afetada, a falha pode estar relacionada ao usuário, ao computador ou às permissões.

How — Como será resolvido?

Aqui são descritos os passos necessários para analisar ou executar a tarefa.

Exemplo:

1. Verificar se o computador está conectado à rede.
2. Testar a comunicação com o servidor.
3. Validar o usuário e a senha.
4. Conferir as permissões de acesso.
5. Realizar um novo teste.
6. Registrar o resultado.

Também é importante informar o resultado dos testes.

Em vez de registrar:

Foram feitos alguns testes.

Prefira:

Foi testada a comunicação com o servidor. O servidor respondeu normalmente e não houve perda de pacotes.

Assim, outra pessoa consegue entender o que já foi verificado.

How much — Quanto será necessário?

Essa pergunta normalmente está relacionada ao custo, mas também pode representar:

• tempo;
• esforço;
• quantidade de pessoas;
• licenças;
• equipamentos;
• horas de trabalho;
• espaço de armazenamento.

Exemplo:

A atividade deve levar aproximadamente uma hora e não exige compra de equipamentos.

Em tarefas maiores, o valor pode incluir mão de obra, deslocamento, licenciamento ou contratação de serviços.

Exemplo prático

Considere a seguinte solicitação:

A impressora do financeiro não funciona.

A frase ainda deixa várias dúvidas. Aplicando o 5W2H, o registro pode ficar assim:

Agora existe informação suficiente para iniciar o atendimento.

Exemplo de um plano de ação

O 5W2H também pode ser usado para organizar uma tarefa que ainda será executada.

Imagine a implantação de uma rotina de backup:

Nesse caso, o 5W2H ajuda a transformar uma ideia genérica em uma atividade organizada.

Erros comuns

Responder de forma genérica

Um exemplo ruim seria:

O quê? Resolver o problema.

Isso apenas repete que existe um problema. Não explica qual é a falha nem qual resultado é esperado.

Tratar uma hipótese como certeza

Sem testes, não é correto afirmar:

O sistema parou porque o servidor está com problema.

Uma forma mais adequada seria:

Existe a possibilidade de falha no servidor. É necessário verificar a comunicação, os serviços e os registros do sistema.

Não definir um responsável

Quando ninguém é claramente responsável, a atividade pode ser esquecida.

Sempre que possível, deve ser definido quem executará a ação e quem verificará o resultado.

Não atualizar o plano

Depois da execução, é importante registrar:

• o que foi feito;
• quais testes foram realizados;
• qual foi o resultado;
• se o problema foi resolvido;
• se ainda existem pendências.

O que o 5W2H não faz?

O 5W2H ajuda a organizar informações, mas não encontra sozinho a causa de um problema.

Problemas mais complexos podem exigir:

• análise de logs;
• testes de conectividade;
• análise de causa raiz;
• linha do tempo do incidente;
• plano de retorno;
• avaliação de riscos.

Portanto, o 5W2H deve ser visto como uma ferramenta de organização, e não como substituto do diagnóstico técnico.

Conclusão

O 5W2H transforma solicitações vagas em informações mais claras.

Com sete perguntas, é possível definir:

• o que precisa ser feito;
• por que a ação é necessária;
• onde ela acontecerá;
• quando será realizada;
• quem será responsável;
• como será executada;
• quanto será necessário.

O principal benefício não está em preencher uma tabela. Está em reduzir dúvidas antes de iniciar uma tarefa.

Quanto mais claro estiver o problema, mais fácil será escolher os testes, definir responsabilidades e verificar se a solução realmente funcionou.