Empecemos como siempre mirando que nos dice la Wikipedia sobre el rol de Product Owner:
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
Bueno, como primera aproximación a la definición de este rol no está mal pero cuando empecemos a implementar la metodología y estemos metidos en las trincheras veremos que este rol es más complejo que una definición de tres líneas.
¿Cómo debe ser la persona que ocupe el rol de Product Owner? Pues desde mi punto de vista debe ser una persona segura de sí misma ya que al ser la puerta de entrada del equipo tendrá la presión de los diferentes clientes que quieren que sus requisitos sean desarrollados antes que el resto. Desde la dirección de la compañía también se le deberá dar potestades al Product Owner para tomar decisiones, ya que de no ser así al final esta figura dejaría de tener valor convirtiéndose en un mero canal de entrada.
El Product Owner tiene que ser un buen escritor de historias. ¿Y qué es esto? Como ya hemos comentado uno de los artefactos más importantes de Scrum son las historias de usuario. El Product Owner es el encargado de escribir dichas historias para comunicar al equipo las diferentes funcionalidades que se incorporarán en un sprint. Por tanto, el Product Owner tiene que hacer foco en adaptar su lenguaje a un lenguaje que el equipo pueda entender. Las historias deben estar bien explicadas y deben quedar claros los criterios de validación de la misma.
Como propietario del producto se encargará de supervisar que los resultados del proyecto son los esperados y que se consigue maximizar la rentabilidad del producto. Esto suena muy bien pero cómo llevar a cabo estas responsabilidades. El Product Owner deberá trabajar estrechamente con el equipo para evaluar que las historias que se desarrollan son las más importantes (priorización de historias). Al inicio de cada sprint deberá re-evaluar las historias para asegurarse que en el próximo sprint las historias que están en lo más alto de la pila son las que permitirán dar un mayor valor tanto al producto como al cliente final. También participa en la presentación del resultado obtenido tras cada sprint validando que las soluciones implentadas cumplen con los criterios de validación (en un entorno ideal esta tarea debería realizarse durante el sprint con la finalidad de adelantarnos a posibles desviaciones).
Ahora imaginemos que queremos desarrollar nuestros productos en nuestra empresa utilizando metodologías ágiles. Ya tenemos un equipo de trabajo y queremos aprovecharlo. ¿Qué perfil se adecúa mejor a este nuevo rol? La respuesta como en muchos casos es depende. Si nuestra compañía es una empresa final, seguramente tendremos un departamento de producto y un departamento de desarrollo. La solución más fácil es escoger un Product Manager para el puesto de Product Owner. En cambio, si estamos en una empresa dedicada a ofrecer servicios a terceros quizás la aproximación más razonable sería la transición de Jefe de Proyectos a Product Owner ya que este perfil cumplirá muchos de los requisitos que hemos definido anteriormente.
Otra pregunta que suele surgir muy a menudo es: ¿El Product Onwer se debe mantener fijo en el tiempo para un equipo o debe variar según el desarrollo que se realiza? Mi opinión es que el Product Owner debe ser siempre el mismo para un equipo Scrum. ¿Por qué? Cada equipo Scrum tiene su propio ecosistema, lo que funciona en un equipo puede no funcionar en otro. La adaptación entre las diferentes personas que conforman el equipo lleva su tiempo, cuanto más se conocen las personas más se refuerzan los lazos de identidad y el trabajo debería mejorar. Si vamos cambiando en el tiempo al Product Owner siempre tendremos un tiempo de aclimatación (como comprenden mejor las historias los miembros del equipo, que se les puede pedir y que no, que les motiva, etc.). Obviamente esto influye directamente en el rendimiento del equipo.
Como propietario del producto se encargará de supervisar que los resultados del proyecto son los esperados y que se consigue maximizar la rentabilidad del producto. Esto suena muy bien pero cómo llevar a cabo estas responsabilidades. El Product Owner deberá trabajar estrechamente con el equipo para evaluar que las historias que se desarrollan son las más importantes (priorización de historias). Al inicio de cada sprint deberá re-evaluar las historias para asegurarse que en el próximo sprint las historias que están en lo más alto de la pila son las que permitirán dar un mayor valor tanto al producto como al cliente final. También participa en la presentación del resultado obtenido tras cada sprint validando que las soluciones implentadas cumplen con los criterios de validación (en un entorno ideal esta tarea debería realizarse durante el sprint con la finalidad de adelantarnos a posibles desviaciones).
Ahora imaginemos que queremos desarrollar nuestros productos en nuestra empresa utilizando metodologías ágiles. Ya tenemos un equipo de trabajo y queremos aprovecharlo. ¿Qué perfil se adecúa mejor a este nuevo rol? La respuesta como en muchos casos es depende. Si nuestra compañía es una empresa final, seguramente tendremos un departamento de producto y un departamento de desarrollo. La solución más fácil es escoger un Product Manager para el puesto de Product Owner. En cambio, si estamos en una empresa dedicada a ofrecer servicios a terceros quizás la aproximación más razonable sería la transición de Jefe de Proyectos a Product Owner ya que este perfil cumplirá muchos de los requisitos que hemos definido anteriormente.
Otra pregunta que suele surgir muy a menudo es: ¿El Product Onwer se debe mantener fijo en el tiempo para un equipo o debe variar según el desarrollo que se realiza? Mi opinión es que el Product Owner debe ser siempre el mismo para un equipo Scrum. ¿Por qué? Cada equipo Scrum tiene su propio ecosistema, lo que funciona en un equipo puede no funcionar en otro. La adaptación entre las diferentes personas que conforman el equipo lleva su tiempo, cuanto más se conocen las personas más se refuerzan los lazos de identidad y el trabajo debería mejorar. Si vamos cambiando en el tiempo al Product Owner siempre tendremos un tiempo de aclimatación (como comprenden mejor las historias los miembros del equipo, que se les puede pedir y que no, que les motiva, etc.). Obviamente esto influye directamente en el rendimiento del equipo.
No hay comentarios:
Publicar un comentario