Módulo 6: Diseñar para el cambio

8. Proyecto: diseña la evolución de Mercado para un cambio

Descripción

Esta es tu graduación del módulo. Durante siete lecciones instalaste la postura del arquitecto que diseña para el cambio: viste que ninguna arquitectura es final —es un flujo de decisiones (lección 2)—, aprendiste a valorar la optionality y su punto de equilibrio (lección 3), a usar la arquitectura sacrificial para comprar información barata (lección 4), a reconocer los dos abismos —el over-engineering (lección 5) y el under-engineering (lección 6)— y a encontrar el punto sensato entre ellos con el right-sizing (lección 7). Todo eso lo viste aplicado a situaciones que te dimos resueltas. Ahora te toca a ti, de cero, sobre un caso nuevo que no analizamos en ninguna lección. La razón de cambiar el caso es la de siempre y es dura: si te dejara re-hacer un portafolio de las lecciones, no sabría si aprendiste el método o memorizaste la respuesta. Con un caso nuevo, la única forma de resolverlo es aplicar el método —y esa es, exactamente, la prueba de que el módulo funcionó—.

Tu entregable es la evolución planeada de Mercado ante un lanzamiento nuevo, en tres artefactos: (1) el portafolio de cambios anticipados que el lanzamiento dispara, cada uno con su probabilidad e impacto; (2) la medición ejecutada de las tres posturas —rígida, over-engineered y right-sized— con Python, que dice cuánto cuesta cada una y qué costuras construir; y (3) el plan de evolución que reparte los cambios en tres cubos —construir la costura hoy, prototipar (sacrificial) lo incierto, y diferir (YAGNI) lo improbable— más el guion de cómo se lo explicas al stakeholder que aprueba el presupuesto. Ninguna parte requiere construir el sistema: es puro trabajo de diseño de la evolución —anticipar, medir, planear—, que es justo lo que separa a un arquitecto que diseña para el cambio de uno que solo reacciona a él. Constrúyelo tú primero; leer la solución de referencia sin haberlo intentado es como leer el marcador de un partido que no jugaste.

Conexión con el módulo: este proyecto cierra el arco. Las lecciones 2 a 4 te dieron la postura (flujo, optionality, sacrificial); las lecciones 5 a 7 te dieron el criterio (los dos abismos y el right-sizing que los evita). Aquí produces los tres artefactos con tus manos, de principio a fin, sobre un caso nuevo. Y con esta lección se cierra el módulo: al final está el resumen de las ocho lecciones y el puente hacia el módulo 7, donde vas a aprender a documentar la evolución que aquí sabes planear —para que el plan sobreviva al tiempo y al recambio de personas—.

El caso del proyecto: Mercado lanza Mercado Plus

La situación nueva —tuya para resolver— es esta:

Mercado quiere lanzar Mercado Plus, una membresía paga (como las de suscripción de los grandes marketplaces): el cliente paga una cuota mensual y a cambio recibe envío gratis, acceso anticipado a ofertas y un catálogo exclusivo. El liderazgo está entusiasmado y tiene prisa. El VP de producto te entrega un roadmap de cambios anticipados que el lanzamiento va a disparar en el sistema, y te pregunta, como arquitecto: "de todo esto, ¿qué construimos ahora para estar listos, qué dejamos para después, y dónde estás menos seguro? Necesito saber qué presupuesto pedir este trimestre". Tu trabajo es responder con el método del módulo —no con intuición—.

El roadmap de cambios que el VP te da, cada uno con lo que sabes de él (te damos los números para que no tengas que inventarlos, igual que un equipo real te daría estimaciones):

membership_billing_recurring — cobro recurrente de la cuota mensual (ciclos, prorrateo, reintentos de cobro fallido). Prácticamente seguro: sin cobro recurrente no hay membresía. p = 0.95. Costura barata (seam = 6000), adaptación posterior 5000... —o reescritura de 60000 si no se deja costura—.
free_shipping_rules_engine — reglas de envío gratis para miembros (umbrales, zonas, excepciones). Casi seguro: es el beneficio estrella. p = 0.90, seam = 5000, adapt = 6000, rewrite = 45000.
early_access_scheduling — programar que los miembros vean las ofertas antes que el resto. Probable. p = 0.60, seam = 4000, adapt = 5000, rewrite = 20000.
exclusive_catalog_segment — un segmento del catálogo visible solo para miembros. Incierto: depende de si se consiguen acuerdos con vendedores. p = 0.40, seam = 7000, adapt = 6000, rewrite = 22000.
tiered_pricing_experiments — experimentar con varios niveles de membresía (Plus, Premium). Muy incierto: nadie sabe si los clientes querrán niveles ni cuáles. p = 0.20, seam = 9000, adapt = 7000, rewrite = 24000.
partner_perks_marketplace — un marketplace de beneficios de terceros (descuentos de socios). Imaginado, nadie lo pidió. p = 0.05, seam = 22000, adapt = 14000, rewrite = 40000.
points_and_rewards_ledger — un sistema de puntos y recompensas tipo programa de lealtad. Imaginado, sin demanda concreta. p = 0.08, seam = 18000, adapt = 12000, rewrite = 30000.

Fíjate en la mezcla, porque es deliberada y es donde el método se pone a prueba: hay cambios casi seguros (billing, envío gratis), probables (acceso anticipado), inciertos (catálogo exclusivo, niveles de precio) e imaginados improbables (marketplace de socios, puntos). El liderazgo, con prisa, podría querer "construirlo todo para estar listos" (over-engineering) o "lanzar lo mínimo y ya veremos" (under-engineering). Tu método debería tener algo mejor que decir. No re-diseñes cómo funciona un sistema de cobro recurrente ni un motor de reglas de envío —eso es de otras guías—; tu trabajo es planear la evolución: decidir dónde dejar costura, dónde prototipar y dónde diferir.

Lo que tienes que entregar

Sigue los pasos en orden; cada uno se apoya en el anterior.

Parte 1 — El portafolio de cambios anticipados

Organiza (en texto o tabla) el roadmap del VP como un portafolio, ordenado por probabilidad, dejando claro para cada cambio su p, su costo de costura y su costo de reescritura. Antes de medir, señala a ojo qué esperas: cuáles cambios "huelen" a costura clara, cuáles a diferir, y cuáles te dan duda. Esto es leer las señales del negocio (lección 7) antes de que el código las confirme.

Parte 2 — La medición ejecutada

Escribe y corre el Python que mide, para el portafolio, las tres posturas: rigid (ninguna costura), over_engineered (todas las costuras) y right_sized (costura donde se paga sola, diferir el resto), decidiendo futuro por futuro con el punto de equilibrio. Entrega los números reales, corridos, no citados de memoria, y la lista de qué costuras construye el right-sizing y cuáles difiere. Reusa las fórmulas de la lección 7.

Parte 3 — El plan de evolución (y el guion para el stakeholder)

Reparte los cambios en tres cubos y justifica cada uno con el método:

Construir la costura hoy — los cambios probables donde el right-sizing dice construir. Recuerda: la costura, no la solución (reserva el derecho de vía, no pavimentes la avenida).
Prototipar (sacrificial) — los cambios inciertos donde la duda no es "¿vendrá?" sino "¿qué es lo que de verdad hace falta?", y un prototipo desechable barato reduce esa incertidumbre antes de comprometerse (lección 4). No todo lo que el right-sizing difiere se difiere a ciegas: algo puede merecer un experimento que aprenda su verdadera probabilidad.
Diferir (YAGNI) — los futuros imaginados improbables donde no dejas ni costura ni prototipo (lección 5).

Y cierra con el guion —tres o cuatro frases— de cómo le explicas al VP qué presupuesto pedir y por qué, en su idioma (dinero y riesgo), no en el tuyo (costuras y probabilidades).

La rúbrica

Así se evalúa el proyecto. No es por extensión ni por elegancia: es por si el plan de evolución está bien hecho y bien defendido con evidencia.

Criterio	No cumple	Cumple	Sobresale
Portafolio	Lista los cambios sin probabilidad ni impacto	Cada cambio con `p`, costura y reescritura	Además señala a ojo, antes de medir, qué espera de cada uno leyendo las señales del negocio
Medición ejecutada	Números citados de memoria o inventados	Las tres posturas corridas en Python, con la lista de costuras	Además declara qué señal del negocio sustenta cada probabilidad
Plan de evolución	Un solo cubo ("hagamos todo" o "lo mínimo")	Los tres cubos (costura / prototipo / diferir) justificados con el método	Además distingue costura de solución, y usa el prototipo sacrificial donde la incertidumbre es de requisitos, no de probabilidad
Guion para el stakeholder	No hay, o habla en jerga técnica	Explica el presupuesto en dinero y riesgo	Además nombra qué se difiere y por qué, y deja el plan como algo que se revisará

El criterio que más pesa, y el que separa a un arquitecto que diseña para el cambio de uno que reacciona a él, es la medición ejecutada cruzada con el plan de tres cubos: si entregas todo lo demás pero los números salieron de tu cabeza, o si metes todo en un solo cubo (todo costura, o todo diferido), no diseñaste la evolución —adivinaste—.

La solución de referencia

Intenta el proyecto entero antes de seguir. Lo que viene es una solución correcta, no la única.

Parte 1 — El portafolio, con lo que se espera a ojo

El roadmap ordenado por probabilidad, con la lectura previa de las señales del negocio:

cambio                          p      senal del negocio                       a ojo
──────────────────────────────  ────   ─────────────────────────────────────   ───────────
membership_billing_recurring    0.95   sin cobro no hay membresia               costura clara
free_shipping_rules_engine      0.90   es el beneficio estrella                 costura clara
early_access_scheduling         0.60   prometido en el pitch de Plus            costura (probable)
exclusive_catalog_segment       0.40   depende de acuerdos con vendedores       DUDA
tiered_pricing_experiments      0.20   nadie sabe si habra niveles              DUDA (incertidumbre de requisitos)
partner_perks_marketplace       0.05   nadie lo pidio, sin estrategia           diferir (YAGNI)
points_and_rewards_ledger       0.08   imaginado, sin demanda                   diferir (YAGNI)

Lo que se espera a ojo, antes de medir: los dos primeros (billing, envío gratis) son costuras clarísimas —probabilidad altísima, sin ellos no hay producto—. early_access_scheduling es probable y también huele a costura. Los dos últimos (partner_perks, points) son futuros imaginados sin demanda: diferir, claro (over-engineering si los construyo). Y quedan dos dudas: exclusive_catalog_segment (0.40) está en la zona gris de probabilidad; tiered_pricing_experiments (0.20) es una duda especial —su incertidumbre no es tanto "¿vendrá?" sino "¿qué querrán los clientes?", que huele a prototipo sacrificial más que a costura o a diferir a ciegas—. La medición confirmará las dos costuras claras y los dos diferidos; las dos dudas hay que resolverlas con el número.

Parte 2 — La medición ejecutada

# Proyecto: disenar la EVOLUCION de Mercado para el lanzamiento de "Mercado Plus"
# (una membresia paga). El liderazgo entrega un roadmap de cambios anticipados y
# pregunta: que construimos hoy, que diferimos, y donde vale un prototipo. Right-sizing:
#   p       : probabilidad de que el cambio llegue
#   seam    : costo de construir la costura hoy
#   adapt   : costo de adaptarse DESPUES si hay costura
#   rewrite : costo de reescribir si NO hay costura
PORTFOLIO = [
    # (nombre, p, seam, adapt, rewrite)
    ("membership_billing_recurring", 0.95,  6000,  7000, 60000),
    ("free_shipping_rules_engine",   0.90,  5000,  6000, 45000),
    ("early_access_scheduling",      0.60,  4000,  5000, 20000),
    ("exclusive_catalog_segment",    0.40,  7000,  6000, 22000),
    ("tiered_pricing_experiments",   0.20,  9000,  7000, 24000),
    ("partner_perks_marketplace",    0.05, 22000, 14000, 40000),
    ("points_and_rewards_ledger",    0.08, 18000, 12000, 30000),
]


def cost_build(p, seam, adapt, rewrite):
    return seam + p * adapt


def cost_defer(p, seam, adapt, rewrite):
    return p * rewrite


rigid_total = over_total = right_total = 0
built, deferred = [], []
print(f"{'cambio del roadmap':<32}{'p':>6}{'build':>10}{'defer':>10}   decision")
print("-" * 76)
for name, p, seam, adapt, rewrite in PORTFOLIO:
    b = cost_build(p, seam, adapt, rewrite)
    d = cost_defer(p, seam, adapt, rewrite)
    rigid_total += d
    over_total += b
    if b <= d:
        right_total += b
        decision = "CONSTRUIR costura"
        built.append(name)
    else:
        right_total += d
        decision = "diferir (YAGNI)"
        deferred.append(name)
    print(f"{name:<32}{p:>6.2f}{b:>10,.0f}{d:>10,.0f}   {decision}")
print("-" * 76)
print(f"{'rigid (0 costuras)':<48}{rigid_total:>10,.0f}")
print(f"{'over_engineered (costura para TODO)':<48}{over_total:>10,.0f}")
print(f"{'right_sized (evolucion planeada)':<48}{right_total:>10,.0f}")
print()
print(f"Construir HOY: {', '.join(built)}.")
print(f"Diferir (YAGNI): {', '.join(deferred)}.")
print(f"Ahorro right-sized vs rigid: {rigid_total - right_total:,.0f} USD.")
print(f"Ahorro right-sized vs over-engineered: {over_total - right_total:,.0f} USD.")

Qué esperar. Al correrlo:

cambio del roadmap                   p     build     defer   decision
----------------------------------------------------------------------------
membership_billing_recurring      0.95    12,650    57,000   CONSTRUIR costura
free_shipping_rules_engine        0.90    10,400    40,500   CONSTRUIR costura
early_access_scheduling           0.60     7,000    12,000   CONSTRUIR costura
exclusive_catalog_segment         0.40     9,400     8,800   diferir (YAGNI)
tiered_pricing_experiments        0.20    10,400     4,800   diferir (YAGNI)
partner_perks_marketplace         0.05    22,700     2,000   diferir (YAGNI)
points_and_rewards_ledger         0.08    18,960     2,400   diferir (YAGNI)
----------------------------------------------------------------------------
rigid (0 costuras)                                 127,500
over_engineered (costura para TODO)                 91,510
right_sized (evolucion planeada)                    48,050

Construir HOY: membership_billing_recurring, free_shipping_rules_engine, early_access_scheduling.
Diferir (YAGNI): exclusive_catalog_segment, tiered_pricing_experiments, partner_perks_marketplace, points_and_rewards_ledger.
Ahorro right-sized vs rigid: 79,450 USD.
Ahorro right-sized vs over-engineered: 43,460 USD.

Lee los tres totales y luego la línea de corte, porque ahí está la respuesta al VP.

Los tres totales: rígido 127500, over-engineered 91510, right-sized 48050. El plan right-sized domina a los dos extremos, igual que en la lección 7: ahorra 79450 contra lanzar sin costuras (rígido) y 43460 contra construir para todo (over-engineered). Ni la prisa del liderazgo por "hacerlo todo" ni el atajo de "lanzar lo mínimo" se acercan a planear la evolución con criterio.

La línea de corte cae entre early_access_scheduling (0.60) y exclusive_catalog_segment (0.40). El right-sizing construye costura en los tres de arriba —donde build es más barato que defer— y difiere los cuatro de abajo. Mira los dos casos del borde: en early_access (0.60), construir cuesta 7000 contra 12000 de reescribir → construir. En exclusive_catalog (0.40), construir cuesta 9400 contra 8800 de reescribir → diferir, por poco. La probabilidad de 0.40, con ese seam y ese rewrite, ya no alcanza para justificar la costura. Y los dos imaginados (partner_perks a 0.05, points a 0.08) se difieren con enorme margen: construir sus costuras costaría 22700 y 18960 contra un rework esperado de apenas 2000 y 2400. Serían over-engineering puro.

Fíjate en algo que la medición sola no captura y que la Parte 3 tiene que resolver: tiered_pricing_experiments (0.20) el right-sizing lo difiere —construir cuesta 10400 contra 4800 de reescribir—, y eso es correcto para una costura. Pero su incertidumbre es de otro tipo: no es "¿vendrán los niveles de precio?" sino "¿qué niveles querrán los clientes, si es que quieren alguno?". Esa es incertidumbre de requisitos, la que la lección 4 resuelve con un prototipo sacrificial. Difierir la costura no significa difierir el aprendizaje. La Parte 3 saca este caso del cubo "diferir a ciegas" y lo pone en el cubo "prototipar".

Parte 3 — El plan de evolución, en tres cubos

Con la medición hecha, el plan reparte los siete cambios así:

Cubo 1 — Construir la costura hoy (los tres que el right-sizing marcó, probabilidad alta):

membership_billing_recurring — deja la costura del cobro recurrente: una interfaz de "ciclo de cobro" separada del checkout de compra única, con las tablas de suscripción propias. No construyas todavía cada caso de prorrateo y reintento exótico; deja la frontera que hará barato agregarlos. (Costura, no solución.)
free_shipping_rules_engine — deja la costura de las reglas de envío: un punto claro donde la lógica de "¿este pedido tiene envío gratis?" se evalúa, separado del cálculo de envío general. Empieza con la regla simple de hoy (miembro → gratis); la costura hace barato sumar umbrales y zonas después.
early_access_scheduling — deja la costura del acceso anticipado: una noción de "visibilidad por segmento de cliente" en el catálogo, en vez de hardcodear "todos ven todo". Barato hoy, y prepara tanto el acceso anticipado como el catálogo exclusivo del futuro.

Recuerda el matiz de la lección 7: en los tres, construyes la costura (interfaz, frontera, contrato —miles de dólares), no la solución completa (el sistema de billing con todos sus casos, el motor de reglas configurable —decenas o cientos de miles). Reservas el derecho de vía; no pavimentas la avenida.

Cubo 2 — Prototipar (sacrificial) (la incertidumbre de requisitos):

tiered_pricing_experiments — el right-sizing lo difirió como costura, y bien: con p = 0.20, construir la maquinaria de niveles de precio sería prematuro. Pero difierir la costura no significa quedarse a ciegas. La duda real aquí es de requisitos —¿los clientes quieren niveles? ¿cuáles? ¿a qué precio?—, y eso se resuelve con un prototipo sacrificial (lección 4): un experimento barato y desechable —una landing con dos o tres niveles ficticios, o un A/B chico con un subconjunto de clientes— cuyo único trabajo es aprender si los niveles mueven la aguja. Se tira después de medir. Cuesta poco, y si resulta que los clientes sí quieren niveles, tiered_pricing sube de 0.20 a una probabilidad alta y entonces entra al cubo 1 en la próxima revisión. No construyes la costura ni la difieres a ciegas: compras la información que dirá cuál de las dos hacer.

Cubo 3 — Diferir (YAGNI) (los imaginados improbables):

exclusive_catalog_segment (0.40), partner_perks_marketplace (0.05) y points_and_rewards_ledger (0.08) — difiérelos. Los dos últimos son futuros imaginados sin demanda (nadie los pidió, no hay estrategia): construir sus costuras sería over-engineering caro (22700 y 18960 para evitar 2000 y 2400 esperados). exclusive_catalog_segment es un caso más fino: su probabilidad (0.40) lo deja del lado de diferir por poco, y además la costura de early_access (que sí construyes) ya deja media puerta abierta —la "visibilidad por segmento"— por si sube. Difiérelos, pero revísalos: si se cierran los acuerdos con vendedores, exclusive_catalog sube y cambia de cubo.

El guion para el VP (en su idioma —dinero y riesgo—, no en el tuyo):

"Para Mercado Plus, pido presupuesto este trimestre para tres cosas: el cobro recurrente, las reglas de envío gratis y el acceso anticipado —son casi seguros, sin ellos no hay producto, y prepararlos ahora nos cuesta una fracción de lo que costaría improvisarlos después—. No voy a pedir presupuesto para el marketplace de socios ni el sistema de puntos: nadie los ha pedido, y construirlos ahora sería gastar en algo que probablemente no usaremos. Y para la idea de niveles de precio, en vez de construirla o descartarla, propongo un experimento barato que nos diga en un mes si los clientes de verdad los quieren —así decidimos con datos, no con corazonadas—. En total, este plan nos ahorra unos 79 mil dólares frente a lanzar sin preparación y unos 43 mil frente a construirlo todo. Y no es una decisión final: revisamos el plan cada trimestre, porque si el negocio cambia —si cerramos acuerdos de catálogo exclusivo, por ejemplo—, lo que hoy diferimos puede pasar a construirse."

Fíjate en cómo el guion traduce todo el módulo al idioma del stakeholder (lección 5): no habla de costuras, probabilidades ni puntos de equilibrio; habla de qué se pide, qué no, por qué, cuánto se ahorra y que el plan se revisará. El arquitecto que diseña para el cambio no solo planea la evolución; sabe explicarla a quien firma el cheque.

Ejercicios

Estos ejercicios transfieren el método a otras decisiones de Mercado, para que confirmes que aprendiste a diseñar la evolución y no a repetir un portafolio.

Ejercicio 1 — El cambio que cambió de probabilidad. Tres meses después del lanzamiento de Plus, los datos del prototipo sacrificial de tiered_pricing_experiments llegan: los clientes sí quieren un nivel Premium, con fuerza. La probabilidad de que los niveles de precio lleguen sube de 0.20 a 0.85. Sin correr código, recalcula sus opciones build y defer con la nueva probabilidad (usa seam=9000, adapt=7000, rewrite=24000), di a qué cubo pasa ahora, y explica qué papel jugó el prototipo en esta transición.

Ver solución

Con tiered_pricing_experiments a p = 0.85:

build = seam + p × adapt = 9000 + 0.85 × 7000 = 9000 + 5950 = 14950.
defer = p × rewrite = 0.85 × 24000 = 20400.

Ahora build (14950) es más barato que defer (20400), así que pasa del cubo 3/2 (diferido / prototipado) al cubo 1 (construir la costura hoy). La costura de niveles de precio ahora se paga sola, cuando con p = 0.20 no lo hacía.

El papel del prototipo: fue exactamente lo que hizo posible esta transición con criterio en vez de a ciegas. Cuando la probabilidad era 0.20, había dos maneras malas de actuar y una buena. La mala número uno: construir la costura igual (over-engineering, 10400 para evitar 4800 esperados). La mala número dos: difierir y olvidarse (under-engineering en potencia: si los niveles resultaban un éxito, llegarían a encontrarse sin costura). La buena: el prototipo sacrificial —comprar la información barata que resolvió la incertidumbre de requisitos—. El prototipo no solo respondió "¿qué niveles quieren?"; al hacerlo, actualizó la probabilidad de 0.20 a 0.85, moviendo el cambio de cubo. Esto ilustra la circularidad del módulo (lección 7): el right-sizing es un flujo que se revisa, el prototipo (lección 4) es una herramienta para reducir la incertidumbre que alimenta esa revisión, y ninguna decisión —ni la de diferir— es final. El prototipo convirtió una duda en un dato, y el dato convirtió un diferido en una costura.

Ejercicio 2 — La prisa del liderazgo. El VP, entusiasmado, propone: "ya que estamos, construyamos también el marketplace de socios y el sistema de puntos ahora, para lanzar Plus con todo y no quedarnos cortos". Con los números de la medición, dale dos razones para no hacerlo, y nombra qué error del módulo estaría cometiendo.

Ver solución

El VP estaría cometiendo over-engineering (lección 5): construir flexibilidad para futuros imaginados que casi nadie ha pedido. Dos razones con los números:

Razón 1 — el costo desproporcionado frente a la probabilidad. Construir la costura del partner_perks_marketplace cuesta 22700, y la del points_and_rewards_ledger cuesta 18960 —juntas, más de 41000—. Pero sus probabilidades son ínfimas (0.05 y 0.08): el rework esperado de no construirlas y adaptarlas si acaso llegan es de apenas 2000 y 2400 —juntas, 4400—. O sea, el VP quiere gastar 41000 para evitar un costo esperado de 4400: pagar casi diez veces de más por flexibilidad que casi seguro no se usará. Es asegurar la casa contra dragones.

Razón 2 — el costo de acarreo y la distracción. Más allá de construirlas (los 41000), esas dos capacidades —un marketplace de terceros, un ledger de puntos— son sistemas complejos que habría que cargar durante toda la vida de Mercado Plus: cada cambio futuro tendría que respetarlas, cada dev nuevo aprenderlas, y todo eso para features que nadie pidió. Y hay un costo de oportunidad: el equipo estaría construyendo eso en vez de pulir el cobro recurrente y el envío gratis, que son lo que de verdad hace o rompe el lanzamiento. Construir "con todo para no quedarnos cortos" no es estar preparado; es diluir el esfuerzo en lo improbable a costa de lo seguro.

La respuesta al VP: "quedarnos cortos sería no preparar lo probable —y eso sí lo estamos preparando (billing, envío, acceso anticipado)—. El marketplace de socios y los puntos no son 'quedarnos cortos'; son construir para un futuro que nadie ha pedido. Si algún día hay demanda real, los construimos entonces, y nos habrá costado esperar casi nada. Construirlos hoy nos cuesta 41 mil y nos distrae de lo que hace funcionar el lanzamiento." Es distinguir "diseñar para el cambio" (probable) de "diseñar para todo cambio" (imaginable), la frase central de la lección 7.

Ejercicio 3 — Otra evolución, mismo método. Mercado quiere, por separado, evolucionar su sistema de búsqueda: hay rumores de que podría necesitar búsqueda por voz, búsqueda con imágenes, y soporte para un idioma nuevo. Sin correr código, describe cómo aplicarías el método completo del módulo (portafolio, medición, tres cubos) a este caso, y qué preguntas harías para asignar las probabilidades. Da el criterio, no una respuesta fija.

Ver solución

El método es el mismo, aplicado a este portafolio nuevo. Los pasos:

Portafolio. Listaría los cambios anticipados —voice_search, image_search, new_language_support, y quizás otros que las señales sugieran— y para cada uno estimaría p (probabilidad), seam (costo de dejar la costura), adapt (adaptarse con costura) y rewrite (reescribir sin ella). Ordenaría por probabilidad.

Medición. Correría el mismo right-sizing de las tres posturas: rigid (0 costuras), over_engineered (todas) y right_sized (costura donde build ≤ defer, diferir el resto), futuro por futuro. Los totales dirían cuánto ahorra planear frente a los dos extremos, y la línea de corte diría qué costuras construir.

Tres cubos. Repartiría: construir la costura en los cambios probables (por ejemplo, si el negocio ya está comprometido con un idioma nuevo, dejar la costura de internacionalización de la búsqueda); prototipar donde la incertidumbre es de requisitos (¿la búsqueda por voz de verdad la usarían los clientes? un prototipo desechable lo diría antes de construir la costura); diferir los imaginados improbables (si la búsqueda con imágenes es un rumor sin demanda, no construir nada).

Las preguntas para asignar probabilidades —y aquí está el criterio, porque las probabilidades se derivan de señales, no se inventan (lección 7)—:

¿Qué está señalando el negocio? ¿Hay un compromiso de producto, un anuncio, una demanda de clientes, un competidor que ya lo hizo? Un idioma nuevo con expansión anunciada es probable; una búsqueda por voz que a alguien "se le ocurrió" es imaginada.
¿Qué dolor reportan ya las squads o los usuarios? (Lección 2 y 5.) Si soporte recibe muchas quejas de búsqueda en otro idioma, la probabilidad sube.
¿La incertidumbre es de "si vendrá" o de "qué necesitamos"? Si es lo primero, decides costura vs diferir; si es lo segundo, prototipas (lección 4).
¿Cuál es la asimetría de costos? (Lección 6.) Para las dudas cerca del punto de equilibrio, ¿quedarme corto dolería mucho más que pasarme? Si sí, inclínate a la costura.

El criterio, en una frase: el método no da respuestas fijas —da un procedimiento (portafolio → medición → tres cubos) alimentado por las señales reales del negocio—. Lo que aprendiste no es "qué hacer con la búsqueda por voz", sino a preguntar las probabilidades correctas, medir el right-sizing, y repartir en costura / prototipo / diferir. Eso es diseñar la evolución de cualquier sistema, no repetir la de Mercado Plus.

Resumen del módulo y hacia dónde sigues

Con este proyecto cierras el módulo 6, la postura del arquitecto ante el tiempo. Empezaste con la tesis —ninguna arquitectura es final: es un flujo de decisiones, medido en la vida media del diseño de Mercado, donde solo el 25% de las suposiciones del día uno sobrevive al año 5 (lección 1)—. La convertiste en postura operativa: la arquitectura no es una foto que se congela sino una película, y lo que la quiebra no es un cambio sino la acumulación —tratarla como final cuesta 2.7x en la vida del sistema— (lección 2). Aprendiste a valorar las puertas abiertas: la optionality tiene valor como un seguro, pero cuesta una prima, y su punto de equilibrio (8.3% en el ejemplo) dice cuándo vale la pena y cuándo se desperdicia (lección 3). Descubriste la herramienta más contraintuitiva: la arquitectura sacrificial, construir para tirar y comprar información barata —un prototipo de 15000 elimina una incertidumbre que costaría 60000 esperados en reconstrucción— (lección 4). Marcaste los dos abismos: el over-engineering, preparar para todo lo imaginable, que paga 25x por flexibilidad no usada (lección 5); y el under-engineering, pintarse en una esquina, que cuesta 4.3x cuando el cambio probable llega sin costura (lección 6). Y encontraste el camino entre ellos: diseñar las costuras con el right-sizing, que domina a los dos extremos (43050 contra 90610 y 133550) porque decide futuro por futuro con la probabilidad, no con el miedo ni la pereza (lección 7). Aquí, en el proyecto, lo hiciste todo tú sobre un caso nuevo: armaste el portafolio, mediste las tres posturas, repartiste en costura/prototipo/diferir, y lo explicaste al stakeholder.

La capacidad que te llevas: ante cualquier sistema y cualquier lista de cambios que el negocio podría pedir, puedes leer las señales para estimar probabilidades, medir el costo de las tres posturas, y decidir con números para qué cambios dejar costura hoy, cuáles prototipar y cuáles diferir —sin caer en el over-engineering que construye para todo ni en el under-engineering que no construye para nada—. Dejaste de tratar la arquitectura como un artefacto que se termina y empezaste a tratarla como un flujo que se postula para el cambio.

Hacia dónde sigues, dentro de esta guía:

Módulo 7 — Documentación que sobrevive. Ya sabes planear la evolución; el módulo 7 te enseña a documentarla para que sobreviva al tiempo y al recambio de personas: la living documentation, el combo C4 + ADR + arc42, los docs-as-code, el README que hace onboarding, y el bus factor. El plan de evolución que armaste aquí —qué costuras dejaste, qué difiriste y por qué— no sirve de nada si vive solo en tu cabeza: el arquitecto que se va se lleva el porqué, y la squad que llega revierte a ciegas las costuras que costó tanto dejar. Documentar la evolución es lo que hace que la postura de este módulo sobreviva a quien la tuvo.

Y hacia el resto del ecosistema: cada vez que este módulo habló de "dejar una costura", "puertas de una o dos vías", "deuda técnica" o "el último momento responsable" sin re-enseñar su mecánica, se apoyaba en la guía hermana architecture-decisions-and-tradeoffs, que sí la enseña. Ahora tienes lo que ninguna guía técnica cubre: la postura mental del arquitecto que planea para el cambio —la disposición de ver el sistema como una película, mantener opciones bajo incertidumbre, construir para tirar, y caminar entre los dos abismos—. Las herramientas se aprenden en las otras guías; el oficio de querer usarlas para diseñar la evolución, y saber cuándo y cuánto, es de esta.

Recursos

Neal Ford, Rebecca Parsons y Patrick Kua — Building Evolutionary Architectures — el cierre natural del módulo: el libro entero es el manual de cómo diseñar y guiar sistemas que evolucionan, exactamente lo que hiciste en este proyecto. En inglés.
Martin Fowler — "Sacrificial Architecture" y "Yagni" — los dos ensayos que dan nombre a las dos piezas más contraintuitivas del módulo (construir para tirar, y no construir para lo improbable), aplicadas en el cubo de prototipar y el de diferir de este proyecto. En inglés.
Andrew Hunt y David Thomas — The Pragmatic Programmer, 20th Anniversary Edition — los temas "Reversibility", "Good-Enough Software" y "Prototypes and Post-it Notes" condensan la postura del módulo: no hay decisiones finales, el software evoluciona, y prototipar para aprender es sabiduría, no desperdicio. En inglés. La mecánica de las decisiones bajo cambio (reversibilidad, último momento responsable, deuda técnica) es la guía hermana architecture-decisions-and-tradeoffs.

← AnteriorDiseñar las costuras Siguiente →Presentación del módulo: documentación que sobrevive