Módulo 8: Proyecto capstone — sé el arquitecto de Mercado ante un cambio

6. Lidera el rollout sin autoridad

Siguiente →

Descripción

Este es el paso 5 del entregable, y es donde la decisión se convierte —o no— en un sistema real. En las lecciones anteriores derivaste los atributos, diseñaste la estructura y la comunicaste con el C4 y el ADR. Pero todo eso es una decisión sobre papel: la arquitectura del cambio solo existe si la organización la ejecuta. Y ejecutarla depende de que cinco squads que no le reportan al arquitecto adopten los contratos del cambio —el de la Seller API, los de plataforma-como-servicio— y de que el equipo seller_platform se forme y arranque. Al terminar esta lección vas a tener el quinto artefacto del dossier —el plan del rollout con su medición— y vas a haber comprobado, ejecutado, que la influencia con guardrails consigue adopción genuina donde el mandato solo consigue papeleo, y que el arquitecto que ordena se vuelve el cuello de botella que el paso 1 juró evitar.

Esto importa porque es el paso donde más arquitectos fracasan sin darse cuenta, convencidos de que "una arquitectura bien diseñada se implementa sola". No se implementa sola. El módulo 4 desmontó ese mito: tener razón no es tener poder. El arquitecto no es el jefe de las squads; su autoridad formal sobre ellas es cero. Si entrega el C4 y el ADR y se va —confiado en que "está bien diseñado, lo construirán"—, cada squad seguirá con sus prioridades, el equipo nuevo no se formará, los contratos no se adoptarán, y en unos meses el sistema real no se parecerá al diagrama —la torre de marfil del módulo 1, ahora sobre el cambio más importante del año—. El paso 5 es el reconocimiento de que la palanca más grande y más difícil del oficio no es técnica sino social: qué conversaciones tiene el arquitecto, qué guardrails construye, cómo consigue que un grupo de gente que no le reporta haga suya una decisión.

Conexión con el módulo: esta lección hace el paso 5 del hilo y aporta la pieza de M4 al capstone. Recibe su entrada del paso 4 (el C4 y el ADR son las herramientas con las que el arquitecto influye —la evidencia que muestra, el porqué que explica—) y del paso 1 (el rol enmarcado: el arquitecto jardinero que no quiere ser la puerta es el que aquí lidera con guardrails). Su salida —qué se adoptó de verdad y quién terminó dueño de qué— alimenta el paso 6: no se puede planear la evolución ni documentar algo que nadie adoptó. La frontera se respeta: aquí el objeto es el liderazgo técnico sin autoridad —influir, dar guardrails, disagree-and-commit, consenso—; la gestión de personas a fondo (contratación, evaluaciones) queda fuera.

El director de orquesta que no toca ningún instrumento

Piensa en un director de orquesta. Frente a él, cuarenta músicos, cada uno experto en su instrumento —el violinista toca mejor el violín que el director, el trompetista mejor la trompeta—. El director no toca ninguno. Su batuta no produce una sola nota. Y sin embargo, es él quien logra que los cuarenta suenen como una sola música en vez de como cuarenta solos simultáneos. ¿Cómo? No ordenándole a cada músico qué nota tocar —sería imposible y absurdo—, sino dando una interpretación compartida: el tempo, la dinámica, la entrada de cada sección, el sentido de la obra. Los músicos, que saben tocar mejor que él, tocan juntos porque el director les dio un marco común que hicieron suyo. Si el director intentara imponer cada nota, la orquesta se detendría; como da un marco y confía en el oficio de cada músico dentro de él, la música fluye.

El arquitecto que lidera el rollout de un cambio es ese director. Las cinco squads saben implementar su dominio mejor que él —catalog sabe de catálogo, payments de pagos—. El arquitecto no les va a decir cómo escribir su código; sería imposible y sería volverse el embudo del paso 1. Lo que da es el marco compartido: el contrato del cambio (cómo se exponen y consumen los servicios), el guardrail que hace barato adoptarlo (un contract-test en CI que verifica el formato sin que el arquitecto revise cada PR), la evidencia de que funciona (el early adopter que ya lo usa), y el consenso que hace que las squads lo hagan suyo. Como el director, su poder no está en producir las notas, sino en lograr que quienes las producen toquen juntos. Esta lección mide la diferencia entre dirigir así —influir con un marco— y el reflejo del que no sabe dirigir: mandar un comunicado de que "es obligatorio" y esperar que suene la música.

Ejemplo trabajado: la adopción, medida

Vamos a comparar dos formas de conseguir que las seis squads (las cinco existentes más seller_platform) adopten el contrato del cambio, midiendo dos cosas a la vez: la adopción genuina (¿cuántas squads lo usan de verdad, no solo en el papel?) y la carga del arquitecto (¿cuántos PRs de migración tiene que revisar?). El escenario del mandato es el reflejo del liderazgo con prisa: un comunicado de que es obligatorio. El escenario de influencia + guardrail es el método del módulo 4: sembrar, dar el carril, buscar consenso. Reusamos los dos motores del módulo 4 —la difusión de la adopción y la carga de revisión—.

# Capstone paso 5: liderar el rollout SIN autoridad. La arquitectura del cambio solo
# existe si la organizacion la ejecuta: el equipo seller_platform se forma, y las squads
# que ahora exponen servicios (catalog, payments, platform...) adoptan el CONTRATO
# estable que hace posible consumirlas sin co-cambiar. El arquitecto no manda: influye,
# da guardrails, y busca el consenso. Medimos dos cosas: adopcion GENUINA y su propia carga.

SQUADS = 6            # 5 existentes + seller_platform
WEEKS = 12


# --- Adopcion genuina del contrato (motor de la leccion 2 del modulo 4) ---
def influence(seed, contagion):
    a, hist = seed, [seed]
    for _ in range(WEEKS):
        a = min(SQUADS, a + contagion * a * ((SQUADS - a) / SQUADS))
        hist.append(a)
    return hist


def mandate(g0, backslide):
    g, hist = g0, [g0]
    for _ in range(WEEKS):
        g = max(0.0, g - backslide * g)
        hist.append(g)
    return hist


adopt_influence = influence(seed=1.0, contagion=0.70)
adopt_mandate = mandate(g0=2.0, backslide=0.12)

# --- Carga del arquitecto (motor de la leccion 4 del modulo 4) ---
# Migrar a contratos estables abre PRs. Con MANDATE el arquitecto revisa cada PR para
# verificar que el contrato se respeta (puerta). Con GUARDRAIL un contract-test en CI
# (fitness function) aprueba la rutina; el arquitecto solo mira las excepciones reales.
PRS_PER_SQUAD = 8
total_prs = SQUADS * PRS_PER_SQUAD
EXCEPTIONS = 6
gate_reviews = total_prs
guardrail_reviews = EXCEPTIONS

print("ADOPCION GENUINA del contrato del cambio (de 6 squads):")
print(f"{'week':<8}{'mandate':>10}{'influence+guardrail':>21}")
for w in (0, 4, 8, 12):
    print(f"{w:<8}{adopt_mandate[w]:>10.2f}{adopt_influence[w]:>21.2f}")
print()
print(f"Semana 12: mandato = {adopt_mandate[-1]:.1f}/6   influencia = {adopt_influence[-1]:.1f}/6")
print()
print("CARGA DEL ARQUITECTO durante el rollout:")
print(f"{'design':<12}{'total_prs':>11}{'arch_reviews':>14}")
print(f"{'GATE':<12}{total_prs:>11}{gate_reviews:>14}")
print(f"{'GUARDRAIL':<12}{total_prs:>11}{guardrail_reviews:>14}")
print()
print(f"El mandato consigue papeleo pero {adopt_mandate[-1]:.1f}/6 real, y pone al arquitecto a")
print(f"revisar {gate_reviews} PRs: el cuello de botella que el paso 1 juro evitar.")
print(f"La influencia con guardrailes llega a {adopt_influence[-1]:.1f}/6 genuina y deja al")
print(f"arquitecto revisando solo {guardrail_reviews}: lidera el cambio sin ordenarlo ni ser la puerta.")

Qué esperar. Al correrlo:

ADOPCION GENUINA del contrato del cambio (de 6 squads):
week       mandate  influence+guardrail
0             2.00                 1.00
4             1.20                 4.44
8             0.72                 5.97
12            0.43                 6.00

Semana 12: mandato = 0.4/6   influencia = 6.0/6

CARGA DEL ARQUITECTO durante el rollout:
design        total_prs  arch_reviews
GATE                 48            48
GUARDRAIL            48             6

El mandato consigue papeleo pero 0.4/6 real, y pone al arquitecto a
revisar 48 PRs: el cuello de botella que el paso 1 juro evitar.
La influencia con guardrailes llega a 6.0/6 genuina y deja al
arquitecto revisando solo 6: lidera el cambio sin ordenarlo ni ser la puerta.

Lee los dos bloques juntos, porque muestran las dos caras del liderazgo sobre este cambio.

El primer bloque es la adopción genuina. El mandato arranca arriba —2.0 el día cero, y si contáramos el "hecho" nominal que las squads reportan bajo presión llegaría a 6/6— pero se erosiona a 0.4 de 6 real para la semana 12: el contrato impuesto se cumple de dientes para afuera (una API que dice seguir el formato pero que rompe en los casos de borde, un servicio marcado "migrado" que nadie usa) y se abandona en cuanto llega la siguiente prioridad. La influencia + guardrail arranca en 1.0 (solo el early adopter), se difunde con la evidencia y el carril barato, y llega a 6.0 de 6 genuina, donde se queda —las seis squads lo usan de verdad porque lo adoptaron por convicción y el contract-test lo mantiene fácil—. En un cambio como abrir a vendedores externos, esta diferencia es la diferencia entre un surface que de verdad funciona en producción y uno que "está migrado" en el tablero pero se cae cuando un tercero lo usa distinto a lo esperado.

El segundo bloque es la carga del arquitecto, y aquí es donde el paso 5 se reconecta con el paso 1. Bajo el mandato, como no hay guardrail, el arquitecto termina revisando cada PR de migración para verificar que el contrato se respeta —48 PRs, el cuello de botella—. Con el guardrail (un contract-test en CI que verifica el formato automáticamente, más el camino pavimentado del contrato bien documentado), la automatización aprueba la rutina y el arquitecto revisa solo las 6 excepciones reales —los casos raros que de verdad piden su criterio, como cómo la costura payout ↔ payments maneja un reembolso—. Ocho veces menos carga, y la que queda es exactamente la que necesita su vista transversal. Recuerda el paso 1: el arquitecto enmarcó su rol para poseer 8 decisiones y delegar 38; si en el rollout se pusiera de puerta de 48 PRs, reintroduciría el embudo por la puerta de atrás, justo lo que juró evitar.

El punto del paso es que estos dos números están conectados, y esa conexión es la tesis del módulo 4 aplicada al capstone. El mandato falla por los dos lados a la vez: consigue adopción hueca (0.4) y vuelve al arquitecto la puerta (48 revisiones). No es coincidencia: mandar sin construir el carril obliga a vigilar el cumplimiento uno por uno, y vigilar el cumplimiento no produce convicción. La influencia con guardrails gana por los dos lados: adopción genuina (6.0) porque se construyó con evidencia y consenso, y carga baja (6) porque el guardrail sostiene el contrato sin el arquitecto. Liderar sin autoridad no es elegir entre adopción y no-ser-cuello-de-botella; es conseguir las dos con el mismo método —o perder las dos con el mandato—.

Profundización: el plan del rollout, squad por squad

El número muestra que la influencia gana, pero no cómo se ejecuta. El plan del rollout no es "convence a las squads"; es un plan concreto que trata a cada squad según su disposición, usando las herramientas del módulo 4. Para este cambio, el mapa de las seis squads y la palanca de cada una:

  • seller_platform (el equipo nuevo) — es quien más quiere el cambio, porque es su razón de existir. Es el early adopter natural: se siembra aquí. Que el surface de vendedores funcione en su equipo primero es la fuente de evidencia para las demás. Palanca: sembrar (difusión, módulo 4).

  • platform — el cambio le pide volver auth y notifications servicios estables (contrato) y montar el gateway. Tiene el dolor (hoy todos le tocan auth) y gana con el contrato. Saldo de confianza alto. Palanca: co-construir el guardrail (el contract-test) con ellos, porque son quienes lo operarán.

  • catalog — el cambio le pide exponer un contrato de ingesta de listings (la costura import ↔ catalog). Equipo pragmático: adopta si el costo es bajo. Palanca: bajar el costo con el guardrail y la evidencia de seller_platform.

  • payments — el cambio le pide exponer un contrato de payouts (la costura payout ↔ payments) que mueve dinero real. Aquí puede haber una objeción legítima: los payouts a terceros tocan cumplimiento y auditoría. Palanca: la load-bearing conversation antes de pedir adopción —escuchar la preocupación de cumplimiento y resolverla en el contrato—; si el contrato no puede acomodar la auditoría, se cambia el contrato (disagree-and-commit bien hecho, módulo 4).

  • orders — ocupada, sin tiempo, no en contra. Palanca: el camino pavimentado —que adoptar el contrato del checkout con el nuevo flujo cueste casi nada—.

  • shipping — la menos tocada por el cambio, adopta con la evidencia acumulada de las demás. Palanca: prueba social (las otras ya lo usan).

El rollout, en fases: sembrar en seller_platform y platform (semanas 1-3, y construir el contract-test que hace barata la adopción); la load-bearing conversation con payments (semanas 2-4, resolver la objeción de cumplimiento en el contrato de payouts antes de pedir nada); difundir con evidencia a las pragmáticas catalog y orders (semanas 3-6, "a seller_platform le funcionó, aquí está el contrato y el test, migrar cuesta poco"); la conversación con shipping (semanas 5-8, la menos tocada, con toda la evidencia ya acumulada); y la junta de consenso (semanas 8-11) que ratifica un acuerdo ya construido en privado, no que decide en frío. El consenso no es que las seis amen el contrato; es que las seis puedan decir "lo entiendo, mis preocupaciones se escucharon, me comprometo".

Aquí está la lección de integración del capstone: el rollout usa los artefactos de los pasos anteriores como herramientas de influencia. La evidencia que convence a las pragmáticas es que seller_platform ya usa la arquitectura del paso 3. El argumento que resuelve la objeción de payments es el ADR del paso 4, que ya nombró la costura payout ↔ payments como un contrato que preserva el cumplimiento. La justificación de por qué vale la pena adoptar es el atributo rector del paso 2 (scalability) traducido a "esto es lo que nos deja crecer 10x". El arquitecto no llega al rollout con las manos vacías: llega con el C4, el ADR y el ranking, y esos son sus instrumentos de persuasión sin autoridad. Un arquitecto que se saltara los pasos 2-4 llegaría al rollout sin evidencia ni porqué —solo con su opinión—, y su única herramienta sería el mandato, que el número acaba de mostrar que pierde.

Un matiz honesto sobre el modelo. Los parámetros de difusión (seed 1.0, contagio 0.70) y de erosión (0.12) son ilustrativos, elegidos para mostrar la forma robusta —la influencia se difunde y se queda; el mandato se erosiona—, no medidos de Mercado. La clasificación de 48 PRs con 6 excepciones asume que la mayoría de la migración es rutinaria (la cubre el contract-test) y solo unos casos tocan criterio real —lo cual es cierto porque se construyó el guardrail; sin él, muchos más PRs necesitarían revisión—. El modelo captura la estructura del problema, no una predicción exacta de semanas.

Errores comunes

Entregar el diseño y esperar que se implemente solo (de tener-razón-es-tener-poder). Qué pasa: el arquitecto termina el C4 y el ADR, los presenta, y asume que las squads "lo construirán porque está bien diseñado". Meses después, seller_platform no se formó del todo, catalog no expuso el contrato de ingesta, y el sistema real no se parece al diagrama. Por qué pasa: es el mito más cómodo del oficio —que la calidad de la decisión garantiza su ejecución—. Cómo detectarlo: si tu plan del cambio termina en "entregar el diagrama", te saltaste el paso más difícil. Cómo corregirlo: la decisión es la mitad fácil; hacerla pasar es la otra mitad, y requiere liderar la adopción activamente —sembrar, dar el carril, conversar, construir consenso—; un diagrama sin rollout es una torre de marfil con buen dibujo.

Mandar el contrato como obligatorio para ir "más rápido" (de mandato). Qué pasa: el VP o el arquitecto, con prisa por el plazo, manda un comunicado de que el contrato del cambio es obligatorio y lo mete en todos los sprints. El tablero dice 6/6 adoptado; la realidad es 0.4/6, con contratos llenos de basura para pasar el checkbox y que se caen cuando un tercero los usa de verdad. Por qué pasa: el mandato compra un titular inmediato y esconde el resultado. Cómo detectarlo: si tu métrica de adopción es "lo reportaron como hecho" y no "lo están usando de verdad", estás midiendo papeleo. Cómo corregirlo: mide la adopción por el uso real (¿un tercero integra sin romperse?, ¿la costura de payouts mueve dinero bien?), no por el reporte; y usa el mandato solo después del consenso, como respaldo institucional que sella lo que ya tiene convicción —nunca en vez del consenso—.

Volverse la puerta que revisa cada PR de migración (de embudo, otra vez). Qué pasa: el arquitecto, sin construir el guardrail, se pone a revisar personalmente cada uno de los 48 PRs de migración "para asegurar que el contrato se respeta", y reintroduce el cuello de botella que el paso 1 desmontó —sobre el cambio más grande del año, justo cuando menos puede darse el lujo—. Por qué pasa: revisar se siente como control de calidad; construir un guardrail se siente como trabajo "extra". Cómo detectarlo: si tu carga de revisión durante el rollout crece con el número de PRs, eres la puerta. Cómo corregirlo: construye el guardrail (el contract-test en CI que verifica el formato automáticamente) antes de que empiece la migración; la automatización aprueba las 42 rutinarias y a ti te dejan las 6 que de verdad piden criterio —lideras el estándar sin ser la puerta—.

Ejercicios

Ejercicio 1 — La objeción legítima de payments. En tu plan, payments puede tener una objeción real al contrato de payouts (mueve dinero de terceros, toca cumplimiento y auditoría). Explica por qué esa objeción se trata distinto de la simple reticencia de una squad "sin tiempo", y qué harías con ella —apoyándote en el ADR del paso 4—.

Ver solución

La objeción de payments se trata distinto porque es un hecho técnico, no una falta de ganas. Una squad "sin tiempo" (como orders) resiste por costo: se mueve si adoptar cuesta poco, y la palanca es el camino pavimentado. La objeción de payments es de otra naturaleza: si el contrato de payouts realmente rompe el cumplimiento o la auditoría de mover dinero a terceros, entonces el contrato está mal, no payments. Escuchar aquí no es solo construir confianza; es recoger información que mejora la decisión —el disagree-and-commit bien hecho del módulo 4: la objeción, si es válida, hace mejor el contrato—.

Qué haría, apoyándome en el ADR. El ADR-021 ya nombró la costura payout ↔ payments como "una costura genuina que exige un contrato estable" —o sea, el diseño ya reconoció que payments expone un contrato, no que seller_platform se mete a su código—. Con eso en la mano:

  1. La load-bearing conversation antes de pedir adopción: un 1:1 con el lead de payments —"¿qué te frenaría de exponer este contrato de payouts?"— para escuchar la preocupación de cumplimiento a fondo. No es resistencia; es una objeción real.

  2. Resolverla en el contrato: asegurar que el contrato de payouts preserve (o mejore) los campos que la auditoría exige y no exponga datos sensibles. Si el contrato no puede acomodar el cumplimiento, se cambia el contrato —eso es escuchar de verdad—. La decisión de cómo estructurar ese contrato de payouts con las garantías de cumplimiento es, además, un problema de api-design y architecture-decisions; el arquitecto aquí lo detecta y lo encauza, no lo re-diseña desde cero.

  3. Y saber cuándo sí escalaría: si payments quisiera, por ejemplo, saltarse la auditoría "para simplificar", eso sería un riesgo grave y el arquitecto escalaría. Pero su objeción es lo contrario —proteger el cumplimiento—, así que se integra, no se combate.

La lección: distinguir la objeción legítima (se integra, mejora el contrato) de la reticencia por costo (se resuelve con el carril barato) es central para liderar sin autoridad. Confundirlas es el error: tratar la objeción de cumplimiento de payments como "resistencia a vencer con evidencia" rompería el cumplimiento; tratar la falta de tiempo de orders como "objeción técnica" no entendería que solo necesitan que sea barato.

Ejercicio 2 — El VP presiona por el mandato. A mitad del rollout, el VP se impacienta: "esto va lento, mejor mando un comunicado de que el contrato es obligatorio y lo metemos en todos los sprints". Con los números del paso, argumenta por qué el mandato conseguiría menos, y reconoce en qué tendría razón el VP.

Ver solución

Por qué el mandato consigue menos. Con los números del paso, el mandato lleva la adopción genuina a 0.4 de 6 para la semana 12 (cumplimiento nominal que se erosiona), mientras la influencia llega a 6.0 de 6 real. Y de paso, el mandato pone al arquitecto a revisar los 48 PRs de migración para verificar cumplimiento —el cuello de botella— contra los 6 del guardrail. El comunicado del VP conseguiría exactamente lo que hay que evitar: un tablero que dice "6/6 adoptado" sobre un sistema donde, cuando un vendedor externo integre de verdad, los contratos se caerán —porque se llenaron de basura para cumplir el checkbox—. La prisa del mandato compra un titular y pierde el resultado, justo en el cambio donde el resultado (que terceros puedan integrar de verdad) es todo.

En qué tendría razón el VP. En la urgencia —el plazo es real y "va lento" puede ser una preocupación válida—. Y el mandato sí tiene un lugar legítimo: como respaldo del consenso, no como sustituto. Una vez que la influencia construyó la adopción genuina (las squads ya usan el contrato porque quisieron), un comunicado del VP declarándolo "oficial" ayuda —le da respaldo institucional a algo que ya tiene convicción, cierra a los rezagados, evita que una squad nueva lo ignore—. El orden importa: mandato después del consenso amplifica; mandato en vez de consenso erosiona. La respuesta al VP: "primero construyamos la adopción real —que ya va en camino, aquí está la evidencia de seller_platform— y luego tu comunicado la sella; al revés, conseguimos papeleo que se cae cuando el primer tercero lo pruebe".

Ejercicio 3 — El rollout se saltó los pasos anteriores. Un arquitecto llega directo a liderar el rollout del cambio sin haber hecho los pasos 2-4: sin el ranking de atributos, sin la maniobra de Conway, sin el C4 ni el ADR. Solo tiene la frase "abran una Seller API y adopten un contrato". Predice por qué su rollout va a fracasar aunque use las técnicas de influencia correctas.

Ver solución

Va a fracasar porque las técnicas de influencia necesitan materia prima, y esa materia prima son los artefactos de los pasos anteriores. Influir sin autoridad no es carisma en el vacío: es persuadir con evidencia, con un porqué, y con un carril barato. Sin los pasos 2-4, el arquitecto no tiene ninguna de las tres:

  • Sin el atributo rector (paso 2), no puede responder "¿por qué debemos adoptar esto?". Su única respuesta es "porque lo digo yo" —que es el mandato, el que pierde—. Con el paso 2, la respuesta es "porque esto es lo que nos deja crecer 10x, la meta que el negocio priorizó (scalability 38)", un porqué que las squads pueden hacer suyo.

  • Sin la estructura decidida (paso 3), no hay una arquitectura clara que adoptar; cada squad interpretará "abran una Seller API" a su manera, y el surface nacerá fragmentado —la fricción 21, no 7—. El rollout estaría difundiendo el caos, no un diseño.

  • Sin el C4 y el ADR (paso 4), no tiene la evidencia visual ni el porqué documentado que convencen a las pragmáticas y resuelven la objeción de payments. No puede mostrarle a catalog "así se ve, así te conectas"; no puede resolverle a payments la objeción de cumplimiento con un contrato ya pensado. Sus load-bearing conversations serían improvisadas, sin sustento.

La lección de integración: el rollout es el paso 5 por una razón —depende de que los cuatro anteriores le hayan dado sus herramientas—. Un arquitecto con excelentes técnicas de influencia pero sin el ranking, la estructura y los artefactos de comunicación es un director de orquesta sin partitura: sabe dirigir, pero no tiene qué. El hilo no se puede empezar por la mitad. El fracaso no sería de sus habilidades sociales; sería de haberlas intentado usar sin lo que las alimenta. Por eso el capstone insiste en el orden: cada paso arma las herramientas del siguiente.

Resumen y siguiente paso

En esta lección hiciste el paso 5 del entregable: liderar el rollout sin autoridad. Con el director de orquesta que no toca ningún instrumento pero logra que cuarenta músicos suenen juntos, entendiste que el poder del arquitecto no está en producir las notas sino en dar el marco que quienes las producen hacen suyo. Lo mediste ejecutando: sobre las seis squads, el mandato consigue papeleo pero solo 0.4/6 de adopción genuina y pone al arquitecto a revisar 48 PRs (el cuello de botella), mientras la influencia con guardrails llega a 6.0/6 genuina y deja al arquitecto revisando solo 6 —gana por los dos lados a la vez—. Viste el plan del rollout squad por squad (sembrar en seller_platform, resolver la objeción legítima de payments, difundir con evidencia, ratificar el consenso) y, sobre todo, que el rollout usa los artefactos de los pasos 2-4 como herramientas de influencia: el atributo rector es el porqué, el C4 y el ADR son la evidencia. Un arquitecto que se salta esos pasos llega al rollout sin materia prima para influir.

Antes de avanzar deberías poder: planear un rollout que trate a cada squad según su disposición y palanca; medir la adopción genuina contra el mandato y la carga del arquitecto; distinguir la objeción legítima (se integra) de la reticencia por costo (se abarata); y explicar por qué la influencia necesita los artefactos de los pasos anteriores para funcionar.

Lo que sigue es el paso 6, el que cierra el oficio. Ya conseguiste que la arquitectura se adopte; la lección 7 te enseña a planear su evolución y a documentarla para que sobreviva. Vas a decidir, ejecutado, qué construir ahora, qué poner en una versión sacrificial que se reemplazará con datos reales, y qué diferir dejando la costura —sin over- ni under-engineering—; y vas a medir cómo la documentación que sobrevive (docs-as-code: el README, el C4 y el ADR versionados) sube el bus factor del surface nuevo, para que el cambio no dependa de una sola cabeza. Es la diferencia entre lanzar una feature y cerrar el oficio.

Recursos

← Anterior5. Produce el C4 y el ADRSiguiente →7. Planea la evolución y la documentación