A Pressa É Inimiga Da Perfeição

O custo real de tentar fazer rápido demais

Eu já perdi três dias de trabalho em cima de um deploy que deveria levar vinte minutos. O problema começou quando eu tentei acelerar um release de produção pulando etapas de validação porque o prazo estava apertado. O resultado foi um rollback às três da manhã e uma reunião constrangedora na segunda. A expressão "a pressa é inimiga da perfeição" existe há séculos justamente porque pessoas repetidamente aprendem essa lição na unha. O conceito central aqui é simples: quando você reduz deliberadamente o tempo dedicado a uma tarefa, os erros que aparecem tendem a custar mais do que o tempo que você supostamente economizou. Isso não é filosofia. É matemática aplicada à produção real. Na prática, eu uso um procedimento bastante específico antes de qualquer entrega. Primeiro, faço uma checklist de verificação baseada em erros que cometi no projeto anterior. Segundo, aplico a regra dos 15 minutos: nada sai da minha mesa (ou do repositório, no caso de código) antes de eu reler ou revisitar tudo uma segunda vez, com uma pausa mínima nesse intervalo. Terceiro, whenever possível, peço para outra pessoa dar uma olhada. Não precisa ser uma revisão formal. Um olhar fresco de dez minutos pega coisa que eu passei três horas sem ver.

A parte que quase ninguém menciona é que velocidade e qualidade não são simplesmente opostas. Existe um ponto ótimo. Trabalhar desesperadamente lento também gera erro, porque a atenção degrade com o tempo. O segredo é administrar o ritmo, não simplesmente correr mais devagar cegamente. Um exemplo concreto que ilustra bem isso: num projeto de automação de testes, eu costumava escrever todos os testes de uma vez, sem rodar o suite entre cada classe. Isso era rápido no início, mas os falsos positivos acumulavam e na hora do release eu gastava horas depurando algo que na verdade era um problema de infraestrutura, não de código. Mudei para um fluxo onde cada módulo era testado individualmente antes de integrar. Ganhava cerca de vinte minutos por ciclo, mas economizava pelo menos duas horas de debugging posterior. O custo do teste isolado é menor do que o custo do teste integrado falhando em produção. Outro detalhe prático que faz diferença: anotar decisões. Quando você está com pressa, toma atalhos mentais que parecem logicos no momento. Trinta minutos depois, você não lembra por quê. Um arquivo de decisão com três linhas por item elimina metade dos erros de retrabalho em projetos médios. Eu mantenho isso num markdown simples dentro do repositório mesmo quando o projeto não é de software.

Agora, preciso ser honesto sobre as limitações. Esse enfoque não funciona em todos os cenários. Situações de resposta a incidentes exigem velocidade extrema e a perfeição entra explicitamente como secundária. Processos criativos iniciais, como brainstorming ou prototipagem rápida, também se beneficiam de um certo grau de pressa controlada. O problema é que esses casos são exceção, não regra, e muitas pessoas aplicam a lógica errada no momento errado. Uma visão contra-intuitiva que muitos não consideram: a pressa às vezes nasce de expectativas irreais impostas por terceiros, não de escolha pessoal. Em ambientes onde prazos são fixos arbitrariamente, culpar oexecutor pelo resultado perfeccionista é injusto e ineficaz. A solução real, nesse caso, é negociar escopo ou recursos, não melhorar a disciplina individual. Isso é óbvio dito, mas raramente resolvido na prática porque a dinâmica de poder não permite. Se você quer uma métrica simples para saber se está cometendo o erro clássico, use a taxa de retrabalho. Se mais de 15% do seu tempo em um sprint é gasto corrigindo coisas que passaram pela primeira revisão, você tem um problema sistêmico de pressa mal gerenciada, não falta de habilidade. Ajuste o processo, não apenas a atitude.