Módulo 1: Qué hace de verdad un arquitecto

Mini-proyecto: diagnostica y rediseña el rol del arquitecto en Mercado

Siguiente →

Descripción

Este es el capstone del módulo. Durante siete lecciones desmontaste las cuatro imágenes falsas del rol y montaste las cuatro reales: el arquitecto no dibuja el plano y se va, sino que está presente (lección 2); no vive en el penthouse, sino que baja al código (lección 3); no vende certezas, sino decisiones reversibles con su porqué (lección 4); no dicta, sino que habilita con guardrails (lección 5); no se vuelve el cuello de botella por quien todo pasa (lección 6); y no comete BDUF, sino que decide al último momento responsable (lección 7). Ahora aplicas todo eso de punta a punta a un caso real: el arquitecto actual de Mercado, que trabaja mal —como trabaja mucha gente de verdad— y al que vas a diagnosticar y rediseñar.

El trabajo del proyecto es el trabajo real de un arquitecto que llega a una organización y encuentra el rol mal ejercido: diagnosticar qué patologías padece la forma actual de trabajar, medir su costo, y rediseñar el rol para que funcione. Fíjate en la frontera, que es deliberada: este proyecto no reestructura los equipos a fondo (eso es Conway, el módulo 2), no produce el diagrama C4 de comunicación (módulo 3), no desarrolla las técnicas de liderazgo sin autoridad (módulo 4). Produce lo que va antes de todo eso: el diagnóstico del rol y su rediseño en un role charter —qué posee el arquitecto, qué delega, cómo habilita— con el costo de coordinación medido antes y después. Es el "quién hace qué" del arquitecto, la base sobre la que los módulos siguientes construyen.

Conexión con el módulo. Es la integración de las siete lecciones en un solo entregable ejecutado. El mapa de ownership usa la clasificación de la lección 1; el diagnóstico usa las cuatro imágenes falsas de las lecciones 2 a 7; el costo de coordinación usa la simulación de colas de la lección 6; y el charter usa el modelo jardinero de la lección 5. Al terminarlo, tendrás el artefacto que abre el trabajo del arquitecto en cualquier organización: un rol diagnosticado y rediseñado, con números. El siguiente paso —cómo estructurar los equipos para lograr la arquitectura deseada— es literalmente el módulo 2 (Conway).

El caso: el arquitecto actual de Mercado

Conoces a Álex, el arquitecto actual de Mercado. Álex es brillante y trabajador —no es el villano de la historia, es la mayoría de los arquitectos bienintencionados—. Pero trabaja así:

  • Dibujó un diagrama detalladísimo de la "arquitectura objetivo" de Mercado hace ocho meses, lo presentó, y desde entonces trabaja sobre ese diagrama sin actualizarlo, aunque el sistema ya no se le parece.
  • No abre el repositorio desde hace medio año; decide y estima desde las reuniones. La semana pasada estimó que mover orders a comunicación asíncrona "toma unos tres días".
  • Revisa y aprueba personalmente cada decisión técnica de las cinco squads —"para que la calidad no se caiga"—, así que las squads viven esperando su visto bueno.
  • Quiere tener todas las decisiones de Mercado resueltas por adelantado en su diagrama, incluidas las que dependen de datos que aún no existen (la carga real, cómo se separará el catálogo).

Tu trabajo es diagnosticar qué patologías tiene el rol de Álex, medir el costo de su forma de trabajar, y proponer el rediseño.

La solución de referencia, ejecutada

Vamos a construir la solución en un solo programa que hace tres pasos: mapea el ownership de las decisiones, mide el costo de coordinación antes y después del rediseño, y emite el role charter. Todo con datos fijos, reproducible.

Parte 1 — Los datos: la semana típica de Mercado

Recibimos, por squad, cuántas decisiones genera en una semana típica y cuántas de ellas cruzan squads (son de nivel arquitecto). El resto son locales:

# Proyecto M1: diagnostica el ROL del arquitecto actual de Mercado y rediseñalo.
# Entrada: las decisiones de una semana tipica por squad (total y cross-team) y
# como trabaja el arquitecto ACTUAL (todo pasa por el = bottleneck).
WEEKLY = {
    # squad -> (total, cross_team)
    "catalog":  (12, 1),
    "orders":   (10, 2),
    "payments": (8, 1),
    "shipping": (9, 1),
    "platform": (7, 2),
}
ARCHITECT_CAPACITY = 20
WEEKS = 8

Parte 2 — El programa completo

Los tres pasos, encadenados. El mapa de ownership (lección 1), el costo de coordinación antes (bottleneck, lección 6) contra después (guardrails, lección 5), y el role charter:

total = sum(t for t, _ in WEEKLY.values())
cross = sum(c for _, c in WEEKLY.values())
local = total - cross

# Paso 1: mapa de ownership (quien decide que).
print("=== Paso 1: mapa de ownership ===")
print(f"{'squad':<10}{'total':>7}{'cross->architect':>18}{'local->squad':>14}")
print("-" * 49)
for squad, (t, c) in WEEKLY.items():
    print(f"{squad:<10}{t:>7}{c:>18}{t - c:>14}")
print("-" * 49)
print(f"{'TOTAL':<10}{total:>7}{cross:>18}{local:>14}")


# Paso 2: costo de coordinacion ANTES (bottleneck) vs DESPUES (guardrails).
def simulate(arrivals, capacity, weeks):
    backlog = total_wait = 0
    for _ in range(weeks):
        backlog += arrivals
        backlog -= min(backlog, capacity)
        total_wait += backlog
    return backlog, total_wait


before_backlog, before_wait = simulate(total, ARCHITECT_CAPACITY, WEEKS)
after_backlog, after_wait = simulate(cross, ARCHITECT_CAPACITY, WEEKS)

print()
print(f"=== Paso 2: costo de coordinacion en {WEEKS} semanas ===")
print(f"{'rol':<28}{'backlog':>10}{'espera(dec-sem)':>17}")
print("-" * 55)
print(f"{'ANTES  (todo al arquitecto)':<28}{before_backlog:>10}{before_wait:>17}")
print(f"{'DESPUES (solo cross-team)':<28}{after_backlog:>10}{after_wait:>17}")
print()
saved = before_wait - after_wait
print(f"Redisenar el rol ahorra {saved} decision-semanas de espera y elimina el backlog.")

# Paso 3: charter del rol (que posee, que delega, como habilita).
print()
print("=== Paso 3: role charter del arquitecto de Mercado ===")
print(f"POSEE   : las {cross} decisiones cross-team/semana (contratos entre squads,")
print("          atributos de calidad, limites de servicio).")
print(f"DELEGA  : las {local} decisiones locales/semana a la squad duena, con guardrails.")
print("HABILITA: guardrails claros (REST interno, postgres, SLOs) + el porque en un ADR.")
print("NO ES   : torre de marfil (baja al codigo), ni dictador, ni cuello de botella.")

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

=== Paso 1: mapa de ownership ===
squad       total  cross->architect  local->squad
-------------------------------------------------
catalog        12                 1            11
orders         10                 2             8
payments        8                 1             7
shipping        9                 1             8
platform        7                 2             5
-------------------------------------------------
TOTAL          46                 7            39

=== Paso 2: costo de coordinacion en 8 semanas ===
rol                            backlog  espera(dec-sem)
-------------------------------------------------------
ANTES  (todo al arquitecto)        208              936
DESPUES (solo cross-team)            0                0

Redisenar el rol ahorra 936 decision-semanas de espera y elimina el backlog.

=== Paso 3: role charter del arquitecto de Mercado ===
POSEE   : las 7 decisiones cross-team/semana (contratos entre squads,
          atributos de calidad, limites de servicio).
DELEGA  : las 39 decisiones locales/semana a la squad duena, con guardrails.
HABILITA: guardrails claros (REST interno, postgres, SLOs) + el porque en un ADR.
NO ES   : torre de marfil (baja al codigo), ni dictador, ni cuello de botella.

Parte 3 — El diagnóstico, leído desde la propia corrida

Paso 1, el mapa de ownership. De las 46 decisiones semanales de Mercado, solo 7 cruzan squads —los contratos entre servicios, los atributos de calidad, los límites de servicio— y 39 son locales, propias de la squad que las vive. Este reparto es el diagnóstico de raíz del rol de Álex: él trata las 46 como suyas ("reviso y apruebo cada decisión técnica"), cuando su nivel son 7. Está metiendo las manos en 39 decisiones que las squads toman mejor que él, porque están más cerca del problema. El mapa ya dice, sin más análisis, dónde está el problema: Álex confundió "algunas decisiones necesitan mi vista" con "todas pasan por mí".

Paso 2, el costo de coordinación. Aquí el diagnóstico se vuelve número. Con el rol actual de Álex —las 46 decisiones pasando por él, capacidad de 20/semana— en 8 semanas se acumula un backlog de 208 decisiones atascadas y 936 decision-semanas de espera: las cinco squads pasan una parte enorme de su tiempo esperando el visto bueno de Álex, que no da abasto por más que trabaje. Con el rol rediseñado —solo las 7 cross-team suben, las 39 locales las deciden las squads con guardrails— el backlog es 0 y la espera es 0. El rediseño ahorra 936 decision-semanas y elimina el atasco. Y lo esencial, que ya sabes de la lección 6: la diferencia no es que Álex trabaje más o menos —su capacidad es 20 en los dos casos— es cuánto trabajo se le hace pasar. El rediseño no le pide a Álex esforzarse más; le pide dejar de ser el paso obligado de las 39 decisiones que no son suyas.

Las cuatro patologías de Álex, nombradas. El caso describe a un arquitecto que padece las cuatro imágenes falsas a la vez —no por casualidad, porque suelen venir juntas—:

  • Torre de marfil (lección 2): dibujó el diagrama hace ocho meses y no lo actualiza aunque el sistema ya no se le parece. El plano dejó de ser una hipótesis viva y se volvió un documento muerto.
  • Despegado del código (lección 3): medio año sin abrir el repositorio, y estima orders asíncrono en "tres días" desde el penthouse —la subestimación optimista clásica; el cambio real ronda las tres semanas—.
  • Dictador y cuello de botella (lecciones 5 y 6): revisa y aprueba cada decisión de las cinco squads, generando las 936 decision-semanas de espera que el paso 2 midió.
  • BDUF (lección 7): quiere todas las decisiones resueltas por adelantado en su diagrama, incluidas las que dependen de datos que aún no existen.

Paso 3, el role charter. El rediseño se cristaliza en un charter de cuatro líneas que reparte el rol. Álex posee las 7 decisiones cross-team —donde su vista transversal es única e insustituible—. Delega las 39 locales a la squad dueña, con guardrails. Habilita con guardrails claros ("REST interno, Postgres, estos SLOs") más el porqué registrado en un ADR, para que las squads decidan las suyas con autonomía y criterio. Y no es ninguna de las cuatro imágenes falsas: baja al código (contra la torre de marfil y el penthouse), no dicta ni es cuello de botella. Ese charter es el entregable central: convierte el diagnóstico en un rol concreto y ejecutable, con el costo medido que justifica el cambio.

Este proyecto es el paso 0 del oficio en cualquier organización. El charter no cierra el trabajo del arquitecto; lo lanza por el resto de la guía:

flowchart LR
    P["Proyecto M1<br/>diagnostico + role charter<br/>(paso 0: que hace el arquitecto)"] --> M2["M2<br/>Conway: estructurar<br/>los equipos"]
    M2 --> M3["M3<br/>C4: comunicar<br/>la arquitectura"]
    M3 --> M4["M4<br/>liderazgo sin<br/>autoridad"]

Léelo así: aquí defines qué hace el arquitecto y rediseñas su rol; de ahí en adelante, la guía te enseña a estructurar los equipos para lograr la arquitectura (Conway), a comunicarla (C4) y a liderar sin autoridad para que el rediseño se sostenga.

Tu entrega

Reproduce y adapta la solución de referencia. Tu entrega tiene tres piezas:

  1. El mapa de ownership ejecutado: las decisiones de la semana repartidas entre las de nivel arquitecto (cross-team) y las locales, con la salida literal de tu programa. Puedes usar los datos del ejemplo o —mejor— ajustar las decisiones de una o dos squads con números propios y ver cómo cambia el reparto.
  2. El diagnóstico: nombra cuáles de las cuatro imágenes falsas padece Álex y con qué evidencia del caso, y presenta el costo de coordinación antes/después (backlog y espera acumulada). El número —las 936 decision-semanas ahorradas— es el argumento del rediseño.
  3. El role charter: las cuatro líneas —POSEE / DELEGA / HABILITA / NO ES— adaptadas a Mercado. Sé concreto en los guardrails que propones (no "hagan las cosas bien", sino "REST interno, estos SLOs, logs en JSON").

Errores comunes

Diagnosticar a Álex como "mal arquitecto" en vez de nombrar patologías estructurales. Qué pasa: la entrega se vuelve un juicio de carácter —"Álex es controlador, no confía en la gente"— en vez de un diagnóstico de las cuatro imágenes falsas con su costo medido. Por qué pasa: es más fácil culpar a la persona que analizar la estructura, y el rol mal ejercido se siente como un defecto personal. Cómo detectarlo: si tu diagnóstico no nombra las patologías concretas (torre de marfil, penthouse, cuello de botella, BDUF) ni mide su costo, es un juicio, no un diagnóstico. Cómo corregirlo: recordar la lección 6 —el cuello de botella es estructural, no un defecto de carácter—. Álex es brillante y trabajador; el problema no es quién es sino cómo está estructurado su rol. Un buen diagnóstico nombra la patología, muestra su costo (las 936 decision-semanas) y propone el cambio estructural (el charter), sin necesidad de culpar a nadie. Eso, además, es lo único que Álex puede aceptar sin ponerse a la defensiva.

Producir un charter que "habilita" pero deja a Álex aprobándolo todo igual. Qué pasa: el charter dice las palabras correctas ("delega, habilita con guardrails") pero en la práctica propone que Álex siga revisando todo "solo para asegurarse", así que el cuello de botella sobrevive con otro nombre. Por qué pasa: es tentador suavizar el rediseño para que Álex no "pierda control", pero eso vacía el charter de efecto. Cómo detectarlo: si en tu diseño las 39 decisiones locales siguen pasando por Álex de algún modo (una revisión "ligera", un OK "rápido"), no rediseñaste nada —el backlog volvería—. Cómo corregirlo: que el charter sea real: las 39 locales las deciden las squads sin pasar por Álex, garantizadas por guardrails, no por su revisión. El músculo de la lección 5 —tolerar decisiones distintas de las propias— es lo que hace verdadero al charter. Un rediseño donde el arquitecto sigue siendo el paso obligado no es un rediseño; es el mismo embudo con lenguaje nuevo.

Saltar del diagnóstico a resolver la arquitectura de Mercado. Qué pasa: la entrega se desvía a "y además Mercado debería separar el catálogo así y usar eventos allá", diseñando el sistema en vez de rediseñar el rol. Por qué pasa: diseñar el sistema es el reflejo de todo arquitecto, y es más "divertido" que analizar el rol. Cómo detectarlo: si tu entrega empieza a proponer la arquitectura técnica de Mercado (qué servicio, qué protocolo), te saliste del proyecto. Cómo corregirlo: recordar la frontera. Este proyecto rediseña el rol del arquitecto —quién decide qué, con qué costo—, no la arquitectura del sistema. Cómo estructurar los equipos para lograr la arquitectura es el módulo 2 (Conway); cómo decidir el protocolo entre orders y shipping es la guía hermana. Aquí el objeto de diseño es el rol, no el sistema.

Ejercicios

Ejercicio 1 — Ajusta la semana y re-mide. Mercado crece y suma una sexta squad, search, que genera 8 decisiones semanales, 2 de ellas cross-team. Añádela a los datos, re-corre el programa mentalmente (o en código) y di cómo cambian el total de decisiones, las que suben al arquitecto, y —cualitativamente— el backlog del rol actual.

Ver solución

Con search (8 total, 2 cross-team), los nuevos números:

  • Total de decisiones: 46 + 8 = 54 por semana.
  • Cross-team (al arquitecto): 7 + 2 = 9.
  • Locales (a las squads): 39 + 6 = 45.

El rol rediseñado sigue sano: llegan 9 al arquitecto contra una capacidad de 20, así que el backlog se mantiene en 0. Sumar una squad no rompe el modelo distribuido, porque cada squad absorbe sus propias decisiones locales con guardrails; solo suben las pocas cross-team, y 9 sigue muy por debajo de 20.

El rol actual (bottleneck) empeora claramente: ahora llegan 54 al arquitecto contra 20 de capacidad, así que se acumulan 34 por semana (antes 26). El backlog crece más rápido y la espera acumulada sube. Esto ilustra el punto más importante del rediseño: el modelo bottleneck se degrada con cada squad que se suma —no escala—, mientras que el modelo distribuido absorbe el crecimiento sin problema. Un arquitecto-embudo se vuelve más insostenible conforme la organización crece; un arquitecto-jardinero escala con ella. Por eso el rediseño no es solo "más eficiente hoy": es lo único que sobrevive al crecimiento de Mercado. (Cómo estructurar esa nueva squad y sus fronteras es el módulo 2, Conway.)

Ejercicio 2 — Escribe los guardrails que reemplazan la revisión de Álex. El charter dice que Álex "habilita con guardrails" para que las 39 decisiones locales no pasen por él. Elige tres tipos de decisión local recurrente en Mercado y escribe, para cada uno, el guardrail concreto que permitiría a la squad decidir sola —recordando la lección 5: define el qué, no el cómo—.

Ver solución

Tres guardrails concretos, cada uno definiendo el qué (la frontera donde la decisión afecta a otros) y dejando el cómo a la squad:

  1. Decisión: cómo un servicio expone su API interna. Guardrail: "Toda comunicación entre servicios es por REST sobre HTTP, con versionado en la ruta y respuestas en JSON." Qué deja a la squad: cómo diseña sus recursos, qué endpoints, qué estructura interna de las respuestas, cómo pagina. Por qué habilita: garantiza la interoperabilidad (lo que afecta a otras squads) sin dictar el diseño de la API (que es de la squad).

  2. Decisión: cómo un servicio maneja su rendimiento. Guardrail: "Cada servicio cumple un SLO de 99.9% de disponibilidad y menos de 200ms de latencia p99; por encima de eso, es asunto de la squad." Qué deja a la squad: si usa cache, réplicas, índices, colas —cualquier técnica— para cumplir el SLO. Por qué habilita: fija el resultado que le importa a Mercado (el atributo de calidad) y deja completamente libre el cómo lograrlo. Es el guardrail del mejor tipo (lección 5).

  3. Decisión: cómo un servicio emite sus logs. Guardrail: "Todos los logs son JSON estructurado con estos campos mínimos (timestamp, service, trace_id, level) para que la observabilidad transversal funcione." Qué deja a la squad: qué librería de logging usa, qué campos extra añade, cómo los estructura internamente. Por qué habilita: asegura que la plataforma pueda correlacionar logs entre servicios (transversal) sin dictar la herramienta (local).

Con estos tres guardrails, decenas de decisiones que antes pasaban por Álex —cómo diseño mi endpoint, qué cache uso, qué librería de logs— las toma la squad sola, sabiendo que mientras se quede en el carril está bien. Los guardrails reemplazan la revisión caso por caso de Álex por una frontera clara y estable. Nota que ninguno dice "hagan las cosas bien" (ambiguo, obliga a preguntar) ni fija el cómo (dictado disfrazado); cada uno pone la frontera exactamente donde la decisión deja de ser local.

Ejercicio 3 — La conversación con Álex. Vas a presentarle a Álex el diagnóstico y el charter. Álex es brillante, trabajador y bienintencionado, y su primera reacción probable es defensiva ("reviso todo porque me importa la calidad"). Esboza cómo le presentarías el rediseño para que lo acepte, apoyándote en el número (las 936 decision-semanas) y sin atacarlo.

Ver solución

La clave es que Álex no es el villano —es brillante y le importa—, así que el rediseño no debe sonar a "lo haces mal" sino a "hay una forma de que tu preocupación por la calidad escale". Algo así:

Empezar por reconocer su intención, que es buena. "Sé que revisas cada decisión porque te importa que la calidad de Mercado no se caiga, y esa preocupación es correcta —de hecho es lo que un buen arquitecto debe tener—." Esto desarma la defensiva: no estás atacando su valor, lo estás validando.

Mostrar el número, no la culpa. "El problema no eres tú ni tu esfuerzo —ya estás a tope—. Es que las cinco squads generan 46 decisiones a la semana y ninguna persona puede revisar todo eso; la aritmética no lo permite. Mira: con el rol actual, se acumulan 208 decisiones atascadas y 936 decision-semanas de espera en dos meses. Las squads pasan ese tiempo esperándote. No es que trabajes poco; es que la estructura te hace el paso obligado de más de lo que cabe en una persona." El número despersonaliza: el enemigo es la estructura, no Álex.

Ofrecer que su preocupación se cumple mejor, no menos. "La calidad que te importa no se cae si dejas de revisar las 39 locales; se sube, porque las squads las toman mejor que nadie —están más cerca del problema— y tú te concentras en las 7 que de verdad necesitan tu vista transversal, donde eres insustituible. Los guardrails garantizan la calidad de las locales sin que tengas que revisarlas una por una. Tu preocupación por la calidad no desaparece; se vuelve escalable." Esto reencuadra el rediseño como cumplir mejor su objetivo, no abandonarlo.

Cerrar con lo que gana Álex. "Y esto te devuelve algo: podrás bajar al código otra vez, hacer los spikes que te hacen estimar bien, tomarte vacaciones sin que Mercado se frene. Dejas de ser el cuello de botella y vuelves a ser el arquitecto."

El principio general: apóyate en el número para que el enemigo sea la estructura (no la persona), reencuadra el rediseño como cumplir mejor su valor (la calidad) en vez de renunciar a él, y ofrécele lo que gana. Un arquitecto brillante y bienintencionado acepta un rediseño que le muestra, con evidencia, que su intención se cumple mejor de otra forma. (Cómo sostener este tipo de conversación que cambia una arquitectura —las load-bearing conversations— y cómo influir sin autoridad es exactamente el módulo 4.)

Resumen y siguiente paso

Cerraste el módulo aplicando su contenido completo a un caso real. Tomaste a Álex, el arquitecto actual de Mercado —brillante, trabajador, y atrapado en las cuatro imágenes falsas a la vez—, y produjiste el artefacto que abre el trabajo del arquitecto en cualquier organización: un mapa de ownership que separa las 7 decisiones de nivel arquitecto de las 39 locales; un diagnóstico que nombra las cuatro patologías (torre de marfil, penthouse, cuello de botella, BDUF) y mide su costo —936 decision-semanas de espera que el rediseño elimina—; y un role charter que reparte lo que el arquitecto posee, delega y habilita. No rediseñaste la arquitectura de Mercado ni sus equipos: hiciste el paso 0 que define qué hace el arquitecto y con qué costo.

Con esto termina el módulo 1. Ya sabes qué es el rol: no el que dibuja el plano y se va, sino el que está presente, baja al código, vende decisiones reversibles con su porqué, habilita con guardrails, evita ser el cuello de botella, y decide al último momento responsable. Lo que sigue en la guía es ejercer ese rol. El módulo 2 ataca la primera herramienta del oficio: la ley de Conway —cómo la estructura de comunicación de la organización moldea la del sistema, y cómo el arquitecto usa la maniobra inversa de Conway para estructurar los equipos y obtener la arquitectura que quiere—. El charter que acabas de escribir dice quién decide qué; Conway te enseña a estructurar los equipos mismos para que la arquitectura deseada emerja de esa estructura. Después vienen la comunicación (C4, módulo 3) y el liderazgo sin autoridad (módulo 4), que hacen que el rol que diagnosticaste aquí de verdad se sostenga.

Recursos

  • Martin Fowler, "Who Needs an Architect?" (IEEE Software, 2003) — martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf. El contraste entre el arquitecto que decide todo y el que habilita, que tu charter formaliza. La lectura que resume el módulo entero. En inglés.
  • Mark Richards y Neal Ford, Fundamentals of Software Architecture, 2ª ed. (O'Reilly, 2020), cap. 1–2 y 21–22 — qué es el rol y cómo un arquitecto efectivo trabaja con los equipos en vez de por encima de ellos. El marco del diagnóstico y el charter de este proyecto. En inglés.
  • Gregor Hohpe, The Software Architect Elevator (O'Reilly, 2020) — sobre el arquitecto que conecta pisos, baja al código y multiplica al equipo; el "NO ES torre de marfil ni penthouse" de tu charter viene de aquí. En inglés.
  • Matthew Skelton y Manuel Pais, Team Topologies (IT Revolution, 2019) — el marco de guardrails, equipos habilitados y plataformas que sostiene el "HABILITA" del charter, y la puerta al módulo 2 (Conway y los tipos de equipo). En inglés.
← AnteriorBDUF contra el último momento responsableSiguiente →1. Presentación del módulo: shipeas tu organigrama