Stakeholders en proyectos de software

Cuando se habla de desarrollo de software, muchos profesionales —sobre todo técnicos— ponen el foco en herramientas, lenguajes o arquitecturas. Sin embargo, más allá del código, olvidarse de los stakeholders en proyectos de software o hacer una mala gestión de estos es uno de los factores que más proyectos arruina.

La gestión de stakeholders en proyectos de software es crucial para el éxito del desarrollo. Involucrar a todos los stakeholders en proyectos de software permite obtener diferentes perspectivas y asegurar que las necesidades de todos sean consideradas.

Qué es un stakeholder

Para responder a la cuestión de qué es un stakeholder, nos vamos a remitir a la definición que nos hacen Klauss Pohl y Chriss Rupp en su Requirements Engineering Fundamentals:

Los stakeholders son personas u organizaciones que directa o indirectamente influyen en los requisitos de un sistema. Ejemplos de stakeholders son los usuarios del sistema, los operadores, los desarrolladores, los arquitectos, los clientes y los probadores.

⚠️ Y recalquemos: los stakeholders no son solo “el cliente” o “el usuario”. Esa visión reducida es precisamente la que más daño hace.

Los stakeholders configuran el ecosistema completo en el que vive tu producto. Y si no los mapeas con inteligencia, corres el riesgo de construir algo técnicamente correcto… pero estratégicamente inútil.

¿Por qué es crítico en proyectos de software?

Los stakeholders en proyectos de software juegan roles variados, desde usuarios finales hasta reguladores, y cada uno tiene un impacto significativo en el desarrollo del producto.

Los stakeholders en proyectos de software, son las fuentes de información, validación y conflicto de objetivos que el ingeniero de requisitos debe identificar, analizar, documentar y armoniza.

Entender a los stakeholders en proyectos de software es esencial para garantizar que el producto final esté alineado con las expectativas de todos los involucrados.

Una adecuada gestión de los stakeholders en proyectos de software no solo ayuda en la identificación de requisitos, sino que también facilita la resolución de conflictos antes de que se conviertan en problemas mayores.

Ignorar o gestionar inadecuadamente a los stakeholders compromete la calidad de los requisitos, genera sobrecostes y amenaza la alineación del producto con sus metas reales.

Por ello, Pohl y Rupp recomiendan mantener listas sistemáticas de stakeholders y documentar sus roles, intereses, disponibilidad, grado de influencia y expectativas en el proyecto. Asimismo, subrayan que la gestión adecuada de stakeholders busca convertir a las personas “afectadas” por el proyecto en colaboradores activos y corresponsables.

Origen y popularización del término

El término “stakeholder” proviene del inglés y se compone de dos palabras:

• stake → literalmente, interés, participación o apuesta
• holder → poseedor o titular

Por tanto, su traducción literal es “poseedor de un interés”, aunque en español se utiliza de forma establecida el término “parte interesada”.

La idea es que cada stakeholder “tiene algo en juego” (has a stake) en el resultado del proyecto o sistema: tiempo, dinero, reputación, recursos, o la propia utilización del producto.

El concepto se popularizó fuera del ámbito empresarial a partir de los años 80, gracias al trabajo de R. Edward Freeman en su obra Strategic Management: A Stakeholder Approach (1984), donde definía a los stakeholders como “cualquier grupo o individuo que puede afectar o ser afectado por el logro de los objetivos de una organización”.

Esta definición fue adoptada progresivamente por los estándares de gestión de proyectos (PMI, ISO 21500) y, más tarde, por la Ingeniería de Software y la Ingeniería de Requisitos, al reconocer que los proyectos de software también involucran actores con intereses diversos, a veces incluso en conflicto.

Características esenciales de un stakeholder

Comprender quién es un stakeholder no basta: lo que realmente marca la diferencia en un proyecto es entender cómo cada uno influye, se ve afectado y se comporta dentro del sistema de relaciones del proyecto.
A continuación se detallan las características esenciales que definen su papel y su impacto en la ingeniería de software y de requisitos.

Influencia, afectación, poder, interés

1. Influencia, poder e interés

Todo stakeholder se define por la combinación de tres variables fundamentales.

Influencia de un stakeholder

Esto hace referencia capacidad de un stakeholder para afectar decisiones, recursos o prioridades dentro del proyecto. Puede ser formal (por jerarquía) o informal (por credibilidad o experiencia).

Aquí la pregunta que debemos hacernos cuando identificamos un stakeholder en un proyecto software es: ¿En qué medida puede este actor cambiar el rumbo del proyecto?

Por ejemplo, un Product Owner que redefine la visión del producto o un arquitecto técnico que decide la tecnología base.

Poder de un stakeholder

Se trata del grado de autoridad o control real que ejerce sobre el proyecto o sus resultados. Suele ser estructural (presupuesto, aprobación, normativa).

Aquí la cuestión clave es: ¿Qué consecuencias tiene ignorar a este stakeholder?

Piensa en un director general que puede cancelar el proyecto o un auditor externo que puede impedir su lanzamiento. En este caso su poder es vital y eso le otorga prioridad a la hora de atender las peticiones.

Interés o afectación de un stakeholder

En este caso hablamos del nivel en que el proyecto impacta los objetivos, tareas o necesidades personales o profesionales del stakeholder. Cuanto mayor sea el impacto, mayor será su interés.

Esta característica responde a la cuestión: ¿Qué gana o pierde este actor con el éxito o el fracaso del proyecto?

Un usuario que depende del sistema para hacer su trabajo diario tiene un alto nivel de interés o afectación, pero si hay un conflicto de intereses con lo que desea un stakeholder de alto poder como el director general, por mayor interés o afectación que tenga, sus peticiones serán menos prioritarias.

Matriz poder/interés

Estos tres factores se representan habitualmente en la matriz poder/interés, una herramienta clásica de análisis que permite priorizar esfuerzos y diseñar estrategias de comunicación:

El objetivo no es contentar a todos, sino alinear expectativas según su poder real y su nivel de afectación.

Actor activo / pasivo

El stakeholder no solo influye: también se ve influido.

Esta doble dirección es lo que convierte la gestión de stakeholders en un ejercicio estratégico y no meramente administrativo.

• Un usuario final se ve afectado en su día a día (nivel operativo).
• Un promotor o directivo se ve afectado en los resultados de negocio (nivel estratégico).
• Un regulador se ve afectado en el cumplimiento normativo (nivel institucional).

Cuanto mayor sea la afectación, más probable será que el stakeholder demande atención, valide entregables o impulse cambios.

Por eso, la identificación temprana de estos actores es crítica: lo que hoy parece irrelevante puede convertirse mañana en un bloqueo legal, técnico o reputacional.

En función de su participación en el proyecto, los stakeholders pueden clasificarse como activos o pasivos. La diferencia clave es que los activos generan requisitos, mientras que los pasivos imponen restricciones o condicionantes.

Ambos son imprescindibles para construir una visión realista del producto: unos definen lo que debe hacer; los otros, lo que debe cumplir.

Activos

Participan directamente en las actividades del proyecto. Pueden tomar decisiones, aportar información, aprobar entregables o usar el sistema.

Por ejemplo: Product Owner, equipo de desarrollo, usuarios finales, testers, departamentos de soporte o legales.

Pasivos

No participan activamente, pero se ven impactados por los resultados o poseen autoridad indirecta sobre ellos.

Por ejemplo: Clientes potenciales, auditores, reguladores, partners externos, opinión pública.

Cómo se entiende un stakeholder en proyectos de software

En ingeniería de requisitos, el stakeholder map no es un organigrama, sino un sistema vivo de relaciones, tensiones y dependencias.

Los stakeholders se conectan entre sí: el interés de uno puede entrar en conflicto con el de otro. Por ejemplo:

• El equipo de marketing busca velocidad y visibilidad.
• El equipo legal prioriza seguridad y cumplimiento.
• El equipo técnico necesita estabilidad y calidad.

Si no se gestionan estos equilibrios, el backlog se fragmenta y las decisiones pierden coherencia.

El ingeniero de requisitos actúa aquí como mediador estructural, alineando visiones para que el sistema represente los intereses reales sin perder viabilidad técnica.

Perspectiva estratégica

Desde un punto de vista metodológico (Pohl & Rupp, IREB; Pressman; PMI), la gestión de stakeholders no se limita a una lista de nombres, sino a un proceso continuo de:

1. Identificación → descubrir quiénes tienen interés o poder.
2. Análisis → evaluar su influencia, expectativas y relaciones.
3. Priorización → decidir dónde enfocar los recursos de gestión.
4. Gestión activa → mantener comunicación, alineación y trazabilidad.
5. Revisión evolutiva → actualizar el mapa conforme el proyecto evoluciona.

De este modo, los stakeholders dejan de ser “entidades externas” y se convierten en componentes estructurales del sistema sociotécnico del proyecto. Un stakeholder no es solo un rol, sino una fuerza de impacto dentro del ecosistema de tu producto.
Algunos deciden, otros validan, otros usan… pero todos, directa o indirectamente, moldean lo que construyes.

Ignorarlos es construir sobre arena: tarde o temprano, el sistema se derrumba.

Gestionarlos con inteligencia, en cambio, te permite alinear arquitectura, estrategia y propósito —los tres pilares de todo software con sentido.

Conocer cómo interactúan los stakeholders en proyectos de software es fundamental para adaptar las estrategias de comunicación y asegurar una colaboración efectiva.

Clasificación de stakeholders

La clasificación más básica distingue entre:

Internos vs Externos

Stakeholders internos

Estos stakeholders forman parte de la estructura organizativa que promueve, financia o lleva a cabo el desarrollo del proyecto. Se trata de actores que operan dentro de los límites de la propia empresa u organización y que, por lo tanto, comparten responsabilidades directas en el éxito o fracaso del producto.

Algunos ejemplos representativos incluyen: directivos de diferentes niveles jerárquicos, product owners encargados de definir la visión del producto, equipos completos de desarrollo que construyen el software, departamentos de marketing responsables de su difusión y posicionamiento, así como equipos de soporte técnico que garantizan su correcto funcionamiento una vez desplegado.

Stakeholders externos

Estos stakeholders se encuentran fuera de los límites organizativos de la empresa o entidad que desarrolla el proyecto, pero mantienen intereses legítimos en su evolución o poseen capacidad significativa para ejercer influencia sobre el mismo.

Aunque no participan directamente en la estructura interna del proyecto, sus expectativas, necesidades y perspectivas deben ser consideradas y gestionadas de manera apropiada.

Entre los ejemplos más representativos de este tipo de actores se encuentran: los clientes finales que utilizarán el producto o servicio resultante, los organismos reguladores que supervisan el cumplimiento normativo, las empresas integradoras que conectan el software con otros sistemas, los auditores que verifican la calidad y conformidad, los partners estratégicos que colaboran en distintos aspectos del proyecto, así como diversos sectores de la sociedad civil que pueden verse afectados o tener opiniones relevantes sobre el impacto del producto desarrollado.

Promotores, usuarios, influencers y reguladores

Dentro de esta estructura básica, podemos desglosar aún más los roles y responsabilidades para obtener una visión más detallada y operativa. Esta segunda capa de clasificación permite identificar con mayor precisión las expectativas, necesidades y formas de participación de cada actor en el proyecto:

Promotores

Son las personas o entidades que impulsan, financian o aprueban el proyecto desde una posición de autoridad estratégica. Tienen capacidad de decisión sobre el rumbo, presupuesto y continuidad del proyecto. Suelen estar interesados en los resultados de negocio más que en los detalles técnicos.

Cómo identificarlos:

• Pregúntate: ¿Quién aprobó este proyecto? ¿Quién pone el dinero?
• ¿Quién puede cancelarlo si no está satisfecho?
• ¿Quién espera ver retorno de inversión o impacto estratégico?

Ejemplo práctico:

En un proyecto de digitalización de una pyme familiar, los promotores serían el director general (que aprobó el presupuesto), el fundador de la empresa (que quiere modernizar el negocio) y posiblemente un inversor externo que financió parte del desarrollo. Aunque no usen el software día a día, ellos deciden si el proyecto sigue adelante.

Usuarios finales

Son las personas que interactúan directamente con el producto o sistema que estás desarrollando. Son quienes lo utilizarán en su día a día para realizar tareas concretas, resolver problemas o cumplir con sus objetivos personales o profesionales.

Es importante señalar que este tipo de stakeholders puede ser sometido a un nivel de análisis mucho más profundo y detallado cuando entramos en la fase de análisis de tipos de usuarios y sus necesidades específicas. En ese momento, no solo identificamos quiénes son los usuarios finales, sino que los segmentamos por perfiles, contextos de uso, objetivos, frustraciones y capacidades técnicas. Este análisis más granular nos permite detectar requisitos funcionales y no funcionales con mayor precisión, y traducir las expectativas generales de estos stakeholders en especificaciones concretas y accionables para el diseño y desarrollo del producto.

Cómo identificarlos:

• Pregúntate: ¿Quién abrirá la aplicación o usará el sistema regularmente?
• ¿Quién depende de esta herramienta para hacer su trabajo o actividad?
• ¿A quién impacta directamente si el sistema falla o no funciona bien?

Ejemplo práctico:

En un proyecto de software para gestionar turnos en un hospital, los usuarios finales serían las enfermeras (que consultan y registran turnos), los médicos (que ven sus horarios) y el personal administrativo (que coordina las asignaciones). Aunque el director del hospital sea quien aprobó el presupuesto, él no es usuario final porque no usará el sistema cada día.

Influencers internos

Son personas o equipos que, sin ser usuarios directos del sistema ni promotores del proyecto, tienen la capacidad de influir en su aceptación, viabilidad o éxito interno. Pueden facilitar su despliegue, bloquearlo, o condicionar cómo se percibe dentro de la organización.

Aunque no toman las decisiones finales ni usan el producto día a día, su opinión, validación o apoyo pueden ser determinantes para que el proyecto avance sin obstáculos.

Cómo identificarlos:

• Pregúntate: ¿Quién puede poner trabas internas si no está conforme?
• ¿Qué equipos deben validar, integrar o dar soporte al sistema aunque no lo usen?
• ¿Quién tiene que aprobar aspectos legales, de seguridad o de cumplimiento?
• ¿Qué departamentos dependen indirectamente del éxito de este proyecto?

Ejemplo práctico:

En un proyecto de CRM para el equipo comercial de una empresa, los influencers internos serían: el departamento legal (que debe validar el tratamiento de datos de clientes), el equipo de soporte técnico (que tendrá que resolver incidencias aunque no use el CRM), y el equipo de ventas de otra región (que podría condicionar la adopción del sistema si no se sienten representados). Ninguno de ellos usa el CRM directamente, pero todos pueden ralentizar o bloquear su éxito si no se les tiene en cuenta.

Influencers externos

Son personas, empresas u organizaciones que, aunque están fuera de tu organización, tienen capacidad de condicionar el éxito del proyecto por su influencia, conocimiento o relación con aspectos clave del mismo. No toman decisiones internas ni usan el sistema directamente, pero su opinión, recursos o posicionamiento pueden facilitar o dificultar que el proyecto avance.

A diferencia de los reguladores (que imponen normas), los influencers externos actúan desde la persuasión, la recomendación o la dependencia técnica. Pueden ser aliados estratégicos, pero también pueden convertirse en obstáculos si no se les tiene en cuenta.

Cómo identificarlos:

• Pregúntate: ¿De qué proveedores o partners depende técnicamente este proyecto?
• ¿Qué empresas o personas externas tienen influencia sobre la percepción del producto en el mercado?
• ¿Quién puede recomendar (o desaconsejar) el uso de nuestro sistema a clientes potenciales?
• ¿Qué actores externos podrían facilitar o bloquear integraciones, despliegues o accesos clave?

Ejemplo práctico:

En un proyecto de software de gestión para restaurantes, los influencers externos serían: el proveedor de TPV (terminal de punto de venta) con el que debe integrarse el sistema (si no colabora, la integración será muy difícil), un consultor tecnológico reconocido en el sector hostelero (cuya opinión puede influir en la adopción del producto), y una asociación de restauradores que recomienda herramientas a sus socios (si no les gusta tu solución, pueden frenar su expansión). Ninguno de ellos forma parte de tu empresa ni usa tu software cada día, pero todos pueden condicionar su éxito en el mercado.

Reguladores

Son los llamados “stakeholders invisibles”. Son personas, organismos o instituciones que establecen las reglas, normas o leyes que tu proyecto debe cumplir para poder funcionar legalmente o ser aceptado en su contexto. No usan el sistema, no lo financian ni lo gestionan directamente, pero tienen autoridad para decir qué está permitido y qué no.

Su poder es formal: pueden impedir que el producto salga al mercado, exigir cambios obligatorios o sancionar si no se cumplen sus directrices. Por eso, aunque no participen activamente en el desarrollo, deben ser identificados y tenidos en cuenta desde el inicio.

Cómo identificarlos:

• Pregúntate: ¿Qué leyes, normativas o estándares debe cumplir este proyecto?
• ¿Qué organismos públicos o instituciones pueden auditar, aprobar o prohibir el uso del sistema?
• ¿Existen certificaciones obligatorias para que el producto pueda comercializarse o usarse?
• ¿Qué sectores regulados están involucrados? (salud, finanzas, educación, datos personales, etc.)

Ejemplo práctico:

En un proyecto de software para gestionar historiales médicos en una clínica privada, los reguladores serían: la Agencia Española de Protección de Datos (AEPD), que supervisa el cumplimiento del RGPD en el tratamiento de datos personales; el Ministerio de Sanidad o las consejerías autonómicas, que establecen criterios sobre cómo deben registrarse y almacenarse los datos clínicos; y posiblemente organismos de certificación ISO si se busca acreditar la calidad del sistema. Ninguno de ellos usará el software, pero todos pueden bloquear su uso si no cumple con sus normativas.

Lo importante no es memorizar etiquetas, sino comprender las relaciones de poder, expectativa y dependencia que configuran tu proyecto.

Principales errores comunes al identificar stakeholders

Identificar bien a los stakeholders es una tarea invisible. No deja líneas de código, no genera pantallas ni métricas de rendimiento. Pero sin ella, todos los artefactos que construyas estarán desalineados desde el inicio.

Los errores más comunes son:

• Limitarse al cliente que paga
• Pensar solo en usuarios “activos”
• Olvidar reguladores o validadores
• Asumir que todos los usuarios tienen los mismos intereses
• No distinguir entre quien decide y quien usa
• No analizar cómo evolucionarán los stakeholders en el tiempo

El resultado habitual: una funcionalidad que funciona, pero no sirve.

Cómo identificar stakeholders correctamente

Usa entrevistas y observación contextual

No te fíes únicamente de lo que aparece redactado en el briefing inicial o en la documentación del proyecto. Es fundamental que hables directamente con usuarios reales, aquellos que van a interactuar con el sistema en su día a día.

Pregunta también a otros equipos dentro de la organización que puedan tener relación directa o indirecta con el proyecto. Observa detenidamente cómo se realiza el trabajo actual, cuáles son los procesos existentes y qué personas están involucradas en cada etapa.

A menudo, mediante este proceso de investigación y observación contextual, descubrirás stakeholders inesperados que no aparecían mencionados en ningún documento oficial pero que tienen un impacto significativo en el éxito del proyecto.

Usa herramientas visuales

• Matriz poder/interés: Clasifica a cada stakeholder según su capacidad de influir en el proyecto (poder) y su nivel de involucramiento o afectación (interés). Te permite decidir a quién dedicar más atención y qué tipo de comunicación usar con cada uno.
• Mapa de influencia: Representa visualmente las relaciones entre stakeholders, mostrando quién influye sobre quién, qué dependencias existen y dónde pueden surgir conflictos. Es especialmente útil para detectar actores clave que no aparecen en el organigrama oficial.
• Tablas de clasificación (ver más abajo): Registran de forma estructurada información crítica de cada stakeholder: rol, expectativas, riesgos si se ignora, nivel de poder e interés. Funcionan como una ficha de referencia para gestionar la comunicación y anticipar problemas.

Estas herramientas visuales son fundamentales porque te obligan a pensar sistemáticamente en cada actor del proyecto. Te ayudan a no olvidar a los «actores en las sombras» (aquellos que no son obvios pero tienen influencia real), y a priorizar dónde invertir tu tiempo y energía de forma estratégica.

Tabla de clasificación

Esta plantilla combina lo mejor de la matriz poder/interés y la matriz RACI en un formato compacto. Te permite documentar quién es cada stakeholder, cuánto poder e interés tiene, qué espera del proyecto y qué riesgos corrés si lo ignorás. Úsala como referencia rápida para diseñar tu estrategia de comunicación con cada actor clave:

Nombre	Rol	Interno/Externo	Interés	Poder	Expectativas	Riesgos si se ignora
Ana, responsable legal	Validadora	Interno	Medio	Alto	Cumplimiento normativo	Bloqueo en validación
Clientes finales	Usuario	Externo	Alto	Medio	Facilidad de uso, fiabilidad	Rechazo del producto
Dirección general	Promotor	Interno	Alto	Alto	Visibilidad, resultados rápidos	Cortes de presupuesto

Este tipo de ficha no es decorativa: te obliga a razonar cada relación, y a preparar una estrategia de comunicación diferenciada para cada stakeholder clave.

¿Cuándo y cómo aparecen los stakeholders a lo largo del proyecto?

Los stakeholders no aparecen todos al inicio ni permanecen iguales durante todo el ciclo de vida del proyecto. En ingeniería de requisitos, esta es una realidad crítica: los actores emergen, cambian y se reconfiguran a medida que el sistema evoluciona.

Al principio —en la fase de visión o arranque— suelen identificarse los stakeholders visibles: quienes promueven el proyecto, lo financian o lo usarán directamente. Son los que están en la mesa de definición. Sin embargo, conforme el desarrollo avanza, empiezan a aparecer otros actores menos evidentes: validadores técnicos, áreas legales, departamentos dependientes, proveedores de integración o incluso usuarios secundarios que nadie había previsto.

Estos stakeholders emergentes surgen cuando el sistema empieza a materializarse y sus impactos se vuelven tangibles. Lo que antes era una abstracción, ahora afecta procesos reales, flujos de trabajo o responsabilidades concretas. Cada avance del proyecto revela nuevas dependencias y expectativas que obligan a revisar y actualizar el mapa de stakeholders.

Además, los stakeholders no son estáticos: cambian de rol, de influencia o de interés según la fase en la que se encuentre el producto.
Por ejemplo:

• Un promotor es protagonista al inicio, pero reduce su implicación una vez aprobado el presupuesto.
• Un usuario final pasa de observador a actor clave durante las pruebas de aceptación.
• Un equipo de soporte se vuelve crítico justo antes del despliegue, cuando se prepara la operación.
• Un regulador puede irrumpir al final del proyecto con nuevas normativas que obligan a rediseñar partes del sistema.

Por eso, la gestión de stakeholders no es una tarea puntual, sino un proceso continuo de observación y ajuste. Igual que el backlog se refina sprint a sprint, el mapa de actores debe revisarse de forma iterativa.
El objetivo no es tener una lista perfecta al inicio, sino mantener la visión viva de quiénes influyen y a quiénes afecta el sistema en cada momento.

En resumen: los stakeholders evolucionan con el proyecto. Si tú no los vuelves a mirar, lo harán solos —y entonces los descubrirás tarde, cuando ya estén bloqueando una entrega o reescribiendo tus requisitos.

El rol estratégico de los stakeholders en proyectos de software

En un proyecto de software, los stakeholders no son figuras decorativas: son fuerzas estratégicas que determinan qué se construye, por qué se construye y cuándo se considera terminado.
Su influencia atraviesa todo el ciclo de vida del producto —desde la definición de los requisitos hasta la aceptación final—, y su gestión inteligente es la diferencia entre un sistema útil y un sistema correcto pero irrelevante.

En la fase de ingeniería de requisitos, los stakeholders son la fuente primaria de información. Cada conversación, conflicto o expectativa que aportan se traduce en decisiones sobre alcance, funcionalidades o criterios de calidad. De ellos surgen tanto los requisitos explícitos (lo que piden) como los implícitos (lo que esperan aunque no lo digan). Un ingeniero de requisitos experto sabe que escuchar a un stakeholder no es anotar lo que dice, sino interpretar lo que necesita.

Durante la priorización, los stakeholders ejercen su poder e interés. Los promotores deciden qué se financia, los usuarios marcan qué se necesita antes, los técnicos advierten lo que es viable, y los reguladores dictan lo que es obligatorio.
Gestionar este equilibrio es un acto de estrategia: cada decisión de prioridad es, en el fondo, una negociación entre intereses humanos, técnicos y organizativos.

En el diseño, los stakeholders influyen de forma más sutil pero igual de determinante. Las decisiones de arquitectura, interfaz o experiencia de usuario se ajustan a sus contextos, procesos y capacidades. Un diseño no es solo una solución técnica: es la representación tangible de cómo se ha interpretado la realidad de los stakeholders.

Y finalmente, en la aceptación del producto, los stakeholders vuelven a tener la última palabra. Un software no se considera terminado cuando compila, sino cuando quienes lo usan, lo aprueban o lo auditan reconocen su valor. La aceptación no es un trámite: es la validación colectiva de que los requisitos —funcionales, de negocio y humanos— han sido entendidos y satisfechos.

En conjunto, los stakeholders son el hilo conductor que conecta el propósito, la construcción y la validación de un sistema.
Un producto que ignora a sus stakeholders puede ser técnicamente impecable, pero carecerá de sentido estratégico.
Un producto que los integra con inteligencia, en cambio, se convierte en una herramienta viva: alineada con la organización, sostenida por sus usuarios y capaz de evolucionar con su entorno.

Cómo comunicarte con cada tipo de stakeholder (sin desgastarte ni improvisar)

Cada stakeholder requiere un canal, una frecuencia y un tono distinto. Gestionarlos como si todos fueran iguales genera ruido, saturación y desgaste.

Tipo de stakeholder	Canal recomendado	Frecuencia	Nivel de detalle
Alta dirección	Resumen ejecutivo, reuniones estratégicas	Mensual o hito	Muy alto nivel, enfoque en valor y riesgos
Usuarios finales	Entrevistas, tests de usabilidad, foros	Iterativa	Enfocado en tareas, experiencia, problemas reales
Equipos técnicos	Documentación, dailies, repositorios	Diario/semanal	Detalle técnico y trazabilidad de decisiones
Legales / normativos	Informes documentales, validaciones	Puntual	Exhaustivo, trazable, formalizado
Soporte / postventa	Guías, formación, canales de feedback	Antes del lanzamiento	Operativo, práctico, accionable

✏️ Regla de oro: La comunicación no es para “informar”, sino para alinear expectativas y prevenir errores futuros.

Caso real: cuando ignoras a los stakeholders, el proyecto se hunde (literalmente)

A principios de los 2000, el Servicio Nacional de Salud británico (NHS) lanzó el National Programme for IT, el proyecto tecnológico más grande de Europa en su momento.

Querían digitalizar todos los historiales médicos del país, conectar hospitales, clínicas y médicos en una única plataforma. En papel, sonaba bien. En la práctica… fue un desastre monumental.

La broma costó más de 12.000 millones de libras y acabó cancelado años después sin haber cumplido ni una fracción de sus objetivos.

¿Y cómo pudo pasar esto? Pues bien, ignoraron a quienes realmente usaban el sistema: médicos, enfermeras, administrativos, gestores de hospital….

¿Por qué se quedaron fuera los stakeholders clave?

Los desarrolladores y directivos del proyecto pensaron que sabían lo que necesitaba el sistema sanitario, y ni siquiera se molestaron en validar esas suposiciones. Básicamente ocurrió que

• Se trató como un problema de tecnología, no de personas.
• Todo venía “desde arriba”, sin participación de los hospitales.
• Creyeron que todos los centros sanitarios funcionaban igual.

Cuando por fin el software llegó a los hospitales, nadie quería usarlo: era lento, confuso y no encajaba en los flujos de trabajo reales. El resultado fue un sistema que no entendía la complejidad local ni las rutinas reales del personal sanitario.

En resumen: construyeron algo técnicamente genial, pero inútil en el día a día.

Qué se podría haber hecho distinto

El fracaso era evitable. Bastaba con aplicar algo tan básico como una gestión real de stakeholders:

1. Hablar con la gente: médicos, enfermeras, técnicos, administrativos, reguladores… todos los que viven el sistema día a día.
2. Probar antes de imponer: lanzar pilotos pequeños, escuchar feedback y ajustar.
3. Dar autonomía: permitir que cada hospital adaptara la herramienta a su forma de trabajar.
4. Iterar con criterio: mejorar sobre uso real, no sobre suposiciones de consultora.

Es vital que los stakeholders en proyectos de software comprendan su rol y el impacto que tienen en el desarrollo del producto para fomentar una relación de colaboración.

Si lo hubieran hecho así, el proyecto habría sido más flexible, más usable y sobre todo, aceptado por quienes debían usarlo.

La moraleja

El National Programme for IT no fracasó por la tecnología. Fracasó porque nadie se tomó en serio a los stakeholders.

Si hubieran escuchado a los usuarios reales, hoy ese sistema sería un referente mundial.

Pero no lo hicieron, y el resultado fue exactamente el que se obtiene cuando se ignoran las voces clave: Un producto técnicamente brillante, pero completamente desconectado de la realidad.

Al identificar y analizar a los stakeholders en proyectos de software, podrás alinear mejor los objetivos del proyecto con las necesidades reales del negocio.

Los stakeholders en proyectos de software deben ser consultados frecuentemente para asegurar que sus requisitos y expectativas se reflejen adecuadamente en el producto final.

Finalmente, no subestimes la importancia de documentar las interacciones con los stakeholders en proyectos de software para mantener un registro claro de sus contribuciones y requerimientos.