El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.
Product owner y relación con Stakeholers

Product owner y Stakeholers. ¿Cómo ha de ser su relación?

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders. 

Cada Stakeholder tiene su propia necesidad que atender. Lo suyo es siempre “lo más importante para la supervivencia de la compañía”, y no van a desaparecer. Tendrás más o menos Stakeholders dependiendo de las diferentes tipologías de producto y de la complejidad de las cadenas de valor existentes. Además, probablemente sean ellos los que tienen acceso directo al cliente final, al que compra vuestro producto, y como Product Owner esa conexión es vital para ti.
Así que, salvo que tengas la suerte de ser el auténtico dueño del producto, vas a tener que entenderte con ellos.

Entenderte con los Stakeholders para obtener información útil es la parte que mayor frustración te puede generar, y sin embargo la más divertida e interesante de ser Product Owner. Te permitirá construir un buen Product Backlog y priorizarlo basándote en las necesidades de la compañía y sus clientes. Te dejo algunos consejos para sobrellevarlo mejor y sacarles más partido.

Crea una red de colaboradores

Fomenta, junto con los otros Product Owner y los Scrum Master, espacios formales en los que relacionarte con los diferentes niveles de responsabilidad de las áreas de negocio. Estos son algunos de los que hemos puesto en práctica en varios de nuestros clientes:

  • Una sesión mensual de negociación entre las áreas de negocio, para priorizar el Backlog del área de IT. 
    • Te permitirá llevar el debate sobre qué debe realizarse primero a donde corresponde, a las áreas de negocio. Ya que son ellas las que tienen la visión global de la compañía.
    • Te evitará mantener múltiples reuniones para tratar de cuadrar las diferentes solicitudes de cada área. En una sola sesión, se acuerda todo.
  • Una sesión bimestral o trimestral de Planificación del área de IT, en la que los diferentes Equipos Scrum realicéis una planificación de alto nivel junto con las áreas de negocio.
    • Te permitirá visualizar cómo se distribuye lo priorizado en la sesión de negociación a lo largo de los Sprints.
    • Te permitirá visualizar dependencias internas y con terceros.
    • Tendrás una planificación consensuada con tus Stakeholders.
  • Incorporar cuanto antes a las personas que representan a las áreas de negocio con las que trabajas en el día a día a la Sprint Review.
    • Ayudará a subir el nivel de la sesión.
    • Os “obligará” en cierto modo, a mostrar incrementos reales de producto. Usa las PPTs para ayudarte en las explicaciones, nunca para sustituir una entrega a medias.
  • Una sesión bimestral o trimestral de Review, a la que asistan los responsables de las áreas de negocio, directores, etc… Es decir, las capas del management que no están en el día a día, pero marcan la dirección en la que va el negocio con sus decisiones.

Gestiona inteligentemente las expectativas

Controla las expectativas, sobre todo al inicio. Estáis arrancando, aprendiendo cómo se crea y gestiona un producto desde una perspectiva Agile, aprendiendo sobre vuestra propia capacidad. Mantén los pies en el suelo y evita pecar de optimismo. Comprometerse a algo poco realista se convierte en punto innecesario de presión o agobio más.

Se conservador en los primeros Sprints, siempre será mejor decir que vas a hacer menos y luego abrir la posibilidad a que hagáis más, que al revés. Generas más frustración creando falsas expectativas, que siendo tacaño en la planificación.

Eso sí, estate atento a que esto no se convierta en lo habitual, y ponlo sobre la mesa para debatir en las Retrospectivas.

Aprende a utilizar el sí y el no ahora de manera efectiva

Atrévete a decir claramente “Ahora no, por que supone…” y “Sí, aunque eso implica…”. Ni todo lo que llega tenemos que atenderlo inmediatamente ni todo debe quedarse para más adelante. Lo que te aconsejo es hacer siempre visibles las consecuencias de cambiar vuestra planificación.

Todo lo que llega fuera del plan tiene impacto, menor o mayor, pero lo tiene. Cuéntale al Stakeholder que te esté pidiendo algo adicional (o urgente o megasúperurgente de vida o muerte), las consecuencias de abordarlo inmediatamente. Hazle responsable de la decisión de atrasar las peticiones de otras áreas o de sus propios compañeros de área. E inmediatamente después comúnicalo a todas las áreas de negocio afectadas. Puede ser un correo o una sesión rápida de 15 minutos, involucrando a quién ha provocado el cambio en el plan.

Si tienes la suerte de haber formalizado la sesión de negociación, siempre le podrás remitir a que lo lleve a la siguiente y negocie con el resto de sus iguales. Y si no puede esperar, visualiza el impacto.

Recuerda que no estás solo

Apóyate en el resto de compañeros de tu Equipo Scrum. El Scrum Master te puede ayudar a facilitar y dinamizar las sesiones con los Stakeholders, a prepararlas para que sean más efectivas. Incluso es un buen apoyo para hacer pedagogía.

Los Desarrolladores seguramente a lo largo de los años tendrán una relación estrecha con algunos Stakeholders. Aprovéchala para llegar a las personas con las que hayas tenido menos relación, o para conseguir un mejor consenso sobre los cambios de planificación. Incluso te puedes apoyar en los que tengan buenas dotes de comunicación.

No estás solo en la relación con los Stakeholders, eres responsable de esa relación pero, como hemos dicho en otras ocasiones, sigues sin tener que hacerlo todo solo.

Introduce tus primeros cambios

Ojalá estos consejos te sirvan para mejorar tu relación con tus Stakeholders. Introducir nuevas ideas en tu día a día puede resultar abrumador. Haz un ejercicio conmigo. Escribe una lista de las 5 ideas más potentes que te gustaría poner en marcha. Para cada una de ellas, apunta:

  • Qué pasa si no lo intentas.
  • Qué pasa si lo intentas y lo consigues.
  • Qué pasa si lo intentas pero no lo consigues.

Quiénes son tus aliados claves para introducir ese cambio y cómo los vas a implicar. Con esta información, prioriza y elige qué vas a hacer primero. ¡Ánimo!

Tabla de contenidos

Comparte:

Más artículos

lean-kanban

Lean Kanban ¿qué es?

El Toyota Production System, data de los años 50 del siglo pasado. Es un complejo conjunto de principios y prácticas que han llevado a Toyota

Devops ¿qué es?

DevOps surge de la necesidad de mejorar el proceso de gestión de las operaciones en los equipos de desarrollo de software. Está basado en un

valor en empresa

Define qué significa VALOR en tu empresa con estas claves

En términos de agilidad, lo primero que se nos viene a la mente es “aporte de valor”. Es una expresión muy manida, con frases como “Con Scrum maximizamos el aporte de valor” o “Primero abordamos los elementos que aporten más valor”.

Suscríbete y mantente al día de las novedades

¿Alguna duda?

¡Reserva 30 minutos con uno de nuestros expertos y soluciónala!