Product Owner, ¿interno o del cliente?

Suele haber con frecuencia, en los equipos de trabajo del sector IT, un debate abierto sobre la figura del Product Owner. Este debate surge en los momentos en los que el Product Owner no cumple con lo que se espera de él.

En términos de Scrum, el rol de Product Owner tiene unas funciones claramente identificadas y su correcto desempeño es vital para el éxito del Producto.

Sin embargo, cuando el Product Owner proviene del cliente a veces nos resulta muy complicado conseguir que éste cumpla con lo esperado.

¿Qué hacemos en estos casos? ¿Sería mejor que el Product Owner fuera también de nuestra empresa?

Para responder esta pregunta, primero tenemos que conocer las responsabilidades de un Product Owner de acuerdo a Scrum. Además, deberíamos saber qué cualidades hacen de un Product Owner un Gran Product Owner.

De acuerdo con la Guía Scrum, esencialmente, estas son las tres responsabilidades de un Product Owner:

Es responsable de maximizar el Valor entregado

Para ello, es necesario que el Product Owner:

• Conozca el Negocio.
• Tenga una Visión del Producto que se quiere construir.
• Sea capaz de definir los elementos que crean Valor .
• Sea capaz de priorizar estos elementos de acuerdo a esta sencilla regla: primero (siempre que las dependencias lo permitan) los elementos de máximo Valor al mínimo Coste. La mayoría de Productos que conozco se desarrollan para ganar dinero, cuanto más y antes, mejor.

El Product Owner debe asegurarse que existe un Product Backlog

¿Significa esto que es el Product Owner la persona que debe escribirlos físicamente? La respuesta es “No".

Si él no lo hace, puede delegar en otras personas para que lo hagan: stakeholders u otros miembros del Dev Team (analistas, UX, etc.) si así se organiza el equipo. Pero el responsable y la persona que responde ante terceros del mismo es el Product Owner.

Por ello, si él no los escribe o no los detalla al nivel requerido, sí debe participar en su definición y descripción, debe guiar a las personas que los escriben, participar en los Refinamientos y velar por que siempre se priorice el máximo Valor al mínimo Coste.

El Product Owner debe liderar el Sprint Planning y el Sprint Review, y participar en el Sprint Retrospective

• En el Sprint Planning, el Product Owner debe definir el Sprint Goal y los elementos del Product Backlog que permiten alcanzar dicho objetivo. El Product Owner debe ayudar al Dev Team a comprender dichos elementos del Product Backlog, explicándolos con suficiente nivel de detalle y respondiendo las preguntas que formule el Dev Team. El Product Owner también debe estar dispuesto a negociar el alcance del Sprint si este excede la capacidad del equipo para ese Sprint.
• En el Sprint Review, el Product Owner también debe liderar la reunión y esto es fundamental. Tiene que invitar a los stakeholders clave para explicarles qué elementos del Product Backlog han sido completados y cuáles no. Asimismo, debe comentar el estado del Product Backlog, recoger el feedback obtenido durante la revisión del Incremento, cruzar esta información con el estado actual del mercado, y actualizar el Product Backlog para que este feedback sea valioso de cara al siguiente Sprint Planning.
• Por último, en la Retrospectiva, el Product Owner debe participar activamente como un miembro más del Scrum Team para inspeccionar las personas y sus relaciones, los procesos y las herramientas de cara a trazar un plan, unas acciones, que mejoren el trabajo del equipo.

Por tanto, comencemos con algo básico y evidente: si un Product Owner no cumple con estas responsabilidades**, bien por falta de tiempo, capacidad o compromiso, entonces no puede ser Product Owner**. O dicho de otro modo, el cumplimeinto de estas responsabilidades es condición necesaria para poder ser Product Owner.

En caso contrario, existirá una disfunción que, en última instancia, acabará lastrando el desarrollo del Producto y frustrando a todo el equipo.

Estas son las tres responsabilidades básicas para cualquier Product Owner. Pero si lo que queremos es ser un Product Owner de nota, además de lo mencionado, el perfil debe también tener las siguientes habilidades:

• Conocedor del Negocio.
• Capacidad de decisión.
• Disponibilidad.
• Orientado al Valor.
• Saber cómo funciona el desarrollo software.
• Comprometido con el equipo.
• Buen comunicador.
• Conseguidor.
• Capacidad de resolución de conflictos.
• Deseo por mejorar su entendimiento y aplicación de Scrum.
• Gestionar expectativas.
• Confiar en el equipo y en el framework.

Una vez que conocemos las principales responsabilidades de un Product Owner y qué cualidades hacen de él un Gran Product Owner, estamos en condiciones de responder a la pregunta que formulamos al comienzo, ¿Product Owner interno o del Cliente?

En mi opinión, siempre que el Cliente pueda ofrecer un Product Owner y éste se comprometa con las responsabilidades del rol (lo que, además, implica conocimiento del Negocio y dedicación) será mejor opción que un Product Owner interno.

No obstante, si el Product Owner propuesto por el Cliente no se compromete, o no cumple con lo esperado durante el desarrollo del Producto, entonces habría que buscar otra persona para desempeñar el rol, bien otra persona del Cliente o bien interno.

Un Product Owner del Cliente, en la mayoría de casos, tendrá más conocimiento del Negocio, “su” Negocio, y esto es fundamental para maximizar el Valor y saber priorizar.

Además, lo normal es que tenga mayor capacidad de influencia dentro de las distintas áreas o departamentos de “su” organización, lo que es de enorme ayuda para resolver dependencias y agilizar integraciones.

Me atrevería a decir que en Paradigma sabemos resolver cualquier problema técnico y esto nunca supone un bloqueo de un desarrollo, pero ¿qué ocurre con las dependencias cruzadas y las integraciones con otros productos de la organización?

Aquí necesitamos toda la ayuda posible para lograr influenciar y movilizar a las personas adecuadas y un Product Owner del Cliente puede abrirnos las puertas que necesitamos abrir.

Otro aspecto a considerar es la responsabilidad final sobre el Producto desarrollado. Si el Product Owner es del Cliente y el Producto no ofrece el Valor esperado, la responsabilidad es del Product Owner, pues es él quien decide y prioriza los elementos del Product Backlog.

Este no es precisamente un tema menor a la hora de elegir entre un Product Owner interno o del Cliente ya que, sin un profundo conocimiento del Negocio, existe un riesgo mayor.

Entre las ventajas de un Product Owner interno estarían su dedicación, su compromiso con el equipo y su conocimiento de Scrum. Sin duda, un Product Owner interno cumplirá con todas las responsabilidades del rol y facilitará el equilibrio de todo el equipo.

Sin embargo, es más complicado que conozca el Negocio, la organización, los stakeholders, los contactos e incluso que tenga capacidad de decisión, lo que es fundamental.

Es difícil que su opinión sea respetada y acatada dentro de la organización si no forma parte de ella, al menos hasta que se establezca una gran relación de confianza.

Otro punto a considerar es el carácter de la relación que se establece entre el Cliente y la empresa. Si queremos facilitar esta relación, es decir, que sea más integrada, un equipo mixto formado por el Cliente y la compañía facilitará la transparencia y aumentará la cohesión entre ambos.

La transparencia es un pilar básico de Scrum, la apertura del trabajo que hace el equipo genera confianza y esto es básico para evitar futuras fricciones.

Conclusión

Aunque cada caso requiere un estudio particular, siempre que el Cliente cuente con un Product Owner que se comprometa con las responsabilidades del rol (e incluso esté dispuesto a pasar evaluaciones por parte del equipo), pueda dedicar el tiempo necesario y conozca el Negocio, será la opción con mayor probabilidad de éxito.

Además, es el Cliente quien asume la responsabilidad del Valor generado, lo cual tiene pleno sentido puesto que, al fin y al cabo, el Cliente es el promotor del Producto.

Sin embargo, hay casos en los que esto no es posible por diversas razones. Entonces podemos contar con Product Owner internos que, sin duda, aportarán muchas otras ventajas, como la implicación, el compromiso, la total dedicación y el profundo conocimiento de Scrum.

En cualquier caso, habrá que estudiar cada situación para tomar la mejor decisión en un contexto específico ya que, el desarrollo de Productos no es, ni nunca será, una ciencia exacta.