Módulo 5: Stakeholders y atributos de calidad

2. De la meta de negocio al atributo de calidad

Siguiente →

Descripción

Al terminar esta lección vas a saber hacer, con método y con números, la traducción que es el corazón de todo el módulo: tomar una lista de metas de negocio —deseos, en el idioma del negocio— y devolver una lista de atributos de calidad priorizados —los -ilities, en un orden defendible—. En la lección 1 viste la intuición: una sola frase ("abrir a vendedores externos") se abre en varios atributos. Aquí lo conviertes en un procedimiento reproducible sobre las seis metas completas de Mercado. La mecánica es sencilla y por eso poderosa: cada meta implica uno o varios atributos, con distinta fuerza; cada meta tiene un peso de negocio (qué tan estratégica es); y el respaldo de negocio de un atributo es la suma, sobre todas las metas, de peso de la meta × fuerza con que esa meta lo implica. Ese número —el score— ordena los atributos por cuánto los sostiene el negocio, no por cuánto le gustan al arquitecto. Vas a ejecutar el mapeo y ver salir el ranking: en Mercado, scalability encabeza (38), seguido de security (30), availability (25), performance (23) y cost (19). Y no te quedas ahí: vas a detectar los conflictos —los pares de atributos que se pelean, porque mejorar uno cuesta el otro— ordenados por cuánto pesan juntos, y vas a ver que el trade-off que más pesa en Mercado es scalability contra cost.

Esto importa porque es la diferencia entre un arquitecto que decide con evidencia y uno que decide con opiniones. Sin este mapeo, cuando llega el momento de elegir —¿optimizo para escalar o para no gastar? ¿pongo primero la seguridad o la velocidad?— el arquitecto no tiene con qué defender su elección más allá de "me parece". Con el mapeo, puede decir: "scalability va primero porque tres metas estratégicas la respaldan con un score de 38, la más alta; cost va al final, no porque no importe, sino porque solo dos metas la sostienen; y por cierto, scalability y cost se pelean, así que ese es el trade-off que tenemos que resolver primero, y aquí está el dato que lo dice". Eso no es burocracia: es tener el mapa que hace que cada decisión posterior sea trazable a una meta de negocio con un peso. Y hay un segundo regalo escondido en el ejercicio: al listar qué metas respaldan cada atributo, el mapeo te muestra los conflictos reales del negocio —"crecer 10x" (scalability) contra "no triplicar la factura" (cost) no es un choque abstracto de atributos, son dos metas concretas del liderazgo que se contradicen, y alguien va a tener que elegir—.

Conexión con el módulo: esta lección es el motor del que cuelga todo lo demás. La lección 1 dio la tesis (traducir el negocio a atributos); aquí la ejecutas a fondo. Las lecciones que siguen refinan cada pieza de este mapeo: la 3 toma un atributo del ranking y lo vuelve medible con un scenario (porque "scalability alta" todavía es vago); la 4 filtra los requisitos que de verdad moldean la arquitectura (los ASRs) de los que no; la 5 descubre los atributos implícitos que este mapeo no captura porque nadie los pidió; y las lecciones 6 y 7 usan los conflictos que detectas aquí para la conversación —cómo le explicas al VP que scalability-vs-cost obliga a elegir, y cómo dices "no puedo darte los dos al máximo"—. Todo el módulo es este mapeo, primero construido (aquí), luego afinado, luego conversado. La frontera se mantiene firme: aquí detectas que los atributos compiten; cómo se resuelve ese conflicto —la matriz de decisión, el ADR— es el método de architecture-decisions, no de esta lección.

El mesero que arma el pedido de una mesa entera

Piénsalo con el mesero de la lección 1, pero ahora con una mesa de seis, no un solo comensal. Cada uno pide en su idioma: "algo ligero", "sin picante que soy sensible", "lo más rápido posible que tengo prisa", "que no sea caro", "algo contundente que vengo con hambre", "lo que sea, pero que alcance para compartir". Seis deseos, en el idioma de la mesa. El buen mesero no los trata como seis pedidos independientes: los traduce todos a la vez a atributos del platillo (ligereza, sin chile, rapidez, precio, porción) y nota dos cosas de golpe. Primero, que algunos deseos empujan al mismo atributo —"ligero" y "sin picante" los pidió más de uno, así que ese atributo pesa más—. Segundo, que algunos deseos se contradicen: "lo más rápido posible" pelea con "algo contundente que toma tiempo cocinar", y "que no sea caro" pelea con "algo contundente de buena calidad". El mesero que sabe su oficio prioriza —¿qué atributo satisface a más comensales importantes?— y nombra los choques en voz alta: "el guiso contundente tarda 40 minutos; si tienen prisa, mejor la pasta". No inventa el conflicto: lo descubre al traducir todos los deseos juntos y ver dónde se cruzan.

Eso es exactamente lo que hace el arquitecto con las metas del negocio, y por eso hay que traducirlas todas juntas, no una por una. Si el arquitecto tradujera "crecer 10x" en aislamiento y luego, en otra reunión, "no triplicar la factura" en aislamiento, nunca vería que las dos se pelean. Es al ponerlas en la misma tabla —los seis deseos de Mercado, con su peso, con los atributos que empujan— donde salta a la vista que un atributo lo respaldan tres metas (pesa) mientras a otro lo respalda una sola (pesa poco), y donde salta el conflicto: "crecer 10x" empuja scalability hacia arriba y "no triplicar la factura" empuja cost hacia abajo, y esas dos fuerzas se van a encontrar de frente. El mapeo de esta lección es el mesero que arma el pedido de la mesa entera: traduce todos los deseos a la vez, ve cuáles se refuerzan, y descubre cuáles chocan.

Ejemplo trabajado: el mapeo meta → atributo priorizado

Vamos a ejecutar la traducción completa sobre las seis metas de Mercado. La estructura de datos tiene tres partes, todas fijas para que el resultado sea reproducible: el peso de negocio de cada meta (de 1, un nice-to-have, a 5, algo estratégico), qué atributos implica cada meta y con qué fuerza (de 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. Luego rankeamos, y por último detectamos qué conflictos pesan más.

# De metas de negocio a atributos de calidad, priorizados -- y con sus conflictos.
# Datos fijos y reproducibles.

# Las metas de Mercado con su peso de negocio (1=nice-to-have .. 5=estrategico).
business_goals = {
    "open_to_external_sellers": 5,
    "grow_10x":                 5,
    "survive_black_friday":     4,
    "protect_payment_data":     5,
    "keep_infra_costs_flat":    3,
    "instant_checkout":         3,
}

# 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)}")

# Pares de atributos que tipicamente COMPITEN: mejorar uno tiende a costar el otro.
tensions = [
    ("scalability",  "cost"),         # escalar cuesta infra
    ("security",     "performance"),  # cifrar/validar/auditar anade latencia
    ("availability", "performance"),  # replicar/consenso puede anadir latencia
    ("availability", "cost"),         # mas redundancia = mas $
]

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:
    combined = score[a] + score[b]
    print(f"  {a} ({score[a]}) vs {b} ({score[b]})  ->  peso combinado {combined}")

print()
top = ranked_tensions[0]
print(f"El conflicto que MAS pesa: {top[0]} vs {top[1]}.")
print("Ese es el trade-off que el arquitecto debe encarar primero. El metodo de")
print("COMO resolverlo se ve en architecture-decisions; aqui solo lo detectamos.")

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 el arquitecto debe encarar primero. El metodo de
COMO resolverlo se ve en architecture-decisions; aqui solo lo detectamos.

Lee el ranking primero, porque es la traducción hecha número. Scalability encabeza con 38, y la columna de la derecha te dice por qué: la respaldan tres metas, 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 el negocio, con sus propias prioridades, empuja scalability más que ningún otro atributo. Fíjate que el número no salió de la nada: 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. Cada punto del score es trazable a una meta con un peso. Esa trazabilidad es el regalo: cuando alguien pregunte "¿por qué scalability es lo primero?", la respuesta no es una opinión, es esta suma.

Ahora fíjate en el contraste que enseña el módulo. Security es segundo (30) aunque solo dos metas lo respaldan —pero las dos con peso 5 y fuerza 3, así que suma alto—. Cost es último (19), y aquí hay un matiz crucial que un lector apurado malinterpreta: último no significa que no importe. El CFO fue explícito con "no triplicar la factura", y esa meta está en la lista con peso 3. Cost es último porque solo dos metas lo empujan y con pesos medios, mientras scalability tiene tres metas y dos de peso máximo. El ranking no dice "ignora el costo"; dice "cuando el costo se pelee con la escalabilidad, la escalabilidad tiene más respaldo de negocio" —que es información valiosísima para la conversación que viene—. El arquitecto que lee esto no descarta el costo; sabe que va a tener que negociarlo contra la escalabilidad, y sabe de qué lado está el peso.

Y ahí entra la segunda mitad de la salida, la de los conflictos, que es donde el mapeo deja de describir y empieza a advertir. El sistema detectó cuatro pares de atributos que se pelean y los ordenó por su peso combinado. El que más pesa es scalability (38) contra cost (19), con peso combinado 57. Traducido: 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 de negocio, ese es el trade-off que el arquitecto tiene que resolver primero —antes que ningún otro—. No es un choque teórico entre dos -ilities abstractos: son dos frases concretas del liderazgo que no pueden cumplirse ambas al máximo. El segundo conflicto (security 30 vs performance 23, peso 53) es el clásico "blindar los datos de pago" contra "checkout instantáneo": cifrar, validar y auditar añade latencia. Los dos conflictos que más pesan salieron directamente de metas reales del negocio, y el arquitecto ahora los tiene nombrados, cuantificados y ordenados —antes de dibujar nada—.

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 con fuerza 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é, tienes una tabla donde cada supuesto está a la vista y el negocio puede corregirlo —"no, para nosotros el costo pesa 5, no 3, porque estamos por levantar capital y la quema importa muchísimo"—. 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. El mapeo no reemplaza el juicio del arquitecto: lo saca de su cabeza y lo pone sobre la mesa, que es donde el negocio puede opinar.

Profundización: por qué el ranking sale del negocio, y qué hace con el empate

Vale la pena detenerse en tres cosas que este mapeo revela y que un arquitecto principiante suele pasar por alto.

Primero, el ranking es del negocio, no del arquitecto —y eso es liberador—. Un arquitecto sin este método carga con una responsabilidad imposible: decidir, con su solo criterio, si Mercado debe priorizar escalar o ahorrar. Es una decisión de negocio disfrazada de decisión técnica, y cuando sale mal, el arquitecto carga 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 haya decidido: es que las prioridades del negocio, hechas explícitas, lo producen. Si el negocio no está de acuerdo con el ranking, 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—.

Segundo, el empate cercano es información, no ruido. Mira performance (23) y availability (25): están casi empatados. Un arquitecto ingenuo vería el ranking y trataría el 3º y el 4º lugar como una jerarquía firme —"availability antes que performance, siempre"—. Pero una diferencia de dos puntos no es una jerarquía firme: es un aviso de que esos dos atributos son de importancia comparable para Mercado, y que la decisión entre ellos va a depender del contexto de cada caso concreto, no del ranking global. El ranking no es un decreto que resuelve todo de una vez; es un mapa de pesos relativos que te dice dónde hay diferencias grandes (scalability 38 contra cost 19: una brecha real) y dónde hay empates que tendrás que romper caso por caso (availability 25 contra performance 23: prácticamente iguales). Leer un empate como si fuera una jerarquía es abusar del número.

Tercero, el mapeo captura lo explícito, y por eso tiene un punto ciego que hay que conocer. Este método rankea los atributos que las metas nombran. Pero hay atributos que ninguna meta nombra y que sin embargo el sistema debe cumplir —integridad de datos, auditabilidad, privacidad—. En este ranking no aparecen, porque ninguna meta de la lista los empuja, y su score sería cero. Eso no significa que no importen; significa que el mapeo de metas explícitas no es suficiente por sí solo, y hay que complementarlo con el descubrimiento de los atributos implícitos (la lección 5). El arquitecto que trata este ranking como la lista completa de lo que el sistema necesita va a entregar exactamente los atributos que el negocio pidió y ninguno de los que dio por hecho —y esos son justo los que estallan—. El mapeo es necesario pero no completo: es la mitad explícita del trabajo, y la lección 5 es la otra mitad.

Y una nota sobre la frontera, que este es el mejor lugar para marcarla. El mapeo detecta que scalability y cost compiten. No te dice cómo resolverlo —cuánto de cada uno, qué arquitectura logra el balance, cómo documentar la elección—. Esa es una decisión con su propio método riguroso: opciones, matriz de decisión ponderada, un ADR que registra el porqué, quizás una fitness function que vigila que el balance se mantenga. Todo eso es la guía architecture-decisions-and-tradeoffs. Aquí tu trabajo termina en "aquí están los atributos priorizados y aquí están los conflictos que hay que resolver, en orden de peso". Entregar eso —un mapa claro de qué compite con qué y cuánto pesa cada lado— es exactamente el insumo que el método de decisión necesita para empezar. Haces el diagnóstico; la otra guía hace la cirugía.

Errores comunes

Priorizar por el gusto técnico del arquitecto en vez de por el peso del negocio (de sesgo). Qué pasa: al arquitecto le apasiona la escalabilidad, así que la pone primero "porque es lo correcto", sin revisar si el negocio la respalda más que a los otros atributos. En una startup que aún no tiene tracción, priorizar scalability sobre cost puede ser un error caro —escalas para un tráfico que no llega mientras quemas el capital que sí importa—. Por qué pasa: es natural priorizar lo que uno domina o disfruta. Cómo detectarlo: si tu ranking coincidiera igual de bien con cualquier empresa, no está anclado en este negocio. Cómo corregirlo: los pesos los pone el negocio, no el arquitecto; corre el mapeo con los pesos reales de la empresa y deja que el ranking salga de ahí, aunque contradiga tu instinto.

Leer "último lugar" como "no importa" (de mal ranking). Qué pasa: cost queda último en el ranking, y el arquitecto concluye "el costo no importa, gastemos lo que haga falta en escalar", ignorando que el CFO puso esa meta con peso 3 explícitamente. Seis meses después, la factura se triplicó y el CFO está furioso —cost importaba, solo pesaba menos que scalability cuando las dos chocan—. Por qué pasa: un ranking invita a tratar los últimos lugares como desechables. Cómo detectarlo: si estás ignorando por completo un atributo que aparece en el ranking (aunque sea abajo), lo malinterpretaste. Cómo corregirlo: el ranking dice quién gana cuando dos atributos chocan, no qué atributos puedes ignorar; cost último significa "cuando pelee contra scalability, scalability gana", no "olvídate del costo".

Traducir las metas una por una y perder los conflictos (de aislamiento). Qué pasa: el arquitecto traduce cada meta en su propia reunión, en su propio documento, 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 explota tarde, en implementación, cuando ya es caro. Por qué pasa: las metas llegan en momentos distintos, de personas distintas, y es cómodo tratarlas por separado. Cómo detectarlo: si no tienes una sola vista con todas las metas y todos los atributos juntos, no puedes haber detectado los conflictos. Cómo corregirlo: traduce todas las metas a la vez, en una sola tabla (como el mesero que arma el pedido de la mesa entera), y corre la detección de conflictos —los choques solo son visibles cuando todo está junto—.

Ejercicios

Ejercicio 1 — Recalcula con pesos nuevos. El CFO de Mercado te dice: "estamos por levantar una ronda de inversión, así que la quema de dinero importa muchísimo más de lo que pensábamos; sube el peso de keep_infra_costs_flat de 3 a 5". Sin correr el código completo, calcula el nuevo score de cost y explica cómo cambia su posición en el ranking. ¿Qué le dirías al arquitecto que aún tiene scalability como prioridad absoluta?

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 —un salto notable—. El ranking ahora sería, aproximadamente: scalability 38, security 30, cost 25 y availability 25 (empate), performance 23.

Qué le dirías al arquitecto. Que el ranking no es una verdad fija: es un reflejo de las prioridades del negocio, y las prioridades cambiaron. Con la ronda de inversión en puerta, el costo ya no es el atributo desechable del fondo de la tabla —ahora pesa tanto como la disponibilidad—. El conflicto scalability-vs-cost, que ya era el que más pesaba (57), ahora pesa aún más (38 + 25 = 63) y es todavía más urgente de resolver. La lección: cuando el negocio cambia, se recorren los pesos y se vuelve a correr el mapeo; un arquitecto que se aferra a "scalability siempre primero" sin actualizar los pesos está decidiendo con un mapa viejo.

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 (escalar cuesta infra). ¿Cómo puede una sola meta empujar dos atributos que se pelean entre sí? ¿Qué te dice eso sobre la naturaleza de las metas de negocio?

Ver solución

Una sola meta puede empujar dos atributos en conflicto porque una meta de negocio suele ser, en el fondo, un deseo de tenerlo todo —y ese deseo, al traducirse, revela su propia contradicción interna—. "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 negocio 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é te dice sobre las metas de negocio: que casi siempre contienen un trade-off oculto que el stakeholder no ve, porque el stakeholder piensa en el resultado deseado (crecer barato y rápido), no en las tensiones técnicas de lograrlo. Parte del oficio del arquitecto es sacar ese trade-off a la luz: "cuando dices 'crecer 10x', estás pidiendo escalar y ahorrar a la vez, y esas dos cosas se pelean; ¿cuál pesa más si tengo que elegir?". Esa pregunta —incómoda para el stakeholder porque lo obliga a elegir algo que creía que podía tener completo— es exactamente el trabajo de las lecciones 6 y 7. El mapeo lo hace visible: cuando una meta implica dos atributos que están en la lista de conflictos, tienes un trade-off que negociar dentro de una sola meta, no entre dos.

Ejercicio 3 — Diseña el mapeo para otra empresa. Una startup de telemedicina tiene tres metas: "cumplir la regulación de salud (HIPAA)" (peso 5), "que una videollamada nunca se corte a mitad de una consulta" (peso 5), y "lanzar rápido para ganarle a la competencia" (peso 4). Asigna a cada meta los atributos que implica y con qué fuerza (usa scalability, availability, security, performance y agrega los que necesites). Sin correr código, predice qué atributo encabezaría el ranking y por qué el resultado sería muy distinto al de Mercado.

Ver solución

Una asignación razonable (el juicio es discutible, esa es la gracia):

  • comply_with_hipaa (peso 5) → security (fuerza 3), auditability (fuerza 3), privacy (fuerza 3). La regulación de salud es, sobre todo, protección y trazabilidad de datos sensibles.
  • no_dropped_calls (peso 5) → availability (fuerza 3), reliability (fuerza 3), performance (fuerza 2). "Nunca se corte" es disponibilidad y confiabilidad de la conexión en tiempo real.
  • launch_fast (peso 4) → time_to_market / simplicity (fuerza 3). Lanzar rápido empuja hacia la simplicidad y en contra de la sobre-ingeniería —y suele competir con security y availability, que toman tiempo—.

Qué encabezaría el ranking. Muy probablemente security (respaldado por HIPAA con peso 5 y fuerza 3 = 15, más lo que aporte privacy/auditability), disputándose el primer lugar con availability (respaldada por "no dropped calls" con peso 5 y fuerza 3 = 15). Scalability, que en Mercado encabezaba con 38, aquí casi no aparece —ninguna de las tres metas la empuja fuerte—.

Por qué es tan distinto a Mercado. Porque el ranking sale del negocio, y este es un negocio completamente distinto. Mercado es un marketplace en crecimiento explosivo: sus metas empujan scalability. La telemedicina es un servicio regulado de salud en tiempo real: sus metas empujan security, availability y compliance. Mismo método, empresas distintas, rankings opuestos. Eso es exactamente lo que demuestra que el método funciona: no impone un orden universal de atributos ("la seguridad siempre primero", "escalar siempre importa"), sino que deriva el orden de las prioridades reales de cada negocio. Un arquitecto que llegara a la telemedicina con el ranking de Mercado en la cabeza priorizaría lo que no importa. El mapeo lo obliga a partir de las metas de esta empresa. (Este ejercicio anticipa el proyecto: en él verás cómo el mismo Mercado, con una meta distinta —pagos a plazos—, produce un ranking donde security domina y scalability cae a cero.)

Resumen y siguiente paso

En esta lección aprendiste a ejecutar la traducción que es el corazón del módulo: de metas de negocio a atributos de calidad priorizados. Con el mesero que arma el pedido de la mesa entera viste por qué hay que traducir todas las metas juntas —solo así se ve qué atributos se refuerzan y cuáles chocan—. Y lo mediste ejecutando: el mapeo que suma peso × fuerza sobre las seis metas de Mercado y produce 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 por peso combinado, que reveló scalability-vs-cost (57) como el trade-off que más pesa —la contradicción entre "crecer 10x" y "no triplicar la factura"—. Entendiste que el ranking sale del negocio y no del arquitecto, que "último lugar" no significa "no importa" sino "pierde cuando choca", que un empate cercano es un aviso y no una jerarquía, y que el mapeo captura lo explícito pero tiene un punto ciego (los atributos implícitos) que hay que complementar.

Antes de avanzar deberías poder: tomar una lista de metas con 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; recalcular el ranking cuando el negocio cambia los pesos; y detectar qué atributos compiten y cuál conflicto pesa más —sin pretender resolverlo aquí—.

Lo que sigue es un problema que el ranking deja abierto: "scalability alta" todavía es un deseo, no un requisito. Un atributo priorizado te dice qué optimizar, pero no cuánto ni cómo sabrás si lo lograste. "Alta disponibilidad" no se puede diseñar ni probar hasta que alguien diga "99.95% de los pedidos completados en menos de 5 segundos durante el pico de Black Friday". En la lección 3 vas a aprender el quality attribute scenario de seis partes —source, stimulus, artifact, environment, response, response measure— que toma un atributo vago y lo vuelve concreto y medible. Vas a ejecutar una validación que separa los scenarios listos para diseñar de los que siguen siendo deseos disfrazados —y la regla dura que gobierna todo: si no tiene una medida, no es un requisito—.

Recursos

← Anterior1. Presentación del módulo: del deseo del negocio al atributo de calidadSiguiente →3. El escenario de atributo de calidad: volver medible lo vago