Módulo 3: Comunicar la arquitectura

8. Proyecto: comunica la arquitectura de Mercado para dos audiencias

Siguiente →

Descripción

En este proyecto vas a actuar como el arquitecto de Mercado y producir, de principio a fin, el paquete de comunicación de un cambio real —los diagramas y el registro que hacen que dos audiencias muy distintas entiendan la misma arquitectura—. No es una lección nueva: es donde ensamblas todo lo del módulo. El escenario: Mercado va a abrir su plataforma a vendedores externos por API. Es una decisión grande —toca el catálogo, los pedidos, la seguridad, la carga— y hay que comunicarla a dos personas que no podrían ser más distintas: el VP de producto, que aprueba el proyecto y quiere entender dónde encaja en el negocio, y una desarrolladora nueva, que la semana que viene empieza a construir la API y necesita saber de qué piezas se compone Mercado y dónde tocará. Un solo mapa no sirve para los dos; darles el mismo diagrama le fallaría a al menos uno. Tu trabajo es producir el paquete completo y validar que cada pieza comunica.

Entregas cuatro cosas: (1) el Context de Mercado para el VP —el mapa del mundo, cinco cajas, cero jerga—; (2) el Container de Mercado para la dev nueva —el mapa de la ciudad, las piezas desplegables con sus tecnologías, incluida la nueva vía de vendedores externos—; (3) un ADR que comunica el porqué de la decisión, para que quien llegue después entienda por qué Mercado se abrió por API; y (4) la validación ejecutada de que cada mapa apunta al nivel correcto para su audiencia y pasa las reglas de higiene —no mezcla niveles, no es espagueti—. Al terminar, tendrás en tus manos exactamente lo que un arquitecto entrega cuando comunica un cambio de arquitectura de verdad.

Conexión con el módulo: este proyecto cierra los siete temas. Usa el C4 (lección 2) para elegir los niveles; dibuja el Context y el Container (lección 3) y decide no bajar a Component ni Code porque no hace falta para estas audiencias (lección 4); ejerce el corazón del módulo, elegir el nivel para cada audiencia (lección 5); añade el ADR como comunicación del porqué (lección 6); y valida contra las reglas que evitan el doc gigante y el espagueti (lección 7). Al final, apunta al módulo 4: comunicar bien es necesario pero no suficiente para que la decisión se ejecute —hace falta liderar sin autoridad—, que es lo que sigue en la guía.

El expediente que le entregas a dos lectores distintos

Piensa en un arquitecto de edificios —de los de verdad, los de ladrillo— que termina el diseño de una casa y tiene que "comunicarlo". No entrega un documento: entrega un expediente con piezas distintas para lectores distintos. Al dueño de la casa le muestra el render: cómo se verá, cuántos cuartos, dónde da el sol —lo que el dueño puede evaluar y aprobar—. Al maestro de obra le entrega los planos técnicos: medidas, materiales, dónde van las vigas —lo que el constructor necesita para trabajar—. Y en una carpeta aparte guarda las notas de decisiones: por qué la cocina va al norte (por la luz), por qué los muros de carga están donde están (por el terreno) —el porqué, para quien tenga que modificar la casa en el futuro—. Nadie le entrega el render al maestro de obra ni los planos al dueño: cada lector recibe la pieza que puede usar, y el porqué se guarda para el futuro.

Tu paquete de comunicación de Mercado es ese expediente. El Context es el render (para el VP-dueño), el Container son los planos (para la dev-constructora), y el ADR son las notas de decisiones (para quien herede el sistema). Un solo artefacto no cumple los tres papeles, igual que un render no sirve para construir ni un plano para aprobar el diseño. Comunicar la arquitectura es armar el expediente completo y saber qué pieza le toca a cada lector.

El encargo: Mercado abre su plataforma a vendedores externos

El contexto de negocio, para que lo tengas claro antes de dibujar. Hoy los vendedores de Mercado publican productos por la web app, a mano. La dirección quiere permitir que vendedores externos —tiendas que ya tienen su propio sistema— se integren por una API pública: que suban su catálogo, sincronicen inventario y reciban pedidos de forma automática, sin entrar a la web. Esto abre Mercado a muchos más vendedores (crecimiento) pero añade una superficie nueva: una API pública que hay que exponer, autenticar y proteger. El arquitecto ya decidió cómo hacerlo a grandes rasgos: una nueva pieza, la Seller API, separada de la API interna, con su propia autenticación por tokens, que valida y encola lo que llega de los vendedores externos antes de tocar el catálogo real. Tu trabajo no es re-decidir eso: es comunicarlo a las dos audiencias y dejar el porqué registrado.

Entregable 1: el Context para el VP (el mapa del mundo)

El VP pregunta: ¿qué hace Mercado, quién lo usa, y dónde encaja abrirlo a vendedores externos? Le das el Context —cinco/seis cajas, cero tecnología— con la novedad marcada: ahora hay dos clases de vendedor, el que usa la web y el externo que se integra por API.

C4Context
    title Mercado - System Context para el VP (con vendedores externos)
    Person(customer, "Customer", "Compra productos")
    Person(seller, "Seller (web)", "Publica desde la web de Mercado")
    Person_Ext(ext_seller, "External Seller", "Tienda con su propio sistema, se integra por API")

    System(mercado, "Mercado", "Marketplace: conecta compradores y vendedores")

    System_Ext(payments, "Payment Gateway", "Cobra pagos")
    System_Ext(carrier, "Carrier API", "Envia pedidos")

    Rel(customer, mercado, "Busca y compra")
    Rel(seller, mercado, "Publica por la web")
    Rel(ext_seller, mercado, "Sincroniza catalogo por API")
    Rel(mercado, payments, "Cobra")
    Rel(mercado, carrier, "Envia")

Cómo se lo cuentas al VP: "Aquí está Mercado y su mundo. Los clientes compran; los vendedores publican. Hoy solo publican por la web (Seller-web); lo que aprobamos es dejar que vendedores externos —tiendas con su propio sistema— se conecten por una API y sincronicen su catálogo automáticamente. Eso nos abre a muchos más vendedores. Las dependencias de siempre —pagos y envíos— no cambian." Seis cajas, una idea, una decisión que el VP puede evaluar: ve el beneficio (más vendedores) y puede preguntar por el riesgo (¿qué implica exponer una API pública?) sin ahogarse en una sola tecnología.

Entregable 2: el Container para la dev nueva (el mapa de la ciudad)

La dev pregunta: ¿de qué piezas se compone Mercado y dónde construyo la nueva API? Le das el Container —las piezas desplegables con sus tecnologías, incluida la nueva Seller API—.

C4Container
    title Mercado - Containers para la dev (con la Seller API nueva)
    Person(customer, "Customer", "Compra")
    Person(seller, "Seller (web)", "Publica")
    Person_Ext(ext_seller, "External Seller", "Se integra por API")

    System_Boundary(mercado, "Mercado") {
        Container(web, "Web App", "React", "Storefront y panel de vendedor")
        Container(api, "Internal API", "FastAPI", "Catalogo, pedidos, checkout")
        Container(seller_api, "Seller API", "FastAPI", "API publica: valida y encola lo de vendedores externos")
        ContainerDb(db, "Database", "PostgreSQL", "Productos, pedidos, usuarios")
        Container(search, "Search Index", "Elasticsearch", "Busqueda de catalogo")
        Container(queue, "Ingest Queue", "Redis", "Cola de cambios de catalogo por validar")
    }

    System_Ext(payments, "Payment Gateway", "Stripe")
    System_Ext(carrier, "Carrier API", "Envia")

    Rel(customer, web, "Usa", "HTTPS")
    Rel(seller, web, "Publica", "HTTPS")
    Rel(ext_seller, seller_api, "Sincroniza catalogo", "HTTPS/API + token")
    Rel(web, api, "Llama", "JSON/HTTPS")
    Rel(seller_api, queue, "Encola cambios", "Redis")
    Rel(api, queue, "Consume y valida cambios", "Redis")
    Rel(api, db, "Lee y escribe", "SQL")
    Rel(api, search, "Indexa y consulta", "HTTPS")
    Rel(api, payments, "Cobra", "HTTPS/API")
    Rel(api, carrier, "Envia", "HTTPS/API")

Cómo se lo cuentas a la dev: "Estas son las piezas. Los clientes y vendedores-web usan la Web App, que llama a la Internal API, que es el corazón —catálogo, pedidos, checkout— sobre PostgreSQL y Elasticsearch. Lo nuevo que vas a construir es la Seller API: una pieza aparte, pública, con autenticación por token, que recibe lo que mandan los vendedores externos, lo encola en Redis, y deja que la Internal API lo valide antes de tocar el catálogo real. La separas de la Internal API a propósito, para que el tráfico externo no toque directo el corazón del sistema." Ocho cajas: la dev sabe qué construir (Seller API + cola), dónde encaja, y por qué está separada. Con esto arranca a codear el lunes con un mapa, no a ciegas.

Fíjate en la decisión de nivel: no bajamos a Component ni a Code. La dev, para arrancar y orientarse, necesita el Container; cuando entre a construir el interior de la Seller API, quizás quiera un Component, pero eso es después y solo de esa pieza. Para el paquete de comunicación de esta decisión, Context + Container es exactamente el conjunto correcto —ni de más (el VP no necesita el Container, la dev no necesita el Code ahora) ni de menos—.

Entregable 3: el ADR que comunica el porqué

El diagrama muestra que la Seller API está separada y encola por Redis. No dice por qué. Ese porqué es lo que el ADR guarda para el dev que en dos años se pregunte "¿por qué la Seller API no escribe directo al catálogo, con lo simple que sería?". El ADR:

# ADR-021: Seller API pública separada, con ingesta por cola

Status: Accepted | Fecha: 2026-07-30 | Deciden: arquitecto, lead de catalog, lead de platform

## Contexto Abrimos Mercado a vendedores externos que se integran por API. Eso expone una superficie pública nueva: tráfico que no controlamos, de volumen impredecible, que podría contener datos inválidos o maliciosos. Si esa API escribiera directo al catálogo (la Internal API y su base de datos), un pico de tráfico externo o una carga masiva de datos malos golpearía el corazón del sistema —el mismo que sirve a los compradores—.

## Decisión Exponer una Seller API separada de la Internal API, con su propia autenticación por token. Lo que llega de vendedores externos no toca el catálogo directo: se encola (Redis) y la Internal API lo consume, valida y aplica a su ritmo. Así el tráfico externo queda aislado del núcleo.

## Consecuencias A favor:

  • El tráfico externo no puede tumbar ni corromper el catálogo: la cola amortigua picos y la validación filtra lo malo.
  • La Seller API se puede escalar y proteger por separado, sin tocar la Internal API.

En contra (el precio que aceptamos):

  • Los cambios de catálogo de vendedores externos no son instantáneos: pasan por la cola, así que hay un retraso hasta que se reflejan. Lo aceptamos porque la seguridad del núcleo vale más que la inmediatez.
  • Una pieza más y una cola más que operar y monitorear.

Este ADR es la nota pegada a la caja de fusibles. Cuando el dev futuro vea que la ingesta tiene un retraso y piense "esto sería instantáneo si la Seller API escribiera directo", el ADR le dirá: sí, lo sabíamos; el retraso es el precio consciente de no dejar que el tráfico externo toque el núcleo. No deshará la separación por ignorancia. El porqué viajó en el tiempo.

Ejemplo trabajado: valida el paquete antes de entregarlo

Antes de dar el paquete por bueno, lo pasas por las reglas del módulo: ¿cada mapa apunta al nivel correcto para su audiencia? ¿cada uno no mezcla niveles y no es espagueti? El siguiente código valida los dos entregables de diagrama —el Context para el VP y el Container para la dev— contra las tres reglas a la vez, y da el veredicto.

# Proyecto: comunicar la arquitectura de Mercado a DOS audiencias.
# Entregable 1: un Context para el VP.  Entregable 2: un Container para el dev nuevo.
# Aqui validamos que cada mapa (a) apunta al nivel correcto para su audiencia y
# (b) pasa las reglas de higiene (no mezcla niveles, no es espagueti).

LEGIBLE_LIMIT = 20
level_rank = {"Context": 1, "Container": 2, "Component": 3, "Code": 4}
recommended = {"VP de producto": "Context", "dev nuevo en el equipo": "Container"}

CORE_RANK = {"container": 2, "component": 3, "class": 4, "method": 4}
RANK_NAME = {2: "Container", 3: "Component", 4: "Code"}


def mixes_levels(elements):
    ranks = {CORE_RANK[e["type"]] for e in elements if e["type"] in CORE_RANK}
    return len(ranks) > 1


def is_spaghetti(elements):
    return len(elements) > LEGIBLE_LIMIT


# Entregable 1: Context para el VP.
context_for_vp = {
    "level": "Context",
    "audience": "VP de producto",
    "elements": [
        {"type": "person", "name": "Customer"},
        {"type": "person", "name": "Seller"},
        {"type": "software_system", "name": "Mercado"},
        {"type": "external_system", "name": "Payment Gateway"},
        {"type": "external_system", "name": "Carrier API"},
    ],
}

# Entregable 2: Container para el dev nuevo.
container_for_dev = {
    "level": "Container",
    "audience": "dev nuevo en el equipo",
    "elements": [
        {"type": "person", "name": "Customer"},
        {"type": "container", "name": "Web App"},
        {"type": "container", "name": "API"},
        {"type": "container", "name": "Checkout Service"},
        {"type": "container", "name": "Database"},
        {"type": "container", "name": "Search Index"},
        {"type": "external_system", "name": "Payment Gateway"},
        {"type": "external_system", "name": "Carrier API"},
    ],
}


def validate(deliverable):
    name = deliverable["audience"]
    level = deliverable["level"]
    want = recommended[name]
    elems = deliverable["elements"]

    fit = "OK" if level == want else "MAL"
    mix = mixes_levels(elems)
    spa = is_spaghetti(elems)

    print(f"Entregable para: {name}")
    print(f"  Nivel: {level}  | audiencia espera: {want}  -> ajuste: {fit}")
    print(f"  Elementos: {len(elems)}  | mezcla niveles: {'si' if mix else 'no'}"
          f"  | espagueti: {'si' if spa else 'no'}")
    ok = (fit == "OK") and (not mix) and (not spa)
    print(f"  VEREDICTO: {'COMUNICA' if ok else 'REVISAR'}")
    print()
    return ok


print("== Validacion de los dos mapas de Mercado ==")
print()
r1 = validate(context_for_vp)
r2 = validate(container_for_dev)
print("Resumen: el VP recibe 5 cajas sin jerga; el dev recibe la ciudad con sus piezas.")
print(f"Ambos entregables comunican: {r1 and r2}")

Qué esperar. Al correrlo:

== Validacion de los dos mapas de Mercado ==

Entregable para: VP de producto
  Nivel: Context  | audiencia espera: Context  -> ajuste: OK
  Elementos: 5  | mezcla niveles: no  | espagueti: no
  VEREDICTO: COMUNICA

Entregable para: dev nuevo en el equipo
  Nivel: Container  | audiencia espera: Container  -> ajuste: OK
  Elementos: 8  | mezcla niveles: no  | espagueti: no
  VEREDICTO: COMUNICA

Resumen: el VP recibe 5 cajas sin jerga; el dev recibe la ciudad con sus piezas.
Ambos entregables comunican: True

Los dos veredictos son COMUNICA, y cada uno por las tres razones juntas. El Context para el VP: nivel correcto (el VP quería el mapa del mundo), un solo nivel, 5 elementos. El Container para la dev: nivel correcto (quería el mapa de la ciudad), un solo nivel, 8 elementos. Ninguno mezcla, ninguno es espagueti, ninguno le da a su audiencia el zoom equivocado. Esa es la firma de un paquete de comunicación bien armado: no "un diagrama enorme que lo muestra todo", sino dos mapas chicos, cada uno afinado para su lector, más el ADR que guarda el porqué. Completitud en el conjunto, comunicación en cada pieza.

Errores comunes

Entregar un solo diagrama "para los dos" (de atajo). Qué pasa: para ahorrarte trabajo, haces un diagrama intermedio y se lo das al VP y a la dev, esperando que a los dos les sirva. Le falla a los dos: al VP le sobra, a la dev le falta. Por qué pasa: producir dos mapas cuesta más que uno. Cómo detectarlo: si tu paquete tiene un diagrama en vez de uno por audiencia, tomaste el atajo que la lección 5 desmonta. Cómo corregirlo: el paquete de comunicación es varias piezas por diseño —Context para el negocio, Container para los devs—; el costo de las dos se paga con no perder ninguna de las dos conversaciones.

Entregar los diagramas sin el ADR (de olvidar el porqué). Qué pasa: das el Context y el Container impecables, pero no dejas registrado por qué la Seller API está separada y encola. Seis meses después alguien "simplifica" conectándola directo al catálogo y reintroduce el riesgo que la separación evitaba. Por qué pasa: los diagramas se sienten como "la documentación" y el porqué se da por obvio (lo es hoy, no en dos años). Cómo detectarlo: si tu paquete no responde "¿por qué es así y no más simple?", te falta el ADR. Cómo corregirlo: toda decisión estructural que alguien podría querer deshacer necesita su ADR —el diagrama muestra el qué, el ADR guarda el por qué—.

Validar el diseño y olvidar validar la comunicación (de foco técnico). Qué pasa: revisas mil veces si la arquitectura es correcta (¿la cola aguanta?, ¿el token es seguro?) pero nunca revisas si los diagramas comunican —si están al nivel de su audiencia, si no son espagueti—. Entregas un diseño impecable que nadie entiende. Por qué pasa: el rigor técnico se siente como el trabajo "de verdad" y la comunicación como un extra. Cómo detectarlo: si no pasaste tus diagramas por las reglas de higiene y el emparejamiento con la audiencia, validaste medio trabajo. Cómo corregirlo: la comunicación es parte del entregable, no su envoltura; corre la validación (nivel + mezcla + espagueti) sobre cada mapa antes de darlo por bueno, como hiciste arriba.

Ejercicios

Ejercicio 1 — Arma el paquete para un cambio distinto. Mercado ahora quiere añadir reseñas de productos (los clientes califican y comentan lo que compraron). Como arquitecto, arma el esqueleto del paquete de comunicación: (a) ¿qué nivel(es) del C4 produces y para quién?; (b) ¿qué caja(s) nueva(s) aparecen en el Container?; (c) ¿qué decisión merecería un ADR?

Ver solución

(a) Niveles y audiencias: el mismo conjunto base —Context para el VP/negocio (que quiere ver que se añade una capacidad de reseñas y cómo encaja) y Container para los devs que lo construirán—. No hace falta Component ni Code para comunicar la decisión; se bajaría a Component solo si el servicio de reseñas resultara internamente complejo, y solo esa pieza.

(b) Cajas nuevas en el Container: al menos un Reviews Service (o un módulo de reseñas en la Internal API, según la decisión), y probablemente su almacenamiento —las reseñas se pueden guardar en la base existente (PostgreSQL) o en una tabla nueva; si hay moderación automática, quizás una cola—. En el Context, en cambio, casi nada cambia: "reseñas" es una función interna, no un actor nuevo del mundo (los clientes ya existían); el Context quizás ni se toca, lo que ya te dice que es un cambio más "de ciudad" que "de mundo".

(c) La decisión que merece ADR: por ejemplo, "¿las reseñas se moderan antes o después de publicarse?" —una decisión con trade-off real (moderar antes protege pero retrasa; moderar después es ágil pero arriesga contenido malo visible)—. O "¿reviews es un servicio aparte o vive dentro del catálogo?". Cualquiera de esas merece un ADR porque tiene un porqué con precio que alguien en el futuro querría entender antes de cambiarlo. Un cambio sin trade-off interesante (dónde se guarda un campo) no necesita ADR.

Ejercicio 2 — Detecta el paquete mal armado. Un colega te pasa su paquete de comunicación para "abrir la API a vendedores externos": un único diagrama que muestra el Context, los seis containers, los componentes internos de la Seller API y las clases de validación, todo en una lámina con 26 elementos; y ningún ADR. Sin correr código, diagnostica qué está mal usando las reglas del módulo y di cómo lo reharías.

Ver solución

Diagnóstico:

  • Mezcla niveles: el diagrama junta Context (el sistema y sus actores), Container (las seis piezas), Component (el interior de la Seller API) y Code (las clases de validación) en una sola lámina —cuatro niveles de zoom encimados—. Falla la regla "un diagrama, un nivel".
  • Espagueti: 26 elementos superan el límite legible de 20. Nadie sigue eso con el ojo.
  • Falta el ADR: no hay registro del por qué la Seller API está separada y encola; el paquete comunica (mal) el qué y nada del porqué.
  • Audiencia: un solo diagrama no puede servir al VP y a la dev a la vez; este, además, no sirve a ninguno —el VP se ahoga, la dev no encuentra su mapa limpio—.

Cómo lo rehago: lo parto en el paquete correcto. (1) Un Context limpio (5-6 cajas) para el VP. (2) Un Container limpio (8 cajas) para la dev, con la Seller API y la cola. (3) Si la Seller API resulta compleja por dentro y la dev lo necesita, un Component solo de esa pieza —diagrama aparte, no encimado—. Las clases de validación no van en ningún diagrama a mano; se leen del código. (4) Un ADR que explique por qué la Seller API está separada y encola. Y (5) paso cada diagrama por la validación (nivel + mezcla + espagueti) antes de entregarlo. El monstruo de 26 elementos se convierte en 2-3 mapas limpios más un ADR: la misma información, ahora comunicada.

Ejercicio 3 — El guion de la entrega. Tienes tu paquete listo (Context, Container, ADR). Mañana lo presentas en una reunión donde estarán el VP de producto y la dev nueva, en la misma sala. Escribe, en cuatro o cinco frases, el guion de cómo conduces la reunión para servir a las dos audiencias sin ahogar ni perder a ninguna.

Ver solución

Un guion que funciona (aplica la técnica de secuenciar niveles desde el Context común, de la lección 5):

  1. Abro con el Context, para todos. "Aquí está Mercado y su mundo. Hoy los vendedores publican por la web; lo que vamos a construir es dejar que vendedores externos se integren por API. Eso nos abre a muchos más vendedores." (El VP ya tiene lo que necesita para su decisión; la dev tiene el marco.)
  2. Marco la decisión y su porqué, brevemente. "Decidimos exponer esa API como una pieza separada que no toca el catálogo directo, por seguridad; el detalle del porqué está en el ADR-021 si quieren profundizar después." (El VP entiende que hay una razón; la dev sabe dónde está registrada.)
  3. Anuncio el cambio de zoom. "VP, con esto ya tienes la foto para aprobar; de aquí en adelante bajo al detalle técnico para [dev]. Quédate si te interesa, pero la decisión de negocio ya está sobre la mesa."
  4. Bajo al Container, para la dev. "[Dev], estas son las piezas; lo que vas a construir es la Seller API y su cola, aquí, separada de la Internal API por la razón que vimos."
  5. Cierro. "El paquete —los dos diagramas y el ADR— está en el repo, versionado con el código, para que no se desactualice."

La clave: el Context es el idioma común donde arranca la reunión; de ahí se baja por niveles anunciando para quién es cada uno, de modo que el VP recibe su mundo y puede desconectar sin sentirse excluido, y la dev recibe su ciudad. Nadie se ahoga, nadie se pierde.

Resumen: qué construiste y hacia dónde sigue

En este proyecto armaste el paquete de comunicación completo de un cambio real de Mercado —abrir la plataforma a vendedores externos por API— para dos audiencias distintas. Produjiste el Context para el VP (el render: el mapa del mundo con la nueva vía de vendedores marcada, seis cajas sin jerga), el Container para la dev nueva (los planos: las piezas desplegables con la Seller API y la cola, ocho cajas con tecnologías), y el ADR-021 que guarda el porqué de la decisión (las notas: por qué la Seller API está separada y encola, con el precio aceptado a conciencia). Y validaste el paquete: los dos mapas dieron COMUNICA porque cada uno respeta las tres reglas del módulo a la vez —el nivel correcto para su audiencia, un solo nivel de abstracción, y un conteo de elementos bajo el límite legible—. Ese es el entregable real de un arquitecto que comunica un cambio: no un documento gigante ni un diagrama total, sino un expediente de piezas chicas, cada una afinada para su lector.

Con esto cierras el módulo 3. Ya sabes comunicar una arquitectura para que la entiendan: elegir el zoom del C4, dibujar los dos mapas que más importan, saber cuándo parar de bajar, elegir el nivel correcto para cada audiencia, usar el ADR como el porqué que viaja en el tiempo, y evitar el documento de 500 páginas y el diagrama-espagueti manteniendo la doc versionada con el código.

Hacia dónde sigue. Comunicar bien es necesario, pero no suficiente. Puedes tener el Context perfecto para el VP, el Container perfecto para la dev y el ADR impecable —y aun así la decisión no se ejecuta, porque el equipo de payments no está convencido, porque nadie tiene la autoridad formal de imponerla, porque el arquitecto se volvió el cuello de botella por donde todo debe pasar—. El módulo 4, liderar sin autoridad, toma justo ahí: cómo el arquitecto influye en vez de mandar, sostiene las conversaciones que mantienen viva una decisión (las load-bearing conversations), practica el disagree and commit, y evita convertirse en el embudo del que hablamos en el módulo 1. La comunicación es la herramienta; convertirla en ejecución real, cuando no tienes el poder de ordenar, es el oficio del próximo módulo.

Recursos

← Anterior7. Evitar el documento de 500 páginas y el diagrama-espaguetiSiguiente →1. Presentación del módulo: liderar sin poder ordenar