Ora Uma Coisa Ora Outra

Lidando com a inconsistência no dia a dia

Ora uma coisa ora outra descreve basicamente qualquer situação onde o comportamento, a decisão ou o resultado muda sem padrão previsível. Pode ser um colega de trabalho, um cliente, um processo interno da empresa. A expressão não se limita ao coloquial — ela aparece com frequência em relatórios de qualidade, análises de processo e até em documentação de sistemas onde a variabilidade é o problema central. Identificar esse padrão exige menos intuição do que medição. Na prática, anote decisões ou resultados por pelo menos duas semanas. Anotações vagas não funcionam. Registre data, hora, contexto e o resultado efetivo. Depois de coletar os dados, você vai perceber que a maioria dessas variações não é aleatória — ela obedece a condições que passam despercebidas no calor do momento. Eu perdi cerca de três semanas tentando resolver um problema de rejeição em um processo de aprovação de documentos. O sistema aceitava um arquivo em um horário e rejeitava o mesmo arquivo horas depois, sem alteração nenhuma no conteúdo. Parecia ora uma coisa ora outra na pior forma possível. O que descobri foi que havia um job noturno de manutenção que sobrescrevia uma configuração de validação às 3h da manhã. O serviço era restaurado manualmente no início do expediente, mas quem fazia isso nem sempre limpava todos os parâmetros. A solução foi automatizar a restauração e adicionar um log de verificação pós-manutenção. Nada heroico. Só fazer o que o processo já devia fazer.

O erro mais comum é tratar a variabilidade como um problema de treinamento. Treinar pessoas para "se atentar mais" raramente resolve porque a causa raiz geralmente é estrutural. Regras ambíguas, dependências ocultas entre sistemas e falta de visibilidade sobre o estado atual do processo são muito mais frequentes do que qualquer falta de atenção por parte do executor. Outro ponto que poucos consideram: a variabilidade pode ser sintoma de um processo que tentou ser flexível demais. Quando uma regra tem muitas exceções e subcondições, quem executa passa a interpretar livremente. O resultado apparente é inconsistência, mas na realidade o processo nunca teve limites claros. A correção costuma ser mais simples do que parece — restringir as regras, não ampliar o treinamento. Se você lida com isso em um contexto técnico, comece mapeando os pontos de decisão. Anote onde o fluxo pode bifurcar e quais são os critérios atuais para cada caminho. Em seguida, compare com os resultados reais. Onde a diferença é maior é onde você tem seu problema de ora uma coisa ora outra. Não precisa de ferramenta complexa. Uma planilha com as variantes identificadas e seus frequência já mostra o padrão.

O único cenário em que esse padrão é aceitável é quando a variabilidade é intencional e prevista — teste A/B, filas dinâmicas, sistemas de load balancing. Fora disso, inconsistência não é traço de inovação. É custo escondido.