Idea principal

Una especificación describe una intención. Un PRD describe un objetivo, unas reglas esperadas, unos escenarios. Un mockup describe una interfaz deseada. Ninguno de esos documentos describe lo que el cliente encontrará: entre ellos y la puesta en producción se hacen compromisos, se ajustan detalles, aparecen casos límite, las restricciones técnicas obligan a modificar ligeramente el comportamiento, y se toman decisiones sobre la marcha en una pull request sin que lleguen al documento inicial.

Esos arbitrajes no son accidentes que haya que suprimir: un producto vivo no se fabrica como un documento congelado. Pero tienen una consecuencia sobre lo que hay que mirar para conocer un producto. La especificación sigue siendo una aproximación útil en un momento dado; la versión en producción es la única descripción completa de lo que se ha entregado.

El efecto también se lee en las herramientas de seguimiento: los tickets se desincronizan igual que las especificaciones, porque los arbitrajes tomados durante la realización no llegan a ninguno de los dos.

Capa aportada por "El backlog no es un vertedero: es una herramienta de acción" (2026-06-03).

Capa aportada por "PM, desarrolladores e IA: los roles se difuminan, las responsabilidades permanecen" (2026-08-01). Esos arbitrajes tienen un nombre y un autor: son decisiones de producto, y son los desarrolladores quienes las toman. Una especificación completa es una ficción — incluso buena, deja zonas mudas: casos límite, mensajes de error, comportamientos implícitos, reglas de seguridad, tiempos de expiración, prioridades invisibles, microinteracciones, decisiones de repliegue. La constatación no describe por tanto solo una brecha entre el documento y la producción; señala quién, de hecho, decide lo que el cliente encontrará.

Por qué es importante

Desplaza el lugar donde se busca la verdad de una funcionalidad: en el comportamiento entregado, no en el ticket que lo pidió. Las brechas no son errores de conformidad, son la materia misma de la decisión de producto.

También dice lo que se pierde quedándose aguas arriba: la parte de las decisiones que determina la experiencia del cliente se ha jugado después del documento, en intercambios que ese documento no registra.

Matices y límites

En ciertos perímetros, la brecha es pequeña y la intención se mantiene: un cambio de etiqueta, un parámetro, una regla de negocio sencilla llegan a producción tal como se escribieron.

Y un producto sometido a una restricción regulatoria invierte parcialmente la regla: allí la conformidad se demuestra tanto sobre el documento como sobre el comportamiento entregado, y la brecha se convierte en un defecto en sí misma.

Preguntas abiertas

• ¿Mediante qué dispositivo podría un arbitraje tomado en una pull request llegar a quien concibió la funcionalidad, sin reconstituir la carga documental que se busca evitar?