7. Traspaso y documentación que sobrevive

Descripción

Al terminar esta lección vas a poder dejar tu operación en un estado en el que otra persona pueda hacerse cargo en seis meses sin veinte horas tuyas de acompañamiento. Vas a entender por qué la documentación que nadie mantiene es peor que ninguna —porque miente—, vas a saber decidir qué se documenta y qué no, vas a convertir el inventario del Módulo 1 en un documento vivo, y vas a conocer la prueba de fuego del traspaso: que otra persona resuelva un incidente simulado sin preguntarte nada.

Esto importa porque es la pieza que cierra el propósito entero del módulo. Todo lo anterior —runbooks, guardia, conducción, retrospectivas— sirve para que la operación funcione hoy sin depender solo de ti. Esta lección se asegura de que siga funcionando mañana, cuando la persona que aprendió todo eso ya no esté, o cuando lleguen personas nuevas que nunca lo vivieron. Un sistema que solo la generación actual del equipo sabe operar tiene una fecha de caducidad que nadie escribió, y esa fecha llega el día que la última persona que sabía se va.

Conexión con el módulo: esta es la segunda mitad de la cuarta pieza del kit —la memoria— y cierra las cuatro piezas. La lección 6 capturó el aprendizaje de cada incidente; esta hace que ese aprendizaje, y todo el resto del conocimiento operativo, sobreviva a las personas. Cierra un arco que empezó en la lección 1 con una pregunta —si mañana no estás, ¿quién atiende esto?— y que ahora se responde por completo. Una nota de frontera que ya conoces pero que aquí es especialmente relevante: esta lección no trata de dónde se guardan los documentos ni de cómo se versionan. Que la documentación viva en un wiki, en Git o en una carpeta compartida, y cómo se controla su historial de cambios, es tema de n8n-git-and-environments-guide. Aquí el objeto es qué se documenta, por qué la documentación miente si no se mantiene, y cómo se prueba que el traspaso de verdad funciona.

El mapa del tesoro con calles que ya no existen

Imagina que heredas un mapa del tesoro. Está detallado, tiene marcas, distancias, referencias. Sales a seguirlo lleno de confianza. Y en el camino descubres que la mitad de las referencias ya no existen: "gira a la izquierda en el roble grande" —el roble se cayó hace años—, "cuenta cien pasos desde la fuente" —la fuente la taparon—, "la casa azul es tu señal" —la pintaron de blanco—.

Ese mapa es peor que no tener ningún mapa. Fíjate bien en por qué, porque es el argumento central de la lección y es contraintuitivo. Si no tuvieras mapa, avanzarías con cuidado, dudando de cada paso, verificando todo, consciente de que no sabes. El mapa desactualizado hace lo contrario: te da confianza falsa. Sigues sus instrucciones creyendo que son ciertas, giras donde ya no hay roble, y terminas más lejos del tesoro que si hubieras improvisado, porque actuaste con la seguridad de quien cree que sabe. El mapa no solo no ayudó: te engañó activamente, y lo hizo justo porque confiaste en él.

La documentación operativa funciona igual, y el momento en que engaña es el peor posible. Un runbook que dice "el token del ERP está en Credenciales → ERP Terra Market" cuando esa credencial ya se renombró, leído por alguien a las tres de la mañana, no produce una duda: produce una acción equivocada ejecutada con confianza. La persona va a Credenciales, no encuentra "ERP Terra Market", y ahora está peor que si el runbook no existiera —porque además de no saber qué hacer, acaba de perder tiempo confiando en algo falso y empieza a dudar de todo lo demás—.

De aquí sale la regla más importante de la lección, y va contra el instinto de "documentar más siempre es mejor":

Documentación que miente es peor que documentación que falta. La que falta te deja alerta; la que miente te desarma. Por eso el objetivo no es documentar mucho, sino documentar poco y verdadero, y mantener verdadero lo poco que documentas.

Ejemplo trabajado: dos traspasos a la misma persona

Renata entra a operaciones el mes que viene. Hoy solo consulta las tablas de ops para sus reportes; a partir del mes que viene, va a poder tomar guardia. Tú tienes que traspasarle la operación. Vamos a ver dos formas de hacerlo.

Versión A — el traspaso por volumen.

Te tomas el traspaso en serio y decides documentar todo. Pasas dos semanas escribiendo: la arquitectura completa de los 18 workflows, cada nodo de cada uno, cada credencial, cada tabla, cada decisión histórica de por qué las cosas son como son. Terminas con un documento de sesenta páginas, orgulloso. Se lo pasas a Renata con un "aquí está todo, cualquier cosa me preguntas".

Qué pasa cuando llega el primer incidente de Renata:

• No encuentra lo que necesita. El ERP da 401 a las tres de la mañana. Renata abre las sesenta páginas y busca. Hay una sección de doce páginas sobre "arquitectura de autenticación del ERP" que explica OAuth2, client_credentials y la rotación de tokens, pero en ningún lado dice, en dos líneas, "renueva el token así". La respuesta está ahí, diluida en doce páginas de contexto que no puede leer a esa hora. Te llama.
• Parte del documento ya miente. En las dos semanas que pasaron desde que lo escribiste, dos cosas cambiaron: una credencial se renombró y un workflow se ajustó tras una retrospectiva. El documento no lo refleja. Renata sigue una instrucción vieja, no funciona, y ahora desconfía del documento entero —con razón—.
• Nadie va a mantener sesenta páginas. Aunque quisieras, mantener actualizado un documento de ese tamaño es un trabajo que nadie hace. En tres meses, la mitad va a estar desactualizada, y el documento entero se habrá convertido en el mapa del roble caído: presente, imponente, y mentiroso.

Documentaste muchísimo y traspasaste poco.

Versión B — el traspaso por operabilidad.

Decides otra cosa: no documentar todo, sino documentar lo que Renata va a necesitar para operar, y probar que funciona. Tu material es mucho más pequeño:

• Los runbooks de los síntomas frecuentes (los de la lección 3), que ya existen y que ya están escritos para alguien sin contexto.
• El inventario vivo de los workflows con sus dueños y su criticidad (del Módulo 1, actualizado), que dice qué es cada cosa y a quién escalar, sin explicar cómo funciona por dentro.
• La lista de accesos: qué credenciales y paneles existen, quién los tiene, y cómo se piden. No los secretos —esos están endurecidos como viste en el Módulo 5— sino el mapa de quién puede qué.
• Un par de retrospectivas recientes, para que Renata vea cómo se piensa un incidente en este equipo.

Y en vez de "cualquier cosa me preguntas", haces algo distinto: un simulacro. Provocas un incidente controlado y dejas que Renata lo resuelva sola, con su material, sin que tú intervengas. Donde se atora, no es que Renata falle: es que el material tiene un hueco, y lo arreglas ahí mismo.

Qué pasa cuando llega el primer incidente real de Renata:

• Encuentra lo que necesita, porque el runbook está escrito para su situación y dice, en dos líneas, qué hacer. Resuelve sin llamarte.
• El material está vivo, porque es pequeño y porque hay una rutina de mantenerlo (que vemos abajo). Lo que lee es cierto.
• Ya lo había hecho una vez, en el simulacro, así que el primer incidente real no es su primera vez.

Qué esperar. La diferencia no está en el esfuerzo —las dos versiones te costaron tiempo— sino en dónde lo pusiste:

	Versión A (por volumen)	Versión B (por operabilidad)
Tamaño del material	60 páginas	Runbooks + inventario + accesos
¿Renata encuentra lo urgente?	No, diluido	Sí, en dos líneas
¿El material se mantiene?	No, imposible	Sí, es pequeño
¿Se probó que funciona?	No	Sí, con simulacro
Horas tuyas en el primer mes de Renata	Muchas (te llama por todo)	Pocas (resuelve sola)

La lección de las dos versiones es que documentar más no es traspasar mejor. La versión A produjo más páginas y menos capacidad de operar. La versión B produjo menos páginas, verdaderas y probadas, y una persona que de verdad puede tomar la guardia. El traspaso no se mide en páginas escritas: se mide en si la otra persona puede, sola.

Qué se documenta y qué no

Si documentar todo es un error y no documentar nada también, la habilidad está en decidir la frontera. Aquí está el criterio, y es el mismo del examen honesto de la lección 2: documenta lo que alguien va a necesitar en el peor momento y no puede deducir solo; no documentes lo que se puede leer del sistema o lo que envejece más rápido de lo que se mantiene.

Traducido a categorías concretas:

Sí se documenta:

• Los runbooks de los síntomas frecuentes. Es la documentación de mayor valor porque es la que se usa bajo presión. Ya sabes cómo se escriben (lección 3).
• El inventario de workflows con dueños y criticidad. Qué existe, qué tan crítico es, y a quién escalar. No cómo funciona por dentro: qué es y de quién es.
• El conocimiento tácito de alto valor: los "cuando pasa X, en realidad es Y" que solo viven en tu cabeza (la lección 2 los llamó por su nombre). El token se rota cada 90 días; andes-express devuelve 200 con cuerpo de error cuando la guía ya existe; reprocesar sin marcar el status duplica pedidos. Estas son las joyas: información imposible de deducir del sistema y carísima de aprender por las malas.
• Los accesos: qué credenciales y paneles existen, quién los tiene, cómo se piden y cómo se rotan. El mapa de quién puede qué.
• Las retrospectivas, como memoria de qué ya pasó y qué se aprendió.

No se documenta (o se documenta con cuidado):

• Lo que se puede leer del propio sistema. La lista exacta de nodos de un workflow ya está en el workflow; copiarla a un documento crea una segunda copia que se va a desincronizar. Si alguien quiere saber los nodos, abre el workflow. Documenta lo que el sistema no dice de sí mismo, no lo que sí dice.
• Lo que cambia más rápido de lo que puedes mantener. Detalles muy volátiles —números exactos de volumen que fluctúan, versiones que suben cada mes— documentados sin fecha son deuda: van a mentir pronto. Si algo cambia seguido, o lo marcas con fecha (como enseña la voz procedimental de NIEVA) o lo dejas fuera y remites a donde se lee en vivo.
• La arquitectura profunda "por si acaso". Explicar cada decisión histórica de diseño se siente responsable, pero produce las sesenta páginas de la versión A: mucho volumen, poca operabilidad, imposible de mantener. Si alguien necesita entender el diseño a fondo, esa es una conversación o una sesión de acompañamiento, no un documento que se pudre.

La prueba para decidir, ante cualquier cosa que dudes si documentar: ¿alguien la va a necesitar bajo presión y no puede obtenerla de otro lado? ¿Y voy a poder mantenerla verdadera? Si las dos respuestas son sí, documéntala. Si la primera es no, no hace falta. Si la segunda es no, documentarla es crear un futuro mapa mentiroso.

El inventario como documento vivo

El inventario de workflows nació en el Módulo 1: la lista de los 18 workflows con su criticidad y su dueño. En este módulo se convierte en el documento central del traspaso, y para servir tiene que estar vivo —no una foto de un día, sino algo que refleja el estado actual—.

Un inventario vivo de Terra Market se ve así:

INVENTARIO DE WORKFLOWS · Terra Market
Última revisión: 2026-07-22 · Responsable de mantenerlo: automatización

WORKFLOW        CRIticidad  DUEÑO          RUNBOOK      NOTAS VIVAS
order-sync      crítico     automatización RUNBOOK-01   token ERP: rota
                                           RUNBOOK-02   cada 90d, últ.
                                                        2026-05-14
inventory-update medio      automatización (2 líneas)   autocorrectivo:
                                                        1 fallo no importa,
                                                        8 seguidos sí
shipment-notify  alto       automatización RUNBOOK-04   carrier reenvía;
                                           RUNBOOK-05   lee campo por
                                                        nombre (post-retro
                                                        2026-07-19)
dead-letter-watch soporte   automatización —            corre cada hora
error-handler    soporte    automatización —            NO se prueba a
                                                        mano (Error Trigger)
... (los otros 13, más breves)

Tres cosas hacen que este inventario esté vivo y no muerto:

Tiene fecha de última revisión y un responsable de mantenerlo. Sin esas dos líneas, nadie sabe si el inventario sigue siendo cierto y nadie es responsable de que lo sea. Un documento sin dueño de mantenimiento es un documento que empieza a morir el día que se escribe. La fecha es el primer lugar que alguien mira para decidir cuánto confiar.

Enlaza al runbook, no lo repite. La columna de runbook apunta; no copia el contenido. Así el inventario se mantiene chico y no hay dos versiones del mismo procedimiento que se puedan contradecir. Cada pieza de información vive en un solo lugar, y las demás la referencian. Esa regla —una fuente de verdad por dato— es lo que hace mantenible el conjunto.

Las "notas vivas" capturan el conocimiento tácito. La columna de la derecha es donde van las joyas: el token rota cada 90 días, shipment-notify ahora lee por nombre tras una retrospectiva. Fíjate en que esa última nota tiene la fecha de la retro que la produjo: así el inventario se convierte en el punto donde el aprendizaje de las retrospectivas (lección 6) se sedimenta y queda disponible para quien llegue después.

La rutina que lo mantiene vivo es sencilla y barata, y sin ella nada de lo anterior sirve: el inventario se revisa cuando cambia algo que le concierne. Cada retrospectiva con una acción que toca un workflow actualiza su fila. Cada workflow nuevo entra con su fila. Cada cambio de dueño se refleja. No es una tarea aparte que se agenda y se olvida: es un reflejo que se dispara con los eventos que ya ocurren. Y una revisión completa, de arriba a abajo, una vez cada trimestre, para cazar lo que se escapó. Un inventario que no se toca en seis meses no es un inventario vivo: es el mapa del roble caído esperando para engañar a alguien.

La prueba de fuego: el simulacro sin ayuda

Aquí está la idea que separa un traspaso real de uno imaginario, y es la misma lógica del Módulo 2 sobre probar el manejo de errores: la única forma de saber si un traspaso funciona es que otra persona resuelva un incidente sin ti. No que diga que entendió. No que lea los documentos y asienta. Que resuelva, sola, con el material que le dejaste, mientras tú te muerdes la lengua.

Por qué el simulacro y no la conversación: porque el traspaso tiene puntos ciegos que solo se ven en la práctica. Cuando tú explicas cómo se resuelve un incidente, rellenas sin darte cuenta cientos de huecos con tu conocimiento tácito —"y entonces entras a n8n" (¿por dónde?), "verificas que esté bien" (¿cómo?)—. Esos huecos son invisibles para ti porque tu cabeza los llena automáticamente. Solo se vuelven visibles cuando otra persona, que no tiene tu cabeza, se atora en ellos. El simulacro es una máquina de encontrar huecos.

Cómo se hace, en concreto:

1. Eliges un incidente realista y lo provocas de forma controlada. No en producción: en un entorno donde puedas romper algo a propósito sin consecuencias. Por ejemplo, apuntar un workflow de prueba a un endpoint inválido para que dé el mismo error que daría el ERP caído. El punto es que la persona vea el síntoma real, no una descripción.

2. La persona lo resuelve con su material, y tú no ayudas. Esta es la parte difícil y la más importante. Vas a querer intervenir en cuanto se atore —"ah, es que tienes que…"— y no debes. Cada vez que se atora en silencio, marcaste un hueco del material. Si la ayudas, tapas el hueco con tu presencia, que es exactamente lo que no va a estar el día del incidente real.

3. Cada tropiezo es un arreglo del material, no un reproche a la persona. Si Renata no encontró la verificación rápida, el runbook la tenía enterrada: la subes. Si no supo a quién escalar, el inventario no lo decía: lo agregas. El simulacro no evalúa a la persona; evalúa la documentación, usando a la persona como detector. Esto es importante decirlo en voz alta antes de empezar, para que quien hace el simulacro no lo viva como un examen personal.

4. Se repite hasta que la persona resuelve sin atorarse. Un simulacro que la persona pasa sin ayuda a la primera es raro y probablemente significa que el incidente era muy fácil. Lo normal es que el primero descubra varios huecos, el segundo menos, y en algún momento la persona resuelva un incidente nuevo sin preguntarte nada. Ese momento —otra persona resolviendo sin ti— es la definición operativa de que el traspaso funcionó. No hay otra prueba que valga.

Fíjate en la simetría con el módulo anterior, porque es la misma idea aplicada a otra cosa. En el Módulo 2 aprendiste que un error workflow que nunca se disparó no se sabe si funciona, y que hay que provocarle fallos a propósito para confiar en él. Un traspaso es igual: uno que nunca se probó con un incidente real no se sabe si funciona, y hay que provocarle un incidente a propósito para confiar en él. La documentación, como el manejo de errores, es infraestructura que solo se ejercita cuando algo se rompe, y por eso se degrada en silencio hasta el día que se necesita. El simulacro es lo que la ejercita antes.

Errores comunes

Documentar por volumen en vez de por operabilidad (conceptual). Qué pasa: se produce un documento enorme y exhaustivo con la idea de que "más completo es mejor". El resultado es la versión A del ejemplo: sesenta páginas donde lo urgente está diluido, que nadie puede usar bajo presión y que nadie va a mantener. Por qué pasa: el volumen se siente como esfuerzo y como responsabilidad —"documenté todo, hice mi parte"— y produce un artefacto imponente que da sensación de logro. Cómo detectarlo: pregúntate si alguien podría resolver el incidente más común usando tu documentación a las tres de la mañana, en menos de dos minutos de lectura. Si tu material obliga a leer diez páginas para encontrar dos líneas, es por volumen. Cómo corregirlo: mide la documentación por si permite operar, no por su extensión. Empieza por los runbooks y el inventario —lo que se usa bajo presión— y deja la arquitectura profunda para conversaciones y sesiones de acompañamiento, no para documentos que se pudren.

Dejar que la documentación mienta (práctico). Qué pasa: se documenta bien una vez, y luego el sistema cambia y el documento no. Con el tiempo, cada vez más partes del documento describen un sistema que ya no existe. Alguien las sigue confiando, actúa mal, y descubre en el peor momento que el mapa tenía calles que ya no están. Por qué pasa: escribir documentación es un evento con recompensa visible; mantenerla es un trabajo continuo sin recompensa visible, así que se deja de hacer. Cómo detectarlo: toma tres afirmaciones concretas de tu documentación —una ruta, un nombre de credencial, un número— y verifícalas contra el sistema real ahora mismo. Si alguna miente, probablemente hay más. Cómo corregirlo: documenta menos para poder mantener lo que queda; pon fecha de última revisión a cada documento y un responsable de mantenerlo; y ata la actualización a eventos que ya ocurren —cada retrospectiva actualiza el inventario y los runbooks que tocó—, para que mantener no dependa de acordarse.

Traspasar de palabra sin probar (práctico). Qué pasa: el traspaso se hace conversando —"te explico cómo funciona todo"— y con un "cualquier cosa me preguntas". La otra persona asiente, cree que entendió, y en el primer incidente real descubre que había cientos de huecos que la conversación tapó con la presencia de quien explicaba. Y esa presencia ya no está. Por qué pasa: explicar de palabra es rápido y se siente completo, porque quien explica rellena todos los huecos en tiempo real sin notarlo. Cómo detectarlo: si tu traspaso no incluyó a la otra persona resolviendo algo sola, no sabes si funcionó. "Entendí" no es evidencia. Cómo corregirlo: haz el simulacro. Provoca un incidente controlado, deja que la persona lo resuelva con su material sin ayudarla, y arregla cada hueco donde se atore. Repite hasta que resuelva sin preguntarte. Solo entonces el traspaso está hecho.

Ejercicios

Ejercicio 1 — Decide qué documentar. Para cada una de estas seis cosas de Terra Market, di si se documenta, no se documenta, o se documenta con cuidado (con fecha, o remitiendo a la fuente viva), y por qué:

(a) La lista exacta de los nodos que tiene order-sync hoy. (b) Que reprocesar dead_letter sin marcar el status duplica pedidos. (c) El volumen exacto de ejecuciones de cada workflow, que fluctúa a diario. (d) Que el contacto real del proveedor del ERP no es el correo de soporte sino el ingeniero de integraciones. (e) La explicación completa de cómo funciona OAuth2 en la autenticación del ERP. (f) Que error-handler no se puede probar ejecutándolo a mano porque el Error Trigger solo se dispara ante fallos automáticos.

Ver solución

(a) No se documenta. La lista de nodos ya está en el propio order-sync; quien la quiera, abre el workflow. Copiarla a un documento crea una segunda copia que se desincroniza en cuanto alguien agregue un nodo. Documenta lo que el sistema no dice de sí mismo, no lo que sí dice.

(b) Se documenta, y es prioritario. Es conocimiento tácito de alto valor: imposible de deducir del sistema, carísimo de aprender por las malas (duplicando pedidos reales), y necesario bajo presión. Va en la nota viva del inventario y en el "nunca" del runbook de reproceso. Es una de las joyas.

(c) Se documenta con cuidado, o no se documenta. Un número que fluctúa a diario, escrito sin fecha, va a mentir mañana. O documentas el orden de magnitud con la fecha ("~1.200/día a jul-2026") sabiendo que es una referencia aproximada, o remites a donde se lee en vivo (las métricas del Módulo 4). Lo que no haces es escribir un número exacto y volátil como si fuera permanente.

(d) Se documenta, y es prioritario. Es exactamente el tipo de conocimiento tácito que solo vive en tu cabeza y que alguien va a necesitar en un incidente —cuando el ERP se cae, hay que contactar a alguien que sirva, no al buzón de soporte—. Va en los accesos y en la nota viva. Imposible de deducir, necesario bajo presión.

(e) No se documenta (o con mucho cuidado). Es la arquitectura profunda "por si acaso" de la versión A. Para operar el token, la persona no necesita entender OAuth2: necesita el runbook de dos líneas de "renueva el token así". Si alguien quiere entender OAuth2 a fondo, es una conversación o remite a la documentación oficial, no doce páginas propias que se pudren.

(f) Se documenta, y es de alto valor. Es un detalle contraintuitivo del sistema —uno esperaría poder probar el error handler a mano— que, si no se sabe, lleva a conclusiones falsas ("lo probé y no hizo nada, está roto"). Imposible de deducir sin conocer la limitación del Error Trigger. Va en la nota viva de error-handler.

Por qué funciona: el ejercicio aplica la prueba de la lección —¿se necesita bajo presión y no se puede obtener de otro lado? ¿se puede mantener verdadero?— a seis casos. Fíjate en el patrón: se documenta el conocimiento tácito imposible de deducir (b, d, f), no se documenta lo que el sistema ya dice (a) ni la teoría profunda (e), y se documenta con fecha lo volátil (c). Las joyas son siempre lo que no se puede leer del sistema.

Ejercicio 2 — Encuentra la mentira. Este runbook de Terra Market tiene tres afirmaciones que podrían haber envejecido y convertirse en mentiras. Identifícalas y di, para cada una, cómo evitarías que mienta en el futuro:

RUNBOOK-01 (fragmento)
· El token del ERP está en Credenciales → "ERP prod token".
· order-sync hace unas 1.200 ejecuciones al día.
· Si no tienes acceso al panel del ERP, escríbele a Carlos.

Ver solución

Las tres afirmaciones frágiles:

"El token está en Credenciales → 'ERP prod token'." El nombre de la credencial puede cambiar —de hecho, en otros runbooks del módulo se llama "ERP Terra Market", así que ya hay una inconsistencia—. Si alguien renombra la credencial y no actualiza el runbook, esta línea manda a la persona a buscar algo que no existe. Cómo evitarlo: primero, una sola fuente de verdad para el nombre —que todos los runbooks usen el mismo— y, sobre todo, que renombrar una credencial dispare la revisión del runbook que la menciona. Atar el cambio del sistema a la revisión del documento.

"order-sync hace unas 1.200 ejecuciones al día." Es un número que puede cambiar con el crecimiento del negocio, y escrito así, sin fecha, parece permanente. Si el volumen sube a 3.000, la línea miente. Cómo evitarlo: marcarlo con fecha ("~1.200/día a jul-2026") para que quien lo lea sepa cuán viejo es el dato, o quitarlo del runbook si no es necesario para actuar —¿la persona de guardia necesita el número exacto para resolver un 401? Probablemente no—.

"Escríbele a Carlos." Las personas cambian de rol y de empresa. Si Carlos se va, esta línea manda a la persona a escribirle a alguien que ya no está. Es el tipo de mentira más común y más peligrosa, porque en un incidente la persona confía en el nombre. Cómo evitarlo: documentar el rol además del nombre ("el administrador del panel del ERP —hoy Carlos—"), de modo que si Carlos se va, quede claro a qué rol hay que buscar el reemplazo; y revisar los contactos en cada revisión trimestral del inventario.

Por qué funciona: las tres mentiras potenciales comparten una raíz —son datos que el mundo cambia (nombres, números, personas) escritos como si fueran permanentes—. La defensa no es escribir mejor una vez, sino (1) poner fecha a lo volátil, (2) documentar roles en vez de solo nombres, y (3) atar la revisión del documento a los eventos del sistema que lo invalidan. Un documento que no tiene forma de enterarse de que el mundo cambió está condenado a mentir.

Ejercicio 3 — Diseña el simulacro. Vas a traspasar la operación a Renata y quieres probar que funciona con un simulacro. Diseña el simulacro completo: (a) qué incidente eliges y por qué; (b) cómo lo provocas sin tocar producción; (c) qué haces tú durante el simulacro; (d) qué haces con lo que descubras; y (e) cómo sabes que el traspaso está terminado.

Ver solución

(a) Qué incidente y por qué: el ERP que no responde (RUNBOOK-01), porque es el más frecuente y el más crítico —el que Renata va a encontrar seguro y el que peor duele si no sabe atenderlo—. El examen honesto de la lección 2 diría: cuadrante "falla seguido / duele mucho", así que es el primero que hay que probar. No elijas un incidente raro para el primer simulacro: elige el que más probablemente le toque.

(b) Cómo lo provoco sin tocar producción: monto un order-sync-test desechable, idéntico en su estructura al real pero apuntando a un endpoint de prueba que devuelve 503 a propósito. Así Renata ve el síntoma real —la alerta, el nodo que falla, el código— sin que ningún pedido real corra peligro. El punto es que el síntoma sea indistinguible del real; una descripción en papel no sirve, tiene que verlo.

(c) Qué hago yo: me callo. Observo, tomo notas de dónde se atora, y no intervengo aunque me duela. Cada vez que Renata dude y no encuentre la respuesta en su material, anoto un hueco. Si la ayudo, tapo el hueco con mi presencia, que es justo lo que no va a estar el día real. Le digo antes de empezar que esto prueba la documentación, no a ella, para que se sienta libre de atorarse.

(d) Qué hago con lo que descubro: cada tropiezo es un arreglo del material. ¿No encontró la verificación rápida? La subo en el runbook. ¿No supo a quién escalar? Lo agrego al inventario. ¿El botón la confundió? Lo anoto para una posible mejora. El simulacro produce una lista de arreglos concretos a la documentación, no una evaluación de Renata.

(e) Cómo sé que terminó: cuando Renata resuelve un incidente que no había practicado antes —uno nuevo, no el que ya vio— sin preguntarme nada, usando solo su material. Ese momento, otra persona resolviendo sin mí, es la definición operativa de traspaso completo. Mientras siga necesitando llamarme, hay huecos; cuando resuelve sola algo nuevo, el material se sostiene por sí mismo.

Por qué funciona: el simulacro convierte el traspaso de una creencia ("le expliqué, creo que entendió") en una prueba con un resultado binario (resolvió sin ayuda, o no). Y desplaza el foco de la persona al material: cada fallo del simulacro no dice "Renata no sabe" sino "al material le falta algo", que es lo único que puedes arreglar de antemano. Es la misma lógica de provocar fallos al error workflow del Módulo 2: la infraestructura que solo se usa en emergencias hay que ejercitarla antes de la emergencia.

Resumen y siguiente paso

En esta lección cerraste la cuarta pieza del kit y con ella el propósito entero del módulo. Con la imagen del mapa del tesoro de calles que ya no existen entendiste la regla más contraintuitiva: la documentación que miente es peor que la que falta, porque la que falta te deja alerta y la que miente te desarma con confianza falsa —y engaña justo a las tres de la mañana, cuando alguien confía en ella—. Comparaste dos traspasos a Renata y viste que documentar por volumen produce sesenta páginas que nadie usa ni mantiene, mientras que documentar por operabilidad produce poco material verdadero y probado, y una persona que de verdad puede tomar la guardia; el traspaso no se mide en páginas sino en si la otra persona puede, sola. Aprendiste el criterio de qué documentar —lo que se necesita bajo presión y no se puede deducir, y que puedas mantener verdadero— y qué no —lo que el sistema ya dice de sí mismo y lo que envejece más rápido de lo que se mantiene—. Convertiste el inventario del Módulo 1 en un documento vivo con fecha, responsable, enlaces en vez de copias, y notas vivas donde sedimenta el aprendizaje de las retrospectivas. Y conociste la prueba de fuego: el simulacro donde otra persona resuelve un incidente sin ti, que es a la documentación lo que provocar fallos a propósito es al manejo de errores.

Antes de avanzar deberías poder: explicar por qué la documentación que miente es peor que la que falta; decidir qué se documenta y qué no con la prueba de "¿se necesita bajo presión y se puede mantener verdadero?"; y diseñar un simulacro de traspaso que pruebe la operabilidad, no la comprensión.

Con esto tienes las cuatro piezas del kit completas: el runbook (qué hacer), la guardia (quién responde), la conducción (cómo se maneja lo que el runbook no cubre) y la memoria (cómo se aprende y cómo lo aprendido sobrevive). Lo que falta es armarlo todo junto sobre Terra Market y —lo más importante— probar que funciona. La lección 8 es el proyecto final y el cierre de la guía. Vas a ensamblar el kit de operaciones completo: los runbooks de los tres síntomas más frecuentes, la rotación de guardia con su criterio de escalamiento, la plantilla de retrospectiva, y el inventario actualizado con dueños. Y lo vas a validar con la única prueba que importa: un simulacro donde alguien más ejecuta un runbook sin tu ayuda. Después, el recorrido por los ocho módulos de la guía y hacia dónde seguir.

Recursos

• Configure workflow settings — n8n Docs — los ajustes por workflow, incluida la asignación del error workflow, que el inventario vivo referencia por workflow sin copiar su contenido.
• Credentials — n8n Docs — la referencia de credenciales cuyo nombre y ubicación son justo el tipo de dato que un runbook debe mantener verdadero para no mentir a las tres de la mañana.
• Executions — n8n Docs — la lista de ejecuciones que hace innecesario documentar el detalle interno de cada workflow: quien lo quiera, lo lee del sistema en vivo.
• n8n-git-and-environments-guide — la guía hermana donde vive dónde se guardan y cómo se versionan los documentos y los workflows; esta lección decide qué se documenta, aquella decide dónde y con qué historial.