Stakeholders y deuda técnica
Los dos asuntos que, según el temario, acompañan al proyecto de principio a fin: las personas que lo afectan o se ven afectadas por él, y el "préstamo" técnico que se contrae para ir más rápido.
- Dar la definición completa de stakeholder (la mitad que se olvida cae en el examen).
- Analizar stakeholders por interés, influencia e impacto y elegir una estrategia para cada uno con la matriz poder/interés.
- Explicar qué es la deuda técnica, sus tipos, y clasificar una situación en el cuadrante de Fowler.
- Proponer cómo gestionar la deuda para que no se vuelva invisible.
Tema 1, diapositivas 51-59. Una de las cinco "ideas clave" del tema es literalmente: "stakeholders y deuda técnica forman parte de la gestión durante todo el proceso".Tema 1, diap. 71. Y en exámenes antiguos salía la definición de stakeholder con opciones que dicen sólo la mitad.
Parte I · Stakeholders
1. Definición: afectar o verse afectado
Los stakeholders o partes interesadas son entidades (personas, grupos u organizaciones) que pueden afectar o verse afectadas por el proyecto.Tema 1, diap. 51. La misma definición en el PMBOK ("individuo, grupo u organización que puede afectar, verse afectado, o percibirse a sí mismo como afectado").
Las dos direcciones importan:
- Pueden afectar al proyecto: el concejal que puede cancelarlo, el proveedor del GPS del que dependes, la agencia de protección de datos que puede sancionar.
- Se ven afectados por el proyecto: los viajeros, los conductores (¿se sentirán vigilados?), los empleados de atención telefónica (recibirán menos llamadas, o distintas).
Las opciones típicas dicen "son las personas que pueden afectar al proyecto" o "son las personas a las que el proyecto puede afectar". Ambas son incompletas. Tampoco son "los usuarios" ni "los propietarios o socios". La correcta incluye las dos direcciones.
Ejemplos de stakeholders: cliente, usuarios, dirección, equipo, proveedores, reguladores (gobiernos, asociaciones…). Y dos ideas que hacen difícil la gestión:
- Tienen objetivos que pueden ser opuestos e incompatibles. El concejal quiere la app para la feria; el departamento de informática municipal quiere que se aloje en sus servidores y cumpla su proceso de seguridad, que tarda meses. El JP no puede satisfacer a ambos al 100 %: tiene que hacer visible el conflicto y llevarlo a quien decide.
- En ingeniería de seguridad se consideran también los stakeholders maliciosos además de los legítimos: el atacante que quiere los datos de ubicación, el usuario que quiere colapsar el servicio. Pensar en ellos es el punto de partida del threat modeling (lección 18).
2. Puntos de vista (viewpoints)
Dos entidades pueden ver el mismo proyecto de forma diferente. Identificar perspectivas ayuda a descubrir objetivos y conflictos, y el análisis de stakeholders debe influir en requisitos y decisiones.Tema 1, diap. 52. Para el viajero, TusBus es "saber si me da tiempo a un café". Para el conductor, "una herramienta que mide si voy con retraso". Para el gerente, "datos para reorganizar líneas". Cada visión genera requisitos distintos, y algunos chocan (¿se muestran retrasos por conductor?).
3. La fase de definición: alinear en el papel
La fase de definición del sistema es el punto de partida donde se identifican todos los stakeholders y se explicitan sus objetivos, expectativas y restricciones, para analizar de forma crítica posibles conflictos, prioridades incompatibles o requisitos contradictorios y resolverlos antes de que el desarrollo comience, porque es mucho más económico alinear intereses en el papel que corregir desviaciones con el código ya escrito.Tema 1, diap. 53.
Es otra vez el coste del error creciente (lección 1), aplicado a las personas. Y es la razón por la que "identificar a los interesados" es uno de los dos procesos de Inicio del PMBOK (lección 2).
4. Analizar stakeholders
Para cada stakeholder, cuatro preguntas:Tema 1, diap. 54.
- Interés: ¿qué esperan o necesitan?
- Influencia: ¿pueden afectar a las decisiones?
- Impacto: ¿cómo les afecta el resultado?
- Estrategia: informar, involucrar, consultar, gestionar.
La matriz poder/interés
La herramienta más usada para pasar del análisis a la estrategia es la matriz poder (influencia) / interés:Ampliación. Matriz de Mendelow (1991); el PMBOK la recoge como técnica de representación de datos.
| Interés bajo | Interés alto | |
|---|---|---|
| Poder alto | Mantener satisfecho / consultar Informes breves, consultarle en lo que le toca. No saturarle, pero que nunca le sorprendas. TusBus: el interventor municipal (aprueba pagos) | Gestionar de cerca / involucrar Participa en decisiones, reuniones frecuentes, demos. TusBus: el concejal de movilidad (sponsor), el gerente de la empresa de autobuses |
| Poder bajo | Monitorizar Esfuerzo mínimo; vigilar si cambia su posición. TusBus: comercios cercanos a las paradas | Informar Comunicación regular, canales para que opinen. TusBus: asociación de usuarios del bus, conductores |
Dos cuidados:
- La matriz cambia durante el proyecto. Los conductores tienen poco poder… hasta que su sindicato amenaza con una huelga si la app muestra retrasos por conductor. Hay que revisarla.
- Poder bajo no significa sin importancia. Los usuarios suelen tener poco poder individual y muchísimo impacto en el éxito: si no usan la app, el proyecto fracasa (lección 1). Por eso se les involucra con prototipos y pruebas de usabilidad.
El resultado del análisis se guarda en un registro de interesados (nombre o rol, interés, influencia, impacto, estrategia, responsable de la relación) y alimenta el plan de comunicaciones.
Parte II · Deuda técnica
5. Qué es
La deuda técnica es el coste futuro provocado por decisiones técnicas que priorizan una solución inmediata; el coste acumulado por tomar atajos o decisiones subóptimas.Tema 1, diap. 55-56. La metáfora la creó Ward Cunningham en 1992.
La metáfora es financiera, y funciona muy bien: es como comprar a crédito. Te permite avanzar rápido hoy, pero pagas intereses (en forma de bugs, complejidad y pérdida de velocidad), y si no la amortizas periódicamente acabas hipotecando todo el proyecto.
- El principal es lo que costaría arreglarlo (refactorizar, escribir los tests que faltan).
- Los intereses son el sobrecoste que pagas cada vez que tocas ese código: cada cambio tarda más, cada cambio rompe algo.
Sus efectos: ralentiza la productividad futura, aumenta la fragilidad del sistema y consume recursos que podrían destinarse a nuevas funcionalidades. Por eso gestionarla activamente es tan crítico como entregar valor en cada iteración.
Pero atención: no toda deuda es mala. Puede ser deliberada o accidental, y debe gestionarse conscientemente.Tema 1, diap. 55. Igual que una hipoteca puede ser una buena decisión, salir a tiempo para la feria con un código mejorable puede ser lo correcto, si se sabe, se registra y se planifica pagarla.
6. El cuadrante de Fowler
Martin Fowler cruza dos ejes: ¿fue deliberada o inadvertida? ¿Fue prudente o imprudente?Martin Fowler, Technical Debt Quadrant (citado en las referencias del Tema 1, diap. 75).
| Imprudente (reckless) | Prudente (prudent) | |
|---|---|---|
| Deliberada | "No tenemos tiempo para diseñar." Se sabe que es un atajo y no se piensa en las consecuencias. | "Tenemos que entregar ya y asumiremos las consecuencias." Decisión consciente, con plan de pago. La única deuda "buena". |
| Inadvertida | "¿Qué es eso de separar en capas?" El equipo no sabía hacerlo mejor. Falta de formación. | "Ahora sabemos cómo deberíamos haberlo hecho." Inevitable: al construir se aprende. Se paga refactorizando. |
Para el gestor cada cuadrante pide una respuesta distinta: la deliberada prudente se registra y planifica; la deliberada imprudente se evita (es presión de plazo mal gestionada); la inadvertida imprudente se ataca con formación, revisiones de código y estándares (calidad, lección 15); la inadvertida prudente se acepta como parte del aprendizaje y se paga con refactorización continua.
7. Tipos y fuentes
La deuda no es sólo "código feo":Tema 1, diap. 57.
| Tipo | Ejemplo TusBus |
|---|---|
| Código / diseño | Lógica de cálculo copiada en tres pantallas |
| Arquitectura | Todo en una base de datos compartida sin separación; imposible escalar la ingesta GPS sola |
| Pruebas | El cálculo de tiempos no tiene tests automatizados; nadie se atreve a tocarlo |
| Infraestructura / dependencias | Librería de mapas en una versión abandonada con vulnerabilidades conocidas |
| Documentación | No hay ADR de por qué se calcula en el servidor |
| Procesos y conocimiento | Sólo Ana sabe desplegar; el despliegue es manual (bus factor = 1, lección 16) |
8. Gestionarla
Cinco pasos:Tema 1, diap. 58.
- Registrar la deuda (en el backlog o en un registro de deuda, como un elemento más).
- Estimar impacto y riesgo (¿cuánto interés pagamos? ¿qué puede pasar si no se arregla?).
- Priorizar su tratamiento (con las mismas técnicas de la lección 5: la deuda que más intereses genera, primero).
- Planificar su reducción (p. ej. reservar un porcentaje de cada iteración, o incluirla en las tareas que tocan ese código).
- Evitar que se convierta en deuda "invisible". Este es el peligro de verdad: la deuda que nadie ha registrado no se puede priorizar ni pagar, sólo sufrir.
Fíjate en que es exactamente el mismo esquema que la gestión de riesgos (identificar → analizar → tratar → seguir, lección 12). No es casualidad: la deuda técnica es una fuente de riesgo.
La relación entre deuda y gestión
La respuesta responsable es hacer explícito el compromiso (trade-off).Tema 1, diap. 59. Ya lo viste en la lección 1 con las restricciones que compiten: "salimos sin tests del módulo de avisos para llegar a la feria; lo registramos como deuda, y en septiembre se dedica la primera iteración a pagarla". Eso es deuda deliberada prudente. Hacer lo mismo sin decirlo es deuda invisible.
Y conecta con el éxito (lección 1): un proyecto que cumple plazo y coste dejando una deuda enorme no ha tenido éxito pleno; ha trasladado el coste al futuro.
Stakeholders y deuda técnica no se gestionan una vez: se identifican pronto, se registran, se revisan durante todo el proyecto y sus conflictos se hacen explícitos.
Práctica
¿Qué afirmación define correctamente a los stakeholders de un proyecto?
- Las personas o grupos que pueden afectar al proyecto con sus decisiones
- Las personas o grupos a los que el resultado del proyecto puede afectar
- Las personas o grupos que pueden afectar o verse afectados por el proyecto
- Los usuarios finales que van a utilizar el software que se desarrolla
Asigna la estrategia de la matriz poder/interés a cada stakeholder de una app de citas de un hospital.
- El director médico, que financia el proyecto y quiere estar en cada decisión
- El responsable de seguridad del hospital, que puede bloquear la puesta en marcha pero sólo le preocupa la auditoría
- La asociación de pacientes, muy interesada pero sin poder de decisión
- La empresa de cafetería del hospital, poco afectada y sin influencia
El concejal quiere TusBus para la feria; el departamento de informática exige su proceso de seguridad de cuatro meses, que lo impide. ¿Qué debe hacer el JP?
- Hacer caso al concejal, porque es el sponsor y tiene más poder
- Hacer caso a informática, porque la seguridad siempre está por encima
- Hacer visible el conflicto pronto y llevarlo a quien debe decidir
- Esperar a ver cuál de los dos insiste más antes de tomar partido
Verdadero o falso: "En el análisis de stakeholders para seguridad se tienen en cuenta también los posibles atacantes".
- Verdadero
- Falso
Clasifica cada situación en el cuadrante de deuda técnica de Fowler.
- "Salimos sin caché para llegar a la feria; lo hemos registrado y lo hacemos en septiembre"
- "No hay tiempo para diseñar, ya lo arreglaremos cuando se pueda"
- "¿Tests automáticos? Nunca hemos usado eso, lo probamos a mano"
- "Tras seis meses entendemos el dominio y ahora vemos cómo deberíamos haberlo modelado"
¿Cuáles son pasos de la gestión de la deuda técnica según el temario?
- Registrar la deuda existente
- Eliminar toda la deuda antes de cada entrega
- Estimar su impacto y su riesgo
- Priorizar y planificar su reducción
- Prohibir al equipo tomar cualquier atajo
- Evitar que se convierta en deuda invisible
¿De qué tipo es cada deuda?
- El módulo de pagos no tiene ningún test automatizado
- Usamos una librería abandonada con vulnerabilidades conocidas
- Sólo una persona sabe cómo se despliega el sistema
- Todos los servicios comparten una base de datos sin separación
- No queda escrito por qué se eligió esta base de datos
Explica con la metáfora financiera qué son el "principal" y los "intereses" de la deuda técnica, y por qué la deuda invisible es la más peligrosa.
Repaso espaciado · lecciones 1, 5, 7
El equipo va tarde y el JP decide, sin decírselo a nadie, quitar las pruebas del último módulo para cumplir la fecha. ¿Qué error de gestión comete?
- Ninguno, porque la fecha es la restricción más importante del proyecto
- Sacrifica calidad en silencio y crea deuda invisible sin trade-off explícito
- Usa mal MoSCoW, porque las pruebas son siempre un requisito Must
- Elige un ciclo de vida predictivo cuando debería haber sido ágil
¿Qué técnica de priorización es "una semántica estándar, no una estrategia"?
- WSJF
- Kano
- MoSCoW
- Value vs. Effort
Para profundizar
Martin Fowler, Technical Debt Quadrant (5 min) y su texto general Technical Debt. Para stakeholders, la lectura del campus: Tavares, "Stakeholder Management: Dr Kelly Heuer of the PMI on How to Deliver Complex Projects at Scale…", Authority Magazine, 2026 (enlace en el campus virtual).
Haz la matriz poder/interés de tu práctica y pide a un asistente que te haga de "abogado del diablo": ¿qué stakeholder has olvidado? ¿Cuál puede cambiar de cuadrante?
Resumen imprimible: Referencia · Fundamentos.