Viabilidad, arquitectura y decisiones técnicas
¿Debemos hacer este proyecto? Las cinco viabilidades, cómo se decide con números, por qué la arquitectura es una decisión de gestión y cómo se dejan registradas las decisiones importantes (ADR).
- Hacer las preguntas de viabilidad técnica, económica, temporal, organizativa y legal ante un proyecto.
- Calcular un ROI y un periodo de recuperación sencillos, contando todos los costes (desarrollo + operación + mantenimiento).
- Saber cuándo una incertidumbre exige un prototipo o prueba de concepto.
- Justificar una decisión técnica por requisitos y restricciones, no por moda, y escribirla como ADR.
Tema 1, diapositivas 41-47. Es terreno de preguntas de aplicar: "¿qué tipo de viabilidad se cuestiona aquí?", "¿qué hacer si la fecha es fija y no da tiempo?", "¿qué partes tiene un ADR?".
1. La pregunta fundamental
El estudio de viabilidad responde a una pregunta: ¿debemos hacer este proyecto?Tema 1, diap. 41. Fíjate en el verbo: no es "¿podemos?", es "¿debemos?". Un proyecto puede ser técnicamente posible y aun así no deber hacerse (no compensa, no llega a tiempo, la organización no está preparada, es ilegal).
Tiene cinco dimensiones:
| Viabilidad | Pregunta | TusBus |
|---|---|---|
| Técnica | ¿Podemos construirlo? | ¿Los datos GPS permiten una estimación con error < 60 s? |
| Económica | ¿Compensa? | ¿Los beneficios (menos quejas, más uso del bus, imagen) justifican desarrollo + 3 años de operación? |
| Temporal | ¿Llegamos a tiempo? | ¿Se puede publicar antes de la feria? |
| Organizativa (operativa) | ¿La organización puede adoptarlo y operarlo? | ¿Quién del ayuntamiento publicará incidencias? ¿Hay alguien para mantenerla? |
| Legal / regulatoria | ¿Podemos hacerlo legalmente? | ¿Tratamos datos de ubicación? ¿Cumplimos RGPD y accesibilidad de apps públicas? |
Ampliación: en la literatura en inglés se resume con el acrónimo TELOS: Technical, Economic, Legal, Operational, Scheduling.
El resultado del estudio no es "sí/no" sin más. Puede ser: seguir, no seguir, o seguir redefiniendo (menos alcance, más plazo, otra solución). Y conecta con todo lo anterior: los supuestos y restricciones de la lección 3 son exactamente lo que se comprueba aquí.
2. Viabilidad técnica
Las cuatro preguntas de las diapositivas:Tema 1, diap. 42.
- ¿Podemos construirlo con la tecnología disponible?
- ¿Tenemos conocimientos y recursos? (Si nadie del equipo ha hecho nunca una app con mapas en tiempo real, es un riesgo de personas, no sólo técnico.)
- ¿Existen integraciones, datos o restricciones críticas? (En software, las integraciones con sistemas ajenos son la fuente nº 1 de sorpresas: la API del GPS del ayuntamiento.)
- ¿Qué incertidumbres requieren un prototipo o prueba de concepto?
Prototipo, prueba de concepto, spike y MVP
La cuarta pregunta es la más importante, porque es la forma de comprar información barata antes de comprometer el proyecto:Ampliación. El spike viene de XP y se usa en Scrum (Tema 2, diap. 35: "los spikes/prototipos pueden reducir incertidumbre").
| Herramienta | Responde a | Se tira después | TusBus |
|---|---|---|---|
| Prueba de concepto (PoC) | ¿Es técnicamente posible? | Normalmente sí | Script que lee una semana de datos GPS y calcula el error de estimación |
| Prototipo | ¿Así es como lo quieren / lo entienden? | Normalmente sí | Maqueta navegable en Figma para enseñar a 20 viajeros |
| Spike (ágil) | Investigación con tiempo acotado para poder estimar o decidir | Sí (se queda el conocimiento) | "2 días para ver si la librería de mapas soporta 500 marcadores" |
| MVP (producto mínimo viable) | ¿Lo usarán de verdad? Es un producto real mínimo | No, se evoluciona | Versión con 3 líneas y sólo tiempos de llegada |
Cuál elegir depende del tipo de incertidumbre: técnica → PoC/spike; de requisitos o usabilidad → prototipo; de mercado → MVP.
3. Viabilidad económica y temporal
Económica: beneficios frente a costes
Beneficios esperados frente a costes, y los costes son de desarrollo + operación + mantenimiento.Tema 1, diap. 43. El error habitual es comparar los beneficios sólo con el coste de construirlo. Una app cuesta dinero cada año que existe: servidores, licencias, actualizaciones de sistema operativo, corrección de errores, soporte. A eso se le llama coste total de propiedad (TCO), y lo verás en la lección 14.
Dos medidas sencillas (ampliación, SWEBOK v4, Software Engineering Economics):Ver SWEBOK v4, KA Software Engineering Economics, que también trata el VAN (valor actual neto) y la tasa interna de retorno.
Ejemplo. Una app interna cuesta 40.000 € de desarrollo y 10.000 €/año de operación. Ahorra 30.000 €/año en horas administrativas. Beneficio neto anual = 30.000 − 10.000 = 20.000 €. Payback = 40.000 / 20.000 = 2 años. ROI a 3 años = (3 × 30.000 − (40.000 + 3 × 10.000)) / (40.000 + 3 × 10.000) = (90.000 − 70.000) / 70.000 ≈ 28,6 %.
No todos los beneficios son monetarios: en TusBus, la imagen del ayuntamiento o la reducción de emisiones son beneficios intangibles que el business case debe recoger aunque no se puedan sumar en euros.
Temporal: ¿hay fecha objetivo y es posible cumplirla?
Las fechas objetivo vienen de:Tema 1, diap. 43. una oportunidad de negocio, la competencia, circunstancias objetivo (la feria), límites externos (la ley entra en vigor el 1 de enero) o límites internos (se acaba la financiación del proyecto europeo).
Y la frase clave: una fecha fija puede obligar a reducir alcance o aumentar recursos. Es la tríada de la lección 1 aplicada: si el plazo no se mueve, algo tiene que moverse. Lo que no debe moverse en silencio es la calidad. Y cuidado con "aumentar recursos": como verás en la lección 16 (ley de Brooks), añadir personas a un proyecto que ya va tarde puede retrasarlo más. Normalmente la palanca más eficaz con fecha fija es el alcance, con prioridades claras (lección 5).
Una decisión de viabilidad frecuente (ampliación) es construir o comprar: ¿desarrollamos el cálculo de tiempos o licenciamos un servicio existente? Se comparan TCO, plazo, riesgo (dependencia de un proveedor), control y si es diferenciador para el negocio. Lo que no te diferencia, normalmente se compra.
4. Arquitectura software
Cuando los sistemas crecen, el problema del diseño va más allá de algoritmos y estructuras de datos: diseñar la estructura global del sistema se convierte en un problema nuevo, el de la arquitectura (Garlan y Shaw, 1994).Tema 1, diap. 44-45. Tres definiciones de las diapositivas, cada una con su matiz:
- Garlan y Perry (1995): estructura de los componentes, sus interrelaciones, y los principios y reglas que gobiernan su diseño y evolución.
- Bass, Clements y Kazman (1998): estructura o estructuras del sistema: componentes, sus propiedades observables y las relaciones entre ellos.
- Martin Fowler (2001): los elementos del núcleo, las piezas que son difíciles de cambiar; los cimientos sobre los que se edifica el resto.
La de Fowler es la que más interesa al gestor. Si arquitectura es "lo difícil de cambiar", entonces equivocarse en arquitectura es el ejemplo máximo del coste del error creciente. Por eso las decisiones de arquitectura se toman pronto, con cuidado y por escrito.
Decisiones técnicas: requisitos, no modas
La arquitectura define la estructura fundamental del sistema, y las decisiones técnicas deben responder a requisitos y restricciones. No basta con elegir tecnologías "de moda"; los clientes tienden a pedirlas (buzzwords).Tema 1, diap. 46.
"Queremos la app con blockchain e IA" no es un requisito, es una moda. Las preguntas son: ¿qué requisito resuelve? ¿Qué RNF lo exige? ¿Qué coste y riesgo añade? En TusBus, ¿hacen falta microservicios? Con un equipo de 4 personas y una sola app, casi seguro que no: un monolito bien modular es más barato de construir y operar. Microservicios resuelven problemas de escala de organización (muchos equipos independientes) que este proyecto no tiene.
Lo que de verdad dirige la arquitectura son los RNF (lección 4): rendimiento, disponibilidad, seguridad, mantenibilidad. Por eso se llaman a veces requisitos arquitectónicamente significativos.
5. Architecture Decision Records (ADR)
Un ADR es un documento que recoge una decisión importante junto con su contexto y sus consecuencias. Registra y traza las decisiones; su estructura es contexto → decisión → alternativas → consecuencias; y facilita la revisión, el mantenimiento y el aprendizaje del equipo.Tema 1, diap. 47. Referencia: repositorio de referencia de ADR. El formato lo popularizó Michael Nygard en 2011.
¿Por qué existe? Porque dentro de dos años alguien abrirá el código, verá que se usa PostgreSQL y no MongoDB, y preguntará "¿por qué?". Sin ADR, nadie se acuerda, la persona que lo decidió se fue, y se reabre una discusión ya cerrada (o, peor, se cambia sin entender las razones). Es la memoria del proyecto, y conecta con la gobernanza (lección 17: "difícil saber quién decidió y sobre todo por qué").
Buenas prácticas (ampliación):
- Un ADR por decisión, corto (una página), en el repositorio junto al código.
- Tiene estado: propuesto, aceptado, rechazado, obsoleto o sustituido por otro ADR.
- Es inmutable: si cambias de opinión, no editas el antiguo; escribes uno nuevo que lo sustituye. Así queda la historia.
- Sólo para decisiones significativas (difíciles de cambiar, con impacto en RNF o coste). No para "usamos tabuladores".
- "La viabilidad pregunta si podemos hacer el proyecto": la pregunta fundamental es si debemos hacerlo.
- "La viabilidad económica compara beneficios con el coste de desarrollo": compara con desarrollo + operación + mantenimiento.
- "Un ADR documenta la arquitectura completa del sistema": no, documenta una decisión, con su contexto, alternativas y consecuencias.
- "Hay que usar la tecnología que pide el cliente": las decisiones técnicas responden a requisitos y restricciones; si el cliente pide una moda, se analiza qué necesidad hay detrás.
Práctica
¿Qué tipo de viabilidad se cuestiona en cada caso?
- Nadie sabe si la API del proveedor soporta el volumen de peticiones necesario
- El mantenimiento anual costaría más de lo que la app ahorraría
- El sistema debe estar operativo cuando entre en vigor la ley, en tres meses
- El hospital no tiene personal que sepa gestionar el nuevo sistema de citas
- La app guardaría datos de salud sin una base jurídica clara para tratarlos
Un estudio de viabilidad económica compara 50.000 € de beneficios anuales con 80.000 € de desarrollo y concluye que se recupera en menos de dos años. ¿Qué error puede tener?
- Ninguno: si se recupera en dos años, el proyecto es siempre viable
- Que no incluye costes de operación y mantenimiento de cada año
- Que la viabilidad económica no debe usar cifras sino juicio experto
- Que los beneficios deben calcularse sólo a partir del tercer año
Un sistema cuesta 60.000 € de desarrollo y 6.000 €/año de operación. Ahorra 30.000 €/año. ¿Cuál es su periodo de recuperación (payback)?
TusBus tiene fecha fija (la feria) y el estudio muestra que, con el alcance actual, no llega. Según el temario, ¿qué opciones hay?
- Reducir alcance o aumentar recursos, decidiendo de forma explícita
- Mantener alcance y fecha reduciendo las pruebas de forma discreta
- Mantener todo igual y confiar en que el equipo haga horas extra
- Cancelar el proyecto, porque no es viable si no llega con todo
¿Qué herramienta usarías para reducir cada incertidumbre?
- No sabemos si con los datos GPS se puede estimar con error inferior a 60 s
- No sabemos si los usuarios mayores entenderán la pantalla de la parada
- No sabemos si los viajeros usarán la app de verdad en su día a día
- Necesitamos dos días para saber si una librería sirve y poder estimar
El cliente insiste en que la app de reservas de un pequeño club use microservicios "porque es lo moderno". ¿Cuál es la mejor respuesta del JP?
- Aceptarlo, porque el cliente paga y decide la tecnología del proyecto
- Rechazarlo, porque los microservicios nunca son adecuados para apps
- Analizar qué requisito lo justificaría y explicar su coste y su riesgo
- Aceptarlo pero hacer un monolito en secreto para ahorrar tiempo
¿Qué elementos forman la estructura de un ADR según el temario?
- Contexto
- Presupuesto
- Decisión
- Alternativas
- Cronograma
- Consecuencias
Un año después se decide sustituir la base de datos elegida en el ADR-007. ¿Qué se hace con el ADR?
- Se edita el ADR-007 con la nueva decisión para que esté actualizado
- Se borra el ADR-007, porque ya no refleja el estado del sistema
- Se escribe un ADR nuevo que sustituye al ADR-007, que queda marcado
- No se hace nada, porque los ADR sólo se usan al principio del proyecto
Explica, usando la definición de arquitectura de Fowler, por qué las decisiones de arquitectura son también decisiones de gestión.
Repaso espaciado · lecciones 2-5
¿Qué afirmación sobre la priorización es correcta según el temario?
- Debe fijarse al principio y no cambiarse para dar estabilidad
- Debe ser explícita y revisable, reflejando valor, urgencia, riesgo y coste
- Debe hacerla el equipo técnico, que es quien conoce el esfuerzo
- Debe basarse siempre en una única estrategia para ser coherente
Clasifica estos RNF por su objeto.
- La app consumirá menos del 2 % de batería por hora de uso
- La documentación seguirá la plantilla corporativa de la empresa
- El sistema cumplirá la normativa de facturación electrónica
Para profundizar
Repositorio de referencia de ADR (enlazado desde las diapositivas): mira dos o tres plantillas y ejemplos reales (inglés, 15 min). Para la idea de "arquitectura = lo difícil de cambiar", el ensayo de Fowler Software Architecture Guide.
Escribe un ADR de una decisión de tu práctica y pide a un asistente que lo revise contra la estructura contexto → decisión → alternativas → consecuencias.
Resumen imprimible: Referencia · Fundamentos.