Sempre me pego pensando naquelas reuniões onde a gente tenta alinhar alguma coisa sobre padrões. Não são as reuniões de crise, onde tudo pega fogo e a gente só quer apagar o incêndio. São as outras, as que acontecem num dia normal, depois do almoço, quando o cafezinho já esfriou. A gente fala de convenções de código, de como documentar APIs, de testar melhor. Começa com uma boa intenção, claro. Alguém puxa o assunto, geralmente porque viu alguma inconsistência que causou um bug chato ou dificultou um deploy. E aí a conversa flui, com alguns se manifestando, outros quietos. E é nesse silêncio que eu me concentro. O silêncio não é desinteresse, nunca é. Pelo menos, não pra quem vive o dia a dia de verdade.
É um silêncio diferente. Não é o silêncio de quem não entendeu ou não se importa. É mais o silêncio de quem está calculando, avaliando o custo. A gente fala de “boas práticas”, de “refatoração”, de “débito técnico”. Palavras que, na teoria, fazem todo sentido. Mas na prática, cada um já tem a sua fila de tarefas, o seu backlog que não para de crescer. E o padrão novo, por mais benéfico que seja a longo prazo, significa um desvio de rota, um tempo a mais no curto prazo.
Lembro de uma vez, propusemos padronizar a forma como as mensagens de erro eram logadas. Parecia simples. “Vamos usar sempre este formato, com este nível de detalhe”. A ideia era facilitar o debug, o monitoramento. Na reunião, todo mundo concordou, assentiu com a cabeça. Nenhuma objeção explícita. Mas aí veio o que sempre acontece: a adoção foi lenta. Meses depois, ainda encontrávamos logs em formatos antigos, misturados com os novos. Não era má vontade. Era a inércia, a pressão do “precisa ir pro ar”. Era o desenvolvedor, na pressa, copiando um trecho de código antigo que já tinha a forma de logar, e nem se dando conta. Ou se dando conta, mas optando por não parar para ajustar, porque o “problema maior” era outro.
É um ciclo que se repete. A gente percebe que algo está desalinhado. Cria um padrão para alinhar. E aí o novo padrão vira mais uma coisa na lista de “coisas a fazer” que nunca têm prioridade máxima. Não é que o padrão seja ruim. É que ele surge como uma imposição, mesmo que velada. Surge como uma interrupção. “Agora você vai ter que mudar o jeito que faz isso”. E ninguém gosta de ser interrompido, ainda mais quando já está no limite.
Pensei sobre isso outro dia, vendo um code review. Um pedaço de código funcionava, entregava o que era esperado. Mas não seguia a convenção de nomenclatura que tínhamos “definido”. O revisor apontou, o autor ajustou. Pequena coisa, mas gerou um roundtrip a mais. O que se ganha com esse ajuste imediato? A satisfação de ver o padrão sendo seguido? Sim, mas e o custo para o autor, que precisou interromper o que estava fazendo, puxar a branch de novo, ajustar, testar, e subir? Multiplique isso por dezenas de pequenas coisas, e o impacto começa a pesar.
Talvez o ponto não seja “estabelecer padrões”, mas “integrar padrões”. Torná-los parte do fluxo natural, quase invisíveis. Aquela sensação de que o padrão já está lá, embutido nas ferramentas, nos templates, nos linters. Não como uma regra que você precisa lembrar, mas como um guarda-corpo que te impede de cair sem você sequer perceber que estava perto do abismo. Se o linter já apita quando a nomenclatura está errada, é menos um item para o revisor lembrar, e menos um atrito para o autor. Se o template do projeto já vem com a estrutura de logs definida, ninguém precisa reinventar a roda ou copiar algo desatualizado.
É um ajuste de perspectiva. Em vez de pensar “como fazer as pessoas seguirem o padrão”, talvez o ideal seja “como fazer o padrão seguir as pessoas”. Como ele pode se encaixar no dia a dia delas, no ritmo que já existe, sem criar fricção adicional. Como ele pode ser um facilitador silencioso, não uma exigência barulhenta. É sobre encontrar os pontos de dor, não os pontos de controle. Se um padrão resolve um problema que a equipe sente de verdade, a adesão é natural. Se ele resolve um problema que só faz sentido em uma discussão teórica de alto nível, a resistência é quase garantida.
A gente passa muito tempo nas reuniões falando o que precisa ser padronizado. Talvez devessemos passar mais tempo pensando como isso pode ser feito de forma orgânica, quase imperceptível. Menos sobre documentar uma regra em um wiki, e mais sobre automatizar a aplicação dessa regra. Menos sobre palestras e mais sobre ferramentas. É a diferença entre dizer “não pode fazer isso” e fazer com que “isso” seja um pouco mais difícil de fazer.
No fim das contas, a resistência não é contra o padrão em si. É contra o esforço extra, a interrupção, a sensação de que algo que já estava funcionando agora precisa de “melhoria” que não estava no planejamento. É contra a imposição de uma nova forma de fazer algo que já tinha uma forma, mesmo que imperfeita. E isso é algo que, como profissional de TI, eu entendo perfeitamente. Ninguém gosta de ter o fluxo interrompido.
Acho que ainda estou pensando sobre como as pessoas reagem a essas tentativas de organizar as coisas. É quase como um bug silencioso na comunicação, onde a intenção é boa, mas o efeito prático acaba sendo um overhead invisível que se acumula.
