Módulo 5: Stakeholders y atributos de calidad

6. Hablar el idioma del stakeholder

Siguiente →

Descripción

Al terminar esta lección vas a saber hacer la traducción que decide si tu arquitectura llega a existir: convertir un trade-off técnico en su consecuencia de negocio, dicha en el idioma de quien firma el presupuesto. En las lecciones anteriores hiciste todo el trabajo del lado del arquitecto —traducir metas a atributos (2), volverlos medibles (3), filtrar los que importan (4), descubrir los implícitos (5)—. Pero ese trabajo no vale nada si, cuando te sientas frente al VP de finanzas y te pregunta "¿por qué necesitamos gastar tanto en disponibilidad?", le respondes "porque necesitamos 99.99% con replicación multi-región activa-activa". Acabas de perder la conversación, no porque tu argumento sea malo, sino porque lo dijiste en un idioma que tu interlocutor no habla. El VP no piensa en nueves; piensa en dólares, riesgo y tiempo. La habilidad de esta lección es traducir de vuelta: "99.99% de disponibilidad" no le dice nada, pero "cada hora que estemos caídos en Black Friday son X dólares de venta que se van y no vuelven, y esta inversión es el seguro que lo evita" le dice todo. Vas a ejecutar la tabla que hace esa traducción para la disponibilidad —cada nivel de nueves convertido en minutos caídos al año, en ventas perdidas, y en costo de infraestructura—, y vas a ver la frase del módulo hecha número: más disponibilidad = más dinero, en los dos sentidos (más disponibilidad protege más venta, y cuesta más infra).

Esto importa porque es la mitad del oficio que los arquitectos técnicamente brillantes más descuidan, y la que más los limita. Un arquitecto puede tener el mejor diseño del mundo, perfectamente derivado de las metas, medido, priorizado —y verlo morir en una junta porque no supo explicárselo a quien decide—. La arquitectura no la aprueba un comité de arquitectos; la aprueba gente de negocio que controla el presupuesto y las prioridades, y que evalúa tu propuesta con la única vara que conoce: ¿cuánto cuesta, qué riesgo cubre, cuánto tarda? El arquitecto que solo habla en atributos técnicos deja esa evaluación en manos del stakeholder sin darle las herramientas para hacerla bien —y un stakeholder que no entiende tiende a recortar lo que no comprende—. El arquitecto que traduce el trade-off a dinero y riesgo le entrega al stakeholder exactamente lo que necesita para decidir, y —crucial— deja la decisión en sus manos, que es donde pertenece: el arquitecto no decide cuánto vale la pena gastar en disponibilidad; presenta el trade-off en términos que el negocio entiende, y el negocio decide. Hablar el idioma del stakeholder no es manipulación ni "vender"; es hacer posible que la persona correcta tome la decisión correcta con la información correcta.

Conexión con el módulo: esta lección cierra la doble dirección que la lección 1 anunció. Las lecciones 2 a 5 fueron la primera dirección: traducir el negocio a atributos para poder diseñar. Esta es la segunda: traducir los trade-offs de vuelta al negocio para poder acordar. Usa todo lo anterior como insumo —el ranking de la lección 2 dice qué atributos importan; los scenarios de la 3 dan los números (99.95%, menos de 5 segundos) que aquí traduces a dinero; los conflictos que detectaste (scalability vs cost) son justo los que tienes que explicar—. Y prepara la lección 7: una vez que sabes poner cada atributo en dinero, puedes mostrar por qué "todo al máximo" es imposible dentro de un presupuesto, que es el "saber decir no". La frontera se mantiene con firmeza: aquí aprendes a comunicar el trade-off en el idioma del negocio; cómo se decide cuál nivel elegir —la matriz, el ADR— es el método de architecture-decisions, y de hecho esta traducción es el insumo que hace esa decisión posible, porque pone las opciones en términos comparables para quien decide.

El agente inmobiliario que traduce "cimientos reforzados" a "dormir tranquilo"

Piénsalo con quien vende la casa, no con quien la construye. Un ingeniero estructural le explica a una familia que quiere comprar: "esta casa tiene cimientos de losa de cimentación con refuerzo sísmico de acero grado 60, muros de carga con confinamiento y una relación de esbeltez conservadora". Todo cierto, todo excelente ingeniería —y la familia no entendió nada—. Asienten con cara de póker, sienten que les están vendiendo algo caro que no comprenden, y su instinto es desconfiar o pedir descuento. Ahora entra un buen agente inmobiliario y traduce lo mismo: "esta casa está construida para aguantar un temblor fuerte sin agrietarse; en la zona sísmica en la que van a vivir, con sus hijos, eso significa que pueden dormir tranquilos y que la casa va a valer más cuando la quieran vender, porque no va a tener los daños que tendrán las de al lado". La familia entendió perfectamente. No aprendió qué es el acero grado 60 —no le hace falta—; entendió lo que significa para ellos: seguridad de su familia y valor de su inversión. El agente no mintió ni infló: tradujo una propiedad técnica (refuerzo sísmico) a la consecuencia que le importa al comprador (tranquilidad + valor de reventa).

Fíjate en lo que hizo el agente, porque es exactamente el oficio de esta lección. Tomó un atributo técnico que el comprador no puede evaluar (¿el refuerzo sísmico vale su costo? el comprador no tiene forma de saberlo) y lo convirtió en una consecuencia que el comprador sí puede evaluar (¿vale la pena la tranquilidad de mi familia y un mejor valor de reventa? eso sí lo puedo sopesar). Y al hacerlo, le devolvió al comprador el poder de decidir bien: ahora la familia puede comparar el sobreprecio del refuerzo contra el valor que le da, y decidir. El ingeniero, con toda su razón técnica, había dejado a la familia sin poder decidir —solo con la sensación de que le vendían algo caro—. El arquitecto de software es ese agente inmobiliario cuando se sienta frente al negocio: su trabajo no es impresionar con la ingeniería (eso aleja a quien decide), sino traducir cada atributo y cada trade-off a la consecuencia que el stakeholder puede sopesar —dinero, riesgo, tiempo—, y así ponerlo en posición de decidir bien. El que habla en "acero grado 60" pierde; el que traduce a "dormir tranquilo" gana, y hace ganar a quien lo escucha.

Ejemplo trabajado: los nueves traducidos a dinero

Vamos a ejecutar la traducción para el atributo estrella de estas conversaciones: la disponibilidad. El VP habla de "no caernos"; el arquitecto habla de "nueves" (99%, 99.9%, 99.99%). La tabla que sigue traduce cada nivel de nueves a las tres cosas que el VP sí entiende: cuántos minutos al año estaría caído el sistema, cuánta venta se pierde en ese tiempo (a una facturación fija por minuto), y cuánto cuesta la infraestructura para lograr ese nivel (relativa al nivel base). Los datos son fijos: Mercado factura 1200 USD por minuto, y cada nivel tiene un costo de infra relativo conocido.

# El idioma del stakeholder no es "availability", es DINERO. Traducimos cada
# nivel de disponibilidad a lo que el VP entiende: minutos caidos al ano y
# ventas perdidas. Asi "mas 9s" se vuelve "mas dinero" -- en los dos sentidos.

MINUTES_PER_YEAR = 365 * 24 * 60          # 525600
revenue_per_minute = 1200                 # USD/min que factura Mercado (dato fijo)

# Nivel de disponibilidad -> costo de infra RELATIVO para lograrlo (dato fijo).
levels = [
    # etiqueta,  uptime,    costo de infra relativo
    ("99%",      0.99,       1.0),
    ("99.9%",    0.999,      2.5),
    ("99.99%",   0.9999,     6.0),
    ("99.999%",  0.99999,   15.0),
]

print(f"{'nivel':<10}{'caida/ano':>14}{'venta perdida/ano':>21}{'infra':>8}")
rows = []
for label, uptime, infra_cost in levels:
    downtime_min = MINUTES_PER_YEAR * (1 - uptime)
    lost = downtime_min * revenue_per_minute
    rows.append((label, downtime_min, lost, infra_cost))
    print(f"{label:<10}{downtime_min:>10.0f} min{lost:>17,.0f} USD{infra_cost:>7.1f}x")

print()
print("Lo que oye el VP -- el margen de cada '9' extra:")
for i in range(1, len(rows)):
    label = rows[i][0]
    saved = rows[i - 1][2] - rows[i][2]
    infra = rows[i][3]
    print(f"  pasar a {label:<9}: evita {saved:>12,.0f} USD/ano de venta  (infra {infra:.1f}x)")

print()
print("Cada '9' extra evita MENOS venta y cuesta MAS infra. Hay un punto donde")
print("el siguiente 9 ya no se paga solo: ahi es donde el arquitecto dice basta.")

Qué esperar. Al correrlo:

nivel          caida/ano    venta perdida/ano   infra
99%             5256 min        6,307,200 USD    1.0x
99.9%            526 min          630,720 USD    2.5x
99.99%            53 min           63,072 USD    6.0x
99.999%            5 min            6,307 USD   15.0x

Lo que oye el VP -- el margen de cada '9' extra:
  pasar a 99.9%    : evita    5,676,480 USD/ano de venta  (infra 2.5x)
  pasar a 99.99%   : evita      567,648 USD/ano de venta  (infra 6.0x)
  pasar a 99.999%  : evita       56,765 USD/ano de venta  (infra 15.0x)

Cada '9' extra evita MENOS venta y cuesta MAS infra. Hay un punto donde
el siguiente 9 ya no se paga solo: ahi es donde el arquitecto dice basta.

Mira primero la tabla de arriba, y date cuenta de lo que acaba de pasar: un atributo técnico se volvió una columna de dólares. "99%" no le dice nada al VP; "5,256 minutos caídos al año —casi cuatro días— y 6.3 millones de dólares de venta perdida" le dice todo. La disponibilidad dejó de ser un concepto de ingeniería y se volvió una cifra en el idioma en el que el VP piensa. Y fíjate en la fuerza del contraste entre renglones: pasar de 99% a 99.9% recorta la caída de casi cuatro días (5,256 minutos) a menos de nueve horas (526 minutos). Para un negocio que factura 1200 USD por minuto, esa es la diferencia entre perder 6.3 millones y perder 630 mil. Ese es el argumento —no "necesitamos un noveno más", sino "el primer noveno extra nos ahorra 5.7 millones de dólares al año"—. El VP no necesita entender replicación para aprobar eso; necesita comparar 5.7 millones ahorrados contra el costo de 2.5x la infra, y esa comparación la sabe hacer con los ojos cerrados.

Ahora la segunda tabla, la de los márgenes, que es donde la traducción se vuelve sabiduría y no solo comunicación. Fíjate en el patrón brutal: cada noveno extra evita cada vez menos venta. El primer salto (a 99.9%) evita 5.7 millones. El segundo (a 99.99%) evita 568 mil —diez veces menos—. El tercero (a 99.999%) evita 57 mil —otra vez diez veces menos—. Y al mismo tiempo, la columna de infra muestra que cada noveno cuesta cada vez más: 2.5x, 6x, 15x. Los dos efectos van en direcciones opuestas y se cruzan: llega un punto donde el siguiente noveno evita tan poca venta y cuesta tanta infra que ya no se paga solo. Para Mercado, con estos números, saltar a 99.9% es una obviedad (evita 5.7 millones por 2.5x de infra); saltar a 99.999% es probablemente absurdo (evita 57 mil y cuesta 15x —seguramente mucho más de 57 mil al año—). El arquitecto que domina esta tabla no llega a la junta a pedir "el máximo de disponibilidad"; llega a decir "el punto óptimo para nosotros es 99.9% o quizás 99.99%, y aquí está el número que lo dice —más allá de eso, estaríamos pagando millones por evitar miles—". Eso es "más disponibilidad = más dinero" entendido de verdad: no como eslogan, sino como una curva de rendimientos decrecientes que dice hasta dónde subir.

Un matiz honesto, y es importante para no usar esta tabla como una calculadora ingenua. El modelo asume que toda la caída se traduce en venta perdida a una tasa constante —lo cual simplifica de más—. En la realidad: parte de la venta perdida durante una caída se recupera después (el cliente vuelve más tarde); las caídas no son uniformes (una caída de 5 minutos en Black Friday cuesta muchísimo más que 5 minutos un martes a las 4am); y hay costos que la tabla no captura (una caída daña la reputación y la confianza, no solo la venta de ese rato). Entonces, ¿la tabla miente? No —hace algo más útil que ser exacta: vuelve el trade-off discutible en el idioma correcto—. El VP puede mirar el "6.3 millones" y decir "eso está inflado, la mitad de esa venta la recuperamos después", y esa es exactamente la conversación que quieres tener —una sobre dinero y supuestos de negocio, que el VP domina, en vez de una sobre nueves, que no domina—. La tabla no pretende dar la cifra exacta de venta perdida; pretende poner el trade-off sobre la mesa en dólares para que el negocio lo ajuste con su conocimiento y decida. Un número discutible en el idioma del negocio es infinitamente más útil que un "99.99%" perfecto que el VP no puede evaluar.

Profundización: el elevador del arquitecto y las tres monedas del negocio

Gregor Hohpe, en The Software Architect Elevator, tiene la mejor metáfora para lo que hace esta lección: el arquitecto es quien sube y baja en el elevador de la organización. En el penthouse está el negocio, que piensa en estrategia, mercado, dinero y riesgo. En el sótano está la ingeniería, que piensa en servicios, latencia, colas y despliegues. La mayoría de la gente vive en un solo piso: los ejecutivos nunca bajan al sótano, los ingenieros nunca suben al penthouse. El arquitecto es raro y valioso precisamente porque viaja entre los pisos: entiende lo bastante del negocio para hablar en el penthouse y lo bastante de la ingeniería para hablar en el sótano, y su trabajo es llevar información de un piso a otro traducida. Baja la estrategia del negocio y la convierte en atributos para la ingeniería (lecciones 2-5); sube los trade-offs de la ingeniería y los convierte en dinero y riesgo para el negocio (esta lección). Un arquitecto que solo sabe hablar en el sótano no sirve en el penthouse, y viceversa. La habilidad completa es el viaje en las dos direcciones —y esta lección es el viaje de subida, el más descuidado—.

Para traducir bien hacia arriba, ayuda saber que el negocio maneja esencialmente tres monedas, y todo atributo técnico se cambia por una de ellas:

Dinero. La moneda universal del negocio. Casi cualquier atributo se puede traducir a dinero: la disponibilidad, a venta protegida (la tabla que ejecutaste); la escalabilidad, al costo de crecer o al costo de no poder crecer (venta que no capturas porque el sistema no aguanta); el rendimiento, a conversión (cada segundo de latencia en el checkout es un porcentaje de carritos abandonados, que es dinero); el costo de infra, obviamente, a dinero directo. Cuando puedas poner un atributo en dólares, hazlo: es la moneda que el negocio entiende sin esfuerzo.

Riesgo. Cuando algo no se puede poner en dinero directo, se pone en riesgo —la probabilidad y la magnitud de una catástrofe—. La seguridad rara vez se traduce a "genera X dólares"; se traduce a "evita el riesgo de una fuga que costaría multas, demandas y reputación". La auditabilidad (lección 5) se vende en riesgo: "el día que el regulador pregunte y no tengamos el rastro, es una multa". El riesgo es la moneda de los atributos que previenen desastres en vez de generar ingresos. El truco es cuantificar el riesgo tanto como se pueda: no "es riesgoso", sino "una fuga de datos de pago en nuestra escala son, mirando casos comparables, entre X y Y millones más la pérdida de confianza".

Tiempo. La tercera moneda, y la que conecta con la deuda técnica. El tiempo se traduce en time-to-market (lanzar antes que la competencia vale dinero) y en velocidad futura (una arquitectura mantenible te deja construir más rápido después). Aquí es donde el arquitecto explica el trade-off del atajo: "podemos lanzar esto en la mitad del tiempo tomando este atajo, pero es una deuda —cada feature futuro sobre esta base va a costar un 30% más hasta que la paguemos—". El VP entiende perfectamente "más rápido ahora, más lento después", porque es un trade-off de tiempo, que es una moneda de negocio. Nombrar la deuda en tiempo (no en "código feo") es lo que la vuelve una decisión de negocio consciente en vez de una sorpresa técnica.

Y aquí está el principio que amarra la profundización con la frontera del módulo: traducir el trade-off al idioma del negocio no es tomar la decisión —es hacer que el negocio pueda tomarla—. Cuando pones "99.9% evita 5.7 millones por 2.5x de infra", no estás decidiendo el nivel de disponibilidad; estás poniendo el trade-off en una forma que el VP puede sopesar, y el VP decide. Ese es el respeto correcto por la frontera: el arquitecto no usurpa la decisión de negocio (cuánto vale la pena gastar es del negocio), ni la abandona (dejar que el VP decida sin entender el trade-off es negligencia). Traduce, presenta, y deja decidir. Cómo se estructura esa decisión cuando hay varios atributos en conflicto —la matriz ponderada, el ADR que la registra— es el método de architecture-decisions; pero ese método solo funciona si las opciones están expresadas en términos que el que decide entiende, y ponerlas en esos términos es, precisamente, el trabajo de esta lección. Eres el traductor que hace la decisión posible, no el que la toma.

Errores comunes

Hablar en jerga técnica al que no la habla (de monolingüismo). Qué pasa: el arquitecto le explica al VP "necesitamos consistencia eventual, sharding por tenant y replicación multi-región", y el VP asiente sin entender y decide por instinto —normalmente recortar lo que no comprende—. Por qué pasa: el arquitecto vive en el idioma técnico y no registra que su interlocutor no lo habla; además, la jerga da una falsa sensación de rigor. Cómo detectarlo: si tu explicación al negocio incluye términos que un VP de producto no usaría en una frase, estás hablando el idioma equivocado. Cómo corregirlo: antes de cada conversación con un stakeholder no técnico, traduce cada atributo a su moneda de negocio (dinero, riesgo, tiempo) y habla solo en esa moneda —guarda la jerga para el sótano—.

No decir el costo del trade-off (de omisión). Qué pasa: el arquitecto propone la solución "buena" (99.99%, todo redundante) sin mostrar qué cuesta ni qué alternativa más barata existe, así que el negocio no puede sopesar —solo ve una cifra grande sin contexto—. O al revés: acepta un atajo sin nombrar su costo futuro, y la deuda estalla después sin que nadie la haya decidido. Por qué pasa: mostrar el costo se siente como debilitar la propuesta, y nombrar la deuda de un atajo se siente como aguar la fiesta del lanzamiento rápido. Cómo detectarlo: si tu propuesta no incluye "esto cuesta X y la alternativa cuesta Y", no diste el trade-off, diste una orden. Cómo corregirlo: presenta siempre el trade-off completo —qué ganas, qué cuestas, qué alternativa hay— en las tres monedas; la tabla de nueves es el modelo: no "pongamos 99.99%", sino "aquí está lo que cada nivel cuesta y evita, decidan".

Usurpar la decisión de negocio disfrazándola de técnica (de extralimitación). Qué pasa: el arquitecto decide él solo que Mercado tendrá 99.99% de disponibilidad "porque es lo correcto técnicamente", sin presentarle al negocio el trade-off en dinero para que decida. Cuando la factura llega, el negocio se siente pasado por encima —y con razón: cuánto gastar en disponibilidad es una decisión de negocio que el arquitecto tomó sin permiso—. Por qué pasa: es más rápido decidir uno mismo que traducir y esperar, y el arquitecto confunde "yo sé cuál es el mejor nivel técnico" con "yo debo decidir el nivel". Cómo detectarlo: si decidiste un nivel de calidad que cuesta dinero significativo sin que el negocio haya visto y aprobado el trade-off, te extralimitaste. Cómo corregirlo: traduce, presenta las opciones en dinero/riesgo/tiempo, y deja que el negocio elija —tu trabajo es hacer la decisión posible y bien informada, no tomarla en su lugar—.

Ejercicios

Ejercicio 1 — Traduce el atributo a su moneda. Para cada uno de estos atributos, di en cuál de las tres monedas del negocio (dinero, riesgo, tiempo) lo traducirías principalmente, y escribe una frase que se lo explique a un VP no técnico: (a) rendimiento del checkout (latencia); (b) seguridad de los datos de pago; (c) mantenibilidad del código.

Ver solución

(a) Rendimiento del checkout → dinero (vía conversión). "Cada segundo extra que tarda el checkout, un porcentaje de la gente abandona el carrito. Bajar la latencia de 4 a 1 segundo puede recuperar, digamos, un 5% de las compras que hoy se pierden en la espera —a nuestro volumen, eso son X dólares al mes—." (El rendimiento se traduce a dinero a través de la conversión: latencia → carritos abandonados → venta perdida.)

(b) Seguridad de los datos de pago → riesgo. "No es que la seguridad genere ventas; es que una fuga de datos de tarjeta nos costaría multas por incumplir PCI-DSS, probables demandas, y —lo más caro— la pérdida de confianza de los clientes, que en un negocio de pagos es casi imposible de recuperar. Esta inversión es el seguro contra un evento que, mirando casos comparables, costaría millones." (La seguridad casi siempre se vende en riesgo: previene un desastre, no genera ingreso.)

(c) Mantenibilidad del código → tiempo. "Un código bien estructurado significa que cada feature nuevo lo construimos más rápido. Si tomamos atajos ahora para lanzar antes, ganamos unas semanas hoy pero cada cosa que hagamos después sobre esa base va a costar más —es una deuda que pagamos con velocidad futura—. La pregunta es cuánto vale para ustedes lanzar antes contra ir más lento después." (La mantenibilidad se traduce a tiempo: velocidad de desarrollo futura, time-to-market.)

La lección: cada atributo tiene una moneda "natural" en la que se explica mejor. Elegir la moneda correcta es la mitad de la traducción; la otra mitad es cuantificar tanto como se pueda dentro de esa moneda.

Ejercicio 2 — Encuentra el punto óptimo. Usando la tabla ejecutada, un compañero argumenta: "si 99.9% es bueno, 99.999% es mejor; pidamos siempre el máximo de nueves". Con los números de la tabla, explícale por qué está equivocado, y cómo le explicarías al VP dónde está el punto donde conviene parar.

Ver solución

Por qué está equivocado: porque ignora que los dos lados del trade-off van en direcciones opuestas. Cada noveno extra evita cada vez menos venta (rendimientos decrecientes) y cuesta cada vez más infra (costos crecientes). De la tabla:

  • Pasar a 99.9% evita 5,676,480 USD/año y cuesta 2.5x. Un negocio redondo: ahorras millones por multiplicar por 2.5 la infra.
  • Pasar a 99.99% evita 567,648 USD/año más y cuesta 6x. Todavía puede valer la pena, depende de cuánto sea "6x la infra" en dólares.
  • Pasar a 99.999% evita solo 56,765 USD/año más y cuesta 15x. Casi con seguridad no vale la pena: estás pagando 15x la infra (probablemente cientos de miles o millones al año) para evitar 57 mil dólares de venta. Pagas millones para ahorrar miles.

"Siempre el máximo" ignora que el último noveno es carísimo y evita poquísimo. El máximo no es el óptimo.

Cómo se lo explicarías al VP: "Cada noveno extra de disponibilidad nos protege menos venta que el anterior, pero cuesta más. El primer salto (a 99.9%) es obvio: nos ahorra 5.7 millones al año por 2.5 veces la infra. El segundo (a 99.99%) todavía puede convenir. Pero el tercero (a 99.999%) nos costaría 15 veces la infra para evitar apenas 57 mil dólares de venta al año —pagaríamos millones para ahorrar miles—. Mi recomendación es 99.9% (o 99.99% si quieren el colchón extra), y aquí está el número que dice por qué más allá de eso estaríamos quemando dinero." El punto óptimo es donde el ahorro marginal del siguiente noveno deja de superar su costo marginal —y la tabla lo hace visible—. (Cómo se formaliza esa decisión de "cuál nivel elegir" cuando entran más factores es el método de architecture-decisions; aquí lo que hiciste fue ponerla en términos que el VP puede decidir.)

Ejercicio 3 — Reescribe la respuesta que perdió la junta. Un arquitecto le respondió al VP de finanzas, que preguntaba por qué el proyecto era caro: "porque necesitamos consistencia fuerte en las transacciones de pago, idempotencia en los reintentos, y un sistema de doble escritura con outbox para no perder eventos". El VP recortó el presupuesto. Diagnostica por qué esa respuesta falló y reescríbela en el idioma del negocio.

Ver solución

Por qué falló: la respuesta está en el idioma del sótano —"consistencia fuerte", "idempotencia", "doble escritura con outbox"— frente a alguien que vive en el penthouse. El VP de finanzas no tiene forma de evaluar si "idempotencia en los reintentos" vale su costo, así que oye "palabras técnicas caras que no entiendo" y hace lo único que sabe hacer con lo que no comprende: recortarlo. El arquitecto tenía razón técnica (esas cosas son necesarias para no perder ni duplicar pagos) pero la comunicó en un idioma que garantizaba el rechazo. No perdió por estar equivocado; perdió por ser incomprensible.

Reescrita en el idioma del negocio (moneda: riesgo + dinero): "El costo que ves está protegiendo algo muy concreto: que nunca cobremos dos veces a un cliente ni perdamos un pago a la mitad de una transacción. En un negocio que mueve dinero, cobrar dos veces significa reembolsos, disputas con el banco, clientes furiosos que se van, y en volumen, un golpe real a los ingresos y a la confianza. Perder un pago significa que vendimos algo y no cobramos —dinero que se evapora—. La parte 'cara' del proyecto es, en el fondo, la maquinaria que garantiza que cada peso que un cliente paga se cobre exactamente una vez, ni cero ni dos. Puedo mostrarte, si quieres, cuánto nos costaría un mes de errores de cobro sin esa maquinaria, para comparar contra lo que cuesta construirla —y verás que es mucho más barato construirla que vivir sin ella—."

Por qué funciona: traduce cada término técnico a su consecuencia de negocio (consistencia + idempotencia → "nunca cobrar dos veces ni perder un pago"), la pone en las monedas correctas (riesgo de reembolsos/disputas/fuga de clientes, y dinero de pagos perdidos), y ofrece cuantificar el riesgo para que el VP compare —dejándole la decisión con la información correcta—. Misma verdad técnica, idioma opuesto, resultado opuesto.

Resumen y siguiente paso

En esta lección aprendiste la segunda dirección de la traducción del módulo: convertir un trade-off técnico en su consecuencia de negocio, en el idioma de quien decide. Con el agente inmobiliario que traduce "cimientos reforzados" a "dormir tranquilo" viste que impresionar con la ingeniería aleja a quien decide, mientras que traducir a la consecuencia que puede sopesar lo pone en posición de decidir bien. Lo mediste ejecutando: la tabla que convierte cada nivel de disponibilidad en minutos caídos, en venta perdida y en costo de infra —"más disponibilidad = más dinero" hecho número—, y los márgenes que revelan que cada noveno extra evita menos y cuesta más, hasta un punto donde ya no se paga solo. Conociste el elevador de Hohpe (el arquitecto viaja entre el penthouse del negocio y el sótano de la ingeniería) y las tres monedas del negocio (dinero, riesgo, tiempo), y el principio que las gobierna: traducir el trade-off no es tomar la decisión, es hacer que el negocio pueda tomarla —ni usurparla ni abandonarla—.

Antes de avanzar deberías poder: traducir cualquier atributo a su moneda de negocio (dinero, riesgo o tiempo) y explicarlo sin jerga; leer una tabla de trade-off para encontrar el punto de rendimientos decrecientes donde conviene parar; presentar siempre el costo y la alternativa, no solo la solución; y respetar la frontera —traducir y presentar, dejar que el negocio decida—.

Lo que sigue es la conversación más difícil de todas, y la que separa a un arquitecto maduro de uno que quiere caer bien: saber decir no. Ya sabes poner cada atributo en dinero. La consecuencia inevitable es que no se puede tener todo al máximo —el presupuesto no alcanza, y algunos atributos se pelean entre sí—. Cuando el stakeholder pide "lo quiero todo: máxima disponibilidad, máxima seguridad, máximo rendimiento, mínimo costo", el arquitecto tiene que saber responder. En la lección 7 vas a ejecutar la demostración de que "todo al máximo" rebasa cualquier presupuesto, y vas a aprender que el "no" del arquitecto no es "no se puede" sino "esto es lo que sí cabe, priorizado por el valor de negocio" —el "sí, pero cuesta esto" que convierte un deseo imposible en una decisión responsable—.

Recursos

← Anterior5. Los atributos implícitos que nadie pidióSiguiente →7. Saber decir no (y el costo del sí)