Bus factor y compartir conocimiento

Descripción

Todas las lecciones anteriores de este módulo convergen aquí. Living documentation, docs-as-code, el sistema C4 + ADR + arc42, la regla de lo estable contra lo volátil, el README de onboarding —todo eso existe, en el fondo, para una sola cosa: que el conocimiento del sistema no dependa de una sola cabeza. Esta lección hace explícito ese objetivo y lo mide con la métrica que lo captura: el bus factor. La lección 1 lo introdujo; esta lo lleva a fondo. Vas a simular qué pasa cuando una persona concreta se va de Mercado —qué módulos quedan huérfanos—, a identificar los puntos únicos de falla, y a comparar los distintos seguros contra ese riesgo, midiendo cuál cuesta menos. La conclusión, medida, es la tesis del módulo entero: la documentación de lo estable es el seguro más barato contra que el conocimiento se vaya cuando una persona se va.

La idea de fondo es tratar el conocimiento como un riesgo que se asegura, no como algo que simplemente "está ahí". Un módulo que entiende una sola persona es un riesgo concreto —el día que esa persona se va, el módulo queda sin dueño— y, como todo riesgo, se puede reducir pagando una prima. Hay dos primas posibles: documentar lo estable del módulo (barato: escribes sus límites y decisiones una vez) o formar un segundo dueño humano por pairing o rotación (caro: semanas de que otra persona aprenda el módulo trabajándolo). Las dos suben el bus factor de 1 a 2, pero cuestan órdenes de magnitud distintos. Esta lección ejecuta esa comparación y muestra por qué la documentación gana como seguro —con un matiz honesto que la lección subraya: la doc no reemplaza al humano, porque el humano hace algo que la doc no puede—.

Conexión con el módulo. Es la lección-síntesis: recoge todo lo anterior y lo pone al servicio del bus factor. Living documentation y docs-as-code (lecciones 2-3) son cómo se mantiene viva la doc que sube el bus factor; el sistema C4+ADR+arc42 (lección 4) es qué piezas la componen; lo estable vs lo volátil (lección 5) es qué se documenta para que el seguro sea barato; el README (lección 6) es el bus factor del conocimiento operativo. Todo apunta aquí. Con la analogía del módulo: es la receta escrita que sobrevive a que la abuela ya no esté —el conocimiento que se queda cuando la persona se va—. Frontera con el resto: la gestión de personas a fondo (retención, planes de sucesión, 1:1s) es management y queda fuera; aquí solo la dinámica conocimiento↔documentación y su economía como seguro.

Una analogía: la receta escrita que sobrevive a la abuela

Piensa en una familia y en el platillo que hace inolvidables sus reuniones —el mole, la paella, el guiso que todos esperan— y en dos maneras en que ese conocimiento vive.

La receta que solo está en las manos de la abuela. La abuela hace el guiso de memoria, como lo aprendió de su madre: un puñado de esto, "hasta que se vea así", el punto exacto que reconoce con el ojo y la nariz. Nunca lo escribió —no le hizo falta, ella siempre estuvo—. Toda la familia da por hecho que el guiso es de la abuela, que siempre habrá guiso porque siempre está la abuela. Y entonces la abuela ya no está. Y con ella se va el guiso: nadie sabe las proporciones, nadie reconoce "el punto", los intentos de reproducirlo salen parecidos pero nunca iguales, y con los años el sabor exacto se pierde para siempre. No se perdió porque a nadie le importara; se perdió porque el conocimiento vivía en una sola cabeza y esa cabeza se fue. El guiso tenía bus factor 1.

La receta escrita que sobrevive. Otra familia, con la misma abuela y el mismo guiso, hace una cosa distinta a tiempo: una tarde, se sientan con ella y escriben la receta —las proporciones exactas, cómo reconocer "el punto", los trucos que ella da por obvios—. No es lo mismo que la abuela (ella improvisa, ajusta, tiene un instinto que ninguna receta captura del todo), pero es lo estable del guiso: lo que no cambia, lo que se puede transmitir. Cuando la abuela ya no está, el guiso sobrevive: la familia lo hace con la receta, sale bien, y —esto es lo importante— se lo pueden enseñar a la siguiente generación, que se lo enseñará a la siguiente. El conocimiento dejó de depender de una sola persona. El guiso ya no tiene bus factor 1.

Aquí está la lección entera: escribir la receta no reemplaza a la abuela —su instinto para improvisar se fue con ella—, pero salva lo esencial del guiso de morir con ella. La abuela es Elena; el guiso es el módulo de payments; la receta escrita es la documentación de lo estable. Mientras Elena esté, no hace falta la receta —ella sabe—, y por eso es tan tentador no escribirla ("total, Elena sabe de payments"). Pero esa comodidad es la trampa: el día que Elena se va, si nadie escribió la receta, payments queda como el guiso perdido —nadie sabe por qué está hecho así, cuál es "el punto", qué decisiones lo sostienen—. Escribir la receta a tiempo —documentar lo estable de payments antes de que Elena se vaya— es lo que hace que el conocimiento sobreviva. Esta lección mide por qué escribir la receta es mucho más barato que formar a otra abuela, y por qué, como seguro, es la mejor inversión.

Ejemplo trabajado: quién se va, qué queda huérfano, y cuál seguro cuesta menos

Vamos a hacer tres cosas medidas. Primero, simular qué módulos de Mercado quedan huérfanos si cada persona se va —para encontrar los puntos únicos de falla—. Segundo, identificar los módulos en riesgo (bus factor 1). Tercero, comparar el costo de dos seguros para llevar esos módulos a bus factor ≥ 2: documentar lo estable contra formar un segundo dueño humano. El mapa de conocimiento tiene seis módulos ahora (añadimos search, que también lo mantiene una sola persona):

# Bus factor y compartir conocimiento. Simulamos quien se va y que modulos quedan
# HUERFANOS (sin nadie que sepa mantenerlos). Un modulo con un solo conocedor es un
# punto unico de falla. Luego comparamos dos seguros contra eso: documentar lo
# ESTABLE (barato) vs poner un segundo dueno humano por pairing/rotacion (caro).
OWNERSHIP = {
    "catalog":  {"Ana", "Beto", "Caro"},
    "orders":   {"Beto", "Diego"},
    "payments": {"Elena"},
    "shipping": {"Diego", "Caro"},
    "platform": {"Ana", "Elena", "Beto"},
    "search":   {"Caro"},
}
PEOPLE = sorted({p for owners in OWNERSHIP.values() for p in owners})

# 1) Si esta persona se va hoy, que modulos quedan huerfanos?
print("== Simulacion: quien se va -> que queda huerfano ==")
for person in PEOPLE:
    orphaned = [m for m, owners in OWNERSHIP.items() if owners - {person} == set()]
    tag = ", ".join(orphaned) if orphaned else "-"
    print(f"  se va {person:<6}-> huerfanos: {tag}")
print()

# 2) Modulos en riesgo hoy (bus factor <= 1): puntos unicos de falla.
at_risk = [m for m, owners in OWNERSHIP.items() if len(owners) <= 1]
print(f"Modulos en riesgo (bus factor 1): {', '.join(at_risk)}  ({len(at_risk)})")
print()

# 3) Dos seguros para llevar CADA modulo en riesgo a bus factor >= 2:
DOC_DAYS = 2      # documentar lo estable (limites + decisiones) de un modulo
PAIR_DAYS = 15    # formar un segundo dueno humano por pairing/rotacion
doc_cost = len(at_risk) * DOC_DAYS
pair_cost = len(at_risk) * PAIR_DAYS
print("Costo de asegurar los modulos en riesgo (llevarlos a bus factor >= 2):")
print(f"  documentar lo estable: {len(at_risk)} x {DOC_DAYS}d = {doc_cost} dias")
print(f"  segundo dueno humano:  {len(at_risk)} x {PAIR_DAYS}d = {pair_cost} dias")
print(f"  la doc es {pair_cost / doc_cost:.1f}x mas barata como SEGURO.")
print()
print("La doc no reemplaza al humano (el humano evoluciona el modulo); pero como")
print("SEGURO contra que una sola cabeza se lleve el conocimiento, es lo mas barato.")

Qué esperar. Al correr el archivo, la salida es exactamente esta:

== Simulacion: quien se va -> que queda huerfano ==
  se va Ana   -> huerfanos: -
  se va Beto  -> huerfanos: -
  se va Caro  -> huerfanos: search
  se va Diego -> huerfanos: -
  se va Elena -> huerfanos: payments

Modulos en riesgo (bus factor 1): payments, search  (2)

Costo de asegurar los modulos en riesgo (llevarlos a bus factor >= 2):
  documentar lo estable: 2 x 2d = 4 dias
  segundo dueno humano:  2 x 15d = 30 dias
  la doc es 7.5x mas barata como SEGURO.

La doc no reemplaza al humano (el humano evoluciona el modulo); pero como
SEGURO contra que una sola cabeza se lleve el conocimiento, es lo mas barato.

Lee la simulación primero, porque revela dónde está el riesgo real, que no es donde uno esperaría.

La simulación: solo dos salidas dejan huérfano un módulo. Fíjate en el patrón. Si se va Ana, Beto o Diego, no queda ningún módulo huérfano —"huérfanos: -"—: los módulos que ellos mantienen tienen otros conocedores que los sostienen. Pero si se va Caro, search queda huérfano (Caro es su único dueño); y si se va Elena, payments queda huérfano. Esto es revelador: de cinco personas, solo dos son puntos únicos de falla, y no por ser las "más importantes" en general, sino porque son las únicas que sostienen un módulo. El riesgo del bus factor no se reparte parejo entre las personas —se concentra en quienes son el único dueño de algo—. Y observa que Elena aparece en dos módulos (payments y platform), pero solo deja huérfano payments: platform tiene a Ana y Beto que lo sostienen. Ser conocedor de muchos módulos no te hace un punto único de falla; ser el único conocedor de uno sí. El riesgo está en la exclusividad, no en la cantidad.

Los módulos en riesgo: payments y search, bus factor 1. La simulación identifica exactamente dos módulos en riesgo —los que una sola persona mantiene—. Estos son los que hay que asegurar; los otros cuatro ya tienen respaldo. Fíjate en la eficiencia del diagnóstico: no hay que "mejorar la documentación en general", hay que asegurar dos módulos concretos. El bus factor te dice exactamente dónde poner el esfuerzo —en los cuellos de botella, no repartido—.

La comparación de seguros: la doc es 7.5x más barata. Para llevar cada módulo en riesgo a bus factor ≥ 2, hay dos caminos. Documentar lo estable de payments y search —sus límites y decisiones, la "receta"— cuesta unos 2 días por módulo, 4 días en total. Formar un segundo dueño humano por pairing o rotación —que otra persona aprenda payments y search trabajándolos hasta poder mantenerlos sola— cuesta unos 15 días por módulo, 30 días en total. La documentación es 7.5 veces más barata como seguro. Con 4 días de trabajo eliminas los dos puntos únicos de falla del sistema; con el camino humano, gastarías casi mes y medio-persona para el mismo bus factor.

Y el matiz honesto, en la última línea, que evita el malentendido peligroso. El programa lo dice claro: "la doc no reemplaza al humano (el humano evoluciona el módulo)". Documentar payments no lo vuelve tan mantenible como tener dos expertos humanos —un humano puede evolucionar el módulo, tomar decisiones nuevas, improvisar ante lo que la doc no previó, como la abuela que ajusta el guiso—. La doc captura lo estable (la receta), no el instinto vivo. Entonces, ¿por qué gana la doc? Porque como seguro —como protección contra el riesgo específico de que el conocimiento se pierda cuando la persona se va— la doc es imbatiblemente barata y suficiente: evita que payments quede huérfano (sin nadie que lo entienda) por una fracción del costo. La lección no es "documenta en vez de formar gente"; es "documenta lo estable como seguro barato y forma gente donde necesites evolución activa". Para el riesgo de perder el conocimiento, la doc es el seguro correcto; para tener un módulo con dueños activos que lo hagan crecer, hacen falta humanos. Son complementarios, no sustitutos —y el error es no tener ninguno de los dos y confiar en que Elena nunca se vaya—.

Como diagrama, el riesgo y su seguro se ven así:

Riesgo de conocimiento en Mercado (quien es punto unico de falla)
  Caro  ── unico dueno de search   ─┐
  Elena ── unico dueno de payments ─┴─> 2 modulos en bus factor 1

Dos seguros para subir a bus factor 2:
  documentar lo estable   ████ 4 dias      <- barato, evita orfandad
  segundo dueno humano    ██████████████████████████████ 30 dias
                          la doc es 7.5x mas barata como SEGURO

Profundización: el conocimiento como riesgo asegurable

El experimento trató el conocimiento como un riesgo que se asegura. Vale la pena desarrollar esa lente, porque cambia cómo un arquitecto piensa la documentación —de "una buena práctica que estaría bien tener" a "una decisión de gestión de riesgo con una economía clara"—.

Empecemos por por qué el bus factor 1 es tan tentador de dejar así, porque entender la tentación es la mitad de la cura. Mientras la persona está, el conocimiento concentrado en ella es más eficiente, no menos: no hay que documentar nada, no hay que enseñarle a nadie más, se le pregunta y responde al instante. Un equipo que optimiza para la velocidad de hoy naturalmente deja que el conocimiento se concentre —es el camino de menor esfuerzo—. El costo del bus factor 1 no existe mientras la persona está; aparece de golpe el día que se va, y para entonces es tarde para escribir la receta (la abuela ya no está para dictarla). Esta asimetría temporal —beneficio inmediato de concentrar, costo diferido y súbito de la salida— es exactamente la estructura de un riesgo no asegurado: ahorras la prima mientras no pasa nada, y pagas todo junto cuando pasa. La disciplina del arquitecto es pagar la prima antes, cuando la persona todavía está para dictar la receta.

Ahora, por qué la documentación es un seguro tan bueno para este riesgo específico. El riesgo del bus factor no es "el módulo deja de funcionar" —el código sigue corriendo cuando Elena se va—; es "nadie entiende el módulo lo suficiente para mantenerlo, cambiarlo o arreglarlo con seguridad". Ese entendimiento tiene dos capas: lo estable (por qué está así, cuáles son sus límites, qué decisiones lo sostienen —la receta—) y lo vivo (el instinto para evolucionarlo ante lo nuevo —la abuela improvisando—). La documentación captura barata y perfectamente la primera capa, que es la que más se pierde y más cuesta reconstruir: reconstruir el porqué de una decisión que nadie documentó puede tomar semanas de arqueología en el código y aun así quedar en conjetura. La segunda capa, el instinto vivo, la doc no la captura —pero esa se recupera más rápido si tienes la primera*: un dev nuevo con buena doc de lo estable de payments puede volverse un dueño competente en días, porque no tiene que redescubrir el porqué; ya lo tiene escrito—. La doc no evita que necesites gente; hace que formar gente nueva sea barato, porque parte de una receta en vez de cero. Por eso la doc de lo estable es el seguro correcto: cubre exactamente lo que más se pierde y hace barato recuperar el resto.

De ahí sale la relación entre los mecanismos de compartir conocimiento, que conviene ordenar porque no compiten sino que se complementan. La documentación de lo estable es el seguro base: barato, permanente, no depende de que nadie esté. El pairing y la rotación (que dos personas trabajen juntas un módulo, o que la gente rote entre módulos) construyen el conocimiento vivo en más de una cabeza: más caro, pero da dueños activos que evolucionan el módulo. Las revisiones de código esparcen conocimiento de a poco, como efecto secundario del trabajo normal. Un equipo maduro usa los tres: documenta lo estable de todo (seguro barato universal), y aplica pairing/rotación donde necesita dueños activos redundantes (los módulos críticos que evolucionan rápido). El error no es elegir mal entre ellos; es no usar ninguno y dejar que cada módulo dependa de una cabeza. Y dentro de esa mezcla, la documentación es lo que hace todo lo demás más barato: con buena doc de lo estable, el pairing es más rápido (el que aprende parte de la receta), la rotación es menos riesgosa (el que llega tiene mapa), y el onboarding no depende de nadie (lección 6).

Un matiz sobre la métrica misma, para usarla con juicio. El bus factor es una aproximación útil, no una verdad exacta: "conocer un módulo" no es binario (hay grados de entendimiento), y el modelo simplifica. Pero su valor no está en la precisión del número, sino en lo que te obliga a ver: que el riesgo de conocimiento se concentra en quienes son el único dueño de algo, y que ese riesgo es invisible hasta que se materializa. Usa el bus factor como un radar de puntos únicos de falla —para encontrar los módulos que dependen de una cabeza y asegurarlos antes de que esa cabeza se vaya—, no como una métrica de vanity que hay que maximizar en abstracto. Subir el bus factor de un módulo sano de 3 a 4 no vale nada; subir el de payments de 1 a 2 elimina un punto único de falla. El radar te dice dónde, la economía te dice con qué seguro (casi siempre, empezar por la doc de lo estable).

Errores comunes

Confiar en que la persona nunca se irá (no asegurar el riesgo). Qué pasa: el equipo sabe que payments solo lo entiende Elena, pero lo deja así —"Elena no se va a ir", o simplemente no se piensa en ello— porque mientras Elena está, todo funciona y preguntar es más rápido que documentar. El día que Elena avisa que se va, hay un mes de pánico intentando extraerle todo lo que sabe. Por qué pasa: el bus factor 1 es más eficiente en el corto plazo (no cuesta nada mientras la persona está), y su costo es diferido e invisible hasta la salida. Cómo detectarlo: si hay módulos que "solo fulano entiende" y nadie lo trata como un problema, si el equipo entra en pánico cuando esa persona se va de vacaciones, estás confiando en que nunca se irá. Cómo corregirlo: tratar cada bus factor 1 como un riesgo a asegurar ahora, mientras la persona está para dictar la receta —documentar lo estable del módulo es el seguro más barato—; la prima se paga antes, no después.

Creer que documentar reemplaza a formar gente (o viceversa). Qué pasa: un equipo documenta lo estable y concluye "listo, ya no dependemos de nadie" —olvidando que la doc no evoluciona el módulo, que para eso siguen haciendo falta dueños activos—; o al revés, un equipo hace pairing y rotación pero no documenta nada, y cuando ambas personas que conocían un módulo se van, se pierde el porqué igual. Por qué pasa: se piensa en documentación y en formación de gente como sustitutos que compiten, cuando son complementos que cubren cosas distintas (lo estable vs lo vivo). Cómo detectarlo: si justificas no documentar diciendo "es que hacemos pairing", o no formar dueños diciendo "es que está documentado", estás tratando complementos como sustitutos. Cómo corregirlo: usar los dos —documentar lo estable como seguro base universal (barato), y pairing/rotación donde necesitas dueños activos que evolucionen el módulo—; la doc hace lo estable barato de preservar, la gente hace lo vivo posible de evolucionar.

Maximizar el bus factor en abstracto (perder el radar). Qué pasa: el equipo, tomando el bus factor como una métrica a maximizar, invierte en subir el bus factor de módulos que ya están sanos (de 3 a 4) o en documentar todo por igual, en vez de atacar los puntos únicos de falla concretos. Gasta esfuerzo donde no hay riesgo. Por qué pasa: se confunde la métrica (un radar para encontrar riesgo) con una meta (un número grande es bueno). Cómo detectarlo: si estás documentando o formando gente en módulos que ya tienen varios dueños mientras dejas un bus factor 1 sin tocar, perdiste el radar. Cómo corregirlo: usar el bus factor para localizar los cuellos de botella (los módulos con un solo dueño) y concentrar el seguro ahí; subir un módulo sano no reduce el riesgo del sistema (que lo fija el más débil, como vimos en la lección 1). El objetivo no es un bus factor alto en promedio, es que ningún módulo crítico esté en 1.

Ejercicios

Ejercicio 1 — Por qué Elena en dos módulos deja huérfano solo uno. En la simulación, Elena es conocedora de dos módulos (payments y platform), pero cuando se va solo queda huérfano payments, no platform. Explica por qué, y qué te dice esto sobre dónde vive de verdad el riesgo del bus factor.

Ver solución

Elena deja huérfano solo payments porque es la única dueña de payments, pero no la única de platform. Cuando se va, payments se queda sin nadie que lo conozca (era su único dueño) → huérfano; pero platform todavía tiene a Ana y a Beto, que lo siguen sosteniendo → no huérfano. Lo que determina si la salida de Elena deja un módulo huérfano no es cuántos módulos conoce Elena, sino en cuáles es la única conocedora. Conocer platform junto con otros dos no crea riesgo; ser la única que conoce payments sí.

Esto revela dónde vive de verdad el riesgo del bus factor: en la exclusividad, no en la cantidad de conocimiento. Una persona que sabe de muchos módulos pero siempre acompañada de otros no es un punto único de falla en ninguno —su salida no deja nada huérfano—. Una persona que es la única que sabe de un solo módulo sí lo es. El riesgo no se mide por "cuánto sabe la persona" (que es la intuición común: "Elena sabe muchísimo, es un riesgo enorme") sino por "de qué es la única que sabe". La consecuencia práctica: para reducir el riesgo del bus factor no hay que preocuparse por las personas que más saben en general, sino por identificar cada módulo con un solo dueño y asegurar ese módulo —darle un segundo conocedor o documentar lo estable—. El radar apunta a los módulos exclusivos, no a las personas sabias.

Ejercicio 2 — El seguro correcto para cada capa. El texto distingue dos capas del conocimiento de un módulo: lo estable (el porqué, los límites —la receta—) y lo vivo (el instinto para evolucionarlo —la abuela improvisando—). Para cada capa, di qué mecanismo la protege mejor (documentación / pairing-rotación), y explica por qué la documentación gana como "seguro" aunque no capture la capa viva.

Ver solución

Lo estable (el porqué, los límites) lo protege mejor la documentación. Esta capa es exactamente lo que un ADR y la descripción de límites capturan: por qué payments está separado, qué contratos expone, qué decisiones lo sostienen. Es información que cambia poco (estable) y que la doc preserva barata y perfectamente. Y es la capa que más se pierde cuando la persona se va, porque el porqué no está en el código —reconstruirlo sin doc es arqueología lenta y conjetural—. Documentar lo estable es el seguro correcto para esta capa: barato, permanente, y cubre lo que más costaría recuperar.

Lo vivo (el instinto para evolucionar el módulo) lo protege mejor el pairing/rotación. Esta capa —tomar decisiones nuevas, improvisar ante lo que la doc no previó, hacer crecer el módulo— no se puede escribir en una receta, porque es juicio en tiempo real. Solo se transmite trabajando el módulo junto a otra persona (pairing) o rotando gente por él, hasta que más de una cabeza tenga el instinto. Para tener dueños activos redundantes que evolucionen payments, hacen falta humanos, no doc.

Por qué la doc gana como seguro aunque no capture la capa viva: porque el riesgo específico que asegura el bus factor es que el conocimiento se pierda cuando la persona se va, y la capa que más se pierde y más cuesta reconstruir es la estable (el porqué) —justo la que la doc captura barata—. La capa viva, en cambio, se recupera más rápido si tienes la estable documentada: un dev nuevo con buena doc del porqué de payments se vuelve un dueño competente en días, no semanas, porque no tiene que redescubrir el porqué. Así que la doc no solo asegura la capa estable directamente; también abarata recuperar la capa viva. Como seguro contra la pérdida de conocimiento, la doc cubre lo esencial por una fracción del costo. Lo que la doc no hace es reemplazar tener dueños activos —para evolución continua siguen haciendo falta humanos—, pero ese es un objetivo distinto (tener el módulo bien atendido) del que asegura el bus factor (que el conocimiento no muera con una salida). Cada mecanismo para su capa; la doc para lo estable, la gente para lo vivo; y la doc primero porque es el seguro más barato de lo que más se pierde.

Ejercicio 3 — La prima que se paga antes. El texto dice que el bus factor 1 es "un riesgo no asegurado" cuya prima hay que pagar antes de que la persona se vaya. Un gerente responde: "pero documentar payments ahora cuesta tiempo que necesitamos para features; mejor lo documentamos si algún día Elena avisa que se va". Explica por qué esa estrategia falla, usando la analogía de la abuela y la estructura temporal del riesgo.

Ver solución

La estrategia falla porque el mejor momento para escribir la receta es cuando la abuela todavía está, y "si algún día avisa que se va" suele ser demasiado tarde o de muy mala calidad. Piensa en la estructura temporal del riesgo: el bus factor 1 no cuesta nada mientras Elena está (por eso es tentador dejarlo), y su costo aparece de golpe cuando se va. La estrategia del gerente —"documentamos cuando Elena avise"— asume que habrá un momento cómodo, entre el aviso y la salida, para extraer todo su conocimiento. Pero ese momento es malo por tres razones. Primero, puede no existir: la gente a veces se va de golpe (una oferta con inicio inmediato, una enfermedad, un conflicto), sin período de aviso útil. Segundo, aun con aviso, ese período está saturado de traspaso apurado y Elena ya tiene un pie afuera —la documentación hecha bajo presión de salida es incompleta y de baja calidad, comparada con la que se escribe con calma mientras el conocimiento se usa a diario—. Tercero, y más sutil: mucho del conocimiento de Elena es tácito —cosas que ella da por obvias y ni recuerda que sabe—, y eso solo aflora escribiéndolo mientras trabaja el módulo normalmente, no en una sesión de "vuélcame todo lo que sabes" que el cerebro no puede hacer a demanda.

Es exactamente la abuela: la familia que espera a que la abuela "avise" que se va para escribir la receta descubre que no hubo aviso (se fue de golpe), o que en el apuro la receta salió incompleta, o que la abuela, presionada a dictar de memoria en una tarde, olvidó los trucos que solo salían cocinando. La familia que escribió la receta a tiempo —una tarde tranquila, cocinando juntas, con la abuela en plena forma— capturó lo estable bien. La prima del seguro se paga antes justamente porque el riesgo, cuando se materializa, no da tiempo de asegurarse: no puedes comprar seguro contra incendio cuando la casa ya está en llamas. Documentar lo estable de payments ahora —4 días, barato— es pagar la prima mientras se puede; esperar a que Elena avise es apostar a que habrá tiempo y calidad para hacerlo después, y esa apuesta se pierde seguido. Y el costo de perderla —payments huérfano, semanas de arqueología, decisiones deshechas por ignorancia— es mucho mayor que la prima que se quiso ahorrar.

Resumen y siguiente paso

En esta lección llevaste al fondo la idea que sostiene todo el módulo: que el conocimiento no dependa de una sola cabeza, medido con el bus factor. Simulaste quién se va de Mercado y viste que el riesgo se concentra en quienes son el único dueño de un módulo —solo Caro (search) y Elena (payments) dejan algo huérfano, y Elena en dos módulos deja huérfano solo uno, porque el riesgo vive en la exclusividad, no en la cantidad—. Comparaste los seguros para subir el bus factor a ≥ 2: documentar lo estable (4 días) contra formar un segundo dueño humano (30 días), y mediste que la doc es 7.5 veces más barata como seguro. Con la receta que sobrevive a la abuela, entendiste el matiz clave: la doc no reemplaza al humano (el instinto vivo se va con la persona) pero salva lo esencial de morir con ella —y como seguro contra la pérdida del conocimiento, es imbatiblemente barata—. Aprendiste a tratar el conocimiento como un riesgo asegurable, a pagar la prima antes (mientras la persona está para dictar la receta), y a usar el bus factor como un radar de puntos únicos de falla, no como una métrica a maximizar en abstracto.

Antes de avanzar deberías poder: explicar por qué el riesgo del bus factor vive en la exclusividad y no en la cantidad de conocimiento; distinguir qué capa (estable/viva) protege mejor cada mecanismo (doc/pairing) y por qué la doc gana como seguro; y argumentar por qué la prima del seguro se paga antes de la salida, no después.

La lección 8 es el proyecto que cierra el módulo: tomas el rol del arquitecto de Mercado ante un escenario real —Elena se va en un mes y entran seis devs nuevos este trimestre— y produces el paquete de documentación que sobrevive: la estructura docs-as-code, el README que hace onboarding, la decisión estable de payments capturada en un ADR para que sobreviva a Elena, y el reporte ejecutado que da el veredicto —¿está la documentación de Mercado lista para sobrevivir la salida de Elena?—. Todo lo del módulo converge en ese entregable: living documentation, docs-as-code, el sistema C4+ADR+arc42, lo estable, el README, y el bus factor de esta lección, aplicados a un caso que se mide.

Recursos

• Cyrille Martraire, Living Documentation (Addison-Wesley, 2019), sobre knowledge sharing y bus factor — el desarrollo canónico de la doc como mecanismo para que el conocimiento no dependa de individuos. En inglés.
• El concepto de bus factor / truck factor (Wikipedia y la literatura de ingeniería de software) — el origen y las variantes de la métrica, y estudios que la miden en proyectos reales de código abierto. En inglés.
• Matthew Skelton y Manuel Pais, Team Topologies (IT Revolution, 2019) — sobre cómo estructurar equipos y compartir conocimiento para que la capacidad no dependa de individuos; complementa el bus factor con la dimensión organizacional (el módulo 2 de esta guía). En inglés.
• Andrew Hunt y David Thomas, The Pragmatic Programmer, 20th Anniversary Edition (Addison-Wesley, 2019), sobre knowledge portfolios y no ser irreemplazable — la ética de compartir conocimiento en vez de acumularlo como poder. En inglés.
• Gene Kim, Jez Humble, Patrick Debois y John Willis, The DevOps Handbook (IT Revolution, 2016), sobre compartir conocimiento (pairing, revisiones, documentación) como práctica de resiliencia organizacional. En inglés.