Aja Ou Haja Paciência

O problema que ninguém resolve direito

Quando você tem que escolher entre agir rápido e ter paciência, a maioria das pessoas erra de um jeito grosseiro. Eu vi engenheiros de produto, gestores de projeto e até desenvolvedores sênior caírem nessa armadilha repetidamente. O assunto aja ou haja paciência não é sobre filosofia. É sobre tomar decisões com informações incompletas sob pressão de prazo. A situação que eu mais vejo acontecer: o sistema quebra no sábado à noite, o cliente está ligando, e todo mundo entra em modo ataque. A gente age. A gente paga o hotfix. A gente contorna o problema. E seis meses depois o mesmo bug volta porque ninguém entendeu a causa raiz.

Quando aja ou haja paciência é a resposta certa

Ter paciência não significa sentar e esperar. Significa reservar tempo suficiente para investigar antes de tocar no código, no processo ou no cliente. A impaciência gera soluções que são piores que o problema original. Eu já perdi duas semanas refazendo uma correção que poderia ter sido feita em dois dias se eu tivesse parado de tentar resolver na primeira hora. O cenário clássico onde a paciência salva seu pescoço é quando você não tem dados suficientes. Você está vendo um sintoma e não a causa. Se você age nesse momento, você está apostando chute. Eu trabalhei num caso onde a latência subiu de forma intermitente. O time de plantão reiniciava os containers toda vez que o gráfico oscilava. Isso acontecia seis vezes por semana durante três meses. Nobody could find the root cause because every action was reactive. A virada aconteceu quando eu parei de lidar com os alertas e passei a medir o padrão real. Descobriu-se que era um vazamento de memória em uma biblioteca de logging que só ativava em cargas específicas. Uma linha de configuração mal configurada num serviço secundário. Resolver isso levou uma tarde. Os dois meses de hotfixes poderiam ter sido evitados com uma investigação inicial mais calma.

A mecânica da decisão

A regra prática que eu uso é simples e quase ninguém aplica consistentemente. Antes de agir, você faz três perguntas em voz alta ou por escrito. A primeira: o que eu sei com certeza agora? A segunda: o que eu estou assumindo sem ter dado o dedo? A terceira: qual é o custo de esperar sessenta minutos para verificar? Se a resposta para a primeira pergunta for "pouca coisa" e a terceira for "baixo", você pára. Você coleta mais sinal antes de tocar em nada. Na prática, isso significa olhar os logs háteis, checar o histórico de mudanças recentes, conversar com quem reportou o problema em vez de apenas observar o gráfico. O erro inverso também é comum. As pessoas esperam demais em situações onde a ação imediata é crítica. Se um servidor de produção está com 99% de uso de CPU e o tráfego está subindo, não adianta agendar uma reunião para segunda. Aí a urgência exige movimento. O segredo é saber diferenciar os dois cenários.

Sinais de que você deve agir agora

Dano financeiro em andamento. Perda de dados confirmada. Cliente ativo sendo impactado negativamente a cada minuto. Falha em cascata iniciada. Nesses casos, a paciência é irresponsabilidade. Você age, documenta depois, e reflete no pós-mortem. Sinais de que você deve ter paciência. Comportamento inconsistente. Problema que não se repete sob as mesmas condições. Múltiplas causas possíveis sem evidência concreta. Equipe já estressada e tomando decisões emocionadas. Aqui o risco de agir errado é maior que o risco de esperar. O meu ponto de ruptura pessoal foi quando estava resolvendo um problema de rede num ambiente híbrido. A equipe de infraestrutura queria trocar o roteador de borda naquela noite. Eu pedi vinte minutos para confirmar um detalhe. Descobriu-se que o link de backup estava caindo aleatoriamente por causa de uma negocição mal configurada no switch. Trocar o roteador não resolveria nada. Se tivessem agido sem essa verificação, estaríamos com o mesmo problema e mais desorganização no ambiente.

O guia prático

Para aplicar isso no dia a dia sem precisar de ceremony pesada, use o seguinte fluxo. Quando o problema aparecer, anote-o e defina um tempo de espera antes de qualquer ação. Esse tempo varia conforme o contexto. Para incidentes críticos, quinze minutos. Para comportamentos estranhos, até duas horas. Durante esse tempo, colete dados. Não faça nada que altere o estado do sistema. Depois do período de espera, você toma uma decisão baseada em evidência, não em intuição. Se a evidência for insuficiente, você estende o período. Isso parece lento, mas na média economiza quatro horas de retrabalho por incidente. Em projetos maiores, essa economia escala proporcionalmente. Um detalhe que poucas pessoas consideram: a paciência também se aplica ao aprendizado. Se você está estudando uma nova ferramenta ou metodologia, não espere dominar tudo antes de começar a usar. Age com o conhecimento que tem, corrige na prática, e tenha paciência com a curva de aprendizado. A rigidez aqui é pior que a pressa. Eu vi gente esperar três meses "estudando" antes de colocar nada no ar. Melhor ter funcionado básico rodando na primeira semana e melhorar depois.

O equilíbrio real não está na regra. Está no julgamento acumulado. Quanto mais incidentes você resolve, mais rápido consegue distinguir entre "preciso agir agora" e "posso esperar". Não existe checklist que substitua essa experiência. O que existe é o hábito de revisar suas decisões depois, registrar o que funcionou e o que não funcionou, e ajustar o radar para a próxima vez. Se você quer um artefato concreto para começar, a forma mais barata e eficiente é um documento simples com três campos: problema observado, ações realizadas, e resultado. Preencha em dez minutos após qualquer decisão importante. Em seis meses você tem um banco de dados pessoal de decisões que vale mais que qualquer curso sobre o tema aja ou haja paciência. O próprio ato de registrar já te força a ser mais claro sobre o que você sabia e o que estava assumindo no momento da ação. A parte mais difícil não é saber a teoria. É ter disciplina para não clicar no botão de deploy às três da manhã só porque você está cansado e quer que aquilo termine. Eu levo esse aviso comigo desde que um rollback apressado quebrou um deploy de sexta à tarde e gerou um domingo inteiro de recuperação. A lição ficou gravada.