Jueves, 12 Diciembre 2013 10:18

Qué pasa cuando el product owner no es el "dueño del producto"... Destacado

Escrito por
Valora este artículo
(0 votos)

En Scrum, uno de los roles es el de "dueño del producto" o "product owner", y es uno de los pilares que hace funcionar la ecuación del trabajo en equipo bajo esta metodología, pero hasta ahora he visto muy pocos "dueños del producto" que correspondan con quien realmente va a terminar siéndolo... por lo que me ha tocado trabajar hasta ahora, el dueño del producto no suele ser quien finalmente lo usará o lo poseerá, sino personas que la empresa (o la empresa contratista) identifica como quienes deberán dar las pautas al equipo de desarrollo... una especie de "super analista funcional pero solo en el nivel conceptual".

A mi parecer, este no es el rol previsto en esta metodolo(filoso)fía, y puede ser causa de riesgo de fracaso del proyecto. Veamos un poco por qué:

 La última versión de la Scrum Guide (julio 2013) indica que el dueño del producto es responsable entre otras cosas de:

  • maximizar el valor del producto y del trabajo del equipo de desarrollo
  • la gestión del product backlog, priorizarla y asegurar su visibilidad y comprensión
  • debe ser una única persona (no está permitido que este rol sea desarrollado por un comité)

Obviamente no es lo único que dice al respecto, pero sustancialmente son estas las características que menciona.

Creo sin embargo que esto por sí solo no asegura que se siga la filosofía de scrum (así como la adherencia a los rituales de scrum no asegura por sí mismo que el equipo sea ágil).  Esta es mi visión al respecto (en particular cuando el dueño del prodcuto no es el "dueño" del producto sino alguien designado en la empresa para cubrir este rol):

El dueño del producto debe ser quien tiene la visión y la idea del producto que se desea desarrollar (se trate esto de un producto software o de cualquier otro tipo). El es quien indica el rumbo hacia donde deben estar orientados todos los esfuerzos del equipo en lo que respecta al producto (no olvidemos que el equipo también destina esfuerzo a la mejora continua y al proceso). Además de eso, es quien gestiona el budget del proyecto y quien por lo tanto tiene poder de decisión sobre qué funcionalidades incluir en un release o no. Por último, es quien puede dar por finalizado un proyecto (si el contrato lo permite), y quien finalmente asegura que el proyecto sea un éxito o un fracaso mediante la transmisión al equipo de su visión de producto y del negocio.

Es una gran tarea, y requiere de mucho tiempo y esfuerzo, además de dotes de disciplina e inteligencia emocional no menores...

Sin embargo, por lo que he visto o me han comentado, no es infrecuente que quien es designado como dueño de producto lo sea a tiempo parcial (y generalmente con una prioridad menor respecto a otras tareas). Esto de por sí puede ser grave, pero sería subsanable si el equipo sostiene y colabora con su dueño del producto. El problema real que he visto, es que al ser percibido por el product owner como un trabajo de baja prioridad respecto a los otros que ejecuta, provoca un nivel de compromiso no adecuado a lo requerido a este rol, y por lo tanto:

  • el equipo percibe este bajo nivel de compromiso, por lo que suelen de consecuencia disminuir su propio compromiso al no sentir valorado el producto
  • la definición puede ser superficial, lo que propicia equívocos y malinterpretaciones durante el sprint y a posteriori. Este no es un punto menor ya que para evitar futuros conflictos, se suele elegir escribir mayor documentación de la que generalmente sería necesario al desarrollo, pudiendo llegar a determinar, al interno del equipo, una relación de tipo contractual... lo que supone, en la filosofía agile, una aberración.
  • el PO puede no dedicar el tiempo y esfuerzo necesario  a desarrollar una visión del producto, o no sentirse respaldado por los sponsor para tomar decisiones al respecto, convirtiéndose en un PO proxy que se dedica solamente a transmitir las consultas a los verdaderos "dueños del producto". Esto en el fondo no hace más que agregar probables errores de interpretación entre quien realmente desea el producto (diríamos el "product owner natural") y 
  • y por sobre todas las cosas, al no tener visión del producto ni poder de decisión, no podrá hacerse cargo de sus propias decisiones ya que los errores no serán percibidos como disparadores de aprendizaje sino como riesgos para su carrera, para peor en una tarea de baja prioridad... En este marco, es bastante usual que el PO tienda a "descargar sus errores" en los otros miembros del equipo, sea este el equipo de desarrollo o el scrum master.

Estos son los principales problemas que he detectado en estos casos, pero posiblemente no sean los únicos, y vos tengas algún otro para compartir...

No digo con esto que no sea posible que el product owner sea una persona designada a tal efecto. Lo que quiero puntualizar es que esta tarea requiere de mucha capacidad, dedicación y esfuerzo, y que no puede ser tomada a la ligera ni por quien realiza la designación, ni por quien tiene la suerte de ejecutarla.

 

 

Leer 2642 veces Modificado por última vez en Lunes, 11 Agosto 2014 14:59
Volver arriba