O Que Ser Pragmatico

O problema de quem começa a tentar ser pragmático

A maioria das pessoas escuta o conceito e imediatamente entra em espiral de autocrítica. Percebe que não consegue decidir rápido, que gasta tempo demais planejando algo simples, que acaba entregando trabalho meio pronto porque queria que ficasse perfeito. Isso é normal. O que ser pragmatico não tem nada a ver com eficiência pura, como muitos vendem em conteúdo motivacional. Tem a ver com uma disciplina dolorosa de corte. Eu passei anos trabalhando com desenvolvimento de software e gestão de produtos. Em 2019, peguei um projeto interno que deveria ser entregue em três semanas. Eu tinha desenhado uma arquitetura para o módulo de autenticação que levava dois dias para implementar. Dois dias, em um cronograma de três semanas, com toda a dependência concentrada naquela única peça. Meu time já estava atrasado em outra frente. Eu poderia ter insistido na solução elegante, que seria tecnicamente sólida e facilmente extensível. O prazo morreu de qualquer forma. Entregamos com um login por token JWT hardcodado, valendo apenas para o domínio interno da empresa, com uma linha de comentário avisando que precisaria ser refeito depois. A solução funcionou, a equipe entregou todo o resto no prazo, e a refatoração veio duas semanas depois quando o projeto já estava em produção com usuários reais.

o que ser pragmatico na prática

Ser pragmático significa escolher a opção que resolve o problema com o menor esforço necessário, considerando restrições reais de tempo, recursos e impacto. Não é o oposto de qualidade. É o oposto de perfeccionismo disfarçado de excelência técnica. Na prática, você para de perguntar qual seria a melhor solução possível e começa a perguntar qual é a menor solução que atende ao critério de aceitação do stakeholder. O primeiro passo prático é mapear restrições antes de qualquer decisão. Tempo disponível, orçamento, competências da equipe,Dependencies externas, deadline rígido ou flexível. Eu uso uma folha simples com cinco colunas: escopo mínimo, deadline, riscos aceitáveis, alternativas recusadas e critério de sucessopara marcar como pronta. Parece exagero para uma decisão pequena, mas o formato força você a justificar para si mesmo cada corte que está prestes a fazer. Sem esse exercício, a maioria das pessoas simplesmente toma decisões baseadas em intuição e depois culpa o resultado como se fosse azar. O segundo passo é definir o critério de suficiência antes de começar. O que é suficiente para considerar o trabalho como completo? Se você está construindo uma landing page, o suficiente pode ser que o formulário de contato envie um email e abra em pelo menos dois navegadores. Se você está escrevendo um relatório, o suficiente pode ser que contenha três fontes distintas e responda diretamente às perguntas do gestor. Essa definição deve ser feita antes de qualquer trabalho prático, senão você vai continuar ampliando o escopo conforme avança e nunca vai alcançar o fim.

Armadilhas que ninguém conta

A principal armadilha do pragmatismo é a ilusão de que cortar esforços gera economia líquida. Na realidade, cortes mal avaliados criam débito técnico que cobra juros altos. Quando eu fiz aquele login hardcodado em 2019, sei que iria precisar ser refatorado. Sabia disso no momento da decisão. O pragmatismo não se resume ao presente imediato; ele inclui o custo futuro da decisão. Se você corta algo que vai quebrar em produção dentro de uma semana, isso não é pragmatismo, é improvisação. O diferencial é saber quando o risco futuro é baixo o suficiente para assumir. Outra armadilha comum é confundir pragmatismo com preguiça disfarçada. Existem decisões que pedem simplicidade e outras que pedem robustez. Um script que roda uma vez na vida do projeto não precisa de tratamento de exceção elegante. Um serviço que roda 24 horas por dia em produção precisa. A distinção exige maturidade para ler o contexto. Comece a treinar isso fazendo uma pergunta obrigatória antes de qualquer entrega: qual é a probabilidade disso ser usado novamente e em que escala? Se a resposta for baixa para ambas as perguntas, simplify. Se a resposta for alta, invista o tempo extra. Eu já vi equipes aplicarem pragmatismo em situações em que o contexto exigia o oposto total. Um caso específico que me marcou envolve uma API interna de pagamento. A equipe decidiu usar uma implementação simples com chamadas HTTP diretas ao gateway, sem fila de retry, sem circuit breaker, sem log estruturado. O argumento era que o sistema seria usado internamente e o tráfego seria baixo. Dois meses depois, o gateway teve uma instabilidade de 47 minutos. Todas as transações daquela janela foram perdidas. Zero log, zero retry, zero rastreabilidade. O custo daquela decisão pragmática mal aplicada foi de aproximadamente R$ 120 mil em vendas canceladas e horas extras de emergência para reconstruir os registros manualmente. Se aquela API tivesse um sistema de fila com retry exponencial e logging adequado, o tempo de implementação teria dobrado, mas o risco de perda total seria praticamente nulo. Pragmatismo, nessa situação, teria sido aplicar o padrão correto desde o início.

ferramentas úteis para praticar

Não existe software milagroso para isso. As ferramentas mais úteis são basicamente anotação e conversa. Eu costumo manter um caderno físico de decisões com data, problema, opções consideradas, decisão tomada, justificativa e data de revisão. A revisão é o que transforma o caderno de um diário bonito em uma ferramenta real. Defina uma data automática de revisitada para cada anotação — duas semanas para decisões rápidas, trinta dias para decisões estruturais. Quando chegar a data, reabra a anotação e pergunte se a decisão ainda faz sentido. Na maioria das vezes, ela faz. Às vezes, você percebe que mudou de ideia por boas razões e atualiza o registro. Esse hábito custa cerca de quinze minutos por semana e reduz drasticamente a quantidade de decisões questionáveis que persistem por anos. Outra prática útil é o brainstorm reverso. Antes de fechar uma solução, liste mentalmente todas as formas pelas quais ela pode falhar. Não de forma dramática, apenas de forma sistemática. Cada ponto de falha identificado é uma oportunidade de ajustar a solução antes de implementá-la. Em geral, esse exercício leva entre cinco e dez minutos e evita horas de retrabalho posterior. Para medição, eu uso uma métrica simples chamada taxa de retrabalho. É a proporção de tarefas que precisam ser refeitas, ampliadas ou corrigidas significativamente após a entrega inicial. Se essa taxa estiver acima de vinte por cento durante dois meses consecutivos, o pragmatismo está funcionando mal e você está cortando esforço demais. Se estiver abaixo de cinco por cento, provavelmente está sendo excessivamente cauteloso e gastando mais do que o necessário. A zona ideal fica entre oito e quinze por cento, variando conforme o tipo de trabalho.

Aprender o que ser pragmatico leva tempo. Não é um interruptor que se liga. É um músculo que se desenvolve com revisão constante, falhas observadas e ajustes deliberados. A maioria das pessoas nunca chega a dominar completamente, e isso é okay. O importante é estar ciente de onde você está no espectro entre perfeccionismo paralisante e improvisação irresponsável. O espaço util entre esses dois extremos é onde o trabalho útil acontece.