El Product Owner

El Product Owner

Si tienes pensado utilizar Scrum déjame que te diga una cosa: el Product Owner es la estrella de la fiesta.

Mentalízate que este rol es el más importante de los tres roles Scrum (los otros dos son Equipo de Desarrollo y Scrum Master), entre muchas cosas porque es el nexo de unión entre el negocio y tecnología.

En este post vamos a analizar este importante rol de Scrum y analizaremos cómo debe proceder un buen Product Owner.

El Product Owner según la Guía Scrum

Dice la Guía Scrum:

El Dueño de Producto es el responsable de maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo.

Esta frase tan rimbombante recoge algo de capital importancia: el Product Owner es la persona (porque debe ser una persona en particular, no un comité ni nada por el estilo) que determina que lo que se construya tenga verdaderamente valor de negocio.

También encontrarás en la Guía Scrum respecto a cómo debe realizar el Product Owner eso de maximizar el valor del producto:

El cómo se lleva a cabo esto podría variar ampliamente entre distintas organizaciones, Equipos Scrum e individuos.

Vamos, que decir esto y nada es lo mismo…

Esto se traduce en que, entre otras cosas, tiene la responsabilidad de proporcionar un Product Backlog óptimo al Equipo de Desarrollo, con las historias de usuario completas, bien redactadas y entendibles (sin ambigüedades) y correctamente priorizadas. Casi nada.

No tiene por qué ser él solo quien cree el Product Backlog, ya que puede y debe contar con ayuda. Pero en última instancia él será siempre el responsable del Product Backlog.

La Guía también indica que el Product Owner debe:

Optimizar el valor del trabajo que el Equipo de Desarrollo realiza.

Lógico. El Dueño de Producto debe proporcionar al DevTeam las historias de usuario adecuadas en el orden de prioridad óptimo.

Por tanto, si tienes un Product Owner que no es solvente a la hora de realizar eso de maximizar valor del producto, date por fastidiado.

La principal responsabilidad del Product Owner: maximizar valor

No importa cuán bueno sea tu Equipo de Desarrollo: si el Product Owner no ha ideado un producto con verdadero valor de negocio, el DevTeam desarrollará maravillosamente una bonita basura que no servirá para nada y que no meterá dinero en los bolsillos de tu empresa.

Así que ya te haces una idea de hasta qué punto es importante el rol del Product Owner y de cuánto se puede fastidiar tu proyecto si su Product Owner no hace lo que se espera de él.

Cómo actuará un buen Product Owner

Antes de comenzar un proyecto, conviene tener una buena charla con el Product Owner, darle apoyo metodológico y, sobre todo, dejarle muy claro que su papel es primordial para la buena consecución de un proyecto agile.

Yo procuro siempre hacer eso. Me gusta presentarme a la persona y decirle qué esperamos de ella. Unos se lo toman mejor que otros, pero prefiero dejar clara las bases y que ninguno pueda decir que no se le advirtió en dónde se metía…

Veamos entonces cómo debe actuar un buen Product Owner.

Es responsable de todo el ciclo de vida del producto

Su nombre no deja mucho lugar a dudas: Product Owner, dueño del producto. Es por tanto el principal responsable de la buena marcha del producto.

Por buscarle una similitud con una gestión tradicional, el Product Owner sería semejante al director del proyecto, la persona a la que le ponen la cara roja cuando éste no va bien.

Esto implica controlar cuestiones tan importantes como los costes directos e indirectos y beneficios relacionados con el producto, lo que se suele llamar Coste Total de Propiedad (TCO – Total Cost of Ownership).

Además, como podrás imaginarte, el Product Owner es responsable de que el Equipo de Desarrollo cumpla con los plazos y los objetivos.

Es un experto en el negocio

Esta es quizá la principal virtud que debe tener el Product Owner. Al final, el desarrollo software no es más la materialización de una idea de negocio. Por tanto, si esa idea de negocio no es la adecuada, se desmontará todo como un castillo de naipes.

El Product Owner debe conocer perfectamente el negocio y el mercado, de tal forma que sepa visualizar, con la ayuda del resto de stakeholders, una solución tecnológica que verdaderamente aporte valor a la compañía y la posicione delante de la competencia.

Debe saber leer el mercado y extraer de dicha información qué es lo más conveniente para la compañía a la hora de crear el producto. Una buena forma de recibir información del mercado es obtener feedback a partir de las frecuentes releases del producto (¿recuerdas aquello de inspección y adaptación?)

De hecho, corresponde a él decidir cuándo un incremento debe ser liberado, es decir, puesto en producción, para que el mercado le dé respuesta.

Cuando hablamos del Design Thinking hicimos referencia a las fases de Empatizar, Definir e Idear, de las que debe salir la idea de negocio que después plasmaremos en un prototipo. Es evidente que el Product Owner llevará el peso de todo este proceso de la creación de la idea de negocio.

He conocido Product Owners que delegaban muchas veces en el Equipo de Desarrollo la definición de requisitos de negocio. Es una responsabilidad que no le corresponde al DevTeam.

El Equipo Scrum, Product Owner, Scrum Master y DevTeam, forman una unidad. El Product Owner podrá recibir por tanto ayuda y sugerencias del Scrum Master y de los desarrolladores, pero no debe olvidar nunca a quién corresponde idear el producto.

Representa a las distintas áreas de negocio y stakeholders

Durante el Design Thinking, el facilitador será típicamente el Scrum Master, hará de árbitro, pero el liderazgo de este ejercicio es sin lugar a dudas del Product Owner, que deberá aunar en dichas sesiones a todos los stakeholders y deberá saber sacar de ellos toda la información necesaria para la creación de la idea del producto.

Y no sólo los requisitos puramente funcionales, también deberá tener presente otros aspectos como los legales.

Posteriormente, durante la construcción del producto, surgirán dudas y habrá que ir refinando las historias de usuario del Product Backlog. El Product Owner deberá tener siempre claro, con la suficiente antelación, qué stakeholder deberá aclarar tal o cual aspecto del Product Backlog. 

Otro tema importante: los Sprint Review están para TODOS los stakeholders, son sesiones de trabajo donde se persigue el recibir feedback de los stakeholders (especialmente, de los usuarios). He estado en proyectos dónde sólo asistía (aparte del DevTeam) el Product Owner y poco más. Eso hace la demo inútil, o casi.

El Product Owner debe preocuparse de que asistan los stakeholders al Sprint Review, si no todos por lo menos que asistan los más relevantes. De lo contrario, al final falta gente importante que puede detectar posibles desviaciones o falta de requisitos y esto es peligrosísimo para el proyecto.

Crea las Historias de Usuario

El Product Owner es el responsable del Product Backlog, artefacto que refleja el producto. Por tanto, le corresponde la responsabilidad de crear todas las Historias de Usuario.

Esta es una tarea muy compleja. No se trata de ir escribiendo requerimientos hasta que ya no te quede ninguna funcionalidad más que cubrir. Ni por asomo.

Las historias deberán reflejar la funcionalidad del producto de forma iterativa e incremental. Por tanto, las historias deben describir funcionalidades completas. Posteriormente, conforme vas bajando en el Product Backlog, otras historias mejorarán o ampliarán dichas funcionalidades.

No es nada fácil construir un buen Product Backlog. En una mayoría de casos te encuentras Product Backlog que no son más que una funcionalidad completa de un producto dividida en trozos, cada trozo una historia de usuario. Esto rompe completamente con el paradigma agile de aportar continuamente valor.

Como indica el primer principio del Manifiesto Agile:

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor

Por tanto, desde la primera historia, debe poder entregarse algo útil, no funcionalidades aisladas que por sí solas no aportan ningún valor. Insisto, el enfoque a la hora de crear las historias de usuario debe ser iterativo e incremental.

Pero además de saber crear correctamente las historias, deberá saber redactarlas de forma que cumplan con los criterios de INVEST (Independientes, Negociables, Valiosas, Estimables, Cortas –Short – y Testeables).

Crear y redactar una historia de usuario es todo un arte, así que la experiencia y el compromiso del Product Owner es vital.

Prioriza el Product Backlog

Este requisito va de la mano del anterior. No se pueden entregar valor de forma iterativa e incremental, aportando valor de forma temprana y continua, si no priorizas. Está claro que habrá funciones que son la madre del cordero, otras que son mejoras considerables y otras que aportarán poco o ningún valor. Veremos esto con más detalle en el apartado de cómo priorizar un Product Backlog.

Detectará rápidamente posibles desviaciones

El Product Owner detectará rápidamente cualquier desviación del producto respecto a las expectativas del usuario. No necesitará esperar a la Sprint Review, que es el evento pensado para la inspección y la adaptación del incremento. Hará continuamente seguimiento de los desarrollos ya que trabajará codo con codo con el resto del Equipo Scrum.

Y por supuesto, asistirá a las Reviews y procurará que también acudan aquellos stakeholders necesarios para detectar cualquier anomalía en el incremento.

Sabe comunicarse con el Equipo de Desarrollo

El Product Owner no es una persona de negocio, en el sentido clásico. Es alguien que debe tener un pie en Negocio y otro dentro del Equipo Scrum. Así que debe saber comunicarse con los desarrolladores. En modo alguno se el pide que sea un experto técnico, pero sí que sea capaz de mantener un diálogo y ponerse en la piel de los desarrolladores.

No importa cuán voluntarioso sea el Product Owner y cuán comprometido esté con el Equipo de Desarrollo, además deberá bajarse a las trincheras y entenderse con ellos. Aquí está claro que la buena redacción de las historias de usuario es un factor fundamental.

Esto es especialmente importante cuando el equipo de desarrollo le planteen historias técnicas que se deberán abordar antes que las historias de usuario. Muchos Product Owners, debido a esa desconexión con la parte técnica, no atienden a razones cuando el DevTeam le sugieren abordar trabajo que en principio no aporta ninguna solución de negocio. El buen Product Owner deberá ser comprensivo al respecto y confiar en el criterio de los responsables técnicos.

Por ejemplo, si antes de abordar una historias de usuario de especial interés para el Product Owner, el Equipo de Desarrollo le sugiere que lo primero es tener una buena infraestructura de integración continua, el Product Owner debe entender por lo menos de qué se le está hablando y de esta forma cuestionarse las prioridades marcadas en principio.

Forma parte del Equipo Scrum

El Product Owner no es un ente ajeno a los desarrolladores, no existe una brecha entre negocio y desarrolladores. Como indica el 4º principio del Manifiesto Agile:

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

Aquí no existe eso de ellos y nosotros. En Scrum, el Product Owner, el Scrum Master y el Equipo de Desarrollo forman un todo. Por tanto, el Product Owner debe pasar gran parte de su tiempo sentado con el equipo Scrum, trabajando juntos con el objetivo del Sprint Goal en mente.

Por otra parte, cuando el equipo de desarrollo solicite refinamiento, el Product Owner deberá estar disponible para aclarar cualquier duda que pueda surgir. Esto es especialmente importante, así que el Product Owner no debe escatimar el feedback a los desarrolladores. Una vez por semana (aunque habrá semanas que no sea necesario) se celebrará una reunión de refinamiento con el DevTeam.

En resumen, ¿cuáles son las responsabilidades de un Product Owner?

En general, las obligaciones de un Product Owner son principalmente:

  • Ser el referente funcional y de negocio del producto.
  • Crear las historias de usuario que comprenden el Product Backlog. De hecho, el Product Backlog es su responsabilidad.
  • Respetar y apoyar los principios agile. Priorizar mediante el método MoSCoW u otro método semejante los requerimientos del proyecto de modo que éste siga un esquema iterativo y de mejora continua y donde la prioridad va de más a menos. Este punto es el que determina si será un proyecto agile o no.
  • Estar disponible al DevTeam para resolverle cualquier duda funcional (incluir una reunión de refinamiento por semana).
  • Aglutinar y representar a los stakeholders y procurar que asistan a las demos (especialmente los usuarios) y según la necesidad a determinados refinamientos. El Product Owner debería comenzar la reunión explicando el objetivo planteado en el Sprint, el avance que se ha logrado, lo que no se ha logrado completar y los impedimentos que hubo.
  • Conocer perfectamente el incremento y detectar rápidamente posibles desviaciones.

Product Owner responsable

 

¿Debe el Product Owner tener conocimiento técnico?

Uffff, menuda pregunta.

Te encontrarás opiniones de todo tipo al respecto, desde los que dicen que el Product Owner es un representante o embajador del negocio dentro del equipo Scrum, hasta los que dicen que debe tener conocimiento técnico para poder comunicarse mejor con el Equipo de Desarrollo y saber traducirles requisitos de negocio de muy alto nivel a cuestiones más técnicas para que el equipo sepa desarrollarlas.

Bajo mi punto de vista, este segundo enfoque corresponde más al de un business analyst que a un Product Owner. Pedirle al Product Owner que sea un experto en el negocio y en el mercado, que sepa aglutinar a todas las áreas del negocio, que controle cuestiones de costes y beneficios, que priorice, que dé feedback al equipo técnico… y que también tenga base técnica, sinceramente creo que es pedirle peras al olmo.

Si ya es difícil encontrar un Product Owner solvente, pretender que además sepa traducir un requisito de negocio a “mirad chicos, esto lo solventáis desarrollado una transacción que lea de Base de Datos la tabla X, obtenga el registro Y que a su vez el batch nocturno Z de las 6:15 alimentó…” es simplemente iluso.

Si encuentras un Product Owner así dímelo, por favor. Habrás encontrado un mirlo blanco.

Reflexión final

Creo que ha quedado claro que un Product Owner dista bastante del tipo de negocio de toda la vida… Son muchas las cosas que se esperan de este rol, así que no es fácil dar con tantos Product Owners solventes.

¿Qué espero de ti como Product Owner? Que luches por ese enfoque y que priorices. Que te pide negocio ahora no sé qué chorrada, perfecto, ¡¡pero va al vagón de cola!!

He conocido proyectos agile donde se perdió un tiempo valiosísimo en chorradas (que si no me gusta este color, que mejor usar un slider en vez de una caja de texto, etc) y cuando realmente había que abordar lo imprescindible ya el proyecto se iba de plazos y de pasta. En agile, lo perfecto es enemigo de lo bueno.

Y si eres un Scrum Master y te toca lidiar con un Product Owner novato, ayúdalo en todo lo que puedas. Hazle entender qué se espera de él y procura ser su principal apoyo.

Si tu rol es de gerencia, no asignes el papel de Product Owner a cualquiera, si no quieres que tu producto sea un fiasco. Elige a la persona adecuada y piensa que cualquier cosa se puede aprender en esta vida, pero que la actitud y la buena predisposición para aprender y formarte o la tienes o no la tienes.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

2 comentarios en “<b>El Product Owner</b>”

Deja un comentario