Quando Enfrentamos Problemas Complexos

O que acontece quando a coisa aperta

Problemas complexos não precisam de mágica para serem resolvidos. Eles precisam de um processo repetível que não desmorone quando o tempo aperta. Eu trabalho com isso há anos, em ambientes onde cada dia traz algo diferente e imprevisível. O que funciona é mais simples do que parece, e o que quebra é mais óbvio do que gostaríamos de admitir. A primeira coisa que todo mundo faz errado é pular direto para a solução. Você vê um problema, pensa na resposta e já começa a construir. Isso funciona até funcionar, e quando não funciona, você gastou dias ou semanas indo pelo caminho errado. O método que eu uso divide o processo em quatro etapas que se sobrepõem, não em sequência rígida. Definição do problema — escrever o que está acontecendo, quais são os sintomas reais e quais são os que são apenas ruído. Eu costumo pedir para quem está com o problema escrever tudo em uma página. Sem formatação especial, sem gráficos bonitos. Só texto. Se não consegue escrever em uma página, não entendeu o problema ainda.

Decomposição — quebrar o problema em partes que possam ser resolvidas isoladamente. A regra prática aqui é: se você não consegue resolver uma parte sozinha, ainda está grande demais. Continue dividindo. Eu já vi gente tentar resolver sistemas inteiros de uma vez. Não funciona. Cada parte tem que caber na cabeça de uma pessoa num único dia de trabalho. Experimentação controlada — testar hipóteses em vez de construir soluções completas. Um experimento leva no máximo uma tarde. Se leva mais que isso, você não está fazendo um experimento, está construindo algo. A diferença é importante porque muda como você mede o sucesso. Síntese — juntar o que funcionou e descartar o que não funcionou. Esta é a parte que mais gente ignora. Você gasta tempo testando, mas não gasta tempo documentando o que aprendeu. Sem documentação, você repete os mesmos testes depois, com o mesmo resultado.

Eu tenho um template simples que uso em todos os projetos. Ele é basicamente uma tabela com quatro colunas: o que eu testei, o resultado, o que aprendi, e o que faço agora. Ocupa dois minutos para preencher e economiza horas de confusão. Quem quiser, pode baixar uma versão em formato CSV aqui. É literalmente quatro cabeçalhos e linhas em branco. O ponto que quase ninguém menciona: a maioria dos problemas complexos não é complexa demais, é mal definida. Quando eu vejo alguém travado por semanas, 80% das vezes o problema real era diferente do problema que eles estavam resolvendo. O diagnóstico errado gera esforço desperdiçado. O diagnóstico certo, mesmo com uma solução simples, avança rápido. Um caso específico que eu lembro: tínhamos um sistema que falhava de forma intermitente em produção. O log mostrava timeouts aleatórios em horários diferentes. A equipe inteira partiu para otimização de código, perfilagem de performance, ajuste de banco de dados. Nada resolvia. Eu passei duas semanas seguindo o padrão que não aparecia nos logs. A solução não estava no código. Estava em uma dependência externa — um serviço de terceiros que tinha um limite de requisições por minuto que variava conforme a carga do datacenter deles. Nosso sistema atingia esse limite em horários de pico, mas só em certas regiões. A workaround foi implementar um wrapper com retry exponencial e fallback para cache local, reduzindo a dependência direta. O problema não era complexo. Era invisível.

Outro insight contraintuitivo: resolver problemas complexos muitas vezes significa adicionar complexidade temporária, não remover. Parece absurdo, mas é o padrão. Você adiciona Logging, você adiciona Monitoring, você adiciona Abstração entre camadas que pareciam óbvias. Essa complexidade extra é o preço da visibilidade. O erro é achar que precisa remover tudo depois. Às vezes, a complexidade adicional vira parte permanente do sistema, e isso é normal. O importante é saber qual parte é essencial e qual parte é lixo acumulado. O que esse método não faz: não resolve problemas onde a informação fundamental é inacessível. Se você não tem acesso aos logs corretos, se os dados estão em silos que não conversam entre si, se as pessoas certas não estão disponíveis para entrevistas, o processo todo fica cego. Numa ocasião, precisei lidar com um sistema legado onde ninguém mais sabia como funcionava. Nenhum documento, nenhum código fonte, apenas binários compilados. O melhor workaround que encontrei foi recriar o comportamento observando entradas e saídas, tipo engenharia reversa comportamental. Demorou duas semanas para mapear um fluxo que deveria levar dois dias. A lição: invista em documentação desde o começo, mesmo que pareça desnecessário. Os erros mais comuns que eu vejo:

1. Começar a resolver antes de entender. Você vai rápido e vai para o lugar errado. Leva três vezes mais tempo voltar. 2. Tratar todos os problemas como se tivessem a mesma estrutura. Problemas técnicos são diferentes de problemas humanos, que são diferentes de problemas organizacionais. O método de decomposição funciona para todos, mas as ferramentas de solução não. 3. Não medir progresso. Sem métricas claras, você não sabe se está avançando ou apenas ocupado. Defina um indicador de progresso antes de começar qualquer experimento.

Quando o problema é grande demais para um ciclo de iteração, a tentação é paralisar. Eu recomendo cortar o escopo deliberadamente. Pegue a menor parte do problema que você consegue isolar e resolva ela. Mesmo que seja trivial. O valor não está na solução em si, mas no fato de que você gerou um resultado concreto que pode servir de base para o próximo ciclo. Se nenhuma das etapas acima fizer sentido no seu contexto específico, o problema provavelmente não é complexo — é mal estruturado. Reexamine as suposições que você está fazendo sobre o que está acontecendo. Às vezes, o problema real é simplesmente que as pessoas envolvidas não estão falando a mesma língua.