Muchos bloqueos tienen origen en una mala identificación de stakeholders reales en proyectos software. Nacen en no haber identificado bien quién decide, quién usa, quién sufre, quién audita y quién puede vetar. En este artículo explico cómo construir un mapa de stakeholders útil de verdad en proyectos reales, cómo trabajar cuando solo tienes proxies y cómo convertir conflicto e incertidumbre en especificación ejecutable antes de que el coste de descubrir tarde se dispare.
Has estado ahí. Tres sprints dentro del proyecto, el equipo avanza con confianza y, de repente, aparece alguien que nunca estuvo de verdad en la foto: Legal diciendo que ese flujo no puede salir así, Seguridad cuestionando accesos y trazabilidad, Operaciones preguntando quién va a sostener eso a las tres de la mañana, o un usuario crítico descubriendo demasiado tarde que el sistema no resuelve su problema real.
En ese punto solemos usar expresiones elegantes: “ha cambiado el requisito”, “falta alineación”, “hay que redefinir alcance”. Pero muchas veces el problema es más simple y más incómodo: el proyecto arrancó con una foto incompleta de sus stakeholders reales.
Mi tesis es esta: una parte enorme de los bloqueos de requisitos no nace en el código; nace en no haber identificado bien quién decide, quién usa, quién sufre, quién audita y quién puede vetar. Si ese mapa está mal, el proyecto no se rompe de golpe. Se degrada. Primero aparecen ambigüedades. Luego suposiciones. Después decisiones implícitas. Y al final llegan el retrabajo, el bloqueo o el incidente.
Lo que quiero defender aquí no es la “gestión de stakeholders” como disciplina de PowerPoint. Quiero defender algo más útil: un método de ingeniería para hacer explícitos actores, incentivos, restricciones y conflictos cuando todavía es barato discutirlos.
El punto de partida correcto: el conflicto no es un fallo, es el estado natural
En ingeniería nos gusta imaginar que, si preguntamos bien, obtendremos una lista razonable de requisitos y podremos seguir adelante. La práctica real rara vez se comporta así. Bashar Nuseibeh y Steve Easterbrook llevan décadas describiendo la ingeniería de requisitos como una actividad donde conviven múltiples perspectivas parciales, y donde la inconsistencia y el conflicto no son anomalías que deban ocultarse, sino una realidad que hay que gestionar explícitamente. Su trabajo sobre viewpoints y gestión de inconsistencias es valioso precisamente por eso: asume que distintos actores ven el sistema desde lugares diferentes y que esas visiones chocan.
Eso encaja muy bien con otra idea clásica que sigue teniendo mucho filo: los requisitos no se limitan a “recogerse”; se negocian hasta alcanzar entendimiento suficiente para decidir. Klaus Pohl sitúa la negociación como una actividad central de la ingeniería de requisitos, orientada a alcanzar acuerdo entre stakeholders sobre qué debe hacer el sistema y bajo qué condiciones. Donald C. Gause y Gerald M. Weinberg, en Exploring Requirements: Quality Before Design, empujan en la misma dirección: la calidad de la solución depende de que antes exista una comprensión compartida del problema y de los requisitos, no de lanzarse demasiado pronto al diseño.
Esa es la idea que conviene grabarse a fuego: si el proyecto parte de una comprensión falsa o incompleta de quién importa y qué teme cada actor, el error no desaparece porque el equipo avance; simplemente se desplaza a fases donde sale más caro corregirlo. La propia definición de ingeniería de requisitos que recoge IREB insiste en metas como conocer los requisitos relevantes, alcanzar consenso entre stakeholders, comprender sus necesidades y documentarlas de forma sistemática.
Qué es un stakeholder cuando dejamos de hablar en abstracto
En teoría, casi todo el mundo sabe qué es un stakeholder. En la práctica, muchísima gente sigue usando “cliente”, “usuario” y “negocio” como si fueran sinónimos. No lo son.
Para trabajar en proyectos reales, a mí me interesa una definición operativa. Stakeholder es cualquier persona, grupo u organización que influye en el sistema, se ve afectado por él, condiciona sus restricciones o tiene capacidad real para validarlo, bloquearlo o sufrir sus consecuencias. Esa visión amplia es coherente con la forma en que la ingeniería de requisitos trata el contexto del sistema y la necesidad de identificar a las partes relevantes para comprender necesidades, restricciones y validaciones.
Con esa lógica, me funciona separar el mapa en cinco preguntas muy simples.
| Quién paga | Quién patrocina el cambio, pone presupuesto o espera retorno económico, político u operativo. |
| Quién usa | Quién ejecuta el flujo principal y necesita que el sistema le facilite hacer un trabajo real. |
| Quién sufre | Quién hereda la fricción cuando el diseño falla: soporte, backoffice, guardias, operación, conciliación, formación, gestión manual o incidencias. |
| Quién audita | Quién valida cumplimiento, trazabilidad, seguridad, legalidad, segregación o readiness operativa. |
| Quién veta | Quién puede decir “así no entra” aunque no haya estado presente durante semanas. |
Esta taxonomía no es un truco retórico. Es una defensa contra uno de los errores más caros de todos: creer que quien paga representa automáticamente a quien usa, a quien sufre y a quien valida.
La cadena real del desastre: del stakeholder invisible a la mala especificación
Hay una secuencia que se repite muchísimo en proyectos problemáticos:
stakeholder mal identificado
→ restricción no descubierta
→ requisito ambiguo o ausente
→ decisión implícita tomada por el equipo
→ conflicto tardío
→ retrabajo, veto o problema operativo
Esta cadena importa porque conecta organización y ejecución. El mapa de stakeholders no es valioso por sí mismo. Es valioso porque evita que el equipo técnico tenga que rellenar huecos críticos con intuición.
Y en cuanto el equipo rellena huecos sin saberlo, ya no está implementando requisitos; está produciendo interpretación. Eso puede salir bien una vez por casualidad. Pero como método, es una ruina.
Los errores que más caro salen
Antes del método, merece la pena poner nombre a los fallos más típicos.
1. Limitarse a quien paga
Es el clásico. Se habla con el sponsor, se asume que ese discurso representa al resto y se da por hecho que ya existe cobertura suficiente. Luego aparecen usuarios operativos, soporte o compliance a corregir el dibujo.
2. Tratar a todos los usuarios como un bloque homogéneo
No existe “el usuario”. Existe un conjunto de segmentos con fricciones distintas. Un operador que usa el sistema doscientas veces al día no optimiza lo mismo que un supervisor, un auditor o un usuario ocasional.
3. Olvidar a quien sufre
En muchos proyectos, Operaciones y Soporte son stakeholders fantasma. No figuran en el arranque, pero heredan el sistema real y pagan sus costes de fricción.
4. Descubrir tarde a quien audita
Legal, Seguridad, Compliance o Auditoría no siempre generan funcionalidad visible, pero sí generan límites. Y algunos de esos límites cambian flujo, datos, arquitectura o modelo de permisos.
5. Dejar que el equipo complete huecos sin trazabilidad
Cuando falta información, el proyecto siempre tiende a avanzar. La cuestión nunca es si avanza, sino sobre qué supuestos avanza.
Si corriges estos cinco fallos, la probabilidad de llegar a un producto ejecutable y sostenible sube mucho.
El método: un Stakeholder Map que sirva para decidir, no para decorar
Aquí está lo importante. No quiero un mapa bonito. Quiero un mapa que permita descubrir pronto dónde están las tensiones reales y qué decisiones hay que tomar antes de fijar arquitectura.
1) Haz primero el mapa rápido: paga, usa, sufre, audita, veta
Antes de matrices y talleres, haz una sesión corta con el equipo core y responde estas preguntas:
- ¿Quién paga?
- ¿Quién usa?
- ¿Quién sufre?
- ¿Quién audita?
- ¿Quién veta?
En este punto, trabaja con roles, no con nombres. Busca amplitud, no precisión perfecta.
Regla práctica: si al terminar solo tienes bien identificado a quien paga y a quien usa, el mapa todavía está verde.
2) Lista actores sin filtrar
Después, amplía la foto. En proyectos medianos o grandes, deberían salir con naturalidad entre ocho y doce actores o segmentos relevantes. Si salen cuatro o cinco, casi seguro que estás dibujando el mundo ideal y no el real.
Incluye como mínimo:
- sponsors y decisores,
- usuarios directos e indirectos,
- operación y soporte,
- arquitectura o plataforma si condiciona,
- seguridad,
- legal o compliance si aplica,
- auditoría o regulador si aplica,
- áreas proveedoras o consumidoras de datos,
- y actores que puedan perder poder, control o tiempo con el cambio.
Ese último grupo suele olvidarse. Y luego sorprende que haya resistencia.
3) Marca poder real, no solo organigrama
La matriz poder/interés sigue siendo útil, pero solo si no te la crees demasiado.
Yo distingo tres cosas:
- poder formal: puede aprobar, bloquear o imponer condición,
- influencia real: no firma, pero condiciona por conocimiento, historial, dependencia o credibilidad,
- interés o afectación: cuánto le cambia la vida si esto sale bien o mal.
Así evitas confusiones muy habituales. Un usuario puede tener interés altísimo y poder bajo. Un auditor puede tener interés moderado y poder de veto altísimo. Un referente técnico histórico puede no estar en el comité y aun así influir más que media jerarquía.
4) Convierte actores en restricciones y decisiones
Aquí es donde el mapa deja de ser descriptivo y empieza a servir.
Para cada stakeholder crítico, fuerza estas preguntas:
- ¿Qué gana si esto sale bien?
- ¿Qué pierde si sale mal?
- ¿Qué miedo tiene?
- ¿Qué restricción representa?
- ¿Qué decisión tiene que validar o firmar?
- ¿Qué señal temprana me diría que voy contra su realidad?
Ese último punto vale mucho. Los stakeholders casi nunca “aparecen de la nada”. Antes dejan rastro: retrasos en validación, lenguaje vago, tickets recurrentes, silencios incómodos, objeciones difusas, “esto ya lo veremos más adelante”.
5) Haz explícitos los conflictos
Aquí está una de las claves del artículo. Si Nuseibeh y Easterbrook tienen razón al tratar conflicto e inconsistencia como una condición normal del trabajo de requisitos, entonces ocultar conflictos por comodidad no es madurez: es autoengaño. (cs.toronto.edu)
Por eso conviene registrar conflictos con un formato simple:
- Conflicto: A quiere X vs B necesita Y
- Tipo: crítico, importante o menor
- Impacto: qué rompe si no se decide
- Decisor: quién firma el trade-off
- Fecha límite: hasta cuándo sigue siendo barato decidir
Si un conflicto no tiene decisor y fecha límite, no está gestionado. Solo está pospuesto.
6) Valida con quien puede hacer daño real
No valides preguntando “¿os gusta el mapa?”. Eso no sirve.
Valida con preguntas que toquen nervio:
- ¿Falta alguien con capacidad real de veto?
- ¿Qué restricción vuestra no estamos viendo?
- ¿Qué os haría decir “esto no puede entrar en producción”?
- ¿Qué parte de este mapa es un malentendido?
Si nadie corrige nada, no siempre es buena noticia. A veces solo significa que aún no has tocado nada sensible.
La realidad incómoda: no siempre tienes acceso a los stakeholders adecuados
En teoría, todo esto suena limpio. En la práctica, muchas veces ni siquiera hablas con la fuente correcta.
Trabajas con proxies. Con equipos funcionales intermedios. Con managers que filtran. Con áreas que “representan” al negocio. Con product owners que no pueden absorber todos los matices. Con organizaciones donde ciertas áreas no se dejan molestar hasta el final.
Eso no invalida el proyecto. Pero cambia por completo el riesgo.
Si Gause y Weinberg insistían en la necesidad de construir comprensión compartida antes de diseñar, y si Pohl sitúa la negociación como actividad central para alcanzar acuerdo real entre stakeholders, entonces un proyecto gobernado casi exclusivamente por mensajes indirectos tiene un problema claro: la negociación se degrada y la comprensión compartida se llena de pérdida. (http://bbau.ac.in/index.aspx)
Cuando el proxy sabe negocio, pero no produce especificación ejecutable
Aquí hablo en primera persona porque esto me ha pasado tal cual.
En un proyecto, yo estaba en el área técnica y el acuerdo era que tendríamos un área funcional como interfaz entre negocio y desarrollo. Sobre el papel, esa capa debía darnos lo necesario para ejecutar el modelo técnico y la implementación. El problema es que ese equipo funcional no estaba compuesto por perfiles capaces de traducir dominio a especificación ejecutable, sino por personas que conocían muy bien el negocio y la normativa aplicable. En aquel caso, contabilidad. Nosotros sabíamos de reglas, patrones, arquitectura, diseño y desarrollo. No sabíamos de contabilidad.
El choque llegó cuando empezaron a llegar documentos. Eran guías muy detalladas sobre cómo debía trabajar una persona del área contable para cumplir la norma. Eran útiles para operar manualmente el proceso. Pero no eran suficientes para el equipo técnico: faltaban reglas explícitas, contratos de datos, catálogos de valores, ejemplos representativos, excepciones y criterios de decisión.
A partir de ahí, me tocó hacer un trabajo que no debería haber recaído en técnica: convertir ese material en hipótesis, estructurarlas como reglas y volver al cliente para validar cuáles eran correctas y cuáles no. Se puede avanzar así, sí. Pero es caro, lento y peligroso. El conocimiento existía. Lo que no existía era una interfaz adecuada entre dominio e implementación.
Ese es el fondo del problema: el proxy sabía negocio, pero no estaba devolviendo una especificación que el equipo pudiera ejecutar con seguridad.
Por qué esto encaja con la teoría y no es solo una anécdota
Esta experiencia no contradice la teoría de requisitos. La confirma.
Klaus Pohl y la tradición más sistemática de requisitos insisten en que stakeholders, conocimiento de dominio, negociación y documentación deben tratarse de forma estructurada. IREB también subraya que comprender necesidades y alcanzar consenso forman parte del núcleo de la disciplina, no de un adorno metodológico. Además, la literatura reciente sobre conocimiento de dominio en requisitos sigue reforzando la misma idea: conocer el dominio mejora la calidad de las preguntas, la cobertura de asuntos relevantes y el lenguaje compartido con stakeholders. (http://bbau.ac.in/index.aspx)
Traducido a la práctica: si el conocimiento de negocio llega en formato narrativo, ambiguo o incompleto, y el equipo necesita convertirlo en comportamiento implementable, el riesgo no está en el dominio; está en la interfaz entre dominio y especificación.
La salida práctica: plantillas de traducción de negocio a ejecutable
La mejor salida que he visto en escenarios así no es “tener más reuniones”. Es obligar a que el conocimiento vuelva en un formato mínimo que el equipo sí pueda convertir en decisiones implementables.
Una plantilla sencilla suele bastar si fuerza cinco cosas:
1. Regla en lenguaje controlado
“Si ocurre X y se cumple C, entonces el sistema debe producir Y”.
2. Datos mínimos y origen
Qué campos hacen falta, de dónde salen y qué significan.
3. Catálogo o dominio de valores
Valores posibles, rangos, unidades, semántica y excepciones.
4. Ejemplos representativos
Uno normal, uno borde y resultado esperado.
5. Validación
Quién confirma la regla y con qué evidencia.
Esto no convierte al negocio en arquitecto ni al analista en oráculo. Pero reduce muchísimo el espacio para la interpretación silenciosa. Y ahí está una de las claves de la calidad en requisitos.
Cómo pasar del mapa al producto que realmente hay que construir
Mapear stakeholders no es el fin. Es el mecanismo para definir mejor el producto.
La utilidad real aparece cuando conviertes ese mapa en tres salidas:
- una definición más precisa del problema,
- una lista de decisiones explícitas,
- y un backlog que no nazca roto por supuestos invisibles.
Técnica 1. Del stakeholder al trabajo real
Con cada stakeholder clave, sobre todo con quien usa y quien sufre, formula esto:
“Cuando ocurre X, necesito poder hacer Y para lograr Z.”
Eso obliga a bajar del discurso a la tarea real.
Técnica 2. Separar lo que piden de lo que necesitan
Cuando alguien pide un dashboard, un botón, un informe o “meter IA”, haz tres preguntas:
- ¿Qué decisión o acción desbloquea esto?
- ¿Qué pasa hoy cuando no lo tienes?
- ¿Cómo sabremos que el problema está resuelto?
Así limpias bastante humo.
Técnica 3. Tratar los conflictos como decisiones de producto
Cuando A quiere velocidad y B quiere trazabilidad, o A quiere menos pasos y B quiere más control, no estás ante un drama interpersonal. Estás ante una decisión de producto con consecuencias en UX, datos, operación y cumplimiento.
Técnica 4. Recordar que quien audita define mucho de lo no funcional
Legal, Seguridad, Compliance, Auditoría y Operaciones muchas veces no piden funcionalidad visible. Pero sí piden trazabilidad, segregación, retención, observabilidad, runbooks, alertas, reversibilidad, readiness operativa.
Si eso entra tarde, no estás ante un ajuste menor. Estás ante un rediseño.
Los artefactos mínimos que sí merecen existir
No hacen falta veinte documentos. Pero sí tres artefactos vivos.
1. Una tabla ligera de stakeholders
Con columnas como estas:
- actor o rol,
- tipo: paga, usa, sufre, audita, veta,
- poder real,
- incentivo,
- miedo o riesgo,
- restricción,
- señal temprana,
- cadencia o canal.
2. Un registro de conflictos
Con:
- conflicto,
- impacto,
- tipo,
- decisor,
- fecha límite,
- estado.
3. Un registro de decisiones
Con:
- decisión,
- contexto,
- opciones consideradas,
- decisión tomada,
- quién la firma,
- consecuencias,
- fecha de revisión si aplica.
Esto evita que el proyecto se pase la vida rediscutiendo lo mismo sin memoria.
Cuándo sé que el mapa todavía no sirve
Desconfío del mapa cuando pasa alguna de estas cosas:
- no sé nombrar quién tiene veto real,
- todo el mundo parece alineado demasiado pronto,
- no han aparecido conflictos relevantes,
- Operaciones y Soporte aún no han dicho nada,
- el conocimiento llega solo por intermediarios y sin trazabilidad,
- Legal o Seguridad “ya revisarán al final”,
- o el equipo técnico ya está tomando decisiones funcionales porque nadie las ha cerrado.
Cuando veo una de estas señales, no toca acelerar. Toca volver al mapa.
Conclusión: esto no va de consenso, va de hacer ejecutable el proyecto correcto
Mapear stakeholders no elimina el conflicto. Tampoco garantiza que todo vaya bien. Lo que sí hace es mover el conflicto a una fase donde todavía podemos discutirlo sin pagar un precio desproporcionado.
Y esa diferencia es enorme.
Si no identificas pronto quién decide, quién usa, quién sufre, quién audita y quién veta, el conflicto no desaparece. Migra. Primero a los requisitos. Luego al diseño. Después al desarrollo. Más tarde a validación. Y, si todo va mal, a producción.
Por eso este trabajo no es burocracia. Es ingeniería preventiva aplicada a proyectos reales.
No para contentar a todo el mundo.
No para fabricar rituales.
Sino para convertir una organización llena de intereses, restricciones y tensiones en algo que el equipo pueda construir con criterio, trazabilidad y menos ruido.
Qué haría mañana mismo si tuviera que arrancar un proyecto
Haría cinco cosas, en este orden.
Primero, dibujar el mapa rápido: quién paga, quién usa, quién sufre, quién audita y quién veta.
Después, listar entre ocho y doce actores reales y marcar cuáles están cubiertos por proxy.
Luego, abrir un registro de conflictos y otro de decisiones desde el primer momento, aunque estén casi vacíos.
A continuación, validar con al menos un actor con capacidad real de bloqueo antes de dar por buena la arquitectura.
Y por último, allí donde el conocimiento llegue a través de intermediarios, exigir una traducción mínima a reglas, datos, catálogos, ejemplos y validación.
Porque en proyectos reales, cuando el stakeholder correcto no entra a tiempo, alguien rellena ese hueco.
Y demasiadas veces ese alguien es el equipo técnico.