Idea principal

A una especificación, un PRD o una maqueta se les acusa de mentir en cuanto se descubre la distancia entre lo que anuncian y lo que el producto hace. La acusación apunta al objeto equivocado: esos documentos no se equivocaron, dejaron de ocupar la función para la que fueron escritos.

Antes de la puesta en producción, una especificación sirve al diálogo. Da al Product Manager, a los desarrolladores y a las áreas de negocio algo que rebatir: permite explorar una hipótesis, acotar un perímetro, hacer aparecer un desacuerdo antes de que cueste caro, decidir. Su valor no está en su exactitud, sino en su capacidad de provocar objeciones: un documento que nadie ha discutido ha fracasado aunque describa exactamente lo que se entregará.

El paso a producción le retira esa función. Los compromisos asumidos durante el desarrollo, los casos límite descubiertos, los arbitrajes resueltos en una merge request han entrado en el producto sin volver a pasar por el documento. Lo que decía del comportamiento ya no es una propuesta que discutir: es una descripción que compite con la que lleva el repositorio, y que pierde. El artefacto no se vuelve falso, se vuelve regenerable: lo que enuncia del comportamiento se reconstruye desde el código, y mantenerlo a mano equivale a cuidar un duplicado que deriva.

El vuelco tiene fecha, por tanto, y no es la fecha de redacción. Un mismo documento es legítimo antes de la entrega e ilegítimo después, sin que ninguna de sus frases haya cambiado.

Por qué es importante

Esto disuelve el falso dilema entre "hacen falta mejores especificaciones" y "hay que dejar de escribirlas". Ambos bandos suponen que la especificación tiene un estatus único; tiene dos, y el error habitual consiste en prolongar el primero más allá del momento en que caduca.

También reorienta el esfuerzo: en lugar de reescribir un documento después de cada entrega para que siga siendo verdadero, se escribe abiertamente para la conversación que debe abrir, y se acepta que quede caducado en cuanto se pone en producción. El cuidado se desplaza hacia la calidad de la discusión previa y hacia la capacidad de regeneración posterior, dos cosas que, al contrario que la actualización manual, no se degradan con el tiempo.

Matices y límites

El vuelco solo afecta a la parte descriptiva. Una especificación contiene casi siempre, mezcladas en los mismos párrafos, la descripción de un comportamiento y la razón que llevó a adoptarlo; la segunda no se regenera desde ningún repositorio y debe sobrevivir al documento.

Una especificación puede además ser oponible: anexo de un contrato con un cliente, pieza de un expediente regulatorio, compromiso escrito de una licitación. Conserva entonces una autoridad jurídica que la puesta en producción no le retira, aun cuando el producto se aparte de ella, y es justamente esa distancia la que se convierte en el asunto.

Por último, "la puesta en producción" supone una frontera nítida. Un despliegue progresivo detrás de un feature flag, una entrega a unos pocos clientes piloto, una vuelta atrás, estiran el momento del vuelco en lugar de marcarlo.

Preguntas abiertas

• ¿Qué marca, en concreto, ese cambio de estatus sobre el documento mismo, para que un lector que lo reabre ocho meses después sepa cuál de los dos regímenes está consultando?
• ¿Una especificación escrita sabiendo que caducará en la entrega se escribe de otra forma: más corta sobre el comportamiento, más larga sobre las alternativas descartadas?