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

Como lidar com pessoas que passam por alto o que importa

Existe um tipo de colaborador que você encontra em qualquer equipe de tecnologia ou engenharia: aquele que lê o título, pula o parágrafo e entrega trabalho com erros bobos. Formulários não preenchidos até o final. Parâmetros invertidos em funções. Nomes de variáveis que não dizem respeito ao que a função faz. O problema não é a falta de inteligência. É a falta de um hábito de revisão que não se improvisa. Eu já passei mais tempo do que gostaria corrigindo entregas assim. Um exemplo específico que não sai da minha cabeça: em 2022, recebi um script de automação para migração de um banco legado. O código funcionava. Mas o cara tinha colocado o hostname do banco de produção dentro de uma constante chamada HOSTNAME_BK em vez de HOSTNAME_PROD. O backup rodava limpo, os logs não mostravam erro nenhum, e só descobrimos quando o script tentou ler dados de um ambiente que já tinha sido desligado. Eu gastei uma tarde inteira rastreando porque o índice de leitura estava zerado, quando na verdade a connection string era a única coisa errada. A solução foi simples, mas demorada: padronizei nomes de variáveis com um prefixo obrigatório por ambiente e adicionei um check inicial que valida todas as credenciais antes de rodar qualquer operação. Isso acabou virando padrão no time.

O sujeito que não presta atenção nos detalhes e o custo real do trabalho mal revisado

A maioria das pessoas subestima o impacto de pequenos deslizes. Parece besteira, mas detalhes são o que separam um processo confiável de um processo que depende exclusivamente da sorte de não dar ruim. Não estou falando de perfeccionismo patológico. Estou falando de criar uma barreira mínima entre o que foi escrito e o que será executado no mundo real. Quem não prestava atenção aos detalhes costuma ter um perfil comportamental previsível. Trabalha rápido. Senta na cadeira e não reseta a mente antes de entregar algo. Confia que "está bom o suficiente". E aqui está o ponto que poucos entendem: o problema não é a velocidade. O problema é a ausência de um gate de qualidade pessoal. Você pode ser veloz e ainda assim revisar seu próprio trabalho se tiver um procedimento fixo.

Na prática, a técnica que funciona melhor não é cobrar atenção. É criar checkpoints obrigatórios. Recomendo o seguinte fluxo: Primeiro, o revisor deve ler o trabalho de trás para frente quando se trata de código ou documentação. Isso quebra o padrão cognitivo e força o cérebro a processar cada linha isoladamente, em vez de completar automaticamente o que deveria estar ali. Eu aplicava isso em revisões de pull request e reduzia significativamente a quantidade de erro fino que passava despercebido.

Segundo, antes de considerar algo entregue, o responsável deve responder a três perguntas escritas: o que eu fiz, o que eu testei e onde pode falhar. Se a terceira resposta for "não sei", o trabalho não está pronto para revisão. Simples assim. Essa última parte é a que mais salva projetos. A maioria dos erros graves vem de alguém que não sabia onde o código poderia quebrar. Um insight contraintuitivo que aprendi na prática: pessoas desatentas costumam ser boas ideias criativas. Elas enxergam o macro enquanto ignoram o micro. Tentar transformar todo mundo num ser meticuloso é perder tempo e energia. O jeito é separar funções. Quem tem esse perfil faz brainstorming, arquitetura inicial e prototipagem rápida. Quem precisa de meticulosidade faz revisão, testes e implementação final. Trabalhar contra a natureza das pessoas só gera frustração e entrega pior.

O outro lado da moeda, e preciso ser honesto aqui, é que mesmo com checklist e gate de qualidade, erros acontecem. Checklist é ferramenta, não mágica. Se o processo for muito pesado, as pessoas começam a preencher por preencher e o risco aumenta, não diminui. Já vi times onde o checkup de revisão virava uma burocracia de quarenta campos que ninguém lia. Nesses casos, a solução foi cortar o formulário pela metade e focar apenas em três pontos críticos: segurança, integridade dos dados e funcionalidade principal. Menos campos, mais responsabilidade em cada um. Se você lida com sujeito que não presta atenção nos detalhes no seu dia a dia, considere usar revisão em pares com rotação semanal. Isso tira a pressão de uma única pessoa e cria um circuito de verificação natural. Funciona especialmente bem em equipes de até oito pessoas. Acima disso, a rotação perde eficácia porque o conhecimento contextual se dispersa.

Uma ferramenta útil é o código de cores em documentos compartilhados. Vermelho para campos obrigatórios que precisam de validação, amarelo para pontos de atenção que exigem confirmação, verde para itens já verificados. Visual é mais rápido do que texto para pessoas que tendem a pular informações. Eu implementei isso em documentos de especificação técnica e vi o tempo de retrabalho cair de uma média de quatro horas por sprint para cerca de quarenta minutos. Claro que isso depende do volume de entregas, mas a diferença é consistente. Também é importante reconhecer quando não vale a pena insistir. Às vezes o erro é pequeno demais para justificar o esforço de correção. Se uma planilha tem uma célula errada mas o relatório final não é afetado, reclamar da célula não muda nada. Aprenda a discernir o erro crítico do erro cosmético. Gastar energia nos dois igual é o caminho mais rápido para o burnout.

O que resta, na prática, é entender que lidar com esse perfil exige estrutura, não reclamação. Criei processos, adotei padrões de nomenclatura, implementei validações automáticas e deixei de tentar mudar a pessoa. Resultado: menos dor de cabeça e mais trabalho entregue com qualidade aceitável.