7. Saber decir no (y el costo del sí)

Descripción

Al terminar esta lección vas a saber dar la respuesta más difícil del oficio —y la que más distingue a un arquitecto maduro de uno que quiere caer bien—: decir no, o su versión más honesta, "sí, pero cuesta esto". Toda la maquinaria de las lecciones anteriores conduce aquí. Tradujiste las metas a atributos (2), los volviste medibles (3), filtraste los que importan (4), descubriste los implícitos (5), y aprendiste a poner cada uno en dinero (6). La consecuencia inevitable de todo eso es una verdad incómoda que el stakeholder no quiere oír: no se puede tener todo al máximo. El presupuesto no alcanza, y además algunos atributos se pelean entre sí —maximizar la seguridad frena el rendimiento; maximizar la disponibilidad dispara el costo—. Cuando el VP dice "lo quiero todo: máxima disponibilidad, máxima seguridad, máximo rendimiento, y que sea barato", está pidiendo algo que no existe, y el arquitecto que dice "claro, lo intentamos" está mintiendo —una mentira cara que se cobra en seis meses—. Vas a ejecutar la demostración de que "todo al nivel 5" rebasa cualquier presupuesto razonable (cuesta 125 puntos cuando hay 60), y de cómo una priorización realista —usando el ranking de la lección 2— sí cabe. El "no" del arquitecto no es "no se puede"; es "esto es lo que sí cabe, priorizado por el valor de negocio, y esto es lo que cuesta cada nivel extra".

Esto importa porque el "no" bien dado es un acto de servicio, y el "sí" a todo es una traición disfrazada de amabilidad. El arquitecto que promete todos los atributos al máximo para no decepcionar al stakeholder no lo está ayudando: lo está condenando a descubrir, cuando ya es tarde, que el sistema no puede ser máximamente seguro y máximamente rápido y máximamente barato a la vez —y para entonces se gastó el presupuesto persiguiendo un imposible en vez de invertirlo donde importaba—. Decir "sí" a todo se siente colaborativo en la junta y es devastador en la ejecución. Decir "no puedo darte todo al máximo, pero puedo darte esto, que es lo que tu negocio de verdad necesita, y aquí está el costo de cada cosa que agreguemos" se siente incómodo en la junta y es un regalo en la ejecución: le da al stakeholder una decisión real —con trade-offs reales— en vez de una fantasía. El arquitecto administra un presupuesto de calidad que es finito, igual que finanzas administra uno de dinero; y su trabajo, como el de un buen asesor financiero, no es decir "sí" a cada gasto sino ayudar a gastar el presupuesto donde rinde más. El "no" es la herramienta que hace posible ese servicio.

Conexión con el módulo: esta lección es la culminación de todo el arco. Usa el ranking de la lección 2 (para saber qué priorizar cuando no cabe todo), los scenarios de la 3 (los niveles concretos que se recortan o se mantienen), la detección de conflictos de la 2 (los atributos que además de caros se pelean), y la traducción a dinero de la 6 (para decir el costo de cada nivel en el idioma del negocio). Es donde todo se junta en la conversación final: no "¿qué atributos necesitamos?" sino "dado que no cabe todo, ¿qué priorizamos y qué difieres, y a qué costo?". La frontera se mantiene, y aquí es más delicada que nunca: esta lección te enseña a comunicar que hay que elegir y a presentar el trade-off del presupuesto; el método riguroso para hacer la elección —cómo se pondera, cómo se decide entre 99.9% y 99.99%, cómo se documenta en un ADR— es la guía architecture-decisions. Aquí dices "hay que elegir, y esto es lo que cuesta cada opción"; allá está el método de cómo se elige.

El presupuesto de la remodelación que no alcanza para todo

Piénsalo con la pareja que remodela su casa, ahora con el sobre del dinero sobre la mesa. Llegan con la lista completa de sus sueños: cocina de chef con todo importado, alberca climatizada, paneles solares, un cuarto de cine, acabados de lujo en todos los baños, jardín paisajista, y un sistema de domótica que controle todo desde el celular. El arquitecto suma los costos y hace lo que ningún vendedor complaciente haría: les dice la verdad. "Todo esto cuesta tres veces su presupuesto. No cabe. Y hay algo más: algunas de estas cosas se pelean entre sí —la alberca climatizada y los paneles solares compiten por el mismo espacio de azotea con buena orientación; no pueden tener las dos al máximo—." La pareja se queda callada, incómoda. Entonces el buen arquitecto hace la segunda mitad de su trabajo, la que justifica su honorario: "Pero no vine a decirles que no se puede. Vine a ayudarles a decidir. Díganme qué les importa más —¿la cocina, porque cocinan todos los días, o el cuarto de cine, que usarían de vez en cuando?—. Con su presupuesto, alcanza para la cocina de chef, dos baños de lujo (no los cuatro), los paneles solares, y un jardín sencillo. La alberca y el cuarto de cine los dejamos preparados para una fase dos, cuando puedan. Aquí está exactamente qué entra, qué se difiere, y cuánto costaría agregar cada cosa que dejamos fuera."

Fíjate en las dos mitades, porque son las dos mitades de esta lección. La primera es el no honesto: "no cabe todo, y algunas cosas se pelean". Un arquitecto complaciente se la salta —dice "sí, vemos cómo le hacemos" y empieza a construir, y a mitad de la obra se acaba el dinero con la casa a medias—. La segunda es el "esto es lo que sí cabe": no un "no" a secas que deja a la pareja sin casa, sino una priorización que convierte el presupuesto limitado en la mejor casa posible para esta pareja (la que cocina, así que la cocina gana). El malo dice "sí" a todo y entrega un desastre a medias. El pésimo dice "no" a secas y no ayuda. El bueno dice "no a todo al máximo, pero sí a esto —lo que más te sirve—, y aquí está el costo de cada cosa que quieras sumar". El arquitecto de software hace exactamente esto con el presupuesto de calidad: no puede maximizar todos los atributos, así que dice la verdad sobre el límite y propone la priorización que da el mayor valor de negocio con lo que hay —dejando explícito qué se difiere y qué costaría agregarlo—.

Ejemplo trabajado: "todo al máximo" contra el presupuesto

Vamos a ejecutar la demostración. Cada atributo se puede llevar a un nivel de 1 (mínimo) a 5 (excelencia), y llevarlo a un nivel más alto cuesta —el costo crece cuadráticamente, porque subir el último escalón de calidad es mucho más caro que el primero (llevar la disponibilidad de 99.9% a 99.99% cuesta más que de 99% a 99.9%, como viste en la lección 6)—. El presupuesto de arquitectura es finito: 60 puntos de esfuerzo este año. Comparamos dos escenarios: el pedido del stakeholder (todos los atributos al nivel 5) contra la propuesta priorizada del arquitecto (niveles según el ranking de la lección 2).

# "Lo quiero TODO al maximo": el pedido imposible. Cada atributo tiene un costo
# que crece rapido con el nivel exigido, y el presupuesto de arquitectura no es
# infinito. Mostramos que prometer todo al 5 es imposible, y como una
# priorizacion realista (la de la leccion 2) si cabe.

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

# Costo (en "puntos de esfuerzo") de llevar un atributo al nivel n (1..5).
# Crece cuadraticamente: subir el ultimo escalon cuesta muchisimo mas que el primero.
def cost_of_level(n):
    return n * n            # nivel 1->1, 2->4, 3->9, 4->16, 5->25

BUDGET = 60                 # puntos de esfuerzo disponibles este ano (dato fijo)

# Pedido del stakeholder: TODO al maximo.
everything_max = {a: 5 for a in attributes}
cost_max = sum(cost_of_level(l) for l in everything_max.values())

# Propuesta del arquitecto: niveles segun la prioridad medida en la leccion 2.
prioritized = {
    "scalability":     5,   # el #1: se lleva la excelencia
    "security":        4,   # muy alto
    "availability":    3,   # bueno
    "performance":     2,   # suficiente
    "cost_efficiency": 1,   # lo minimo por ahora
}
cost_prioritized = sum(cost_of_level(l) for l in prioritized.values())

print(f"Presupuesto de arquitectura este ano: {BUDGET} puntos de esfuerzo")
print()
print("Pedido del stakeholder -- TODO al nivel 5:")
print(f"  costo = 5 atributos x {cost_of_level(5)} = {cost_max} puntos  ->",
      "IMPOSIBLE" if cost_max > BUDGET else "cabe")
print(f"  excede el presupuesto por {cost_max - BUDGET} puntos ({cost_max / BUDGET:.2f}x).")
print()
print("Propuesta priorizada del arquitecto:")
for a in attributes:
    print(f"  {a:<16} nivel {prioritized[a]}  -> {cost_of_level(prioritized[a]):>2} puntos")
print(f"  costo total = {cost_prioritized} puntos  ->",
      "cabe" if cost_prioritized <= BUDGET else "NO cabe",
      f"(margen: {BUDGET - cost_prioritized})")
print()
print(f"El 'no' del arquitecto no es 'no se puede'. Es: 'todo al 5 cuesta {cost_max};")
print(f"tenemos {BUDGET}. Esto es lo que SI cabe, priorizado por el valor de negocio.'")

Qué esperar. Al correrlo:

Presupuesto de arquitectura este ano: 60 puntos de esfuerzo

Pedido del stakeholder -- TODO al nivel 5:
  costo = 5 atributos x 25 = 125 puntos  -> IMPOSIBLE
  excede el presupuesto por 65 puntos (2.08x).

Propuesta priorizada del arquitecto:
  scalability      nivel 5  -> 25 puntos
  security         nivel 4  -> 16 puntos
  availability     nivel 3  ->  9 puntos
  performance      nivel 2  ->  4 puntos
  cost_efficiency  nivel 1  ->  1 puntos
  costo total = 55 puntos  -> cabe (margen: 5)

El 'no' del arquitecto no es 'no se puede'. Es: 'todo al 5 cuesta 125;
tenemos 60. Esto es lo que SI cabe, priorizado por el valor de negocio.'

Mira primero el pedido del stakeholder: todo al nivel 5 cuesta 125 puntos, y hay 60 —lo rebasa por más del doble—. Ese número, 125 contra 60, es toda la lección en una comparación. "Lo quiero todo al máximo" no es una petición ambiciosa que con esfuerzo se podría lograr; es una imposibilidad aritmética. Y fíjate por qué es tan caro: como el costo crece cuadráticamente, llevar cada atributo al nivel 5 cuesta 25 puntos —el escalón más caro de todos—, y cinco atributos a 25 son 125. La cuadratura es la culpable: el nivel 5 no cuesta "un poco más" que el 4, cuesta 25 contra 16, y esa diferencia se multiplica por cada atributo. El arquitecto que promete "todo al 5" está prometiendo gastar 125 donde hay 60, y esa promesa se rompe sola —la única pregunta es si se rompe en la junta (si el arquitecto es honesto) o a mitad de la ejecución con el presupuesto agotado y el sistema mediocre en todo (si no lo es)—.

Ahora la propuesta priorizada, que es el "no" convertido en servicio. En vez de repartir el presupuesto por igual (que daría mediocridad en todo) o prometer todo al máximo (imposible), el arquitecto asigna el presupuesto según el ranking de la lección 2: scalability, que encabezaba, se lleva la excelencia (nivel 5, 25 puntos); security, segundo, va muy alto (nivel 4, 16 puntos); availability, bueno (nivel 3, 9); performance, suficiente (nivel 2, 4); y cost_efficiency, lo mínimo por ahora (nivel 1, 1 punto). Total: 55 puntos, que cabe en los 60, con 5 de margen. Fíjate en lo que esto significa: el arquitecto no dijo "no" a ningún atributo —todos están presentes, ninguno en cero—; dijo "no al máximo en todos", y repartió la excelencia donde el negocio más la valora. La casa no se quedó sin cocina ni sin baños; tiene cocina de chef (el atributo #1 al máximo) y baños decentes (los demás en su nivel justo). Eso es priorizar: no eliminar, sino dosificar la excelencia según el valor de negocio.

Detente en la última frase de la salida, porque es la definición del "no" bien dado: "todo al 5 cuesta 125; tenemos 60. Esto es lo que sí cabe, priorizado por el valor de negocio." Compara las tres formas de responder al "lo quiero todo":

• El "sí" complaciente: "claro, lo intentamos" —miente, y entrega un sistema mediocre en todo cuando el presupuesto se agota—.
• El "no" seco: "no se puede tener todo" —tiene razón, pero no ayuda; deja al stakeholder frustrado y sin plan—.
• El "no" del arquitecto: "no todo al máximo, pero sí esto —lo que tu negocio más necesita—, y aquí está lo que cuesta cada nivel extra que quieras agregar" —dice la verdad y propone el mejor uso del presupuesto y deja la decisión final en manos del negocio—.

El tercero es el único que sirve, y es el más difícil de decir porque exige incomodar al stakeholder en la junta (romperle la ilusión de "todo al máximo") a cambio de servirlo de verdad en la ejecución. El "no" del arquitecto es honesto sobre el límite, constructivo sobre la alternativa, y respetuoso de la frontera —presenta el trade-off, no usurpa la decisión—.

Un matiz honesto sobre el modelo. Los "puntos de esfuerzo", el presupuesto de 60, y el costo cuadrático son una abstracción —no existe una moneda literal de "puntos de calidad" que finanzas apruebe—. En la realidad, el presupuesto es una mezcla de dinero, tiempo de equipo y complejidad tolerable, y el "costo" de un nivel de calidad no es exactamente n². Entonces, ¿el modelo engaña? No —captura dos verdades que sí son robustas y que el arquitecto debe internalizar—. Primera: el presupuesto de calidad es finito, como cualquier presupuesto, y "todo al máximo" lo rebasa siempre. Segunda: la excelencia tiene rendimientos decrecientes y costo creciente —el último escalón de cualquier atributo es desproporcionadamente caro (lo viste literal con los nueves en la lección 6)—, así que llevar todo al máximo es la peor forma de gastar el presupuesto. El modelo no pretende darte el costo exacto en dólares; pretende hacer innegable que hay que priorizar, y darte la forma de hacerlo (asignar la excelencia según el valor de negocio). La aritmética exacta es discutible; la conclusión —hay que elegir, y elegir por valor de negocio— no lo es.

Profundización: el "sí, pero cuesta esto", la deuda nombrada, y los conflictos que ningún presupuesto arregla

El "no" tiene una versión más rica y más usada en la práctica: el "sí, pero cuesta esto". Rara vez el arquitecto dice un "no" rotundo; casi siempre dice "sí, se puede agregar ese atributo o subir ese nivel —y esto es lo que cuesta, en presupuesto, en tiempo, o en algún otro atributo que habrá que bajar—". La diferencia con el "sí" complaciente es que el "sí, pero cuesta esto" nombra el precio. Cuando el VP pide subir la disponibilidad de nivel 3 a nivel 5, el arquitecto no dice "no" ni dice "sí" a secas: dice "sí, subir availability de 3 a 5 cuesta 16 puntos más (de 9 a 25), y como el presupuesto está lleno, tendríamos que bajar algo —por ejemplo, security de 4 a 3— o ampliar el presupuesto; ¿cuál prefieres?". Eso convierte el pedido en una decisión consciente con su costo a la vista, en vez de una concesión silenciosa que se paga después. El "sí, pero cuesta esto" es el "no" en su forma más útil: no bloquea, informa el precio y devuelve la decisión.

Un caso particular del "sí, pero cuesta esto" es nombrar la deuda del atajo rápido. A veces el negocio necesita algo ya —lanzar antes que la competencia, demostrar algo a un inversionista—, y la respuesta correcta es un "sí" al atajo, pero un "sí" con la deuda nombrada. No "lo hacemos rápido" (que esconde el costo), sino "lo hacemos rápido tomando este atajo, y eso es una deuda: nos permite lanzar en la mitad del tiempo, pero cada feature que construyamos después sobre esta base va a costar más hasta que la paguemos, y pagarla nos tomará unas semanas más adelante". El atajo puede ser la decisión correcta —a veces lanzar hoy vale más que la limpieza—, pero solo si el negocio lo elige sabiendo que es deuda. El pecado no es tomar el atajo; es tomarlo sin nombrarlo, para que estalle después como una sorpresa que "los ingenieros no anticiparon". El arquitecto que dice "esto rápido tiene una deuda que pagaremos, y aquí está cuál" convierte un atajo peligroso en una decisión de negocio informada. Es la misma honestidad del costo, aplicada al tiempo en vez de al dinero.

Y hay una razón por la que "todo al máximo" es imposible que va más allá del presupuesto, y es la que amarra este módulo con la frontera: algunos atributos se pelean, así que ni con presupuesto infinito podrías tenerlos todos al máximo. Lo viste en la lección 2: security compite con performance (cifrar, validar y auditar añade latencia), availability compite con cost (la redundancia cuesta), scalability compite con cost. Estos conflictos no son un problema de dinero —son trade-offs intrínsecos—: subir la seguridad al máximo baja el rendimiento por diseño, no por falta de fondos. Así que aun si el VP dijera "toma, presupuesto ilimitado, dame todo al 5", el arquitecto tendría que responder "no puedo —no porque no alcance el dinero, sino porque seguridad-máxima y rendimiento-máximo son físicamente incompatibles; tienes que decirme cuál pesa más—". Esto lleva la conversación a su forma más pura: no "¿cuánto gastamos?" sino "¿qué eliges cuando dos cosas que quieres no pueden coexistir?".

Y aquí, exactamente aquí, está la frontera del módulo en su punto más importante. Esta lección te enseña a ver que hay que elegir, a comunicarlo ("no cabe todo; estos dos además se pelean"), y a presentar las opciones con su costo. Pero cómo se hace la elección —cómo se ponderan los atributos en conflicto, cómo se decide que security pesa más que performance en este caso, cómo se estructura esa decisión para que sea defendible y se registre en un ADR para que sobreviva— es un método riguroso que es el corazón de la guía architecture-decisions-and-tradeoffs. Este módulo te lleva hasta la puerta de esa decisión: derivaste los atributos desde el stakeholder, los priorizaste, detectaste los conflictos, los pusiste en dinero, y comunicaste que hay que elegir. La decisión misma —el acto de elegir entre las opciones con un método— es el trabajo de la otra guía. Es el pase de estafeta perfecto: aquí terminas con "hay que elegir entre security y performance, aquí está lo que cada uno cuesta y vale"; allá empieza "así es como se toma esa elección de forma rigurosa y se documenta". El "no" de esta lección no resuelve el conflicto; lo nombra, lo cuantifica y lo entrega listo para que el método de decisión lo resuelva.

Errores comunes

Prometer todos los atributos al máximo (de complacencia). Qué pasa: el arquitecto, por no decepcionar al stakeholder o por evitar la confrontación, dice "sí, buscamos máxima disponibilidad, máxima seguridad, máximo rendimiento y bajo costo". Es imposible, y el proyecto lo demuestra a mitad de camino: el presupuesto se agota persiguiendo la excelencia en todo y el sistema termina mediocre en todo. Por qué pasa: decir "sí" se siente colaborativo y evita el momento incómodo de la junta; además, el arquitecto puede no haber hecho la aritmética que muestra la imposibilidad. Cómo detectarlo: si tu propuesta no dice qué atributo no va al máximo, prometiste lo imposible. Cómo corregirlo: haz la aritmética del presupuesto (como la de esta lección), muestra que "todo al 5" no cabe, y propón la priorización —el "no al máximo en todos, sí a esto"—.

Decir "no" sin ofrecer la alternativa (de negatividad estéril). Qué pasa: el arquitecto, orgulloso de su rigor, responde "no se puede tener todo" y se detiene ahí —cree que su trabajo era señalar la imposibilidad—. El stakeholder queda frustrado, sin plan, y con la impresión de que el arquitecto es un obstáculo. Por qué pasa: se confunde la honestidad sobre el límite con el servicio completo; decir "no" es la mitad fácil. Cómo detectarlo: si tu "no" no viene seguido de "pero sí esto, priorizado así, con este costo", diste medio trabajo. Cómo corregirlo: el "no" del arquitecto siempre va con la alternativa priorizada —eres el asesor que ayuda a gastar bien el presupuesto, no el guardián que solo dice qué no se puede—.

Aceptar el atajo sin nombrar la deuda (de silencio). Qué pasa: el negocio pide algo rápido, el arquitecto acepta el atajo sin explicar que es deuda, y meses después la velocidad del equipo se desploma sobre esa base frágil —y el negocio culpa a "los ingenieros que no anticiparon"—. Por qué pasa: nombrar la deuda se siente como aguar el entusiasmo del lanzamiento rápido, o el arquitecto asume que "es obvio que hay que limpiarlo después". Cómo detectarlo: si tomaste un atajo y el negocio no sabe explícitamente que contrajo una deuda con un costo futuro, la escondiste. Cómo corregirlo: di "sí, y esto es deuda —nos da velocidad hoy, nos cuesta velocidad después, y pagarla tomará esto—"; el atajo con la deuda nombrada es una decisión de negocio legítima; el atajo silencioso es una sorpresa cara.

Ejercicios

Ejercicio 1 — Reasigna el presupuesto. Con el mismo presupuesto de 60 puntos y el costo cuadrático (n²), el negocio cambia de opinión: ahora la seguridad es lo más importante (van a manejar datos médicos), y la escalabilidad puede bajar. Propón una nueva asignación de niveles a los cinco atributos que quepa en 60 puntos, con security al nivel 5, y verifica el total.

Ver solución

Una asignación razonable con security al máximo y scalability recortada:

atributo	nivel	costo (n²)
security	5	25
availability	4	16
performance	3	9
scalability	2	4
cost_efficiency	2	4
total		58

Total = 25 + 16 + 9 + 4 + 4 = 58 puntos, que cabe en 60 (margen de 2).

Nota lo que cambió respecto a la propuesta original: la excelencia (nivel 5, 25 puntos) se movió de scalability a security, porque el ranking del negocio cambió. Scalability, que antes tenía el 5, ahora está en 2 —sigue presente, pero ya no se lleva la excelencia—. El presupuesto total es casi el mismo (58 contra 55), pero repartido según las nuevas prioridades. Es la lección de la lección 2 aplicada al presupuesto: cuando el negocio cambia lo que valora, se reasigna la excelencia, no se agrega presupuesto mágicamente. Y observa que sigue siendo imposible poner dos atributos en 5 (dos veces 25 = 50, y con los otros tres al mínimo —tres veces 1 = 3— darían 53, que cabría; pero apenas, y dejaría tres atributos en nivel 1, probablemente insuficiente para varios). El presupuesto sigue obligando a que solo uno o dos atributos alcancen la excelencia.

Ejercicio 2 — El "sí, pero cuesta esto". El VP mira la propuesta priorizada original (scalability 5, security 4, availability 3, performance 2, cost_efficiency 1, total 55) y dice: "me encanta, pero necesito que la disponibilidad sea excelente, súbela a nivel 5". Con los números, explica qué cuesta ese cambio y da la respuesta del arquitecto en forma de "sí, pero cuesta esto".

Ver solución

Qué cuesta el cambio. Subir availability de nivel 3 a nivel 5 cambia su costo de 3² = 9 a 5² = 25: un aumento de 16 puntos. El presupuesto ya estaba en 55 (con 5 de margen sobre 60). Sumar 16 lo llevaría a 55 − 9 + 25 = 71 puntos, que rebasa los 60 por 11. No cabe sin recortar otra cosa o ampliar el presupuesto.

La respuesta del arquitecto ("sí, pero cuesta esto"): "Sí, se puede subir la disponibilidad a excelencia. Cuesta 16 puntos más, y el presupuesto ya está lleno, así que tenemos tres caminos, y la decisión es tuya:

1. Recortar otro atributo. Podríamos bajar security de 4 a 3 (libera 7 puntos) y performance de 2 a 1 (libera 3), que casi alcanza —pero bajar la seguridad manejando pagos me preocupa; te muestro el riesgo antes de que decidas—. O bajar scalability de 5 a 4 (libera 9 puntos), lo que nos deja con menos margen para el crecimiento 10x que también pediste.
2. Ampliar el presupuesto en unos 11 puntos (en dinero y tiempo, esto significa X), si la disponibilidad excelente vale ese costo extra para el negocio.
3. Reconsiderar el nivel. ¿Necesitamos de verdad el nivel 5 (99.99%+) o el nivel 4 nos da la disponibilidad que el negocio necesita a un costo mucho menor? Recuerda la tabla de nueves: el último escalón cuesta muchísimo y evita poca venta adicional.

No te voy a decir 'no se puede'; te digo lo que cuesta y cuáles son las opciones. ¿Cuál prefieres?"

Por qué es la respuesta correcta: no es un "no" (bloquearía sin ayudar) ni un "sí" complaciente (rompería el presupuesto en silencio); es un "sí, y este es el precio, elige tú". Nombra el costo exacto (16 puntos), expone los caminos con sus consecuencias en el idioma del negocio, y devuelve la decisión —incluyendo el recordatorio de la lección 6 de que quizás el nivel 5 no vale su costo—. Eso es administrar el presupuesto de calidad como servicio.

Ejercicio 3 — Nombra la deuda. El negocio necesita lanzar el piloto de vendedores externos en seis semanas para una feria importante, y el plan completo (con multi-tenencia robusta, la seguridad al nivel 4, observabilidad) toma doce. El arquitecto propone un atajo: lanzar con aislamiento básico y sin observabilidad completa, para llegar a la feria. ¿Es correcto tomar el atajo? Escribe cómo se lo comunicarías al negocio para que sea una decisión informada y no una sorpresa futura.

Ver solución

¿Es correcto tomar el atajo? Puede serlo —llegar a la feria con un piloto funcional puede valer más para el negocio que un sistema perfecto seis semanas tarde—. La corrección del atajo no es el punto; el punto es que el negocio lo elija sabiendo que es deuda, no que el arquitecto lo tome en silencio. Un atajo elegido con conocimiento es una decisión de negocio válida; un atajo escondido es una bomba de tiempo.

Cómo lo comunicaría (el "sí, con la deuda nombrada"): "Podemos llegar a la feria en seis semanas, sí. Para lograrlo tomaríamos un atajo consciente, y quiero que lo decidan sabiendo exactamente qué implica, porque es una deuda que vamos a tener que pagar:

Qué recortamos para llegar: lanzaríamos el piloto con aislamiento básico entre vendedores (suficiente para una demo controlada con pocos vendedores de confianza, no para abrir al público) y sin el sistema completo de alertas.

Qué deuda contraemos: esto está bien para un piloto de feria con vendedores seleccionados, pero no podemos abrirlo al público general en este estado —el aislamiento básico es un riesgo de que un vendedor vea datos de otro si escala, y sin alertas no nos enteraríamos a tiempo de un problema—. Para pasar de piloto a producción abierta necesitamos las otras seis semanas de trabajo: la multi-tenencia robusta y la observabilidad. Es una deuda concreta con un plan de pago concreto.

La decisión que les pido: lanzar el piloto en seis semanas para la feria, con el compromiso explícito de completar las seis semanas restantes antes de abrirlo al público. Si están de acuerdo con eso, es un atajo responsable. Si en cambio la intención es abrirlo al público justo después de la feria sin pagar la deuda, entonces el atajo es peligroso y deberíamos hablar de otro plan.

Así, dentro de tres meses, cuando digamos 'necesitamos seis semanas más antes de abrir al público', no será una sorpresa ni un 'los ingenieros se atrasaron': será la deuda que decidimos juntos contraer hoy."

Por qué funciona: dice "sí" al atajo (no bloquea al negocio), pero nombra la deuda en términos de negocio (riesgo de fuga entre vendedores, ceguera ante fallos), acota dónde el atajo es aceptable (piloto controlado, no público), y fija el plan de pago explícito. Convierte un atajo que podría estallar en una decisión de negocio consciente y compartida. El pecado habría sido lanzar el atajo callado y dejar que la deuda apareciera después como una falla imprevista.

Resumen y siguiente paso

En esta lección aprendiste la respuesta más difícil del oficio: saber decir no, o su forma honesta, "sí, pero cuesta esto". Con la remodelación cuyo presupuesto no alcanza para todo viste las dos mitades del trabajo —el no honesto ("no cabe todo, y algunas cosas se pelean") y el "esto es lo que sí cabe" (la priorización que da el mayor valor con lo que hay)—, y por qué el "sí" complaciente y el "no" seco fallan los dos. Lo mediste ejecutando: "todo al nivel 5" cuesta 125 puntos contra un presupuesto de 60 —imposible por más del doble— porque el costo de la calidad crece cuadráticamente, mientras que la propuesta priorizada (la excelencia para el atributo #1, niveles decrecientes para el resto) cabe en 55. Entendiste el "sí, pero cuesta esto" que nombra el precio de cada cambio, la deuda del atajo que hay que nombrar para que sea decisión y no sorpresa, y la razón más profunda de que "todo al máximo" sea imposible: algunos atributos se pelean, así que ni con presupuesto infinito coexisten al máximo. Y viste dónde termina este módulo y empieza la guía de decisiones: aquí nombras y cuantificas que hay que elegir; allá está el método de cómo elegir.

Antes de avanzar deberías poder: demostrar con la aritmética del presupuesto que "todo al máximo" no cabe; proponer una priorización que quepa asignando la excelencia según el valor de negocio; responder un pedido de "súbeme este atributo" con un "sí, pero cuesta esto" que nombre el precio y las opciones; y nombrar la deuda de un atajo para convertirlo en decisión informada.

Con esta lección cierras el arco de las seis lecciones de tema. En la lección 8 —el proyecto— vas a poner todo junto sobre un lanzamiento nuevo de Mercado: los pagos a plazos (Buy Now, Pay Later). Vas a derivar los atributos priorizados desde las metas del lanzamiento (y vas a ver algo revelador: la seguridad domina y la escalabilidad cae a cero, prioridades opuestas a las del caso de vendedores externos —el método, no la receta—), filtrar los ASR, descubrir los implícitos, y escribir el guion de la conversación con el CFO en su idioma. Es la prueba de que aprendiste a ser el traductor de las dos direcciones, sobre un caso que no viste en las lecciones.

Recursos

• Mark Richards & Neal Ford — Fundamentals of Software Architecture — su principio de que un arquitecto debe soportar pocas características de arquitectura y "nunca busques la mejor arquitectura, busca la menos mala" es la formalización del "no se puede todo al máximo" de esta lección.
• Google SRE Book — Embracing Risk — el capítulo que argumenta por qué 100% de disponibilidad (el "máximo") es el objetivo equivocado, y cómo elegir el nivel correcto sopesando costo contra valor; la versión operativa del presupuesto de calidad y del punto donde conviene parar.
• Martin Fowler — TechnicalDebt — el ensayo canónico sobre la deuda técnica: qué es, cuándo es un atajo legítimo y cuándo una imprudencia, y por qué hay que hacerla visible para decidirla conscientemente. La base del "nombra la deuda del atajo" de esta lección.
• Gregor Hohpe — The Software Architect Elevator — su tratamiento de las decisiones y los trade-offs, y de cómo el arquitecto comunica lo que cuesta cada opción al negocio, sostiene el "sí, pero cuesta esto" —el arquitecto como quien hace visible el precio de cada decisión—.