Na medida do possível: o que funciona quando a perfeição não existe
A maior parte dos projetos não termina bem porque as pessoas esperam condições ideais para começar. Eu vi isso acontecer em escala pequena e grande. Um colega meu tentou implantar um novo sistema de versionamento num time de oito pessoas. Ele documentou tudo, pediu pausa nas entregas por duas semanas e ainda assim ninguém adotou. O problema não era a ferramenta. Era a expectativa de que tudo precisaria estar perfeito antes de tocar. Na medida do possível é uma abordagem prática para tomar decisões com informação incompleta, recursos limitados e prazos apertados. Não é sobre aceitar mediocridade. É sobre reconhecer que a maioria das escolhas no mundo real é feita sob pressão de tempo e incerteza, e que adiar uma decisão boa até ter certeza absoluta geralmente resulta em nenhuma decisão.
A diferença entre na medida do possível e improvisação
Muita gente confunde os dois. A improvisação é agir sem plano algum. Na medida do possível tem estrutura. Você identifica o que é fixo e imutável, o que é flexível, e o que pode ser revisto depois. O que é fixo em qualquer projeto costuma ser: requisitos regulatórios, dependências externas que você não controla, e contratos assinados. O que é flexível varia de projeto para projeto. Tempo, escopo, qualidade percebida do resultado final. Eu aplico esse raciocínio em praticamente tudo. Quando precisei migrar um banco de dados PostgreSQL de 400 gigabytes para uma nova infraestrutura num data center diferente, na verdade o plano original era manter o sistema offline por 72 horas. Na medida do possível, eu pesquisei e encontrei uma solução de replicação lógica que permitia manter o serviço rodando com apenas 14 minutos de downtime para o apontador final de DNS. Não era o plano ideal. Era o plano que funcionava com as restrições que tínhamos. A opção teria sido cancelá-lo ou aceitar o impacto no negócio.
Como estruturar uma decisão na medida do possível
O processo é simples na teoria e difícil na prática porque exige honestidade. Você começa listando todas as variáveis do problema. Não as soluções. As variáveis. Em seguida, você classifica cada uma como rígida, negociável ou irrelevante para a decisão atual. Variáveis rígidas não entram em negociação. Variáveis negociáveis têm margem. Variáveis irrelevantes são descartadas da conversa imediatamente. Aí você faz a parte mais importante, que a maioria das pessoas pula: você define qual é o mínimo aceitável. Não o ideal. O mínimo. Se o resultado final não atingir esse patamar, a decisão não é válida, independente de quão rápida ou barata ela foi. Esse mínimo funciona como uma âncora contra a tendência natural de aceitar qualquer coisa que pareça confortável no momento.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Depois de estabelecido o mínimo, você considera as opções disponíveis e seleciona a que entrega mais valor dentro das restrições rígidas, sem violar o patamar mínimo. Isso geralmente elimina 80 por cento das alternativas logo de cara. O que sobra é pequeno o suficiente para uma análise séria.
Onde essa abordagem falha
Funciona mal em situações onde o tempo de decisão é extremamente curto e o custo do erro é alto simultaneamente. Cirurgia, controle de tráfego aéreo, sistemas nucleares. Nesses cenários, o modelo na medida do possível simplesmente não se aplica porque não há margem para revisão posterior. Usar essa mentalidade em contextos de segurança crítica é irresponsável. Também falha quando aplicado de forma consistentemente como desculpa para falta de planejamento. Se toda decisão importante no seu time segue o discurso "fazemos na medida do possível", eventualmente você descobre que nunca planejou nada com rigor. A abordagem exige disciplina para funcionar. Sem ela, vira sinônimo de desorganização disfarçada de pragmatismo.
Erros comuns que eu vejo acontecendo
O primeiro erro é tratar variáveis negociáveis como se fossem rígidas. Pessoas se apegam a ferramentas, metodologias ou processos específicos e transformam isso em constraint imutável. Se você decide que precisa usar Kubernetes porque "é o padrão da indústria", você acabou de criar uma restrição rígida artificial que provavelmente não existe. Remova-a da lista e reavalie. O segundo erro é definir o mínimo aceitável depois de escolher a opção, não antes. Isso é viés de confirmação disfarçado de pragmatismo. Você já escolheu o que queria fazer e agora está inventando justificativas. O mínimo deve ser definido antes de qualquer opção ser considerada, preferencialmente por alguém que não tenha interesse emocional no resultado.
O terceiro erro é não revisar as decisões tomadas na medida do possível quando as condições mudam. Uma escolha feita com informações incompletas continua válida apenas enquanto as premissas continuarem verdadeiras. Quando uma variável rígida se torna negociável ou vice-versa, a decisão precisa ser reavaliada. Ignorar isso é o caminho mais rápido para acumular débito técnico ou operacional. A utilidade real dessa mentalidade aparece quando você para de esperar que as coisas estejam certas antes de agir. Elas nunca vão estar. O importante é saber qual é o piso inegociável e construir a partir dali.
