Por que profissionais nunca optimizam aquilo que mais entendem
A expressão "em casa de ferreiro o espeto é de madeira" descreve um padrão recorrente e muitas vezes frustrante em qualquer área de especialização. Um ferreiro que fabrica espetos de ferro para os outros, mas usa um espeto de madeira na sua própria mesa, porque madeira é mais barata, mais leve ou simplesmente porque não pensou nisso a tempo. O princípio aplica-se exactamente da mesma forma a programadores que constroem aplicações complexas enquanto a sua própria página de login continua a falhar. A aplicação funciona. O servidor aguenta tráfego. Mas o acesso é tão mau que ninguém quer entrar.
Em casa de ferreiro o espeto é de madeira
Isto não é preguiça. É um viés cognitivo. Quando alguém domina uma área, o cérebro tende a alocar energia e atenção para onde já há competência, não para onde existe a necessidade mais urgente. O que se torna invisível são as falhas básicas no próprio campo de actuação. Algo que um observador externo corrigiria em dez minutos passa despercebido por anos. Eu vi isto acontecer em primeiro lugar num projecto de interface de dados. A equipa passava semanas a refinar visualizações avançadas, gráficos interactivos, filtros compostos. O formulário de autenticação, que era usado por toda a equipa todos os dias, tinha campos desalinhados, labels confusos e um campo obrigatório sem explicação. Ninguém na equipa tocava nisso. O problema só foi resolvido quando convidei um designer para uma sessão de duas horas. Ele fez cinco alterações e o formulário ficou funcional. Eu estava no projecto há oito meses.
A lição prática é simples: quanto mais tempo passas dentro de um sistema, menor a probabilidade de ver as falhas mais óbvias. Isso acontece porque a familiaridade cria cegueira. O cérebro para de processar como novidades os elementos com os quais convive diariamente. O efeito cresce exponencialmente com a antiguidade no projecto. Existem contadores directos para este problema. Um deles é a técnica do teste de usabilidade com pessoas externas ao projecto. Pedir a alguém que nunca tocou na ferramenta para completar uma tarefa básica. O tempo que essa pessoa demora, os erros que comete e as perguntas que faz revelam instantaneamente o que a equipa interna não consegue ver.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro contador é forçar um rodízio de responsabilidades. Se cada membro da equipa passa uma semana a lidar com o suporte ou com os fluxos mais básicos que normalmente ignora, os pontos cegos desaparecem rapidamente. Este método consome tempo inicialmente, mas reduz o tempo médio de resolução de problemas críticos em cerca de 40% após dois meses de implementação. O risco de não fazer nada é concreto. Um projeto de consultoria que acompanhei perdeu três meses porque a equipa de backend optimizava queries complexas enquanto a base de dados crescia descontroladamente. O volume de dados não era problema novo. Era conhecido desde o início. Apenas ninguém da equipa de desenvolvimento se preocupava com isso, porque gestão de dados era responsabilidade de outra área. Quando o problema chegou ao ponto de ruptura, a solução mais rápida envolvia migração de infraestrutura. Custo estimado: quatro semanas de paralisação e 15 mil euros em serviços urgentes.
Outra armadilha comum é o efeito de zona de conforto profissional. Quem trabalha todos os dias com uma tecnologia específica desenvolve uma tendência a ignorar alternativas mais simples que resolvem o mesmo problema. Isto é particularmente visível em engenharia de software, onde é comum construir integrações complexas para funcionalidades que já existem noutras bibliotecas ou ferramentas mais simples. O resultado é código que ninguém mantém excepto quem o escreveu. Outro ponto que poucos mencionam: a expressão também se aplica a áreas fora do trabalho. Pessoas que resolvem problemas financeiros para clientes mas não organizam as próprias finanças. Arquitetos que desenham edifícios funcionais mas vivem em espaços caóticos. Médicos que tratam milhares de pacientes mas negligenciam os próprios exames de rotina. O padrão é sempre o mesmo. A especialização gera pontos cegos intencionalmente.
Se precisas de aplicar isto no teu contexto actual, o primeiro passo é mapear as áreas em que tens mais experiência e listar especificamente o que estás a ignorar nelas. Não de forma genérica. Lista concreta: quais funcionalidades, processos ou decisões estão atrasadas ou mal feitas na tua própria operação? Depois, atribui uma pessoa externa ao projecto para avaliá-las durante uma semana. O relatório resultante costuma revelar entre três a sete problemas críticos que a equipa interna não conseguia enxergar. Existe uma limitação importante neste tipo de abordagem. Ela funciona bem para problemas operacionais e de usabilidade. Funciona mal para problemas estruturais profundos que exigem mudanças de paradigma, pois mesmo observadores externos tendem a normalizar o que veem todos os dias. Nestes casos, a única saída é contratar consultoria especializada de fora do sector, não de dentro.
O princípio continua a ser útil porque revela algo que pouca gente quer admitir: a competência extrema cria vulnerabilidades específicas. Reconhecer isso evita desperdício de tempo e dinheiro. E, às vezes, resolve o problema que estava bloqueado há meses antes mesmo de começar a procurar solução.
