Idea principal

Cuando un equipo constata que una especificación ya no está al día, el reflejo es ver en ello una falta de rigor. El mecanismo está en otra parte. En cada modificación, incluso menor, habría que encontrar la especificación correcta, la maqueta correcta, el documento de soporte correcto y la entrada de changelog correcta, y luego corregirlos todos. Ese trabajo es proporcional al número de artefactos, no al tamaño del cambio: corregir una etiqueta puede exigir tocar cinco documentos.

En un producto vivo, ajustado y enriquecido durante meses o años, la suma de esas resincronizaciones supera el tiempo disponible. Nadie decide dejar que las cosas diverjan; cada uno decide, una vez más, que no es a eso a lo que dedicará la próxima hora. La divergencia es el resultado acumulado de esos arbitrajes, todos razonables tomados de uno en uno.

Por eso la remediación por la disciplina no funciona: pide ganar un arbitraje de coste a base de voluntad.

Por qué es importante

Esto desplaza el lugar de la solución. Mientras la divergencia se lee como una negligencia, se responde con reglas, revisiones y recordatorios — que añaden coste a un gesto ya demasiado caro. Leída como un arbitraje de coste, pide una respuesta sobre el coste: reducir el número de artefactos que mantener, o reducir el precio de su actualización.

También evita atribuir a un equipo un defecto que pertenece a la estructura de su trabajo.

Matices y límites

El arbitraje no es igual de defendible en todas partes: un changelog entregado al cliente y una maqueta de trabajo interna no tienen la misma consecuencia cuando divergen. El coste ahorrado no se paga en el mismo sitio.

Y la demostración vale para un producto que evoluciona de forma continua. En un perímetro congelado, la resincronización es un coste puntual, y el argumento se cae.

Preguntas abiertas

• ¿Cómo medir el coste realmente pagado por una divergencia, para compararlo con el coste de mantenerla al día?