Módulo 5: Stakeholders y atributos de calidad

4. Requisitos arquitectónicamente significativos: la señal y el ruido

Siguiente →

Descripción

Al terminar esta lección vas a saber separar, de la avalancha de requisitos que le llegan a un arquitecto, los poquísimos que de verdad moldean la arquitectura de los muchísimos que no —y por qué gastar tu energía en los equivocados es la forma más común de que un arquitecto se vuelva irrelevante o cuello de botella—. A un producto de Mercado le llegan cientos de requisitos por trimestre: "el botón de compra debe ser verde", "aislar los datos de cada vendedor", "mostrar el rating con estrellas amarillas", "soportar 10x el tráfico", "agregar un campo de apodo al perfil", "cumplir PCI-DSS para los datos de tarjeta". Todos son requisitos legítimos. Pero solo algunos son arquitectónicamente significativos: los que, si los ignoras al principio, te obligan a rehacer medio sistema después. Esos se llaman architecturally-significant requirements (ASRs), y el criterio para reconocerlos es una prueba de tres preguntas: ¿moldea la estructura del sistema? ¿es caro de cambiar más tarde? ¿es de alto riesgo (de negocio o técnico)? "Aislar los datos de cada vendedor" pasa las tres —decide la estructura de datos completa, es carísimo de retrofitear, y una fuga es un desastre—. "El botón verde" no pasa ninguna —no toca la estructura, se cambia en una línea de CSS, y equivocarse no arriesga nada—. Vas a ejecutar un filtro que toma ocho requisitos de Mercado y los separa: cinco resultan ASR (la señal) y tres, ruido para el arquitecto (importan al producto, no a la estructura).

Esto importa porque el tiempo y la atención de un arquitecto son el recurso más escaso de un equipo, y la trampa es tratar todos los requisitos como si merecieran ese recurso por igual. El arquitecto que se mete a decidir el color del botón, el texto de un mensaje o si el campo se llama "apodo" o "nickname" está robando tiempo de las decisiones que sí son irreversibles y caras, y —peor— se está volviendo el cuello de botella que el módulo 4 enseñó a evitar: todo pasa por él, incluso lo que no debería. Al mismo tiempo, el arquitecto que no identifica un ASR a tiempo —que trata "aislar los datos de cada vendedor" como un detalle que se resolverá después— condena al equipo a un refactor doloroso cuando descubra, con el sistema ya construido, que la multi-tenencia había que diseñarla desde el primer día. El ASR es la herramienta que le dice al arquitecto dónde meterse y dónde no: métete a fondo en los cinco requisitos que moldean la estructura; deja los otros tres al equipo de producto, que sabe mejor que tú de qué color va el botón. Distinguir la señal del ruido no es un lujo intelectual: es lo que te permite ser un arquitecto que habilita en vez de uno que estorba.

Conexión con el módulo: esta lección es el filtro que hace manejable todo lo anterior. La lección 2 priorizó los atributos; la 3 los volvió scenarios medibles. Pero si tuvieras que escribir un scenario de seis partes para cada requisito que llega, te ahogarías —y la mayoría no lo merece—. El ASR es el criterio que decide sobre cuáles requisitos vale la pena hacer el trabajo pesado (priorizar, escribir el scenario, diseñar la estructura) y cuáles se despachan sin ceremonia. Es el embudo entre "todo lo que pide el negocio" y "las pocas cosas que moldean la arquitectura". Las lecciones que siguen se apoyan en él: la 5 descubre ASRs implícitos que nadie escribió (los atributos que el negocio dio por hecho); y las 6 y 7 son las conversaciones sobre esos pocos ASRs que importan —no vas a negociar con el VP el color del botón, vas a negociar el nivel de aislamiento y su costo—. La frontera se mantiene: aquí identificas qué requisito es significativo; cómo se decide la solución para ese ASR —qué arquitectura de multi-tenencia, con qué trade-offs— es el método de architecture-decisions.

El inspector de estructura que ignora el color de la pintura

Piénsalo con la casa otra vez, pero ahora con el inspector que revisa una remodelación. Los dueños tienen una lista larguísima de cambios que quieren: tirar un muro para unir la sala y el comedor, cambiar el color de las paredes a azul, mover el baño de planta baja al otro lado de la casa, poner cortinas nuevas, agregar un segundo piso, cambiar las perillas de las puertas. El inspector estructural llega y hace algo que parece frío pero es sabiduría pura: ignora por completo el color, las cortinas y las perillas, y se concentra en tres cosas —tirar el muro, mover el baño, agregar el piso—. ¿Por qué? Porque esas tres tocan la estructura: tirar un muro puede afectar una carga; mover el baño implica replantear toda la plomería y el drenaje; agregar un piso cambia los cimientos. Equivocarse en cualquiera de las tres significa rehacer la casa, con costos enormes y riesgo real de que algo se caiga. El color de las paredes, en cambio, se cambia un sábado con una brocha; las cortinas, en una tarde; las perillas, en diez minutos. Si el inspector gastara su atención en aprobar el tono de azul, estaría haciendo el trabajo equivocado y —peor— retrasando a los dueños en decisiones que ellos pueden tomar solos.

El inspector aplica, sin nombrarla, la prueba del ASR: ¿toca la estructura? ¿es caro de cambiar después? ¿es de alto riesgo? El muro, el baño y el piso pasan las tres; el color, las cortinas y las perillas no pasan ninguna. Y la consecuencia es doble, igual que en el software. Primero, el inspector se mete a fondo solo en las tres decisiones estructurales —las estudia, las calcula, se asegura de que no se caiga la casa—. Segundo, y menos obvio: al no meterse en el color y las cortinas, le devuelve esas decisiones a los dueños, que son quienes deben tomarlas —el inspector no tiene por qué opinar del azul—. El arquitecto de software es ese inspector. De la lista de requisitos que llegan, la mayoría son "el color de la pintura" —importantes para el producto, triviales para la estructura— y unos pocos son "tirar el muro" —los ASRs, donde el arquitecto debe poner toda su atención—. Confundir los dos es el error: ni te metas en el color (estorbas), ni ignores el muro (se cae la casa).

Ejemplo trabajado: filtrar los ASR del ruido

Vamos a ejecutar la prueba de tres preguntas sobre ocho requisitos que le llegaron al arquitecto de Mercado. Para cada uno, tres señales binarias: ¿moldea la estructura? (0/1), ¿es caro de cambiar después? (0/1), ¿es de alto riesgo? (0/1). Sumamos las tres para obtener una "señal" de 0 a 3, y aplicamos la regla: un requisito con señal ≥ 2 es ASR; el resto es ruido para el arquitecto. La regla del ≥ 2 (en vez de exigir las tres) es deliberada: un requisito puede ser significativo aunque no marque las tres —el checkout rápido, por ejemplo, moldea la estructura y es caro de cambiar aunque no sea de alto riesgo de negocio—.

# No todo requisito moldea la arquitectura. Un ASR (architecturally-significant
# requirement) es el que SI la moldea. Criterio de 3 preguntas:
#   (1) moldea la estructura?  (2) es caro de cambiar despues?  (3) es de alto riesgo?
# Un requisito con >=2 "si" es ASR: la senal. El resto es ruido (importa al
# producto, pero no a la estructura).

requirements = [
    # requisito                                    moldea  caro   alto
    #                                              estruct cambiar riesgo
    ("aislar los datos de cada vendedor",             1,     1,     1),
    ("soportar 10x el trafico en 18 meses",           1,     1,     1),
    ("no perder un pedido si cae el gateway",         1,     1,     1),
    ("cumplir PCI-DSS para datos de tarjeta",         1,     1,     1),
    ("checkout en menos de 2 segundos",               1,     1,     0),
    ("el boton de compra debe ser verde",             0,     0,     0),
    ("mostrar el rating con estrellas amarillas",     0,     0,     0),
    ("agregar un campo apodo al perfil",              0,     0,     0),
]

print(f"{'requisito':<44}{'senal':>6}{'ASR?':>6}   clasificacion")
asrs, noise = [], []
for req, shapes, costly, risky in requirements:
    signal = shapes + costly + risky
    is_asr = signal >= 2
    (asrs if is_asr else noise).append(req)
    tag = "ASR (moldea la arq.)" if is_asr else "ruido (no-arq.)"
    print(f"{req:<44}{signal:>4}/3{('SI' if is_asr else 'no'):>6}   {tag}")

print()
print(f"De {len(requirements)} requisitos: {len(asrs)} son ASR y {len(noise)} son ruido.")
print("El arquitecto gasta su energia en los ASR. Lo demas lo decide el producto,")
print("y cambiarlo despues es barato: por eso no moldea la arquitectura.")

Qué esperar. Al correrlo:

requisito                                    senal  ASR?   clasificacion
aislar los datos de cada vendedor              3/3    SI   ASR (moldea la arq.)
soportar 10x el trafico en 18 meses            3/3    SI   ASR (moldea la arq.)
no perder un pedido si cae el gateway          3/3    SI   ASR (moldea la arq.)
cumplir PCI-DSS para datos de tarjeta          3/3    SI   ASR (moldea la arq.)
checkout en menos de 2 segundos                2/3    SI   ASR (moldea la arq.)
el boton de compra debe ser verde              0/3    no   ruido (no-arq.)
mostrar el rating con estrellas amarillas      0/3    no   ruido (no-arq.)
agregar un campo apodo al perfil               0/3    no   ruido (no-arq.)

De 8 requisitos: 5 son ASR y 3 son ruido.
El arquitecto gasta su energia en los ASR. Lo demas lo decide el producto,
y cambiarlo despues es barato: por eso no moldea la arquitectura.

Lee la tabla de arriba abajo y verás dos mundos claramente separados. Arriba, los cinco ASR: "aislar los datos de cada vendedor" marca 3/3 —moldea la estructura (decide cómo se particionan los datos, cómo se autoriza cada request, quizás cómo se despliega cada tenant), es carísimo de cambiar después (retrofitear multi-tenencia a un sistema mono-tenant es de los refactors más dolorosos que existen), y es de alto riesgo (una fuga entre vendedores es un desastre legal y de reputación)—. "Cumplir PCI-DSS" igual: define dónde y cómo viven los datos de tarjeta, es carísimo de agregar tarde, y el riesgo regulatorio es enorme. Estos son los "muros" de la casa: el arquitecto tiene que meterse a fondo, porque equivocarse significa rehacer el sistema.

Abajo, los tres de ruido: "el botón de compra debe ser verde", "estrellas amarillas", "campo de apodo" —todos 0/3—. No tocan la estructura (son detalles de presentación o un campo más en una tabla), se cambian en minutos, y equivocarse no arriesga nada grave. Ojo con la palabra "ruido": no significa que no importen. El color del botón puede afectar la conversión, y eso es dinero; el campo de apodo puede ser justo lo que pidió un cliente importante. Son requisitos legítimos y valiosos para el producto. "Ruido" es estrictamente desde el punto de vista del arquitecto: son decisiones que no moldean la arquitectura y que, por lo tanto, el arquitecto no debe acaparar. El equipo de producto sabe mejor que el arquitecto de qué color va el botón —tienen los datos de conversión, entienden a los usuarios—. Que el arquitecto se meta ahí es doblemente malo: hace peor la decisión (no es su expertise) y se convierte en cuello de botella. La clasificación no desprecia esos requisitos; los pone en las manos correctas.

Detente en el caso interesante, el que enseña por qué la regla es "≥ 2" y no "= 3": "checkout en menos de 2 segundos" marca 2/3 y es ASR. Moldea la estructura (un checkout sub-2-segundos puede exigir decisiones de caché, de procesamiento asíncrono, de cómo se ordenan las llamadas a servicios) y es caro de cambiar después (si lo diseñaste sin pensar en la latencia, apretarla luego puede requerir reestructurar el flujo). Pero no lo marcamos de alto riesgo: si el checkout tarda 2.5 segundos en vez de 2, es malo para la conversión pero no es un desastre como una fuga de datos. Un requisito puede ser arquitectónicamente significativo por moldear la estructura y ser caro de cambiar, sin ser de alto riesgo catastrófico. Por eso el umbral es 2 de 3: exigir las tres dejaría fuera requisitos que sí moldean la arquitectura. Las tres preguntas son señales independientes de significancia, y con dos basta para que el arquitecto deba prestar atención. Este caso te enseña a no volver la prueba un dogma rígido: es un criterio con matices, no un checkbox de tres casillas obligatorias.

Un matiz honesto sobre las señales binarias. En el ejemplo, "moldea la estructura", "caro de cambiar" y "alto riesgo" son 0 o 1 —una simplificación—. En la realidad son grados: "aislar los datos" moldea la estructura muchísimo; "checkout rápido" la moldea bastante; "un caché para reportes" quizás la moldea un poco. Podrías usar una escala (0-3) en vez de binario y afinar el umbral. Pero el binario captura lo esencial y evita la falsa precisión: para el 90% de los requisitos, la respuesta a "¿toca la estructura?" es un sí o un no bastante claros, y los casos fronterizos (como el checkout) se resuelven con las otras dos preguntas. La herramienta no pretende ser un algoritmo exacto que reemplace el juicio; pretende forzar las tres preguntas correctas sobre cada requisito, para que ninguno se cuele sin que el arquitecto haya decidido conscientemente si merece su atención o no. El valor no está en el número final; está en haber preguntado.

Profundización: por qué estas tres preguntas, y el ASR que llega disfrazado

Vale la pena entender por qué estas tres preguntas —y no otras— definen la significancia arquitectónica, porque cada una captura una razón distinta por la que un requisito merece la atención del arquitecto.

"¿Moldea la estructura?" es la pregunta de la forma. Un requisito arquitectónicamente significativo es el que, para cumplirse, obliga a organizar el sistema de cierta manera —a partir los datos así, a separar estos servicios, a poner esta cola aquí—. "Aislar los datos de cada vendedor" no se cumple con una función; se cumple con una forma del sistema (cómo se particiona, se autoriza, se despliega). El color del botón no impone ninguna forma: el sistema puede tener cualquier estructura y aun así pintar el botón de verde. Si un requisito se puede satisfacer sin cambiar cómo están organizadas las piezas del sistema, no moldea la estructura.

"¿Es caro de cambiar después?" es la pregunta de la irreversibilidad. Aquí se conecta con toda la guía hermana architecture-decisions: las decisiones que importan son las caras de revertir. Un requisito que se puede satisfacer tarde, sin dolor, no necesita la atención del arquitecto al principio —se puede diferir—. Uno que, si no lo consideras desde el día uno, te obliga a un refactor masivo, es un ASR precisamente porque el momento de decidirlo es ahora. Retrofitear multi-tenencia, seguridad o escalabilidad a un sistema que no las contempló es de lo más caro que hay; pintar el botón de otro color, de lo más barato. La pregunta separa lo que hay que decidir temprano de lo que puede esperar.

"¿Es de alto riesgo?" es la pregunta del costo del error. Algunos requisitos, si se hacen mal, producen desastres —una fuga de datos de pago, una caída en Black Friday, un incumplimiento regulatorio—. Otros, si se hacen mal, producen molestias —un botón feo, un mensaje confuso—. El arquitecto debe poner su atención donde el costo de equivocarse es catastrófico, porque ahí es donde su experiencia previene el desastre. Un requisito de alto riesgo merece atención arquitectónica aunque su estructura sea simple, porque lo que está en juego es grande.

Ahora, el peligro real: el ASR que llega disfrazado de requisito trivial. La prueba es fácil cuando el requisito grita su significancia ("aislar los datos de cada vendedor" obviamente moldea todo). Es traicionera cuando un ASR llega vestido de detalle inocente. Ejemplo clásico: el equipo de producto pide "agregar soporte para que los precios se muestren en la moneda local del comprador". Suena a una función de presentación —como el color del botón—. Pero si lo piensas con las tres preguntas, puede ser un ASR: ¿moldea la estructura? Quizás mucho (¿dónde se guardan los tipos de cambio? ¿se recalculan en cada request o se cachean? ¿el precio se almacena en una moneda base y se convierte, o en varias? ¿los impuestos cambian por país?). ¿Es caro de cambiar después? Sí, si lo diseñaste asumiendo una sola moneda. ¿Es de alto riesgo? Cobrar el precio equivocado por un error de conversión es serio. Lo que parecía "el color del botón" resulta ser "tirar un muro". El oficio no es solo aplicar la prueba a los requisitos que obviamente la merecen; es oler cuáles requisitos aparentemente triviales esconden una decisión estructural, y correrles la prueba antes de despacharlos como ruido. El error más caro no es meterse en el color del botón; es no meterse en el "detalle de presentación" que en realidad era multi-moneda.

Y la frontera, una vez más. La prueba del ASR te dice cuáles requisitos moldean la arquitectura y merecen tu atención. No te dice qué arquitectura elegir para satisfacerlos —qué esquema de multi-tenencia, qué estrategia de escalado, qué arquitectura de multi-moneda—. Identificar que "aislar los datos de cada vendedor" es un ASR es el trabajo de esta lección; decidir entre las opciones de aislamiento (base de datos por tenant, esquema por tenant, fila por tenant con filtrado) sopesando sus trade-offs es el método de architecture-decisions. El ASR es el qué merece una decisión; la matriz y el ADR son el cómo se toma esa decisión. Esta lección te enseña a construir la agenda del arquitecto —la lista corta de lo que de verdad importa—; la otra guía te enseña a resolver cada punto de esa agenda.

Errores comunes

Tratar todos los requisitos como si merecieran atención arquitectónica (de acaparamiento). Qué pasa: el arquitecto revisa y opina sobre todo lo que llega —el color del botón, el texto del mensaje, el nombre del campo— y se vuelve el cuello de botella por el que pasa cada decisión, incluso las triviales. El equipo se frena esperando su bendición para cosas que podría decidir solo. Por qué pasa: la sensación de que "un buen arquitecto se involucra en todo", o la incomodidad de soltar el control. Cómo detectarlo: si el equipo no puede decidir el color de un botón sin ti, acaparaste. Cómo corregirlo: corre la prueba del ASR y suelta explícitamente lo que da 0/3 —dile al equipo "esto es de ustedes, no me pregunten"—; tu valor está en los cinco ASR, no en los tres de ruido.

No correrle la prueba al requisito disfrazado (de significancia oculta). Qué pasa: un requisito llega vestido de detalle trivial ("mostrar precios en moneda local", "permitir exportar a Excel", "que los usuarios se puedan borrar a sí mismos") y el arquitecto lo despacha como ruido sin pensarlo —hasta que, meses después, resulta que escondía una decisión estructural (multi-moneda, un pipeline de exportación, el borrado en cascada y el cumplimiento de GDPR)—. Por qué pasa: la prueba se aplica solo a lo que parece significativo, y lo disfrazado se cuela. Cómo detectarlo: si despachaste un requisito como ruido sin hacerte las tres preguntas, no lo filtraste —lo asumiste—. Cómo corregirlo: córrele la prueba a todo requisito que toque datos, dinero, identidad, o integraciones externas, por trivial que suene; ahí es donde se esconden los ASR disfrazados.

Volver la prueba un dogma de "3 de 3" (de rigidez). Qué pasa: el arquitecto exige que un requisito marque las tres casillas para considerarlo ASR, y así deja fuera el "checkout en menos de 2 segundos" (2/3) porque no es de alto riesgo —y lo trata como ruido, sin diseñar para la latencia—. Cuando el checkout resulta lento y hay que reestructurar el flujo, el refactor es caro. Por qué pasa: un criterio de tres preguntas invita a tratarlas como un AND estricto. Cómo detectarlo: si estás descartando requisitos que moldean la estructura solo porque no son catastróficos, endureciste la regla de más. Cómo corregirlo: las tres preguntas son señales independientes; con dos basta, y a veces con una muy fuerte (un requisito que moldea la estructura de forma masiva es ASR aunque sea barato y de bajo riesgo). El umbral es una guía, no un candado —el juicio decide los casos de frontera—.

Ejercicios

Ejercicio 1 — Corre la prueba. Al arquitecto de Mercado le llegan tres requisitos nuevos: (a) "permitir que los compradores dejen reseñas con fotos"; (b) "cambiar el logo de Mercado por la versión de temporada navideña"; (c) "cumplir con el derecho al olvido de GDPR: cuando un usuario lo pida, borrar todos sus datos personales en 30 días". Para cada uno, responde las tres preguntas (¿moldea la estructura? ¿caro de cambiar? ¿alto riesgo?) y clasifícalo como ASR o ruido.

Ver solución

(a) Reseñas con fotos.

  • ¿Moldea la estructura? Sí. Almacenar y servir fotos no es trivial: ¿dónde se guardan (object storage)?, ¿se moderan (pipeline de moderación)?, ¿se redimensionan (procesamiento)?, ¿cómo se sirven a escala (CDN)? Introduce piezas estructurales nuevas.
  • ¿Caro de cambiar después? Sí, más o menos. Si empiezas guardando fotos "de cualquier forma" y luego necesitas moderación y CDN, hay retrabajo.
  • ¿Alto riesgo? Medio. Fotos ofensivas o ilegales son un riesgo de reputación y legal.
  • Clasificación: ASR (al menos 2/3). El "con fotos" es lo que lo vuelve significativo —"reseñas de solo texto" sería mucho menos—.

(b) Logo navideño.

  • ¿Moldea la estructura? No. Es un asset que se reemplaza.
  • ¿Caro de cambiar? No. Minutos.
  • ¿Alto riesgo? No.
  • Clasificación: ruido (0/3). Decisión de marketing/producto; el arquitecto no se mete.

(c) Derecho al olvido (GDPR).

  • ¿Moldea la estructura? Sí, mucho. Borrar "todos los datos personales de un usuario en 30 días" obliga a saber dónde vive cada dato personal —en cuántas tablas, en qué servicios, en qué backups, en qué logs, en qué caché, en qué sistema de analítica—. Eso puede exigir un inventario de datos, un mecanismo de borrado en cascada, y decisiones sobre backups y logs. Es profundamente estructural.
  • ¿Caro de cambiar después? Carísimo. Retrofitear "borrar todo rastro de un usuario" a un sistema que esparció datos personales por todos lados sin control es de los refactors más dolorosos.
  • ¿Alto riesgo? Altísimo. Incumplir GDPR son multas millonarias.
  • Clasificación: ASR (3/3). Y es el caso didáctico: parece una función de producto ("un botón de borrar mi cuenta") y es una de las decisiones estructurales más pesadas que existen. El ASR disfrazado de la profundización, en carne y hueso.

Ejercicio 2 — El requisito disfrazado. Un product manager te dice, de pasada: "ah, y necesitamos que los reportes se puedan exportar a Excel, es solo un botoncito". ¿Lo despacharías como ruido o le correrías la prueba? Argumenta qué preguntas harías para decidir, y da un escenario en el que ese "botoncito" resulta ser un ASR.

Ver solución

No lo despacharía como ruido sin correrle la prueba. "Exportar a Excel" es exactamente el tipo de requisito que llega disfrazado de trivial ("es solo un botoncito") y puede esconder una decisión estructural. Las preguntas que haría:

  • ¿Cuántos datos exporta, y de dónde salen? Si es una tabla de 50 filas que ya está en pantalla, es trivial (ruido). Si es un reporte de millones de filas que hay que agregar de varias fuentes, generar el archivo puede tumbar el servidor si se hace síncrono —lo que obliga a un pipeline asíncrono, una cola, generación en background, notificación cuando esté listo—. Eso es estructura.
  • ¿Con qué frecuencia y cuántos usuarios a la vez? Un export ocasional es una cosa; mil usuarios exportando reportes grandes al cierre de mes es un problema de carga que moldea la arquitectura.
  • ¿Qué datos van en el archivo? Si el export incluye datos personales o de pago, aparece un tema de seguridad y auditoría (¿quién exportó qué? ¿el archivo se cifra? ¿dónde se guarda temporalmente?).

Escenario donde el "botoncito" es un ASR: el CFO necesita exportar el reporte de todas las transacciones del trimestre —varios millones de filas— para su análisis financiero, y lo hace justo al cierre de mes cuando todos los demás también corren sus reportes. Si el export es síncrono, la petición tarda minutos, mantiene una conexión y una porción de memoria ocupadas, y varias a la vez pueden degradar todo el sistema. La solución correcta —generar el archivo de forma asíncrona en un worker, guardarlo en object storage, y avisar al CFO con un link cuando esté listo— es una decisión arquitectónica: introduce una cola, un worker, almacenamiento temporal y un flujo de notificación. El "botoncito" resultó ser tirar un muro. La lección: los requisitos que tocan volumen de datos, integraciones o datos sensibles merecen la prueba aunque el PM los presente como triviales.

Ejercicio 3 — La agenda del arquitecto. Tienes una lista de 20 requisitos para el próximo trimestre. Al correrles la prueba, 4 resultan ASR y 16 ruido. Un compañero te dice: "entonces el 80% de los requisitos no te importan, qué cómodo". Explica por qué esa lectura es equivocada, qué significa de verdad la clasificación, y cómo cambia tu forma de trabajar con cada grupo.

Ver solución

La lectura "el 80% no te importa" es equivocada por confundir "no requiere atención arquitectónica" con "no importa". Los 16 requisitos de ruido sí importan —al producto, al negocio, a los usuarios—; simplemente no requieren que el arquitecto los decida, porque no moldean la estructura, son baratos de cambiar y de bajo riesgo. Que un requisito sea ruido para el arquitecto es una afirmación sobre quién debe decidirlo (el equipo de producto/desarrollo), no sobre si vale la pena.

Qué significa de verdad la clasificación: es la agenda del arquitecto. Los 4 ASR son donde el arquitecto pone su tiempo, su experiencia y su energía —los estudia a fondo, escribe sus scenarios (lección 3), diseña la estructura, documenta las decisiones—. Los 16 de ruido son donde el arquitecto se quita de en medio —confía en el equipo, no los revisa uno por uno, no los convierte en un cuello de botella—.

Cómo cambia tu forma de trabajar con cada grupo:

  • Con los 4 ASR: involucramiento profundo. Priorizas, escribes scenarios medibles, sopesas opciones, documentas en ADRs, hablas con los stakeholders sobre sus trade-offs. Aquí es donde ganas tu sueldo.
  • Con los 16 de ruido: habilitación y confianza. Dejas que el equipo los decida y ejecute. A lo sumo, defines guardrails generales una vez (guías de estilo, patrones, principios) para que el equipo tenga con qué decidir sin ti —el enabling del módulo 4—. No los revisas caso por caso.

Este es, exactamente, el arquitecto que habilita en vez del que estorba (módulo 1) y que evita el cuello de botella (módulo 4). Distinguir la señal del ruido no es para desentenderse del 80%; es para poder atender de verdad el 20% que solo tú puedes atender, y para devolverle al equipo el 80% que ellos deciden mejor que tú. Un arquitecto que trata los 20 requisitos por igual hace mal las 4 decisiones importantes (no le queda tiempo) y estorba en las 16 triviales (no es su expertise). La clasificación es lo que te permite ser útil en ambos frentes.

Resumen y siguiente paso

En esta lección aprendiste a separar la señal del ruido: de la avalancha de requisitos que le llegan a un arquitecto, cuáles son architecturally-significant requirements (ASRs) —los que moldean la estructura, son caros de cambiar y de alto riesgo— y cuáles no. Con el inspector que ignora el color de la pintura y se concentra en el muro, el baño y el piso viste que el oficio es doble: meterse a fondo en lo estructural y quitarse de en medio en lo trivial. Lo filtraste ejecutando: ocho requisitos de Mercado, cinco ASR y tres de ruido, con el "checkout en menos de 2 segundos" (2/3) enseñando por qué el umbral es "≥ 2" y no "3 de 3". Entendiste que "ruido" no significa "sin valor" sino "no lo decide el arquitecto", que las tres preguntas capturan tres razones independientes de significancia (forma, irreversibilidad, costo del error), y que el peligro real es el ASR disfrazado de detalle trivial —el "botoncito" de exportar a Excel que resulta ser un pipeline asíncrono, el "borrar mi cuenta" que resulta ser GDPR—.

Antes de avanzar deberías poder: correrle a cualquier requisito la prueba de las tres preguntas y clasificarlo como ASR o ruido; explicar por qué un requisito de ruido igual importa (pero no al arquitecto); oler cuáles requisitos aparentemente triviales esconden una decisión estructural; y usar la clasificación para construir la agenda del arquitecto —dónde meterte y dónde soltar—.

Lo que sigue es el punto ciego que hemos venido mencionando. Hasta ahora trabajaste con requisitos y metas que alguien pidió —el negocio los puso sobre la mesa, tú los tradujiste, priorizaste, mediste y filtraste—. Pero hay una clase entera de requisitos que nadie pide y todos esperan: que un pedido cobrado no se pierda ni se duplique, que toda transacción de dinero se pueda auditar, que los datos personales estén protegidos, que si algo se cae a las 3am alguien se entere. Son el contrato tácito del dominio, y un arquitecto que solo entrega lo que le pidieron los va a descubrir cuando estallen. En la lección 5 vas a aprender a descubrir los atributos implícitos antes de que exploten: vas a ejecutar la brecha entre lo que las metas explícitas nombraron y lo que un marketplace que maneja dinero y datos de terceros siempre debe cumplir —seis atributos que nadie pidió y que hay que entregar igual—.

Recursos

← Anterior3. El escenario de atributo de calidad: volver medible lo vagoSiguiente →5. Los atributos implícitos que nadie pidió