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:

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

Por tanto, comencemos con algo básico y evidente: si un Product Owner no cumple con estas responsabilidade****s, 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:

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.

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.