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

3. Deriva los atributos de calidad desde la meta

Siguiente →

Descripción

Este es el paso 2 del entregable, y es el corazón del hilo. En la lección 2 reservaste 8 decisiones para el arquitecto y viste que las más importantes son las de atributos de calidad —el SLO de la Seller API, la seguridad de los datos de terceros—. Pero, ¿de dónde salen esos atributos? No del catálogo técnico ni del gusto del arquitecto: salen de la meta de negocio. Al terminar esta lección vas a producir el segundo artefacto del dossier —el mapeo ejecutado de las metas del cambio a atributos de calidad priorizados— y vas a nombrar el conflicto que gobierna todo el cambio. Este es el paso que convierte una frase de negocio ("crecer 10x") en algo con lo que un arquitecto puede diseñar (un ranking de atributos con evidencia), y es el insumo del que cuelgan todos los pasos que siguen.

Esto importa porque el ranking de atributos es lo que le da dirección a la estructura, la comunicación y el rollout. Sin este paso, cuando en la lección 4 tengas que decidir qué equipos crear, no tendrás con qué justificar la elección; cuando en la lección 5 dibujes el C4, no sabrás qué atributo debe optimizar la arquitectura que muestras. El mapeo es la brújula del cambio: dice hacia dónde apunta todo lo demás. Y el resultado de este cambio concreto es revelador —scalability domina, porque "crecer 10x" y "abrir a vendedores externos" la empujan con fuerza máxima—, lo que le dirá al paso 3 que la estructura tiene que producir un surface de vendedores que escale independientemente. Un atributo distinto habría producido otra arquitectura. La meta manda, y este paso es donde ese mandato se hace explícito y medible.

Conexión con el módulo: esta lección hace el paso 2 del hilo y aporta la pieza de M5 al capstone. Recibe su entrada de la lección 2 (el encargo enmarcado: el arquitecto posee las decisiones de atributos) y entrega su salida a la lección 4 (la estructura): el atributo rector que derivas aquí es lo que dicta qué organización diseñar allá. La frontera con la guía hermana se mantiene firme, igual que en el módulo 5: aquí detectas que dos atributos compiten (scalability vs cost); cómo se resuelve ese conflicto —la matriz de decisión, la fitness function— es el método de architecture-decisions-and-tradeoffs, no de esta lección. Tu trabajo aquí termina en "estos son los atributos priorizados y este es el conflicto que hay que encarar primero", que es exactamente el insumo que la estructura del paso siguiente necesita.

El traductor de la ONU que prepara la negociación

Piensa en un traductor en una negociación internacional. En la mesa hay un jefe de Estado que dice, en su idioma, cosas como "queremos crecer económicamente pero sin depender de un solo socio comercial". El traductor no repite palabra por palabra; traduce el sentido al idioma de la otra parte, y —si es bueno— hace algo más: al traducir todas las declaraciones de su jefe a la vez, nota que algunas se contradicen entre sí. "Queremos crecer rápido" y "no queremos endeudarnos" empujan en direcciones opuestas; "queremos abrir el mercado" y "queremos proteger la industria local" chocan de frente. El buen traductor no espera a que la contradicción estalle a mitad de la negociación: la detecta antes, se la señala a su jefe en privado —"señor, estas dos metas que quiere no caben juntas al máximo; ¿cuál pesa más si hay que elegir?"— y así prepara una negociación con los conflictos ya identificados y ordenados por importancia.

Ese traductor hace exactamente lo que hace el arquitecto con las metas de negocio, y por eso el trabajo es traducirlas todas juntas en una sola tabla. Si el arquitecto tradujera "crecer 10x" en una reunión y "no triplicar la factura" en otra, nunca vería que las dos se pelean. Es al ponerlas juntas —con su peso, con los atributos que cada una empuja— donde salta a la vista que un atributo lo respaldan tres metas (pesa mucho) mientras a otro lo respalda una sola (pesa poco), y donde salta el conflicto: "crecer 10x" empuja scalability hacia arriba, "no triplicar la factura" empuja cost hacia abajo, y esas dos fuerzas se van a encontrar de frente. Este paso es el traductor que prepara la negociación: traduce todos los deseos del liderazgo a atributos, ve cuáles se refuerzan, y descubre cuáles chocan —para que el arquitecto llegue a diseñar con los conflictos ya nombrados y ordenados—.

Ejemplo trabajado: el mapeo meta → atributo del cambio

Vamos a ejecutar la traducción sobre las seis metas del cambio de Mercado. La estructura de datos tiene tres partes, todas fijas para reproducibilidad: el peso de negocio de cada meta (1 = nice-to-have, 5 = estratégico), qué atributos implica cada meta y con qué fuerza (1 a 3), y la lista de conflictos conocidos entre atributos. El score de cada atributo es la suma de peso × fuerza sobre todas las metas que lo empujan. Rankeamos, y detectamos qué conflicto pesa más. Es el mismo motor del módulo 5, aplicado ahora como el paso 2 del capstone.

# Capstone: el cambio de negocio de Mercado -- abrir a vendedores externos por API
# y crecer 10x. Reusamos el motor de la leccion 2 del modulo 5 (mapeo meta->atributo
# priorizado + deteccion de conflictos). Es el MISMO metodo, sobre el cambio insignia.

# Las metas del cambio, con su peso de negocio (1=nice-to-have .. 5=estrategico).
business_goals = {
    "open_to_external_sellers": 5,   # abrir el marketplace a vendedores de terceros por API
    "grow_10x":                 5,   # manejar 10x el catalogo y el trafico
    "survive_black_friday":     4,   # aguantar el pico sin caerse
    "protect_payment_data":     5,   # blindar los datos de pago
    "keep_infra_costs_flat":    3,   # no triplicar la factura de infraestructura
    "instant_checkout":         3,   # el checkout no se puede volver lento
}

# Que atributo(s) de calidad implica cada meta, y con que fuerza (1..3).
implies = {
    "open_to_external_sellers": {"scalability": 3, "security": 3, "availability": 2},
    "grow_10x":                 {"scalability": 3, "performance": 2, "cost": 2},
    "survive_black_friday":     {"availability": 3, "scalability": 2, "performance": 1},
    "protect_payment_data":     {"security": 3},
    "keep_infra_costs_flat":    {"cost": 3},
    "instant_checkout":         {"performance": 3, "availability": 1},
}

attributes = ["scalability", "availability", "security", "performance", "cost"]

# Score de cada atributo = suma de (peso de la meta * fuerza con que la implica).
score = {a: 0 for a in attributes}
for goal, weight in business_goals.items():
    for attr, strength in implies[goal].items():
        score[attr] += weight * strength

ranking = sorted(attributes, key=lambda a: score[a], reverse=True)

print("Atributos de calidad priorizados por su respaldo de negocio:")
print(f"{'#':>2}  {'atributo':<13}{'score':>6}   respaldado por (metas)")
for i, attr in enumerate(ranking, 1):
    backers = [g for g in business_goals if attr in implies[g]]
    print(f"{i:>2}  {attr:<13}{score[attr]:>6}   {', '.join(backers)}")

tensions = [
    ("scalability",  "cost"),
    ("security",     "performance"),
    ("availability", "performance"),
    ("availability", "cost"),
]

print()
print("Conflictos entre atributos (mejorar uno cuesta el otro), por peso combinado:")
ranked_tensions = sorted(tensions, key=lambda p: score[p[0]] + score[p[1]], reverse=True)
for a, b in ranked_tensions:
    print(f"  {a} ({score[a]}) vs {b} ({score[b]})  ->  peso combinado {score[a] + score[b]}")

print()
top = ranked_tensions[0]
print(f"El conflicto que MAS pesa: {top[0]} vs {top[1]}.")
print("Ese es el trade-off que gobierna el cambio: crecer 10x (scalability) contra")
print("no triplicar la factura (cost). El COMO resolverlo es architecture-decisions.")

Qué esperar. Al correrlo:

Atributos de calidad priorizados por su respaldo de negocio:
 #  atributo      score   respaldado por (metas)
 1  scalability      38   open_to_external_sellers, grow_10x, survive_black_friday
 2  security         30   open_to_external_sellers, protect_payment_data
 3  availability     25   open_to_external_sellers, survive_black_friday, instant_checkout
 4  performance      23   grow_10x, survive_black_friday, instant_checkout
 5  cost             19   grow_10x, keep_infra_costs_flat

Conflictos entre atributos (mejorar uno cuesta el otro), por peso combinado:
  scalability (38) vs cost (19)  ->  peso combinado 57
  security (30) vs performance (23)  ->  peso combinado 53
  availability (25) vs performance (23)  ->  peso combinado 48
  availability (25) vs cost (19)  ->  peso combinado 44

El conflicto que MAS pesa: scalability vs cost.
Ese es el trade-off que gobierna el cambio: crecer 10x (scalability) contra
no triplicar la factura (cost). El COMO resolverlo es architecture-decisions.

Lee el ranking primero, porque es la brújula del cambio. Scalability encabeza con 38, y la columna de la derecha dice por qué: tres metas la respaldan, y dos de ellas son las más estratégicas (peso 5) —abrir a vendedores externos y crecer 10x—. No es que al arquitecto le guste escalar; es que este cambio, por su naturaleza, empuja scalability más que ningún otro atributo. El número es trazable: open_to_external_sellers (peso 5) la implica con fuerza 3 → 15; grow_10x (peso 5) con fuerza 3 → 15; survive_black_friday (peso 4) con fuerza 2 → 8; total 38. Cuando en la lección 4 alguien pregunte "¿por qué diseñamos un equipo dedicado a escalar el surface de vendedores?", la respuesta no es una opinión: es esta suma. Ese es el trabajo del paso 2: darle a la estructura una dirección defendible.

Fíjate en security, segundo con 30. Aparece alto aunque solo dos metas lo respaldan, porque las dos son de peso 5 y fuerza 3 (abrir a terceros = manejar actores externos no confiables; proteger datos de pago). Este es un dato clave para el cambio: abrir a vendedores externos no es solo un problema de escala, es un problema de seguridad —entra gente de afuera al sistema—, y el mapeo lo captura sin que el arquitecto se lo imponga. Cuando en la lección 5 el ADR justifique poner un gateway con auth de terceros delante de la Seller API, este 30 es su respaldo. Y availability (25), performance (23) y cost (19) cierran el ranking, cada uno trazable a sus metas. Ojo con cost en último lugar: como te enseñó el módulo 5, último no significa que no importe. El CFO puso "no triplicar la factura" con peso 3, explícitamente. Cost es último porque lo empujan menos metas y con menos fuerza que scalability, no porque se pueda ignorar —significa "cuando cost pelee contra scalability, scalability tiene más respaldo de negocio", que es información distinta a "olvídate del costo"—.

Y ahí entra la segunda mitad de la salida, donde el mapeo deja de describir y empieza a advertir. El sistema detectó cuatro pares de atributos que compiten y los ordenó por peso combinado. El que más pesa es scalability (38) vs cost (19), con peso combinado 57. Traducido al negocio: la meta insignia "crecer 10x" (que empuja scalability) y la meta explícita del CFO "no triplicar la factura" (que empuja cost) se contradicen de frente, y como entre las dos suman el mayor peso, ese es el trade-off que gobierna todo el cambio —el que el arquitecto tiene que encarar primero—. No es un choque teórico entre dos -ilities abstractos: son dos frases concretas del liderazgo que no pueden cumplirse ambas al máximo. Este es el conflicto que reaparecerá en la lección 5 (el ADR lo nombra como el precio aceptado), en la lección 6 (la evolución difiere el 10x costoso hasta que el volumen lo justifique) y en la lección 8 (el guion con el VP se construye alrededor de él). El paso 2 no solo prioriza atributos: identifica la conversación difícil que el arquitecto tendrá que tener con el VP, y la deja nombrada y cuantificada desde ahora.

Profundización: por qué este paso ancla todo el hilo

Vale la pena detenerse en tres cosas que hacen de este paso el eje del capstone, porque un arquitecto principiante lo trata como un trámite y se pierde su valor.

Primero, el ranking le quita al arquitecto una decisión que no le corresponde. Sin este método, cuando llegue el momento de elegir entre escalar y ahorrar, el arquitecto cargaría con una decisión de negocio disfrazada de decisión técnica —y cuando saliera mal, cargaría la culpa—. El mapeo devuelve esa decisión a donde pertenece: los pesos los pone el negocio (¿qué tan estratégica es cada meta?), y el arquitecto solo aporta la traducción (qué atributo implica cada meta). Cuando el ranking dice "scalability primero, cost último", no es que el arquitecto lo decidió: es que las prioridades del negocio, hechas explícitas, lo producen. Si el VP no está de acuerdo, la conversación correcta no es "el arquitecto se equivocó" sino "revisemos los pesos" —y eso es sano, porque pone la decisión estratégica donde debe estar—. En el capstone esto es doblemente importante: el ranking es lo que el arquitecto podrá mostrarle al VP en la lección 8 para que la conversación sea sobre pesos de negocio, no sobre preferencias técnicas.

Segundo, el ranking es la entrada de la estructura, no un fin en sí mismo. Este es el punto que distingue al capstone de hacer el proyecto del módulo 5 en aislamiento. Allá, el ranking era el entregable. Aquí, el ranking alimenta el paso 3: que scalability sea el atributo rector es lo que le dice a la maniobra inversa de Conway qué arquitectura producir —un surface de vendedores que escale independientemente, con su propio equipo dueño—. Si hubieras derivado security como rector (como en el proyecto de pagos a plazos del módulo 5), la lección 4 diseñaría otra organización. Por eso el ranking no se guarda en un cajón: es el primer eslabón que amarra al siguiente. Un arquitecto que deriva scalability y luego diseña una organización que no la produce rompió el hilo en su junta más importante.

Tercero, el ranking captura lo explícito y por eso tiene un punto ciego. Este método rankea los atributos que las metas nombran. Pero hay atributos que ninguna meta nombra y que el sistema debe cumplir de todos modos —integridad de datos, auditabilidad, privacidad—. En este ranking no aparecen, porque su score sería cero. Eso no significa que no importen: significa que el mapeo de metas explícitas no es completo por sí solo, y hay que complementarlo con el descubrimiento de los atributos implícitos (la lección 5 del módulo 5). En el capstone, esos implícitos reaparecen en el ADR (que menciona la seguridad de terceros como un atributo del dominio) y en el plan de evolución (que incluye el seller_risk_scoring, un atributo de integridad que ninguna meta pidió por su nombre). El arquitecto que trata este ranking como la lista completa de lo que el sistema necesita entrega exactamente lo que el negocio pidió y ninguno de los atributos que dio por hecho —y esos son justo los que estallan—.

Un matiz honesto, porque el modelo simplifica. Los pesos (1-5) y las fuerzas (1-3) no son verdades del universo: son un juicio del arquitecto, hecho explícito. Alguien podría discutir si grow_10x implica scalability con fuerza 3 o 2, y esa discusión cambiaría el ranking. Pero ese es precisamente el valor del método: vuelve el juicio explícito y discutible. En vez de un arquitecto que decide a ojo y nadie sabe por qué, hay una tabla donde cada supuesto está a la vista y el negocio puede corregirlo. El número no pretende ser exacto; pretende hacer la conversación posible. Un ranking discutible y trazable es infinitamente mejor que una corazonada que nadie puede examinar.

Errores comunes

Derivar los atributos que el arquitecto quiere, no los que la meta empuja (de sesgo técnico). Qué pasa: al arquitecto le apasiona la escalabilidad, así que la pone primero "porque este cambio va a crecer" sin verificar que las metas la respalden más que a los otros atributos. A veces acierta (aquí scalability sí encabeza), pero por la razón equivocada, y en el siguiente cambio pondrá scalability primero también, cuando quizás no toque. Por qué pasa: es natural priorizar lo que uno domina. Cómo detectarlo: si tu ranking sería el mismo para cualquier cambio de cualquier empresa, no está anclado en estas metas. Cómo corregirlo: deja que el ranking salga del mapeo con los pesos del negocio, no de tu instinto; en el proyecto del módulo 5, la misma empresa con otra meta (pagos a plazos) dio security dominando y scalability en cero —prueba de que el método es fiel a la meta, no al arquitecto—.

Traducir las metas una por una y perder los conflictos (de aislamiento). Qué pasa: el arquitecto traduce cada meta en su propia reunión y nunca las pone en la misma tabla, así que jamás ve que "crecer 10x" y "no triplicar la factura" se contradicen. El conflicto scalability-vs-cost explota tarde, en implementación, cuando ya es caro y cuando el VP se sorprende de que "no se podía tener todo". Por qué pasa: las metas llegan en momentos distintos, de personas distintas. Cómo detectarlo: si no tienes una sola vista con todas las metas y todos los atributos juntos, no pudiste haber detectado los conflictos. Cómo corregirlo: traduce todas las metas a la vez (como el traductor que prepara la negociación entera) y corre la detección de conflictos —los choques solo son visibles cuando todo está junto, y detectarlos ahora es lo que prepara la conversación con el VP de la lección 8—.

Tratar el ranking como el entregable final en vez de la entrada de la estructura (de eslabón suelto). Qué pasa: el arquitecto deriva un ranking impecable, lo guarda, y luego diseña la estructura del paso 3 sin volver a mirarlo —diseñando los equipos "como le parece" en vez de para producir el atributo rector—. Por qué pasa: en los proyectos de módulo el ranking era el fin, así que el reflejo es tratarlo como meta, no como medio. Cómo detectarlo: si la organización que diseñas en la lección 4 no se justifica con el atributo que encabezó aquí, rompiste el hilo. Cómo corregirlo: recuerda que en el capstone el ranking alimenta; antes de diseñar la estructura, di en voz alta "el atributo rector es scalability, así que la organización tiene que producir un surface que escale" —y que esa frase gobierne el paso 3—.

Ejercicios

Ejercicio 1 — Recalcula con un peso nuevo. El CFO de Mercado, preocupado por el gasto del 10x, sube el peso de keep_infra_costs_flat de 3 a 5. Sin correr todo el código, calcula el nuevo score de cost y explica cómo cambia su posición en el ranking y cuánto pesa ahora el conflicto rector.

Ver solución

Nuevo score de cost. Cost lo respaldan dos metas: grow_10x (peso 5, fuerza 2 → 10) y keep_infra_costs_flat (ahora peso 5, fuerza 3 → 15). Nuevo score = 10 + 15 = 25. Antes era 19 (con keep_infra_costs_flat en peso 3: 5×2 + 3×3 = 10 + 9 = 19).

Cómo cambia el ranking. Cost sube de 19 a 25, empatando con availability (25) y superando a performance (23). Pasa de último lugar a la mitad de la tabla. El ranking quedaría aproximadamente: scalability 38, security 30, cost 25 y availability 25 (empate), performance 23.

Cuánto pesa ahora el conflicto rector. El conflicto scalability-vs-cost, que ya era el que más pesaba (57), ahora pesa 38 + 25 = 63 —aún más urgente—. Y aquí está lo importante para el capstone: ese aumento cambia la conversación con el VP (lección 8). Con cost en peso 5, el arquitecto ya no puede tratar "no triplicar la factura" como una preocupación secundaria; el 10x costoso pesa casi tanto como el 10x en sí, y eso empujará el plan de evolución (lección 7) a diferir aún más agresivamente la infraestructura cara hasta que el volumen real la justifique. La lección: cuando el negocio cambia un peso, el hilo entero se reacomoda hacia abajo —otro ranking, otro énfasis en la evolución, otra conversación—. El método es el mismo; el contenido es fiel al negocio actual.

Ejercicio 2 — La meta que empuja dos atributos en conflicto. Fíjate en grow_10x: implica scalability (fuerza 3), performance (2) y cost (2). Pero scalability y cost compiten. ¿Cómo puede una sola meta empujar dos atributos que se pelean? ¿Qué revela eso sobre la conversación que le espera al arquitecto con el VP?

Ver solución

Una sola meta empuja atributos en conflicto porque una meta de negocio suele ser, en el fondo, un deseo de tenerlo todo. "Crecer 10x" significa, literalmente, "quiero manejar diez veces más tráfico (scalability) sin que me cueste diez veces más (cost) y sin que se ponga lento (performance)". El VP no lo ve como una contradicción: lo ve como una sola aspiración razonable ("crecer de forma eficiente"). Es el arquitecto, al traducir, quien descubre que dentro de esa sola frase viven dos atributos que tiran en direcciones opuestas.

Qué revela sobre la conversación con el VP. Que la conversación difícil no es entre el arquitecto y el negocio, sino dentro de la propia meta del negocio. El arquitecto no le va a decir al VP "tu meta está mal"; le va a decir "tu meta de crecer 10x contiene, sin que se note, un trade-off: escalar y ahorrar a la vez no se puede al máximo, así que necesito que me digas cuál pesa más cuando choquen". Esa pregunta —incómoda porque obliga al VP a elegir algo que creía que podía tener completo— es exactamente el trabajo de la lección 8 (el guion con el VP). El mapeo la hace posible: cuando una meta implica dos atributos que están en la lista de conflictos, el arquitecto tiene un trade-off que negociar dentro de una sola meta, y llega a la conversación con el número (peso combinado 57) en la mano en vez de con una intuición. Detectar esto en el paso 2 es lo que evita que el conflicto estalle sin aviso en la implementación.

Ejercicio 3 — Predice cómo el ranking dicta la estructura. El atributo rector de este cambio resultó ser scalability (38). En la lección 4 vas a diseñar la organización. Sin hacer los cálculos de Conway todavía, predice: ¿qué tipo de decisión organizacional debería producir un atributo rector "scalability" para el surface de vendedores? Y contrasta: ¿qué decisión distinta produciría si el rector hubiera sido "security"?

Ver solución

Si el rector es scalability, la organización debe producir un surface que escale independientemente. El atributo "escalar el surface de vendedores a 10x" apunta a una decisión organizacional clara: darle al surface de vendedores un equipo dueño único que pueda cambiar y desplegar de forma autónoma, sin coordinar con las otras cuatro squads para cada ajuste —porque un componente que muchos equipos comparten no puede escalar rápido, ya que cada cambio exige coordinación—. Esto es exactamente la maniobra inversa de Conway que verás en la lección 4: para obtener un surface que escala independientemente, se crea un equipo stream-aligned que lo posee de punta a punta. El atributo dicta la forma de la organización.

Si el rector hubiera sido security, la decisión organizacional sería distinta. Un atributo rector "security" (proteger datos sensibles, aislar a los terceros) apuntaría menos a un equipo-que-escala y más a una capacidad transversal de seguridad: quizás un equipo enabling o platform que provee los controles de seguridad, la auth, la auditoría, como servicios que los demás consumen; o fronteras diseñadas alrededor del aislamiento de datos (quién puede tocar qué) más que alrededor del flujo de valor. La estructura se optimizaría para minimizar la superficie de riesgo y centralizar los controles, no para maximizar la velocidad de cambio de un surface.

La lección: el ranking del paso 2 no es un adorno que se guarda —es lo que determina la forma de la organización del paso 3—. El mismo cambio, con un atributo rector distinto, produciría una arquitectura y una organización distintas. Por eso el hilo es causal y el orden importa: derivar bien el atributo rector es lo que hace que la estructura que diseñes después resuelva el problema correcto. Un arquitecto que se saltara este paso y estructurara equipos "por intuición" estaría diseñando la organización sin saber qué atributo tiene que producir —reorganizando a ciegas—.

Resumen y siguiente paso

En esta lección hiciste el paso 2 del entregable: derivar los atributos de calidad desde la meta. Con el traductor de la ONU que prepara la negociación detectando los conflictos antes de que estallen, entendiste por qué hay que traducir todas las metas juntas —solo así se ve qué atributos se refuerzan y cuáles chocan—. Lo mediste ejecutando: el mapeo peso × fuerza de las seis metas del cambio produjo el ranking (scalability 38, security 30, availability 25, performance 23, cost 19), con cada punto trazable a una meta concreta, y la detección de conflictos reveló scalability-vs-cost (57) como el trade-off que gobierna el cambio —la contradicción entre "crecer 10x" y "no triplicar la factura"—. Entendiste que el ranking sale del negocio y no del arquitecto, que este paso ancla el hilo porque el atributo rector dicta la estructura del paso siguiente, y que el mapeo captura lo explícito pero deja un punto ciego (los implícitos) que reaparecerá más adelante.

Antes de avanzar deberías poder: tomar las metas de un cambio con sus pesos y derivar un ranking de atributos con peso × fuerza; explicar por qué un atributo pesa lo que pesa citando las metas que lo respaldan; nombrar el conflicto que gobierna el cambio y cuánto pesa; y explicar cómo el atributo rector dicta la forma de la organización que vendrá.

Lo que sigue es el paso 3, donde el atributo rector se vuelve estructura. Ya sabes que scalability es lo que este cambio debe producir; la lección 4 te enseña a diseñar la organización que lo producirá. Vas a aplicar la maniobra inversa de Conway al surface de vendedores: crear un equipo stream-aligned que lo posea de punta a punta y volver la plataforma un servicio, y vas a medir —ejecutado— cuánto baja la fricción de coordinación del sistema al hacerlo, sin tocar el código primero. El ranking que derivaste aquí es la justificación de esa reestructuración: la organización se diseña para producir el atributo que la meta priorizó.

Recursos

← Anterior2. Enmarca el rol y el encargoSiguiente →4. Aplica la maniobra inversa de Conway