Dos personas del mismo equipo recuerdan la misma reunión de forma distinta. Una dice que el tramo de precios quedó decidido. La otra dice que se planteó y nunca se cerró. Las dos están seguras. Las dos, a su manera, dicen la verdad, porque lo que pasó en esa sala fue una conversación, y una conversación no es un registro. Una semana después la feature sale bajo una interpretación y la otra persona suelta la frase que le cuesta a los equipos de producto más tiempo que cualquier bug: «yo nunca acordé eso».
De ahí no sales discutiendo. No hay artefacto que señalar. Así que el equipo vuelve a litigar una pregunta que ya había respondido, y esta vez la respuesta la moldea quien esté más cansado, sea más senior o esté más recientemente molesto. Multiplica eso por cada elección no trivial que hace un producto y tienes un equipo que gasta un tercio de su energía en re-decidir cosas en vez de decidir nuevas.
El problema es de registro, no de memoria
Es tentador tratarlo como que la gente es olvidadiza o política. Casi nunca es ninguna de las dos. Una decisión es un momento. Ocurre en un hilo de Slack, un pasillo, una llamada, un comentario sobre un mockup. Es real cuando se toma y luego se disuelve en el recuerdo ligeramente distinto de cada uno. Nada la capturó, así que no hay nada con lo que discrepar, solo entre vosotros.
Esto empeora en cuanto entran los agentes en el bucle, y es el núcleo de lo que cambió en el product management en la era IA. Cuando construir era lento, una decisión difusa tenía días de fricción de ingeniería por delante, y esa fricción era, sin querer, una revisión. Alguien preguntaba «espera, ¿decidimos esto?» antes de que costara mucho. Ahora un agente convierte una decisión difusa en código funcionando en una tarde. La fricción desapareció. La elección a medio recordar se vuelve una feature publicada antes de que nadie se pare a comprobar si de verdad se acordó. La velocidad no crea el problema del «yo nunca acordé eso». Elimina el retraso que antes lo cazaba.
Qué registra de verdad un registro de decisiones
Un registro de decisiones no es un acta de reunión ni un parte de estado. El acta recoge qué se dijo. El registro recoge qué se decidió, y lo justo alrededor para que la decisión se pueda entender y, si hace falta, reabrir con fundamento. Por cada entrada, cuatro cosas:
- La decisión en sí, formulada como una afirmación con la que podrías discrepar. No «hablamos de precios» sino «lanzamos con tres tramos, no con facturación por uso».
- El contexto que la forzó, en una o dos frases. Qué era cierto cuando decidiste. Esto es lo que permite a un lector futuro juzgar si la decisión sigue en pie o si el terreno se movió.
- Las alternativas que perdieron, nombradas. El objetivo no es la exhaustividad. Es que «facturación por uso» aparezca como considerada-y-descartada para que nadie la reabra en tres semanas como si fuera una idea nueva.
- Quién la posee, para que haya una persona a la que preguntar, no un comité que reconvocar.
Esa es toda la disciplina. Fíjate en lo que falta: un documento largo de justificación, una plantilla con quince campos, un flujo de aprobación. Un registro que cueste más de un par de minutos por entrada no se mantiene, y un registro que no se mantiene es peor que ninguno, porque ahora la gente se fía de él y está desactualizado.
Dónde tiene que vivir
La forma más habitual en que muere un registro de decisiones es la ubicación. Va a una página de wiki que nadie abre, o a un documento que está una carpeta demasiado lejos del trabajo, y en un mes es ficción. La regla que lo mantiene vivo es la proximidad: la decisión tiene que vivir donde vive el trabajo que depende de ella.
Una decisión sobre un contrato de API va junto a ese contrato. Una decisión sobre lo que una feature hace y deliberadamente no hace va pegada a esa feature, no en un espacio de gobernanza aparte. Cuando la decisión está a un clic de lo que gobierna, pasan dos cosas. La gente registra decisiones de verdad, porque no es un cambio de contexto. Y la gente lee las decisiones de verdad, porque ya está mirando el trabajo de alrededor cuando surge la pregunta.
Este es el mismo fallo que mata a casi toda la documentación, y conviene decirlo claro. Un registro desconectado del trabajo que describe se pudre, porque nada lo obliga a seguir siendo cierto y nada lo pone delante de quien notaría que está mal. Un registro de decisiones no es una excepción. Si es un documento muerto en una esquina, va a derivar de la realidad igual que cada PRD desactualizado que has ignorado en tu vida. El registro tiene que estar lo bastante cerca del trabajo como para que mantenerlo veraz salga más barato que dejarlo mentir.
Quién lo consulta, y cuándo
Un registro que nadie lee es un diario. El valor aparece en cuatro momentos concretos, y conviene diseñar para ellos:
- Cuando se reabre una pregunta cerrada. Alguien vuelve a proponer facturación por uso. En vez de un debate nuevo, abres la entrada: aquí está cuándo decidimos que no y por qué. Ahora la conversación es la correcta, que es «¿ha cambiado el contexto?» y no «¿qué habíamos decidido?».
- Cuando entra alguien nuevo. Una persona nueva no absorbe meses de decisiones por ósmosis ni interrumpiendo a todo el mundo. Lee el registro y hereda el razonamiento, no solo el resultado.
- Cuando algo se rompe y hay que saber si fue a propósito. La mitad de las preguntas de «¿por qué está construido así?» se responden con «lo decidimos, este es el tradeoff». La otra mitad revelan un error real. El registro te dice cuál es cuál, rápido.
- Cuando construyen los agentes. Esta es la nueva. Un agente que trabaja desde una decisión vigente produce código que coincide con lo que el equipo eligió de verdad. Un agente que trabaja desde una decisión desactualizada o no dicha construye con seguridad justo lo que rechazaste. El registro es cómo se ve una decisión cuando es lo bastante duradera para que una máquina construya contra ella sin volver a preguntar a un humano cada vez. Es una hebra de la memoria de producto que un equipo guarda fuera de la cabeza de nadie.
El registro de decisiones y la feature factory
Hay una razón más profunda por la que esto importa, y conecta con cómo un equipo evita convertirse en una feature factory. Una feature factory produce output y nunca se pregunta si el output cambió algo, porque no tiene memoria de por qué se construyó cada cosa. Las decisiones se toman, se olvidan y se rehacen ligeramente distintas, así que el producto acumula features que ya no comparten una intención coherente.
Un registro de decisiones es la primera cuña contra eso. Obliga al equipo a decir qué está eligiendo y por qué, lo que significa que más tarde puedes hacer la pregunta que una factory nunca hace: ¿esta decisión produjo el resultado que apostamos? No puedes conectar una decisión con su resultado si nunca registraste la decisión. Mantener el registro es la condición previa para hacer producto como instalar un comportamiento en vez de publicar features, porque el cambio de comportamiento solo se puede juzgar contra una intención que escribiste.
Dónde encaja PaellaDoc
Este es el problema concreto que estoy construyendo PaellaDoc para volver estructural en vez de heroico. Una decisión no debería depender de la memoria más fuerte de la sala. Cuando se toma una elección, se captura como algo de primera clase, junto a los artefactos y el código que gobierna, con su contexto y las alternativas que batió. Se queda conectada al trabajo, así que no se pudre hasta ser un documento en el que nadie confía, y los agentes construyen contra la decisión que de verdad sigue en pie, no contra una versión a medio recordar.
El problema del «yo nunca acordé eso» nunca sobrevive al contacto con un registro real. Toda la dificultad era que no había nada que señalar. Dale al equipo algo que señalar, mantenlo cerca del trabajo, y la discusión deja de ser sobre el pasado. Vuelve a ser sobre lo único que merece discutirse: qué decidir a continuación.
Preguntas frecuentes
¿Qué es un registro de decisiones (decision log)?
Un registro de decisiones es un registro ligero de las elecciones que toma un equipo, capturadas según ocurren. Cada entrada formula la decisión como una afirmación con la que podrías discrepar, el contexto que la forzó, las alternativas que perdieron y quién la posee. No es un acta de reunión, que recoge qué se dijo. Un registro recoge qué se decidió, lo bastante cerca del trabajo como para seguir diciendo la verdad.
¿Qué se registra en un decision log?
Cuatro cosas por entrada, no más. La decisión en sí, formulada como una afirmación («lanzamos con tres tramos, no con facturación por uso»). El contexto que la forzó, en una o dos frases. Las alternativas que perdieron, nombradas, para que nadie las reabra como ideas nuevas. Y quién la posee, para que haya una persona a la que preguntar. Nada de justificaciones largas ni plantillas de quince campos, o el registro deja de mantenerse.
¿Dónde debe vivir un registro de decisiones?
Junto al trabajo que gobierna, no en una página de wiki que nadie abre. Una decisión sobre un contrato de API va junto a ese contrato; una decisión sobre lo que una feature hace y no hace va pegada a esa feature. Cuando el registro está a un clic de lo que gobierna, la gente escribe las decisiones de verdad y las lee de verdad. La distancia es lo que mata un registro.
¿En qué se diferencia de un acta de reunión?
El acta recoge qué se dijo; el registro recoge qué se decidió. El acta es una transcripción de una conversación, así que conserva la ambigüedad que causó el «yo nunca acordé eso» de entrada. El registro lo resuelve en una sola afirmación con su contexto y sus alternativas descartadas, lo bastante duradera para que un compañero, alguien nuevo o un agente construya contra ella sin volver a preguntar.