O que acontece quando todo mundo decide que regras são opcional
Eu comecei a notar isso em 2018, num projeto de integração entre três times de desenvolvimento que não conversavam entre si. Cada um seguia seu próprio padrão de nomenclatura, suas próprias convenções de commit, seus próprios caminhos de deploy. O resultado foi um caos que levou seis semanas para ser contido. Ninguém estava sendo mal-intencionado. Apenas achavam que regras eram burocracia desnecessária quando se trabalha com gente competente. Isso não é uma exceção. Achei que fosse, até ver o mesmo padrão se repetir em diferentes formatos ao longo dos anos.
Por que as regras são importantes
Regras existem porque a memória humana é falha e o contexto muda rápido demais para confiar na boa vontade individual. Quando alguém new join entra num projeto, as regras são o que permitem que ele entenda o que está acontecendo em menos de duas horas. Sem regras, esse tempo sobe para dois dias, no mínimo. A diferença é entre entregar no prazo e entregar nada. O que a maioria das pessoas não considera no início é que regras não servem só para evitar erros. Elas servem para criar velocidade repetitiva. Uma regra bem desenhada faz com que decisões triviais deixem de existir como decisões. Você para de gastar energia cognitiva escolhendo entre opções óbvias e gasta onde realmente importa.
Aqui vai uma coisa que ninguém conta: regras muito rígidas quebram. Eu vi times inteiros adoecerem porque seguiram um checklist como se fosse sagrado. No meu caso, tínhamos uma regra de code review que obrigava dois aprovers em todas as mudanças. Funcionou bem por uns meses. Aí veio um bug crítico de segurança que precisava de hotfix. O segundo aprovador estava em férias, sem acesso à rede, e o bug ficou exposto por doze horas porque a regra não tinha exceção definida. A solução foi criar um fluxo de emergência com log automático, mas o custo foi alto. Regras precisam ter pontos de fuga. Sem isso, elas viram armadilhas.
Como implementar regras que funcionam de verdade
A primeira coisa errada que as pessoas fazem é escrever regras sem testá-las. Elas passam duas horas documentando um processo que ninguém vai seguir porque não consideraram o contexto real de trabalho. A abordagem correta é diferente: escreva a regra mais simples possível, aplique durante duas semanas, e ajuste com base no que quebrou. Passo um: identifique onde os erros mais caros acontecem. Não onde os erros mais frequentes acontecem. Frequência não é igual a custo. Um erro que ocorre uma vez por trimestre e custa quarenta horas de correção é mais importante do que dez erros pequenos por semana que levam cinco minutos cada. Meus primeiros rascunhos de regras sempre focavam nos errinhos chatos. Levei seis meses pra entender a diferença.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Passo dois: escreva a regra como uma sentença condicional clara. Se X, então Y. Não se espera que X seja atendido, faia Z com o approver alternativo. A ambiguidade é onde as regras morrem. Quando você escreve "seguir boas práticas de segurança", ninguém sabe o que fazer. Quando você escreve "todo input do usuário deve ser sanitizado antes de passar para o banco", todo mundo sabe o que fazer. Passo três: torne a regra visível no momento da decisão. Regra que está num PDF interno com link no Slack não existe na prática. Ela tem que estar no pipeline, no editor de código, no template de documentação. Onde a pessoa vai clicar ou digitar. Se a regra não estiver no caminho natural de trabalho, ela é apenas literatura.
Passo quatro: crie um mecanismo de revisão periódica. Toda regra deve ter uma data de validade implícita ou explícita. Eu costumo colocar uma data de reavaliação de seis meses a partir da criação. Quando chega essa data, alguém precisa responder: esta regra ainda resolve o problema que deveria resolver? Se a resposta for "não sei", a regra já está morta, só não sabem disso ainda.
O que as regras não resolvem
Regras não substituem julgamento. Esse é o erro mais caro que eu já vi acontecer. Times que pensam "temos regras agora, não precisamos mais de senioridade" colidem com problemas que estão fora do escopo do que foi documentado. Um regra cobre o que você conhece. Ela nunca cobre o que você não prevê. Também não adianta esperar que regras criem cultura sozinhas. Cultura é comportamento observado, não comportamento descrito. Se os líderes do time ignoram as regras nos momentos decisivos, todo mundo vai ignorar também. Já vi isso happenar com regras de segurança da informação. O CTO achava que verificar logs era perda de tempo e pedia para "deixar correr". Os juniors aprenderam a lição certa muito rápido.
E tem um limite quantitativo também. Acima de cerca de doze regras ativas por time, a compliance cai drasticamente. Não é uma lei física, é observação prática. As pessoas simplesmente param de lembrar de todas. Aí você precisa escolher quais regras realmente importam e abandonar o resto. Isso é difícil de fazer porque todo mundo acha que a regra que criou é essencial. Quando você precisa de flexibilidade extrema e o custo de seguir regras fixas é alto, considere usar checklists em vez de regras permanentes. Checklists são listas de verificação para situações específicas, não princípios gerais. Eles têm o mesmo efeito protetivo sem a rigidez de uma regra universal. Minha experiência com checklists em incidentes de produção mostra que eles reduzem erros de omissão em algo em torno de oitenta por cento. Regras equivalentes escritas como policy documentariam o mesmo comportamento, mas exigiriam interpretação em cada ocasião, o que introduz variância.
O ponto é simples: regras são ferramentas, não filosofias. Use-as onde adicionam valor. Descarte-as onde adicionam atrito. E monitore isso constantemente, senão você termina com um sistema que protege contra o último incidente em vez de preparar para o próximo.
