Ideia principal

Quando um time percebe que uma especificação não está mais atualizada, o reflexo é enxergar aí uma falta de rigor. O mecanismo está em outro lugar. A cada modificação, mesmo pequena, seria preciso reencontrar a especificação certa, o protótipo certo, o documento de suporte certo e a entrada de changelog certa, e depois corrigir tudo. Esse trabalho é proporcional ao número de artefatos, não ao tamanho da evolução: corrigir um rótulo pode exigir mexer em cinco documentos.

Em um produto vivo, ajustado e enriquecido durante meses ou anos, a soma dessas ressincronizações ultrapassa o tempo disponível. Ninguém decide deixar as coisas divergirem; cada pessoa decide, mais uma vez, que não é isso que vai fazer na próxima hora. A divergência é o resultado acumulado dessas arbitragens, todas razoáveis quando tomadas uma a uma.

É por isso que a remediação pela disciplina não funciona: ela pede para vencer uma arbitragem de custo na força de vontade.

Por que isso importa

Isso desloca o lugar da solução. Enquanto a divergência é lida como negligência, respondemos com regras, revisões e lembretes — que acrescentam custo a um gesto que já é caro demais. Lida como uma arbitragem de custo, ela pede uma resposta sobre o custo: reduzir o número de artefatos a manter, ou reduzir o preço da sua atualização.

Isso também evita atribuir a um time um defeito que pertence à estrutura do seu trabalho.

Nuances e limites

A arbitragem não é igualmente defensável em todo lugar: um changelog entregue ao cliente e um protótipo de trabalho interno não têm a mesma consequência quando divergem. O custo economizado não é pago no mesmo lugar.

E a demonstração vale para um produto que evolui continuamente. Em um escopo congelado, a ressincronização é um custo pontual, e o argumento cai.

Questões em aberto

• Como medir o custo realmente pago por uma divergência, para compará-lo ao custo da manutenção?