Un stakeholder es cualquier persona o grupo que afecta o se ve afectado por tu proyecto. En un equipo tech eso incluye al Product Owner, al área legal, al usuario final, al equipo de soporte que va a atender los reclamos y al director que aprueba el presupuesto. Gestionarlos bien no es política de oficina: es lo que determina si tu trabajo técnico llega a producción o queda trabado.

El Future of Jobs Report 2025 del World Economic Forum ubica al liderazgo, la influencia social y la comunicación entre las habilidades de mayor demanda proyectada, por encima de varias competencias técnicas específicas. No es casual. La mayoría de los proyectos de software que fracasan no fracasan por problemas técnicos. Fracasan porque alguien con poder de decisión no estaba alineado, porque un requerimiento cambió sin que el equipo lo supiera, o porque nadie comunicó un retraso hasta que ya era tarde. Esta guía ordena el mapeo, la priorización y la comunicación con stakeholders aplicada al contexto de proyectos de software y datos.

Qué es un stakeholder y por qué importa en tech

El término viene de la gestión de proyectos y se traduce como "parte interesada". En un contexto tech, la definición operativa más útil es: cualquiera que pueda bloquear, acelerar o modificar tu trabajo.

Tipos de stakeholders en un proyecto de software

• Internos directos. Product Owner, tech lead, diseño, QA, otros equipos de desarrollo con los que tenés dependencias.

• Internos indirectos. Soporte, ventas, marketing, finanzas, legal, seguridad de la información. No participan del día a día pero pueden frenar un lanzamiento.

• Externos. Usuarios finales, clientes que pagan, proveedores de servicios y APIs, entes reguladores.

• Sponsor. Quien financia el proyecto y responde por él ante la organización. Es el stakeholder cuya pérdida de interés cancela iniciativas.

La distinción que más cuesta a los perfiles técnicos: el usuario y el cliente no siempre son la misma persona. En software B2B, el que compra rara vez es el que usa, y sus intereses pueden ser opuestos.

Cómo mapear stakeholders en un proyecto tech

Paso 1: identificarlos

Hacé una lista con tres preguntas: quién aprueba, quién ejecuta, quién recibe el impacto. Sumá una cuarta que casi siempre revela nombres olvidados: si esto sale mal, ¿a quién le llega el problema? Ahí aparecen soporte, seguridad y legal.

Paso 2: clasificarlos por poder e interés

La matriz clásica sigue siendo la herramienta más práctica:

El error habitual es tratar a todos igual: reuniones largas con quien solo necesita un resumen, y resúmenes vacíos para quien necesita el detalle técnico.

Paso 3: registrar qué quiere cada uno

Para cada stakeholder relevante, documentá tres cosas: qué espera del proyecto, qué le preocupa y cómo prefiere que le comuniques. Un director financiero quiere saber costo y plazo; un responsable de seguridad quiere saber qué datos se procesan y dónde se almacenan. La misma noticia se comunica distinto a cada uno.

Paso 4: revisar el mapa

Los stakeholders cambian. Alguien asciende, un área se reorganiza, un cliente nuevo se vuelve prioritario. Revisar el mapa al inicio de cada trimestre o de cada fase evita sorpresas.

Cómo gestionar expectativas sin prometer de más

Es donde más se rompen las relaciones en proyectos tech. Cuatro prácticas que funcionan:

• Comprometerse con rangos, no con fechas exactas. "Entre el 15 y el 22" es honesto y verificable; "el 15" es una promesa que difícilmente sobreviva a un imprevisto.

• Explicitar los supuestos. "Esta estimación asume que el acceso a la API del proveedor llega esta semana". Si el supuesto falla, el retraso ya estaba anticipado.

• Traducir el trade-off. Frente a un pedido nuevo, la respuesta útil no es "no se puede" sino "se puede, y entonces esto otro se corre dos semanas". Convierte una negativa en una decisión del stakeholder.

• Comunicar los problemas temprano. Un retraso avisado con tres semanas de anticipación es gestionable; el mismo retraso avisado el día de la entrega es una crisis.

Cómo comunicar avances a perfiles no técnicos

Un reporte técnico dirigido a una audiencia de negocio no se lee. La estructura que funciona ordena la información de mayor a menor relevancia para quien decide:

1. Estado en una línea. En camino, en riesgo o bloqueado. Con un color si el formato lo permite.

2. Qué se logró desde el último reporte. En términos de valor, no de tareas: "los usuarios ya pueden exportar sus datos", no "se cerró el ticket 482".

3. Qué sigue. Los dos o tres próximos hitos con fechas.

4. Riesgos y bloqueos. Qué puede fallar y qué necesitás de esa persona para desbloquearlo. Siempre con un pedido concreto.

5. Detalle técnico. Al final o en un anexo, para quien lo quiera.

Traducir métricas técnicas a impacto de negocio

Escribir para audiencias que escanean en lugar de leer es una disciplina en sí misma: las recomendaciones de Nielsen Norman Group sobre microcontenido aplican tanto a una interfaz como al asunto del correo con el que reportás el estado del proyecto. Esta traducción es una de las habilidades que más diferencia a un perfil técnico senior. Si te interesa profundizar en la mecánica de reportes y tipos de stakeholder, el artículo sobre qué es un stakeholder, su importancia y cómo reportar complementa esta guía desde la mirada de gestión de proyectos.

Errores frecuentes en la gestión de stakeholders

• Olvidar a soporte y seguridad. Aparecen en el peor momento: el día del lanzamiento.

• Comunicar solo cuando hay buenas noticias. El silencio se interpreta como problema.

• Aceptar cambios de alcance sin registrarlos. Cada pedido informal aceptado se olvida cuando se evalúa por qué el proyecto se retrasó.

• Confundir consenso con alineación. No todos tienen que estar de acuerdo; todos tienen que saber qué se decidió y por qué.

• Usar jerga técnica como escudo. Genera desconfianza y hace que las decisiones se tomen sin vos.

Cursos recomendados de Coderhouse

• Para el marco de gestión: el Curso de Scrum y Metodologías Ágiles cubre las ceremonias donde ocurre buena parte de la gestión de stakeholders.

• Para el rol que más lo ejerce: el Curso de Product Manager trabaja priorización, roadmap y comunicación con áreas de negocio.

• Para la parte de comunicación: el Curso de Oratoria es el más subestimado por perfiles técnicos y el que más rápido cambia cómo te perciben en una reunión de decisión.

• Para una formación completa en producto: la Carrera de Producto integra descubrimiento, priorización y gestión de partes interesadas.

Preguntas frecuentes

¿Quién es responsable de gestionar stakeholders en un equipo tech?

Formalmente, el Product Owner o el project manager. En la práctica, cualquier perfil técnico que tenga dependencias con otras áreas lo hace todos los días: cuando negociás una fecha, cuando explicás por qué algo no se puede hacer como se pidió o cuando avisás un riesgo. Es una habilidad transversal, no una función exclusiva de un rol.

¿Cada cuánto conviene reportar avances?

Depende del cuadrante del stakeholder. A quienes tienen alto poder y alto interés, semanalmente y de forma sincrónica al menos una vez por mes. A quienes tienen alto poder y bajo interés, un resumen mensual breve. A quienes tienen bajo poder, comunicación asincrónica cuando hay novedades relevantes. Lo que nunca funciona es la misma frecuencia y el mismo formato para todos.

¿Qué hago si dos stakeholders quieren cosas incompatibles?

No lo resuelvas por tu cuenta ni elijas al que te presiona más. Documentá las dos posiciones, el impacto de cada opción en plazo y alcance, y lleválo a quien tiene autoridad para decidir, habitualmente el sponsor. Tu rol es hacer visible el trade-off, no absorber el conflicto.

¿Cómo comunico un retraso sin perder credibilidad?

Temprano, con causa concreta, con impacto cuantificado y con opciones. La estructura que funciona: qué pasó, qué efecto tiene en la fecha, dos o tres alternativas (reducir alcance, mover la fecha, sumar recursos) y tu recomendación. Lo que daña la credibilidad no es el retraso: es enterarse tarde.

¿Sirve el mapa de stakeholders en proyectos chicos?

Sí, en versión reducida. Incluso en un equipo de cinco personas, escribir en cinco minutos quién aprueba, quién depende de esto y a quién le llega el problema si falla evita la mayoría de las sorpresas. No hace falta una herramienta: una tabla en un documento compartido alcanza.