Módulo 5: Stakeholders y atributos de calidad

8. Proyecto: deriva los atributos de calidad de Mercado para un lanzamiento

Siguiente →

Descripción

Esta es tu graduación del módulo. Durante siete lecciones aprendiste a traducir metas de negocio a atributos de calidad priorizados (2), a volverlos medibles con scenarios (3), a filtrar los que moldean la arquitectura (4), a descubrir los implícitos que nadie pide (5), a hablar el idioma del stakeholder traduciendo trade-offs a dinero (6), y a decir no —o "sí, pero cuesta esto"— cuando no cabe todo (7). Todo eso lo viste aplicado a una situación: la estrategia de vendedores externos de Mercado. Ahora te toca a ti, de cero, sobre una situación distinta —un lanzamiento que no analizamos en las lecciones—. La razón de cambiar el caso es la de siempre y es dura: si te dejara re-derivar los atributos de los vendedores externos, 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ó—.

Y este caso nuevo esconde una lección que las lecciones no podían enseñar tan claro: la misma empresa, con una meta distinta, produce prioridades de atributos completamente distintas. En los vendedores externos, scalability encabezaba. En este lanzamiento —los pagos a plazos— vas a ver security dominar y scalability caer a cero. No es que el método sea inconsistente; es que el método es fiel al negocio, y este es otro negocio dentro del mismo Mercado. Si terminas el proyecto con el ranking de los vendedores externos en la cabeza, fallaste; si terminas descubriendo que este lanzamiento pide otra cosa, aprendiste que lo que se transfiere es el método, no la receta.

Tu entregable son cuatro artefactos para el lanzamiento nuevo: (1) el mapeo ejecutado meta→atributo priorizado, con sus conflictos, en Python; (2) los ASRs filtrados de una lista de requisitos; (3) los atributos implícitos descubiertos; y (4) el guion de la conversación con el CFO, traduciendo el trade-off principal a su idioma. Ninguna parte requiere construir el sistema: es puro trabajo de derivación y conversación —traducir, priorizar, filtrar, descubrir, comunicar—, que es justo lo que separa a un arquitecto que entiende a sus stakeholders de uno que solo dibuja cajas. 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 5 te dieron el trabajo del lado del arquitecto (traducir, medir, filtrar, descubrir); las lecciones 6 y 7 te dieron la conversación (hablar en su idioma, decir no). Aquí produces los cuatro 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 6, donde vas a aprender a diseñar para el cambio —porque los atributos que priorizas hoy no son los que el negocio pedirá mañana, y el arquitecto planea para esa evolución—.

El caso del proyecto: Mercado lanza pagos a plazos (BNPL)

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

Mercado quiere ofrecer pagos a plazos en el checkout: el modelo Buy Now, Pay Later (BNPL), donde el comprador se lleva el producto hoy y paga en cuotas, y Mercado (o un socio financiero) asume el crédito. El liderazgo lo ve como la próxima gran palanca de conversión. Tu trabajo como arquitecto es tomar las metas de negocio del lanzamiento y derivar los atributos de calidad priorizados, los requisitos que de verdad importan, lo que nadie pidió pero hay que construir, y preparar la conversación con el CFO —que está nervioso, porque esto involucra prestar dinero—.

Las metas del lanzamiento, con su peso de negocio (te las da el liderazgo, para que no tengas que inventarlas):

  • launch_bnpl (peso 5) — ofrecer pagos a plazos en el checkout. La apuesta.
  • instant_credit_decision (peso 4) — decidir si se aprueba el crédito del comprador en menos de 2 segundos, o la conversión se cae.
  • no_fraud_losses (peso 5) — no perder dinero por fraude ni por impagos mal evaluados. Esto es dinero real de Mercado en riesgo.
  • regulatory_compliance (peso 5) — cumplir la regulación financiera del país (prestar dinero está fuertemente regulado).
  • keep_conversion_high (peso 3) — el flujo de BNPL no debe frenar ni complicar el checkout.

Fíjate en la diferencia de naturaleza con el caso de vendedores externos: aquel era una apuesta de crecimiento (más vendedores, más catálogo, más tráfico → scalability). Este es una apuesta financiera y regulada (prestar dinero, decidir crédito, evitar fraude, cumplir la ley → otra cosa por completo). Tu método debería capturar esa diferencia sin que tú se la impongas a mano —debería salir del mapeo—. No re-enseñes cómo funciona un modelo de scoring de crédito ni una pasarela de pagos —eso es de otras guías—; tu trabajo es derivar los atributos y preparar la conversación para este lanzamiento.

Lo que tienes que entregar

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

Parte 1 — El mapeo meta → atributo priorizado (ejecutado)

Escribe y corre el Python que mapea las cinco metas del BNPL a atributos priorizados, con el método de la lección 2 (peso × fuerza, ranking, y detección de conflictos por peso combinado). Asigna tú qué atributo implica cada meta y con qué fuerza —es tu juicio, hazlo explícito—. Entrega el ranking real, corrido, y nombra el conflicto que más pesa.

Parte 2 — Los ASRs filtrados

Toma una lista de requisitos del lanzamiento (invéntala razonablemente, mezclando cosas estructurales y triviales) y corre el filtro de la lección 4 (las tres preguntas: ¿moldea la estructura? ¿caro de cambiar? ¿alto riesgo?). Separa los ASR del ruido y justifica los casos de frontera.

Parte 3 — Los atributos implícitos descubiertos

Construye el contrato tácito del dominio (pagos a plazos = dinero + crédito + regulación) y compáralo contra lo que las metas explícitas nombraron (lección 5). Entrega la brecha: los atributos que nadie pidió pero el dominio exige, con la catástrofe que previene cada uno.

Parte 4 — El guion de la conversación con el CFO

Toma el conflicto principal que detectaste en la Parte 1 y escribe cómo se lo explicarías al CFO en su idioma (lección 6), y cómo le dirías "no puedo darte todo al máximo" con la priorización que sí cabe (lección 7). El CFO está nervioso por el riesgo financiero: háblale en dinero y riesgo.

La rúbrica

Así se evalúa el proyecto. No es por extensión ni por elegancia: es por si la derivación está bien hecha y la conversación bien preparada, con evidencia.

CriterioNo cumpleCumpleSobresale
Mapeo ejecutadoRanking citado de memoria o inventadoRanking corrido en Python con peso × fuerzaAdemás detecta el conflicto que más pesa y lo explica
ASRs filtradosTodo o nada tratado como significativoSepara ASR de ruido con las tres preguntasAdemás atrapa un ASR disfrazado de requisito trivial
Atributos implícitosSolo lo que el negocio pidióDescubre la brecha del contrato tácitoAdemás justifica cada implícito por su catástrofe concreta
Conversación con el CFOJerga técnica o promete todoTraduce el trade-off a dinero/riesgoAdemás dice "no al máximo" con la priorización que sí cabe

El criterio que más pesa, y el que separa a un arquitecto de un dibujante de cajas, es el mapeo ejecutado: si entregas todo lo demás pero el ranking salió de tu cabeza y no de correr el código, no derivaste —afirmaste con cifras inventadas, que es peor, porque finge rigor—.

La solución de referencia

Intenta el proyecto entero antes de seguir. Lo que viene es una solución correcta, no la única —sobre todo en las asignaciones de peso y fuerza, que son juicios discutibles—.

Parte 1 — El mapeo ejecutado

# Proyecto: una capacidad NUEVA de Mercado -- pagos a plazos (Buy Now, Pay Later).
# Misma empresa, meta distinta: los atributos priorizados salen MUY diferentes.
# Reusamos el metodo de la leccion 2 (mapeo meta->atributo + conflictos).

# Las metas del lanzamiento de BNPL, con su peso de negocio (1..5).
business_goals = {
    "launch_bnpl":             5,   # ofrecer pagos a plazos en el checkout
    "instant_credit_decision": 4,   # aprobar/rechazar el credito en < 2 s
    "no_fraud_losses":         5,   # no perder dinero por fraude / impagos
    "regulatory_compliance":   5,   # cumplir la regulacion financiera del pais
    "keep_conversion_high":    3,   # el flujo no debe frenar la conversion
}

# Que atributo(s) de calidad implica cada meta, y con que fuerza (1..3).
implies = {
    "launch_bnpl":             {"security": 3, "availability": 3, "performance": 2},
    "instant_credit_decision": {"performance": 3, "availability": 2},
    "no_fraud_losses":         {"security": 3},
    "regulatory_compliance":   {"security": 3},
    "keep_conversion_high":    {"performance": 2, "availability": 1},
}

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

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("BNPL -- 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]]
    backers_str = ", ".join(backers) if backers else "(ninguna meta lo pide)"
    print(f"{i:>2}  {attr:<13}{score[attr]:>6}   {backers_str}")

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

print()
print("Conflictos entre atributos, 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("En BNPL el arquitecto no pelea scalability vs cost (como en vendedores")
print("externos): pelea SEGURIDAD antifraude vs VELOCIDAD de la decision de credito.")
print("Misma empresa, meta distinta, prioridades opuestas: el metodo, no la receta.")

Qué esperar. Al correrlo:

BNPL -- atributos de calidad priorizados por su respaldo de negocio:
 #  atributo      score   respaldado por (metas)
 1  security         45   launch_bnpl, no_fraud_losses, regulatory_compliance
 2  performance      28   launch_bnpl, instant_credit_decision, keep_conversion_high
 3  availability     26   launch_bnpl, instant_credit_decision, keep_conversion_high
 4  scalability       0   (ninguna meta lo pide)
 5  cost              0   (ninguna meta lo pide)

Conflictos entre atributos, por peso combinado:
  security (45) vs performance (28)  ->  peso combinado 73
  availability (26) vs performance (28)  ->  peso combinado 54
  availability (26) vs cost (0)  ->  peso combinado 26
  scalability (0) vs cost (0)  ->  peso combinado 0

El conflicto que MAS pesa: security vs performance.
En BNPL el arquitecto no pelea scalability vs cost (como en vendedores
externos): pelea SEGURIDAD antifraude vs VELOCIDAD de la decision de credito.
Misma empresa, meta distinta, prioridades opuestas: el metodo, no la receta.

Lee el ranking y date cuenta de lo revelador que es comparado con el caso de las lecciones. Security domina con 45 —muy por encima de todo—, porque tres de las cinco metas la empujan con fuerza máxima: lanzar BNPL (manejar datos financieros y de crédito), no perder dinero por fraude, y cumplir la regulación financiera. Prestar dinero es, en el fondo, un problema de seguridad y confianza antes que nada, y el mapeo lo captura sin que tú se lo impongas —sale de las metas—. Performance (28) y availability (26) vienen después, empatados casi, empujados por la decisión de crédito instantánea y por no frenar la conversión. Y lo más llamativo: scalability y cost quedan en cero —ninguna meta de este lanzamiento las empuja—. En el caso de vendedores externos, scalability encabezaba con 38; aquí no aparece. No porque a Mercado dejó de importarle escalar, sino porque este lanzamiento específico no es sobre crecimiento de volumen: es sobre prestar dinero de forma segura y rápida. El método es fiel a la meta, y la meta cambió, así que el ranking cambió por completo.

Ese contraste es la lección central del proyecto: el mismo método, sobre la misma empresa, con una meta distinta, produce un ranking opuesto. Un arquitecto que hubiera llegado a este lanzamiento asumiendo "en Mercado lo que importa es escalar" (la conclusión del caso anterior) habría priorizado exactamente lo que este lanzamiento no necesita, y descuidado la seguridad que lo domina todo. El método existe precisamente para impedir eso: te obliga a derivar los atributos de las metas de este lanzamiento, no a arrastrar las conclusiones del anterior. Lo que se transfiere entre casos es el método (mapear, priorizar, detectar conflictos); las respuestas son distintas cada vez porque el negocio es distinto cada vez.

Y el conflicto que más pesa lo confirma: security (45) contra performance (28), con peso combinado 73. Traducido al negocio: el arquitecto de BNPL tiene que reconciliar la seguridad antifraude (revisar a fondo cada solicitud de crédito para no prestarle a un estafador o a alguien que no pagará) con la velocidad de la decisión (aprobar en menos de 2 segundos, o el comprador abandona). Esos dos tiran de frente: la seguridad quiere más revisión (más lento), la conversión quiere menos espera (más rápido). Es un trade-off distinto al del caso anterior (donde era scalability vs cost), y salió directo de las metas. Ese es el conflicto que hay que resolver primero —y su resolución rigurosa (cuánta revisión, con qué método de scoring, aceptando qué nivel de riesgo de fraude a cambio de qué velocidad) es el método de architecture-decisions; tu trabajo aquí fue detectarlo y cuantificarlo—.

Parte 2 — Los ASRs filtrados

Una lista razonable de requisitos del lanzamiento, corrida por el filtro de las tres preguntas:

requisito¿moldea?¿caro?¿riesgo?señalclasificación
Guardar el rastro de cada decisión de crédito (para el regulador)1113/3ASR
Aislar y proteger los datos financieros del comprador1113/3ASR
Decidir el crédito en menos de 2 segundos1102/3ASR
Integrar el modelo de scoring de crédito1113/3ASR
Mostrar el plan de cuotas con un ícono de calendario0000/3ruido
El texto del botón: "Paga después" vs "Págalo en cuotas"0000/3ruido
Poder revertir/cancelar un crédito ya otorgado1113/3ASR

Cinco ASR y dos de ruido. Los ASR son donde el arquitecto pone su energía: guardar el rastro de decisiones (auditabilidad regulatoria —moldea cómo y dónde se almacena todo, carísimo de retrofitear, riesgo de multa—), aislar datos financieros, la decisión sub-2-segundos (2/3: moldea la estructura del flujo de crédito y es cara de cambiar, aunque no sea catastrófica —el caso de frontera de la lección 4—), integrar el scoring, y poder revertir un crédito (toca la integridad transaccional y el cumplimiento). El ruido —el ícono del calendario, el texto del botón— lo decide el equipo de producto; el arquitecto no se mete.

El ASR disfrazado (para sobresalir): "poder revertir/cancelar un crédito ya otorgado" suena a una función de producto ("un botón de cancelar"), pero es profundamente estructural: revertir un crédito otorgado implica deshacer una transacción financiera que ya movió dinero, ya se reportó al buró de crédito, quizás ya generó cuotas —es un problema de consistencia transaccional, de compensación de operaciones y de cumplimiento, no un botón—. Es el "botoncito de exportar a Excel" del proyecto: llega vestido de trivial y es tirar un muro.

Parte 3 — Los atributos implícitos descubiertos

El contrato tácito de "pagos a plazos" (dinero + crédito + regulación), comparado contra lo que las metas nombraron:

Las metas explícitas nombraron: security, performance, availability (del ranking). El dominio exige, además, atributos que ninguna meta pidió:

  • auditability (auditabilidad) — cada decisión de crédito y cada movimiento de dinero debe poder rastrearse durante años. Catástrofe que previene: que el regulador investigue una práctica de préstamo discriminatoria o un caso de lavado y no haya rastro —multa y sanción—. (Nota: en las metas está regulatory_compliance, que la implica, pero la auditabilidad como capacidad técnica nadie la pidió por su nombre.)
  • data_integrity (integridad de datos) — un crédito otorgado no puede perderse, duplicarse ni quedar en un estado inconsistente (aprobado pero no registrado, o cobrado dos veces). Catástrofe que previene: cobrar dos cuotas a la vez, o "perder" un crédito y no cobrarlo nunca —pérdida directa de dinero y clientes furiosos—.
  • fairness / non-discrimination (equidad del modelo) — el modelo de scoring no puede discriminar ilegalmente por características protegidas. Catástrofe que previene: una demanda por discriminación crediticia, un riesgo legal y reputacional enorme, específico de prestar dinero con un modelo.
  • recoverability (recuperabilidad) — si el sistema falla a mitad de una decisión de crédito o un cobro, debe recuperarse sin dejar dinero en el limbo. Catástrofe que previene: créditos "a medio otorgar" tras una caída, imposibles de reconciliar.
  • privacy (privacidad) — datos financieros del comprador protegidos según la ley de datos personales. Catástrofe que previene: fuga de datos financieros, con las multas y la pérdida de confianza que eso implica en un producto de crédito.

Cinco atributos implícitos, ninguno pedido, todos pesados. Nota el fairness del modelo: es un implícito específico de este dominio (prestar con un algoritmo) que en el caso de vendedores externos no existía —cada dominio tiene su propio contrato tácito—. Un arquitecto que solo entregara los tres explícitos (security, performance, availability) dejaría fuera la auditabilidad regulatoria, la integridad transaccional del dinero, y la equidad del modelo —tres bombas legales esperando—.

Parte 4 — El guion de la conversación con el CFO

El CFO está nervioso porque esto involucra prestar dinero de Mercado. El conflicto principal es security (antifraude) vs performance (decisión en 2 segundos). Se lo explico en su idioma —dinero y riesgo—, y le digo "no al máximo en ambos":

"El corazón técnico de BNPL es una tensión que te va a importar directamente, porque es sobre tu dinero. Por un lado, para no perder plata, tenemos que revisar bien a quién le prestamos —detectar fraude, evaluar si la persona va a pagar—. Cuanto más a fondo revisamos, menos dinero perdemos por impagos y estafas. Por el otro lado, si la revisión tarda mucho, el comprador abandona el checkout y perdemos la venta —y la conversión es justo la razón por la que lanzamos esto—. Más seguridad protege tu dinero pero frena la venta; más velocidad captura la venta pero deja pasar más riesgo. No podemos tener las dos al máximo: una revisión instantánea y perfecta a la vez no existe.

Lo que propongo no es elegir una y sacrificar la otra, sino un punto donde las dos convivan: una primera evaluación automática en menos de 2 segundos que aprueba a la gran mayoría de clientes de bajo riesgo al instante (protegemos la conversión), y una revisión más profunda —de segundos o minutos— solo para los casos que el modelo marca como dudosos (protegemos tu dinero donde el riesgo real está). Así no frenamos al 95% de los compradores buenos por culpa del 5% sospechoso.

Y quiero ser honesto sobre lo que no estamos maximizando. Este lanzamiento prioriza la seguridad y la velocidad del crédito, que es donde está tu dinero y la conversión. No estamos optimizando para escalar a un volumen gigante ni para minimizar el costo de infraestructura —esas no son las prioridades de este producto, y meterles esfuerzo ahora sería gastar donde no rinde—. Si el BNPL despega y el volumen se dispara, volvemos a priorizar y hablamos de escalar entonces. Por ahora, cada peso de esfuerzo va a que no perdamos dinero y no perdamos la venta. Te puedo mostrar, para cada nivel de revisión antifraude, cuánto riesgo de impago cubre y cuánta conversión cuesta, para que decidas dónde ponemos la raya."

Por qué funciona: traduce el conflicto security-vs-performance a las dos cosas que el CFO entiende (riesgo de perder dinero prestado, y venta perdida por fricción), propone un punto intermedio concreto en vez de un máximo imposible, nombra explícitamente lo que no se prioriza (scalability y cost, los ceros del ranking) para que no haya sorpresas, y le ofrece los números para que él decida dónde va la raya —la doble dirección de la traducción, el "no al máximo" de la lección 7, y el respeto de la frontera (el arquitecto presenta, el negocio decide)—.

Ejercicios

Estos ejercicios transfieren el método a otras decisiones de Mercado, para que confirmes que aprendiste a derivar atributos y no a repetir un caso.

Ejercicio 1 — Cambia una meta y observa el ranking. El liderazgo agrega una sexta meta al BNPL: "prepararnos para procesar 50x el volumen de crédito en dos años, porque queremos que BNPL sea masivo" (peso 5, implica scalability con fuerza 3 y cost con fuerza 2). Sin correr todo el código, calcula el nuevo score de scalability y explica cómo cambia el ranking y el conflicto principal.

Ver solución

Nuevo score de scalability. Antes era 0 (ninguna meta lo empujaba). La meta nueva lo implica con fuerza 3 y tiene peso 5: 5 × 3 = 15. Nuevo score de scalability = 15. El nuevo score de cost = 5 × 2 = 10 (antes 0).

Cómo cambia el ranking. Scalability salta de 0 (último) a 15, superando a scalability y cost anteriores pero quedando aún por debajo de availability (26), performance (28) y security (45). El ranking sería aproximadamente: security 45, performance 28, availability 26, scalability 15, cost 10. Scalability dejó de ser irrelevante y se volvió un atributo de peso medio.

Cómo cambia el conflicto principal. El conflicto security-vs-performance (73) sigue siendo el que más pesa —esa meta nueva no lo toca—. Pero aparece con fuerza el conflicto scalability vs cost (ahora 15 + 10 = 25, antes 0): "queremos ser masivos" (scalability) contra un costo que el CFO vigila (cost). No destrona al principal, pero ya es un trade-off real que antes ni existía.

La lección: agregar una meta reintrodujo un atributo que estaba en cero. Esto muestra por qué el ranking se recalcula cada vez que el negocio cambia sus metas —y por qué el mismo lanzamiento, con una meta más, ya no es el mismo problema de arquitectura—. El método no da una respuesta fija; da una respuesta fiel a las metas actuales.

Ejercicio 2 — El ASR disfrazado, otra vez. Al equipo de BNPL le llega este requisito: "permitir que el usuario cambie su plan de cuotas de 3 a 6 meses después de haber comprado". El product manager lo presenta como "un ajuste menor en la pantalla de mi cuenta". ¿Le correrías la prueba del ASR? Argumenta qué esconde y clasifícalo.

Ver solución

Sí, le correría la prueba —y no es un ajuste menor—. "Cambiar el plan de cuotas después de comprar" toca dinero, crédito ya otorgado y cumplimiento; es exactamente el tipo de requisito que llega disfrazado de trivial. Las tres preguntas:

  • ¿Moldea la estructura? Sí. Cambiar un plan de 3 a 6 meses significa recalcular las cuotas, reajustar el cronograma de cobros, posiblemente recalcular intereses, actualizar lo reportado al buró de crédito, y mantener la consistencia entre el crédito original y el modificado. No es cambiar un número en una pantalla; es modificar un contrato de crédito activo, lo que exige toda una maquinaria de modificación transaccional.
  • ¿Caro de cambiar después? Sí. Si el sistema se diseñó asumiendo que un plan de cuotas es inmutable una vez otorgado, agregar la mutabilidad después es un refactor profundo del núcleo financiero.
  • ¿Alto riesgo? Sí. Un error al recalcular cuotas o intereses es cobrar mal a un cliente —un problema financiero, legal y de confianza—, y modificar mal lo reportado al buró puede dañar el historial crediticio de una persona.

Clasificación: ASR (3/3), y de los pesados. Es el ASR disfrazado en carne y hueso: presentado como "un ajuste menor en la pantalla de mi cuenta", esconde una de las capacidades más delicadas de un sistema de crédito (modificar contratos activos con dinero de por medio). Despacharlo como ruido de producto sería el error caro de la lección 4. La regla se cumple otra vez: todo requisito que toca dinero, crédito o cumplimiento merece la prueba, por trivial que suene su presentación.

Ejercicio 3 — Otra vez el CFO, otra respuesta. Supón que, tras tu propuesta, el CFO dice: "no me convence lo de aprobar automático en 2 segundos; el riesgo de fraude me da miedo. Quiero que todas las solicitudes pasen por revisión profunda, sin excepción, aunque tarden". Con el método, argumenta por qué "revisión profunda para todas" es el "todo al máximo" de la lección 7 aplicado a la seguridad, y cómo le responderías con un "sí, pero cuesta esto".

Ver solución

Por qué es "todo al máximo". "Revisión profunda para todas las solicitudes, sin excepción" es maximizar la seguridad antifraude sin considerar su costo en el otro atributo prioritario: la conversión (performance/velocidad). Es exactamente el pedido imposible de la lección 7, solo que en vez de "todos los atributos al 5" es "un atributo al 5 ignorando con qué se pelea". Y se pelea justo con la razón de ser del producto: si toda solicitud tarda minutos en revisión, la gran mayoría de los compradores —los buenos, que son la enorme mayoría— abandonan el checkout, y BNPL no cumple su meta de conversión. Maximizar la seguridad destruye el valor de negocio del lanzamiento.

La respuesta "sí, pero cuesta esto": "Entiendo el miedo, y tienes razón en que el fraude es un riesgo real de tu dinero. Sí podemos revisar a fondo todas las solicitudes —pero déjame decirte lo que cuesta, porque es mucho—. Si todas pasan por revisión profunda, la decisión ya no toma 2 segundos sino minutos, y por los datos de la industria, cada segundo extra de fricción en el checkout tira la conversión. En concreto: probablemente perderíamos [X%] de las ventas de BNPL —gente buena, de bajo riesgo, que se cansa de esperar y compra sin plazos o no compra—. Estaríamos rechazando indirectamente al 95% de clientes buenos por miedo al 5% sospechoso.

La alternativa que protege tu dinero sin matar la conversión es la revisión escalonada: el modelo aprueba al instante a los clientes que evalúa como claramente de bajo riesgo (la mayoría), y manda a revisión profunda solo a los que marca como dudosos. Así, el esfuerzo antifraude cae donde el riesgo real está, y no castigamos a los compradores buenos. Puedo mostrarte, con datos, cuánto fraude atrapa cada nivel de umbral y cuánta conversión cuesta —y verás que revisar-todo atrapa un poquito más de fraude a cambio de perder muchísima venta buena—. La decisión de dónde poner el umbral es tuya; solo quiero que la tomes viendo las dos columnas, no solo la del miedo al fraude."

Por qué funciona: nombra que "revisar todo" es maximizar un atributo ignorando su conflicto (lección 7), traduce el costo a lo que el CFO entiende (conversión perdida = venta perdida), ofrece la alternativa (revisión escalonada) que da mejor valor de negocio, y devuelve la decisión con los números —sin usurparla y sin ceder a la reacción de miedo—. Es el "sí, pero cuesta esto" en su forma más útil: no bloquea el deseo del CFO, le pone precio y le ofrece un mejor camino.

Resumen del módulo y hacia dónde sigues

Con este proyecto cierras el módulo 5, donde la arquitectura toca al negocio. Empezaste con la tesis —las decisiones de arquitectura salen de las metas del negocio, y el primer trabajo del arquitecto es traducir esos deseos a atributos de calidad— y el arquitecto de casas que convierte "envejecer aquí" en requisitos concretos (lección 1). Ejecutaste la traducción completa, mapeando las metas de Mercado a atributos priorizados (scalability 38, security 30…) y detectando sus conflictos (lección 2). Volviste medible lo vago con el quality attribute scenario de seis partes, y la regla dura —sin medida, no es un requisito— (lección 3). Separaste la señal del ruido con los architecturally-significant requirements, el filtro que dice dónde meterte y dónde soltar (lección 4). Descubriste los atributos implícitos que nadie pide y todos esperan —el contrato tácito del dominio— (lección 5). Aprendiste a hablar el idioma del stakeholder, traduciendo los nueves a dólares —"más disponibilidad = más dinero"— (lección 6). Y aprendiste a decir no —o "sí, pero cuesta esto"—, administrando un presupuesto de calidad finito (lección 7). Aquí, en el proyecto, lo hiciste todo tú sobre un lanzamiento nuevo —los pagos a plazos—, y comprobaste la lección más profunda del módulo: el mismo método, sobre la misma empresa, con una meta distinta, produce prioridades opuestas (security domina, scalability cae a cero). El método se transfiere; las respuestas no.

La capacidad que te llevas: ante cualquier meta de negocio, puedes derivar los atributos de calidad que implica y priorizarlos con evidencia, volverlos medibles, filtrar los que moldean la arquitectura, descubrir los que nadie pidió, y conducir la conversación con el stakeholder que los aprueba —traduciendo los trade-offs a su idioma y sabiendo decir no—. Dejaste de tratar los deseos del negocio como instrucciones a ejecutar al pie de la letra, y empezaste a tratarlos como el material bruto que el arquitecto traduce, en las dos direcciones, para que la arquitectura correcta llegue a existir.

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

  • Módulo 6 — Diseñar para el cambio. Ya sabes derivar los atributos que el negocio necesita hoy. Pero las metas del negocio cambian —el propio Mercado pasó de vendedores externos a pagos a plazos, con prioridades opuestas—, y una arquitectura amarrada a los atributos de hoy se vuelve una jaula mañana. El módulo 6 enseña la postura mental del arquitecto que planea para el cambio, no para la permanencia: mantener opciones abiertas, la sacrificial architecture, y evitar tanto el over-engineering como el under-engineering. Los atributos que priorizaste aquí son una foto; el módulo 6 es aprender a diseñar sabiendo que la foto va a cambiar.

Y hacia el resto del ecosistema: cada vez que este módulo detectó que dos atributos compiten (scalability vs cost, security vs performance) sin resolver el conflicto, se apoyaba en la guía que sí enseña cómo decidir: architecture-decisions-and-tradeoffs —la matriz, el ADR, la fitness function—. Ahora tienes lo que esa guía da por sentado: de dónde salen los atributos, cómo se priorizan desde el stakeholder, y cómo se conversa el trade-off con quien lo aprueba. Este módulo es la puerta de entrada a toda decisión de arquitectura: derivar bien los atributos desde el negocio es el insumo del que depende que la decisión —por más rigurosa que sea— resuelva el problema correcto.

Recursos

← Anterior7. Saber decir no (y el costo del sí)Siguiente →Presentación del módulo: diseñar para el cambio