Plantilla de registro de decisiones para equipos remotos: una página por decisión, con responsable y opciones descartadas

Por qué los equipos asíncronos deciden por escrito

Los equipos que comparten oficina deciden casi todo en voz alta, y quien importa lo oye. Eso deja de funcionar entre zonas horarias: deciden los que estaban despiertos, los que dormían se enteran después, y el razonamiento ya se ha perdido. Escribir la decisión antes de que sea definitiva consigue tres cosas:

• Hace que la decisión se pueda encontrar. Las nuevas incorporaciones, los colaboradores externos y tú mismo dentro de un año podéis buscarla en lugar de preguntar.
• Conserva las alternativas. La opción elegida rara vez es la parte interesante. Las que rechazaste, y por qué, son lo que impide que el mismo debate vuelva cada trimestre.
• Le pone responsable a la decisión. Una decisión sin dueño se revierte en silencio. Una con nombre se defiende o se cambia de forma deliberada.

El mundo del software tiene un formato para esto desde 2011, cuando Michael Nygard publicó "Documenting Architecture Decisions". Su registro de decisiones de arquitectura (ADR) tiene cinco partes: título, contexto, decisión, estado y consecuencias, con los estados proposed, accepted, deprecated y superseded. La plantilla de abajo conserva ese esqueleto y añade los campos que necesita un equipo generalista: un responsable, las opciones descartadas como sección propia, una fecha de revisión y a quién se consultó.

La plantilla de registro de decisiones

Copia esto en una página nueva para cada decisión. Mantén los encabezados; borra el texto de ayuda que no necesites.

Título: Frase nominal corta. "Usar Postgres para el almacén de eventos", no "Base de datos".
ID: DEC-014
Estado: Propuesta | Aceptada | Sustituida por DEC-0xx | Obsoleta
Responsable: Un solo nombre. La persona que puede cambiar esta decisión.
Fecha de decisión: 2026-10-28
Revisar el: 2027-04-28 (o "nunca" para decisiones irreversibles)
Consultados: Personas a las que se pidió opinión antes de decidir
Informados: Personas o canales avisados después de decidir

== Contexto
Qué situación obligó a elegir. Hechos, restricciones y plazos,
no opiniones. De dos a seis frases.

== Decisión
La elección, en una o dos frases completas y en voz activa:
"Vamos a ...".

== Opciones descartadas
1. Opción A: por qué perdió.
2. Opción B: por qué perdió.
3. No hacer nada: qué habría costado.

== Consecuencias
Qué se vuelve más fácil, qué se vuelve más difícil, qué debemos ahora
(migraciones, formación, una decisión posterior).

== Confirmación
Cómo sabremos que la decisión se sostuvo: una métrica, una fecha, una comprobación.

Los ID numerados (DEC-001, DEC-002) importan más de lo que parece. Permiten que un mensaje de chat, un commit o una tarea digan "ver DEC-014" sin un enlace que se romperá, y hacen que "sustituida por DEC-021" no deje lugar a dudas.

Para qué sirve cada campo

Estado. Propuesta significa que el responsable la ha redactado y espera comentarios. Aceptada significa que el plazo de comentarios se cerró y la decisión se mantiene. Sustituida apunta a la decisión más reciente que la reemplazó. Obsoleta significa que ya no aplica y nada la sustituyó. Nunca edites el cuerpo de una decisión aceptada; escribe una nueva y sustituye la anterior.

Responsable. Exactamente una persona. Ni un equipo ni dos corresponsables. El responsable es quien propone la decisión, cierra el plazo de comentarios y es la primera persona a la que se pregunta cuando alguien quiere cambiarla. Si no puedes nombrar un responsable, la decisión no está lista.

Contexto. Las fuerzas en juego: el plazo, el presupuesto, la integración que se rompió, el cliente que lo pidió. Escríbelo para que alguien que lo lea dentro de un año entienda por qué "no hacer nada" no era aceptable. Deja fuera los argumentos; esos van en las opciones.

Opciones descartadas. Es la sección que la mayoría de plantillas omite y la que más rinde. Cada opción descartada lleva una línea y un motivo. "Demasiado caro" no es un motivo; "450 $ al mes con nuestro número de asientos frente a 39 $" sí lo es.

Consecuencias. En ambas direcciones. Una decisión que solo tiene ventajas no se ha pensado bien. Incluye las deudas: la migración que ahora debes, la habilidad que ahora hay que contratar, la decisión posterior que has aplazado.

Confirmación. Cómo comprobarás, más adelante, que la decisión hizo lo que esperabas. Está tomada de MADR, la plantilla Markdown Architectural Decision Records de adr.github.io, que añadió una sección Confirmation junto a Context and Problem Statement, Decision Drivers, Considered Options, Decision Outcome y Pros and Cons of the Options. Una línea de confirmación convierte la fecha de revisión en una pregunta con respuesta en lugar de un simple recordatorio.

Registro de decisiones, ADR y MADR comparados

Si todas las decisiones de tu equipo tocan código, guarda los ADR en el repositorio y sáltate el resto de este artículo. Si tus decisiones incluyen "qué proveedor de nóminas" y "ofrecemos un plan anual", necesitan un lugar que puedan leer las personas ajenas al repositorio.

Cómo documentar una decisión de forma asíncrona

La plantilla es la parte fácil. El proceso es lo que la hace asíncrona en vez de una reunión con más escritura.

1. Abre la entrada como Propuesta antes de haber decidido. El responsable escribe el contexto, un borrador de decisión y al menos dos opciones descartadas. Escribir primero las alternativas es lo que obliga a pensar de verdad; una decisión redactada a posteriori es una nota de prensa.
2. Fija el plazo de comentarios. Dilo en la entrada: "Comentarios hasta el jueves a las 17:00 UTC". Cuarenta y ocho horas cubren dos veces todas las zonas horarias. Para una decisión reversible, bastan veinticuatro.
3. Publica un solo mensaje, en un solo canal. Enlaza la entrada, indica el plazo y menciona por su nombre a las personas consultadas. No pegues toda la decisión en el chat; la página es el registro y el chat es el aviso.
4. Comenta en la página, no en el hilo. Los comentarios en línea quedan anclados a la frase a la que se refieren. Un hilo de chat desaparece en una semana.
5. El responsable cierra el plazo. O la decisión pasa a Aceptada, quizá editada según los comentarios, o el responsable explica por qué cambió y abre un plazo más corto. El silencio es consentimiento; dilo en la entrada para que nadie se sorprenda.
6. Fija la fecha de revisión al aceptar. Seis meses es un valor razonable para decisiones de herramientas y procesos. Para una decisión que no se puede deshacer a bajo coste, escribe "nunca" y explica por qué.
7. Avisa a la lista de informados. Una línea en el canal del equipo: "DEC-014 aceptada: usaremos X. Revisión en abril". Ese es todo el anuncio.

La cadencia de revisión que mantiene vivo el registro

Los registros mueren porque nadie los lee. Dos revisiones periódicas lo evitan, y las hace una sola persona.

Cada semana, cinco minutos. El dueño del registro (normalmente quien lleva operaciones) filtra por Estado = Propuesta y comprueba que cada una tiene un plazo de comentarios que no haya expirado en silencio. Los plazos vencidos pasan a Aceptada o reciben un recordatorio.

Cada mes, veinte minutos. Filtra por Revisar el dentro de los próximos 30 días. Para cada decisión, el responsable responde a la línea de confirmación en un único comentario: se sostuvo, se sostuvo con cambios o no se sostuvo. Una decisión que no se sostuvo recibe una nueva entrada en Propuesta que la sustituye. Es la única reunión que el registro necesita, y puede ser un resumen escrito en lugar de una llamada.

Dos cifras te dicen si el registro funciona. La primera es el porcentaje de decisiones con al menos una opción descartada por escrito; por debajo del 80 por ciento, la gente está registrando a posteriori. La segunda es cuántas entradas están en Sustituida. Cero al cabo de un año significa que las decisiones se cambian en el chat y el registro se ha convertido en ficción.

Cómo llevamos el registro en Atrix

Sirve cualquier herramienta que pueda guardar una página por decisión y filtrar por un campo: una carpeta de archivos Markdown en el repositorio, una base de datos de Notion, un espacio de Confluence. Nosotros llevamos el nuestro como base de datos de páginas en Atrix, que es una página cuyas subpáginas son filas, y así es como funciona en la práctica.

La página de la base de datos tiene siete propiedades, muy por debajo del límite de veinte: Estado como selección con Propuesta, Aceptada, Sustituida y Obsoleta; Responsable como persona; Decidida y Revisar el como fechas; Consultados como texto; Sustituye como texto con el ID anterior; y Confirmada como casilla que marca la revisión mensual. Cada fila es una página completa, así que la plantilla de arriba vive en el cuerpo de la fila y las propiedades en la tabla. Los tipos de propiedad disponibles son texto, número, selección, fecha, casilla, persona y URL, de modo que no hay fórmulas ni rollups; si los necesitas, mantén una hoja de cálculo al lado.

Dos cosas lo hacen mejor que una carpeta de archivos para un equipo no técnico: los comentarios quedan sobre la frase a la que se refieren, y el historial de la página guarda cada edición, así que "quién cambió la decisión después de aceptarla" tiene respuesta. Documentos y pizarras tiene la lista completa de lo que pueden hacer las páginas.

Lo que no esperábamos usar a diario es el servidor MCP. El servidor MCP de Atrix expone 85 herramientas, entre ellas pages_create y pages_append, de modo que un asistente de IA conectado al espacio de trabajo puede redactar una entrada a partir de un hilo de chat y añadirla al registro sin que nadie salga de la conversación. La herramienta pages_append se fusiona con quien esté editando la página en ese momento en lugar de sobrescribirlo, lo cual importa cuando el responsable está a mitad de frase. El asistente redacta en Propuesta; una persona sigue fijando el responsable, cerrando el plazo y marcándola como Aceptada. La configuración es un comando claude mcp add y un inicio de sesión OAuth; la documentación de MCP explica los permisos, y Claude y los demás asistentes listados funcionan igual.

Conviene dejar claros los límites. No hay plan gratuito, así que un espacio de trabajo cuesta 39 $ al mes en Builder con 5 asientos o 149 $ en Studio con 15, tras una prueba de 7 días que requiere tarjeta. La base de datos no tiene columnas de fórmula, y todavía no existe un aviso automático de "toca revisar" sobre una propiedad de página; nosotros usamos el filtro mensual.

Preguntas frecuentes

¿Qué diferencia hay entre un registro de decisiones y un registro de decisiones de proyecto?

Ninguna relevante. En gestión de proyectos se suele hablar de registro o "register", y en equipos de software de "log", pero ambos significan una entrada por decisión con un estado y un responsable. Elige una palabra y úsala siempre para que la búsqueda funcione.

¿Cuánto detalle debe tener una entrada del registro de decisiones?

El suficiente para que alguien que no participó entienda por qué se tomó la decisión y qué se descartó, y nada más. La mayoría de entradas caben en 150 a 400 palabras. Si una entrada pasa de una página, probablemente son dos decisiones, o es un documento de diseño al que la decisión debería enlazar.

¿Qué es un registro de decisiones de arquitectura?

Un ADR es un documento breve que recoge una decisión arquitectónicamente significativa: el contexto, la decisión, su estado y sus consecuencias. El formato viene del artículo de Michael Nygard de 2011 "Documenting Architecture Decisions" y suele guardarse como archivos Markdown numerados en el repositorio. MADR es una plantilla de ADR más estructurada, con secciones para las opciones consideradas y sus pros y contras.

¿Quién debe ser el dueño del registro de decisiones?

Una persona es dueña del registro en su conjunto, normalmente quien lleva operaciones o el responsable de ingeniería, y ejecuta las revisiones semanal y mensual. Cada decisión tiene su propio responsable, que es la persona capaz de cambiarla. Son roles distintos y normalmente deberían ser personas distintas.

¿Hay que registrar también las decisiones pequeñas?

Registra una decisión si revertirla costaría más de una hora, si afecta al trabajo de más de una persona o si es probable que alguien pregunte "por qué" dentro de seis meses. Qué regla del linter activar no necesita entrada; qué linter usar, sí.

¿Qué hacemos con una decisión que resulta equivocada?

Escribe una entrada nueva. Pon la antigua en Sustituida por el nuevo ID y deja su cuerpo intacto. El registro es una historia, y el registro de una decisión equivocada con el razonamiento intacto es más útil que una corregida que oculta lo que se sabía en su momento.

Siguiente paso

Crea una página llamada "Decisiones", conviértela en base de datos con Estado, Responsable y Revisar el, y pega la plantilla en su primera fila. Documentos y pizarras muestra el editor, y la página de precios tiene los límites de cada plan si quieres probarlo con tu propio equipo.