Hoje eu trabalho com diagnóstico de governança corporativa, e a primeira reação de quase todo engenheiro ao ouvir isso é a mesma que eu tive: parece assunto de conselho, advogado e reunião comprida.
Depois de algum tempo dentro, a leitura mudou. Governança é o mesmo conjunto de problemas que a engenharia resolve todo dia, aplicado a pessoas em vez de a sistemas.
A tradução
Governança responde três perguntas sobre uma organização:
Quem pode decidir o quê. Isso é controle de acesso.
Como se sabe o que foi decidido e por quem. Isso é audit trail.
O que impede que uma pessoa sozinha cause dano irreversível. Isso é separação de responsabilidade e princípio do menor privilégio.
São exatamente os mesmos conceitos. A diferença é que num sistema você implementa em guard e constraint, e numa empresa se implementa em estatuto, alçada e comitê.
E as duas falham pelos mesmos motivos: permissão ampla demais, ausência de registro, e regra que existe no papel e não é verificada.
Por que empresa média sofre com isso
Empresa pequena não precisa de governança formal. Três sócios decidem tudo na conversa, e todo mundo sabe de tudo.
O problema aparece na transição. A empresa cresce, entra profissional de fora, o fundador não consegue mais estar em todas as decisões, e ninguém escreveu as regras porque nunca precisou.
O sintoma técnico é reconhecível: o sistema que funcionava com estado global e acoplamento total começa a quebrar quando mais gente mexe.
Empresa familiar tem uma camada a mais, e é a que mais complica. As relações se sobrepõem: a mesma pessoa é filha, sócia e diretora, e cada um desses papéis tem um interesse diferente. Sem separação explícita, a conversa de sucessão vira briga de família com dinheiro no meio.
O que significa medir maturidade
A parte que mais me interessou tecnicamente foi essa: como transformar algo aparentemente subjetivo em número comparável.
O caminho é o mesmo de qualquer avaliação séria. Você decompõe em dimensões, cada dimensão em subtemas, e cada subtema em perguntas com resposta numa escala definida. As respostas sobem hierarquicamente com pesos, e no fim existe um número por dimensão e um agregado.
O rigor vem de três lugares.
A pergunta precisa ser sobre evidência, não sobre percepção. “Existe ata das reuniões do conselho dos últimos 12 meses?” é verificável. “O conselho funciona bem?” é opinião.
Vários respondentes da mesma organização, com papéis diferentes. A divergência entre o que a diretoria acha e o que a operação acha é, sozinha, um dos achados mais úteis do diagnóstico.
E a escala precisa ter significado, não ser um número solto. Uma faixa de pontuação que corresponde a um estágio descrito, do informal ao estruturado, permite que o resultado vire plano de ação em vez de virar nota.
O paralelo que fecha
Diagnóstico de governança e auditoria de código são a mesma atividade.
Nos dois casos você entra num sistema que funciona, procura onde as regras estão implícitas, mede a distância entre o que se acredita e o que acontece de fato, e devolve um plano priorizado.
E nos dois casos o achado mais comum é o mesmo: não é que a regra esteja errada. É que ela nunca foi escrita, e cada pessoa tem uma versão dela na cabeça.
O que engenharia ganha entendendo isso
Duas coisas práticas.
A primeira é que muita exigência que chega como burocracia faz sentido quando você entende de onde vem. Alçada de aprovação, segregação de função, trilha de auditoria: tudo isso vira requisito de sistema, e implementar sem entender o porquê produz a versão que atende à letra e não ao propósito.
A segunda é de carreira. Quem entende como a empresa decide entende por que as prioridades mudam, por que aquele projeto foi engavetado e quem precisa ser convencido. Isso é a diferença entre reclamar da decisão e participar dela.
O ponto que eu levo dessa transição
Passei por e-commerce, infraestrutura de pagamento, viagens, logística e core banking antes de chegar em governança. Domínios muito diferentes, e o padrão que se repetiu em todos foi o mesmo: o gargalo raramente é técnico.
Governança é o nome que se dá pro conjunto de gargalos que não são técnicos, quando alguém finalmente resolve olhar pra eles com método.
E, como todo sistema, ela funciona melhor quando as regras são explícitas, verificáveis e conhecidas por quem opera. Que é exatamente o que a gente tenta fazer com código.