A lei de Conway é uma ferramenta, não uma maldição

A lei de Conway diz que a estrutura de um sistema espelha a estrutura de comunicação da organização que o constrói. A maioria dos engenheiros cita isso como lamento: 'claro que a API é uma bagunça, olha como os times estão divididos'. Eu leio ao contrário. Se a estrutura do sistema segue a estrutura dos times, então estrutura de time é ferramenta de arquitetura, e eu posso usá-la.

Isso não é assunto de gestão. É o instrumento de refatoração mais poderoso disponível para um arquiteto, e não exige tocar em uma linha de código.

A lei funciona nas duas direções

A leitura comum é que times moldam sistemas. Três times constroem três serviços, e as fronteiras dos serviços caem exatamente onde os times param de conversar. Essa parte está bem documentada e eu vejo em toda auditoria: as costuras no código batem com as costuras nos convites de reunião.

A direção menos discutida é que sistemas moldam times. Depois que os três serviços existem, eles definem quem fala com quem. Um recém-contratado entra no 'time do serviço de pagamentos', e a fronteira agora se reforça sozinha. Mesmo que a divisão original estivesse errada, a organização se adaptou a ela, e o cargo de cada pessoa depende de ela continuar existindo.

É por isso que mudanças de arquitetura fracassam quando tentadas como mudanças puramente de código. Você não consegue fundir dois serviços em um módulo enquanto os dois times ainda têm backlogs separados, escalas de plantão separadas e gestores separados. O código vai se afastar de novo em dois trimestres, porque a organização que o produz não mudou.

A manobra inversa

O movimento prático se chama manobra inversa de Conway: decida qual estrutura de sistema você quer, depois organize os times para produzi-la. Se você quer que checkout e pagamentos sejam um módulo coeso com um único contrato para o mundo externo, coloque as pessoas que constroem os dois em um time só, com um backlog só. O código vai acompanhar, não por decreto, mas porque as conversas diárias agora atravessam a fronteira antiga.

Já recomendei isso mais vezes do que recomendei reescrita, e funciona com mais frequência. Uma reescrita briga com a organização. Uma reorganização a recruta.

Ela também expõe fronteiras falsas. Se dois serviços só podem ser mantidos pelas mesmas três pessoas, são um serviço que por acaso faz deploy duas vezes. Se um 'time de plataforma' é dono de uma biblioteca compartilhada que todo time de produto modifica semanalmente, a biblioteca não é plataforma, é gargalo de coordenação, e o organograma está mentindo sobre quem é dono de quê.

Onde vejo dar errado

A falha mais comum é dividir times por camada técnica. Time de frontend, time de backend, time de dados. A lei de Conway então produz um sistema com três camadas que precisam mudar para toda funcionalidade, com três repasses por funcionalidade. O resultado é um sistema cujas fronteiras não protegem nada, porque nenhuma mudança de negócio vive dentro de uma delas.

A segunda falha é dividir por quantidade de pessoas em vez de por domínio. Um time chega a doze, então vira dois de seis, e a divisão é traçada onde for politicamente mais fácil. A fronteira de serviço resultante não tem significado de domínio. Seis meses depois, os dois times estão em todas as reuniões juntos porque toda mudança cruza a linha.

A terceira é ignorar a lei ao contratar terceiros ou agências. Um time externo que constrói um módulo isolado produz um módulo isolado: convenções próprias, tratamento de erro próprio, ideia própria do que é um cliente. Isso é a lei de Conway de novo, e é previsível. Se você quer que o módulo se integre, alguém do time principal precisa estar na sala toda semana.

As perguntas que levo para a liderança

Quando audito um sistema e encontro um problema estrutural, pergunto sobre os times antes de propor uma mudança de código. Quem é dono dessa fronteira? Quem precisa concordar para ela se mover? Quais dois times brigam com mais frequência, e a briga é sobre uma linha que não deveria existir?

Depois desenho duas figuras: o sistema como o código mostra, e o sistema como o organograma sugere. Onde elas discordam, é onde está a dor, e geralmente é onde vai acontecer o próximo incidente.

A correção costuma ser desconfortável, porque significa mudar quem reporta para quem, que é uma conversa mais difícil do que em qual pasta um arquivo fica. Mas é a correção que dura. Desenhe o organograma de propósito, e a arquitetura vai segui-lo. Ela sempre ia seguir.