Registro de decisiones: Cómo registrar decisiones para que los motivos perduren

Las organizaciones recuerdan qué decidieron, pero olvidan por qué. Cómo funcionan los registros de decisiones, qué capturar, una plantilla ligera y cómo vincular cada una con los resultados.

Ibrahim Elkobeissi · 2 de noviembre de 2026 · 6 min de lectura ·

LinkedIn X WhatsApp

La fachada de un gran edificio institucional modernista

Pregunte a un equipo por qué existe una política y, a menudo, escuchará un silencio. Alguien recuerda una reunión. Otro piensa que fue un problema de un proveedor. La persona que lo sabía se fue el año pasado. La decisión sobrevivió. Sus motivos, no.

Esto es algo común y resulta costoso. Sin los motivos, un equipo tiene dos opciones deficientes: mantener una decisión que ya no comprende, o revertirla y arriesgarse a reintroducir el problema que resolvió. Un registro de decisiones ofrece una tercera. Lea el registro, compruebe si las condiciones se mantienen y decida de nuevo con propósito.

Por qué las organizaciones olvidan por qué decidieron

Tres fuerzas actúan en contra de la memoria de una organización sobre sus propias decisiones.

Los motivos viven en las conversaciones. Las decisiones se toman en reuniones, llamadas e hilos de mensajes. El resultado llega a una política o a un plan. El contexto, rara vez.
Las personas se mueven. Quienes evaluaron las opciones cambian de rol o se marchan. Su comprensión se va con ellos.
La memoria se reescribe a sí misma. En un estudio de 1975, el psicólogo Baruch Fischhoff descubrió que, una vez que las personas conocen un resultado, lo juzgan como más predecible de lo que fue. Lo llamó "determinismo progresivo". Después del hecho, una decisión acertada que salió mal parece descuidada, y una afortunada parece sabia.

El último punto es el más importante. Incluso cuando las mismas personas permanecen, su memoria sobre por qué decidieron está moldeada por lo que sucedió después. Solo un registro escrito en el momento preserva lo que se sabía, lo que se esperaba y lo que era incierto.

La guía de arquitectura de Microsoft lo expresa claramente. Una decisión que nunca se registra "probablemente será olvidada, lo que dará lugar a debates repetidos".

Lo que aprendieron los equipos de software: el registro de decisiones de arquitectura

La ingeniería de software tiene una respuesta probada. En noviembre de 2011, Michael Nygard propuso el registro de decisiones de arquitectura, o ADR: un documento breve para cada decisión significativa, numerado en secuencia y conservado con el proyecto. Su formato consta de cinco partes.

Título. Una frase nominal corta con un número, como "ADR 9: LDAP para integración multitenant".
Contexto. Las fuerzas en juego: técnicas, políticas, sociales y locales. Nygard pidió que esta sección fuera neutral en cuanto a valores, una descripción de hechos.
Decisión. La respuesta a esas fuerzas, en frases completas y en voz activa: "Nosotros vamos a..."
Estado. Propuesta, aceptada, obsoleta o sustituida, con una referencia a cualquier reemplazo.
Consecuencias. El contexto resultante. En palabras de Nygard, "Todas las consecuencias deben enumerarse aquí, no solo las 'positivas'".

La práctica se extendió. Thoughtworks incluyó los ADR ligeros en el anillo Adopt de su Technology Radar, su nivel más alto de recomendación, y aconsejó mantenerlos en el control de versiones en lugar de en una wiki separada. El Azure Well-Architected Framework de Microsoft califica el registro de decisiones como uno de los entregables más importantes de un arquitecto de soluciones. Su guía añade dos reglas que vale la pena adoptar: trate el registro como de solo adición (append-only) y registre un nivel de confianza con cada decisión.

Nada de esto es exclusivo del software. Los hospitales cambian sus procedimientos de admisión. Las escuelas cambian sus políticas de evaluación. Las agencias cambian de proveedores. Cada una de estas decisiones tiene contexto, opciones y consecuencias, y cada una será cuestionada más adelante por alguien que no estaba en la sala.

Qué debe capturar un registro de decisiones

Un registro de decisiones es la colección de estos documentos, con un índice que resume cada uno. El manual de ingeniería de Microsoft describe el registro como una tabla de resúmenes ejecutivos, con metadatos, para las decisiones contenidas en los registros completos. La siguiente plantilla de registro de decisiones funciona bien más allá de la ingeniería. Cada campo tiene su razón de ser.

ID y título. Un número y una frase que indique qué se decidió.
Fecha. Cuándo se tomó la decisión, no cuándo se redactó.
Responsable. La persona responsable de la decisión y quién fue consultado.
Contexto. El problema, las limitaciones y las fuerzas en tensión.
Opciones consideradas. Incluyendo las rechazadas y el porqué. Este es el campo que más suele faltar y el que más suele hacer falta.
Decisión. Una frase clara que comience con "Nosotros vamos a..."
Evidencia. Enlaces a los datos, informes, auditorías o comentarios en los que se basó la decisión.
Resultado esperado. Qué debería ser cierto si la decisión funciona, y para cuándo.
Confianza. Alta, media o baja, con una indicación de lo que sigue siendo incierto.
Fecha de revisión. Cuándo se contrastará la decisión con su resultado esperado.
Estado. Propuesta, aceptada, sustituida o retirada, con un enlace a cualquier reemplazo.

Los campos de resultado esperado y confianza cumplen la función de una Journal de decisiones. Registran lo que usted creía antes de conocer el resultado, que es exactamente lo que la retrospectiva borra.

Aplicamos este mismo rigor a nuestras propias decisiones de producto. Lo que se observa se registra de forma separada de lo que se infiere, y las opiniones contradictorias se mantienen en lugar de suavizarse. Una decisión merece, al menos, ese nivel de cuidado.

Enlace cada decisión a su evidencia y a su resultado.

Un registro que se sostiene por sí solo es mejor que nada. Un registro que está vinculado es mucho más útil.

Enlace la evidencia. Cuando una decisión cite una encuesta de pacientes, un análisis de costes o un informe de incidentes, enlace la fuente misma. Los lectores posteriores podrán juzgar si la evidencia sigue siendo válida. La guía de Microsoft señala lo mismo: un registro sin justificación "pierde su valor con el tiempo".

Enlace el resultado. En la fecha de revisión, escriba lo que realmente sucedió junto a lo que se esperaba. Si la brecha es grande, pregunte por qué. ¿Fue débil la evidencia? ¿Cambiaron las condiciones? ¿Fue la decisión acertada y el resultado simplemente desafortunado? La respuesta es una lección, y debe formar parte de la misma cadena. Nuestro artículo sobre lecciones aprendidas que cambian el siguiente proyecto explica cómo lograr que tales lecciones perduren.

Enlace con sucesores. Cuando se revierta una decisión, no edite el registro antiguo. Márquelo como sustituido y señale el nuevo. El historial de un cambio de dirección suele ser lo más valioso del registro.

Un ejemplo hipotético muestra la cadena. Una clínica decide trasladar las llamadas de seguimiento de las enfermeras a un coordinador dedicado. El registro cita datos de finalización de llamadas, nombra al gerente de operaciones como responsable, espera que la finalización aumente en tres meses y establece una fecha de revisión. En la revisión, la finalización ha aumentado, pero la carga de trabajo de las enfermeras no ha disminuido según lo previsto. Un nuevo registro sustituye al primero, ajusta el rol y lo enlaza al anterior. Dos años después, un nuevo gerente puede leer toda la historia en cinco minutos.

Manténgalo lo suficientemente ligero para que sea duradero.

Los registros de decisiones fallan de la misma forma que la mayoría de la documentación. Se convierten en una carga y luego se abandonan. Cinco reglas los mantienen vivos.

Registre solo decisiones significativas. La prueba de Microsoft es útil: decisiones que definen la estructura, afectan cualidades clave o son difíciles de revertir.
Mantenga cada registro corto. Una página o menos. Enlace al material de apoyo en lugar de copiarlo.
Escríbalo cuando decida. Un registro escrito la misma semana es preciso. Uno escrito meses después es una reconstrucción.
Manténgalo donde esté el trabajo. Un registro que se guarda junto a los planes y procedimientos que afecta, se lee. Un registro en una carpeta separada, no.
Empiece ahora y luego complete algunos. Comience con las nuevas decisiones. Luego reconstruya el puñado de decisiones pasadas sobre las que la gente pregunta más, y márquelas como reconstruidas.

Una decisión sin sus razones es una instrucción. Una decisión con sus razones puede ser probada, mantenida o cambiada con cuidado.

Cómo Prism gestiona los registros de decisiones

Prism almacena las decisiones y el conocimiento de una organización como elementos con un nivel de Trust declarado: ratificado, con evidencia, observado o inferido. Cada decisión se enlaza a su evidencia, a los pasos para ejecutarla y a los resultados y lecciones de Pause and Learn que resultan de ella. Cuando una decisión es sustituida, la anterior permanece visible. Los asistentes que su equipo ya utiliza también pueden leer el registro, para que las razones estén ahí cuando alguien pregunte. Las personas toman las decisiones. Prism conserva sus razones.