Resolver um problema
De algo está errado a resolvido ou repassado.
The case
Algo está errado. Você não sabe exatamente o quê, não sabe o quão grave é, e o que você fizer a seguir vai resolver o problema ou fazer você perder uma hora. A maioria das sessões de resolução de problemas falha não porque as pessoas sejam ruins em consertar coisas, mas porque não desaceleram o suficiente no início para descrever com precisão o que está acontecendo.
O instinto é começar a tentar coisas imediatamente. Reiniciar. Reinstalar. Pesquisar o sintoma antes de tê-lo articulado completamente. Às vezes funciona, por sorte — e quando não funciona, você introduziu novas variáveis numa situação que já era confusa.
Uma rotina de resolução de problemas nada mais é do que uma árvore de decisão com um ponto de entrada consistente. Você descreve o problema com precisão, tenta reproduzi-lo, verifica o que mudou, pesquisa de forma deliberada e testa as melhores opções em ordem. Em cada bifurcação, você avança ou pula etapas. Se chegar ao final sem solução, você escala — mas com algo útil, não com um encolher de ombros.
O que uma rotina também oferece é uma condição de parada. Sem ela, a resolução de problemas tende a se expandir para preencher o tempo disponível. O ponto de decisão no passo #12 força a pergunta: ainda vale a pena continuar com isso, ou agora é o problema de outra pessoa?
Resolver um problema
- Anote os passos que você seguiu, o que esperava que acontecesse e o que aconteceu de verdade.
- Tente reproduzir o problema seguindo sua lista exatamente. Se não conseguir reproduzir, volte ao @1 — sua lista ainda não está completa.
- Identifique o que mudou recentemente. Atualização de software, nova entrada, mudança de configuração, qualquer coisa. Se nada mudou, pule para o @7.
- Desfaça a mudança. Volte ao estado ou à versão anterior. Se conseguiu desfazer, volte ao @2 para verificar se o problema ainda existe.
- Isole a mudança. Desative, desconecte ou remova apenas o que mudou e teste novamente. O objetivo é confirmar se essa mudança é a causa antes de fazer qualquer outra coisa. Se isso resolver, pule para o @13.
- Reaplicar a mudança. Você confirmou que ela é a culpada. Anote. Pule para o @13.
- Pesquise a mensagem de erro ou o sintoma exato. Copie o erro exatamente como aparece, se houver. Pesquisas vagas retornam resultados vagos.
- Anote quais soluções aparecem com mais frequência nos resultados. Frequência é um ponto de partida, não uma prova.
- Verifique a data do que você está prestes a tentar. Uma solução de cinco anos atrás pode não se aplicar mais.
- Tente a solução mais confiável. Se resolver, pule para o @13.
- Tente a próxima solução mais confiável. Se resolver, pule para o @13.
- Decida: continuar tentando ou escalar. Quanto tempo você já gastou? Qual é a criticidade? Se for escalar, pule para o @14. Se for continuar, volte ao @10.
- Documente o que resolveu o problema. Uma frase. Você vai esquecer, e vai encontrar isso de novo.
- Escreva um resumo do problema para quem vai assumir. O que você tentou, o que descartou, o que suspeita. Passe adiante de forma clara.
Gambiarra à vontade
O passo mais importante é o #13, e é o que a maioria pula. Resolver um problema e documentar a solução são tarefas diferentes — a segunda é o que impede você de gastar quarenta minutos na mesma coisa daqui a seis meses. Uma frase é suficiente.
Os passos #10 e #11 são marcadores para um loop que pode se estender. Alguns problemas exigem dez tentativas antes de algo funcionar. Adicione passos conforme necessário e tome a decisão no #12 sobre continuar ou passar adiante.
A via de escalada no #14 merece ser levada a sério. Uma passagem clara — o que você tentou, o que descartou — é genuinamente útil para quem receber o problema. Chegar só com "está quebrado" não é.
Se você usar essa rotina para um domínio específico — software, hardware, um equipamento — adapte os passos do meio à sua sequência de diagnóstico habitual. A estrutura permanece a mesma; os detalhes são seus para preencher.