Sujeito Que Não Presta Atenção Aos Detalhes

Quando o colega ignora o que está escrito em frente aos olhos

Tem gente que lê uma instrução de três linhas e erra duas. Eu já trabalhei com esse tipo de pessoa em revisão de código, em documentação técnica e em deploy de produção. O problema não é inteligência. É que o sujeito que não presta atenção aos detalhes enxerga o grosso e deixa escapar o resto. Isso causa prejuízo real. No meu dia a dia, a primeira coisa que eu faço é criar um checklist mínimo antes de qualquer entrega. Não é burocracia, é blindagem. Se você manda um arquivo de configuração sem revisar parâmetros, no final o serviço sobe torto e ninguém consegue achar onde errou em dez minutos.

O sujeito que não presta atenção aos detalhes e o custo disso

Eu vi um caso que durou três dias. Um parceiro recebeu um script de migração com cinco campos obrigatórios no cabeçalho. Ele preench quatro. O quinto era o código do cliente. O dado foi para a tabela errada, a query quebrou e o relatório mensal saiu com números de duas empresas diferentes. Levei mais de trinta horas pra rastrear o erro porque ele tinha assumido que "era só copiar e colar". Quando você trabalha com quem não revisa, o tempo que economiza na execução perde com juros no debugging. Isso é comum em ambientes onde a pressa é valorizada acima da precisão. Você pede uma revisão dupla e a pessoa faz no primeiro rascunho mesmo. Aí a gente entra no problema real.

Como eu lido com isso na prática

A técnica que funcionou pra mim foi simples: transformar o que é óbvio em obrigatório. Em vez de mandar um documento aberto, eu crio campos de entrada que só aceitam certos valores. Quando você trava o que pode ser inserido, não precisa confiar na atenção do outro. Também uso validação automática sempre que possível. Se o sistema rejeita um arquivo que falta um campo, o erro aparece na hora. Você não precisa cobrar a pessoa, o processo cobra por você. Isso reduz o tempo de correção de horas para segundos na grande maioria dos casos. O outro ponto é a comunicação escrita. Eu transformo instruções verbais em checkpoints visuais. Se alguém me diz "vai funcionar", eu peço pra mostrar o resultado esperado em números concretos. Nada de promessas genéricas. Eu quero ver o dado, o print, o log. Sem isso, vira achismo.

Tem um detalhe que quase ninguém menciona: o sujeito que não presta atenção aos detalhes muitas vezes erra nos mesmos lugares. Anote os padrões de erro. Se sempre falta o mesmo campo, sempre esquece a mesma validação, coloque uma barreira nesse ponto específico. Não adianta pedir "mais cuidado", isso não funciona. Funciona mudar o fluxo para que o erro seja impossível ou imediatamente visível. Outra coisa que ajuda é revisar em lotes pequenos. Quanto maior o material, menor a taxa de detecção de erros. Eu nunca testo mais de vinte linhas de uma vez. Depois de vinte, eu paro, respiro e volto. A atenção cai depois de certo tempo de exposição, isso é fato. Se a pessoa insiste em negligenciar revisões depois de você colocar mecanismos de proteção, aí o assunto muda. Você não resolve o problema dela, você só se protege do impacto. Documenta tudo, mantém evidências e encaminha para quem pode decidir se mantém ou não aquela dinâmica de trabalho.

O mercado cheio de gente assim não melhora sozinho. Mas quem sabe montar barreiras práticas costuma ter menos dor de cabeça e mais resultado no fim do mês.