El product owner Gollum

1

Ya van varias publicaciones de personas de referencia en las que veo el rol del product owner definido de una manera que no me gusta. Una lectura simple de la guía scrum puede llevar a pensar en que el product owner es todopoderoso en lo que respecta al producto. Mi opinión es muy diferente.

¿Qué se dice por ahí?

Veamos varias de las tareas, no todas, que se le asignan al product owner según muchos autores, y que veo en muchas organizaciones:

  • Describe las historias de usuario y los criterios de aceptación de las mismas.
  • Decide qué se hace y qué no se hace.
  • Decide la prioridad de las distintas tareas.
  • Pacta con el equipo lo que se realizará en cada sprint
  • Define el product backlog y lo comunica al equipo.
  • Resuelve las dudas del equipo.
  • Maximiza el valor entregado al negocio.
  • Valida la entrega y decide si va a producción.

No sé si ya ves por donde van los tiros, pero a mí me da que estamos creando un Gollum, y podéis seguir el link para ver lo que entiendo por un Gollum. El product owner es el que decide, es el que valora, es el que toma toda las decisiones estratégicas. Es el puto amo y señor del producto. Sabe lo que negocio necesita, no le hace falta preguntarlo. Y el equipo está a sus órdenes. El equipo va a hacer lo que el product owner diga. ¿Me decís que diferencia tiene esto con un jefe?

Lo que luego sucede

Lo que luego pasa es inevitable. Primero de todo, el product owner comenzará a actuar como un jefe, y el Scrum Master pasa a ser un secretario del equipo. He visto equipos en los que el product owner daba órdenes al equipo: “deja eso”, “enséñamelo… no me gusta, ahora así”, “esto lo hará Pepito”. No tarda en querer saber cuándo tendrán vacaciones, y querrá aprobarlas él. ¿No nos damos cuenta de que eso es una jerarquía tradicional y que de ágil tiene sólo una capa de pintura?

Pero lo peor de todo no es que estemos creando un jefe, es que ese product owner se siente como que el producto es suyo. Su opinión es la única que cuenta y no pregunta nada a nadie. Y eso tiene el peor de todos los impactos: olvidarse de los interesados. Los interesados son el resto de la organización. Es la gente de negocio, los de ventas, los directores, los clientes, … cualquiera que su trabajo se vea impactado por el nuevo producto. Cuando los interesados comienzan a quejarse de que “No sabemos qué hace el equipo”, “Es que todavía no hemos visto ni un diseño o ni una pantalla”, “Es que no sabemos cuándo estará”; significa que hemos creado un product owner gollum.

La gestión de interesados es una pieza clave en la gestión de proyectos clásica. Muchos autores, y PMBOK incluído, indican que más del 70% del tiempo del project manager se dedica a la gestión de interesados. ¿Vamos a perder esto por implantar la agilidad? No. El product owner debe atender a los interesados.

Si el product owner desatiende a los interesados pasarán tres cosas:

  • No podrá valorar correctamente el valor que tienen las historias para negocio. Una persona sola nunca podrá analizarlo mejor que los interesados.
  • No podrá alinear el producto a los objetivos de la organización. Al final, por muy ágiles que seamos, existirá en la organización algún tipo de gestión de programa o cartera de proyectos. Algún rol estará encargado de revisar a donde deben ir los productos. O si no cada product owner hará lo que le plazca, sin dirección alguna. Ya sea una gestión centralizada y clásica, o colaborativa, estaremos hablando de interesados clave.
  • No se tendrá en cuenta el impacto en terceros. ¿Estan los de seguridad de acuerdo con lo que vamos a hacer? ¿El departamento legal ha opinado sobre ese circuito de venta online? ¿Los administradores están de acuerdo con la librería que se va a incluir?… Son interesados clave.

El resultado final

Lo que sucede al final es que el producto entregado no aporta valor a negocio. Tendrá muchas posibilidades de ser desechado por los interesados o bloqueado. ¿De qué sirve hacer el mejor backoffice del universo si los usuarios se niegan a usarlo porque no se les ha tenido en cuenta?

No hay mucha diferencia entre una gestión clasica de proyecto con una entrega final y el hacer entregas iterativas sin que las vean los interesados y sin contar con su opinión.

Mi visión del product owner

El product owner debe heredar la mayoría de las funciones que se definen para un project manager. Sobretodo las referentes a la gestión de interesados. No debe imponer sus criterios, sino ser la persona que sirve de vínculo entre el equipo y los interesados. Debe ser alguien orientado a cumplir las expectativas de los interesados y maximizarles el valor entregado.

Así reescribiría todas las características del product owner a:

  • Describe las historias de usuario y los criterios de aceptación de las mismas.
    • Pacta con los interesados las historias de usuario y se asegura de que los criterios de aceptación sean suficientes.
  • Decide qué se hace y qué no se hace.
    • Pacta con los interesados qué se hace y qué no se hace.
  • Decide la prioridad de las distintas tareas.
    • Prioriza las tareas según los criterios que ha pactado con los interesados.
  • Pacta con el equipo lo que se realizará en cada sprint
    • Pacta con el equipo y con los interesados lo que se realizará en cada sprint.
  • Define el product backlog y lo comunica al equipo.
    • Define el product backlog, según las necesidades que le han transmitido (de acuerdo al valor que le comunican los interesados y a los objetivos que le ha marcado la organización) y los comunica a todos los interesados.
  • Resuelve las dudas del equipo.
    • Resuelve las dudas de todos los interesados.
  • Maximiza el valor entregado al negocio.
    • Asegura que el valor entregado sea máximo según los criterios que le indican los interesados.
  • Valida la entrega y decide si va a producción.
    • Presenta la entrega a los interesados, y conjuntamente la validan y pactan su puesta en producción.

Por cierto, el equipo entra dentro del grupo de interesados. Así que cuando hablo de interesados, se incluye al equipo.

Pasamos de un jefe, a un facilitador.

Qué nos dicen el manifiesto ágil y la scrum guide

Tres de los cuatro valores del manifiesto ágil van en la línea de este artículo:

  • Individuos e interacciones sobre procesos y herramientas: “Interacciones” es la palabra clave. No sólo dentro del equipo sino con el exterior, los interesados.
  • Colaboración con el cliente sobre negociación contractual: El cliente o clientes son los principales interesados.
  • Respuesta ante el cambio sobre seguir un plan: Es decir, no hay que seguir el plan del product owner sino evaluar con los interesados el entorno y responder a los cambios.

Y si vamos a los principios del manifiesto nos encontramos con:

  • Nuestra mayor prioridad es satisfacer al cliente […]: ¿Cómo le vamos a satisfacer si no hablamos con él?
  • Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto: El product owner es el que permite este trabajo conjunto y cotidiano.

Y la scrum guide no detalla cómo debe ser ese rol (“How this is done may vary across organizations”). Pero si me quedo con una segunda lectura de estas expresiones:

  • The Product Owner is the sole person responsible for managing the Product Backlog: Dos comentarios con repecto a esta frase. Primero habla de “managing”, es decir, gestionar. Gestionar el product Backlog no es decidirlo todo, sino gestionarlo. Segundo usa la palabra “responsible”, que no es responsable sino encargado, que es un false friend típico de la matriz RACI.
  • Ordering the items in the Product Backlog to best achieve goals and missions: ¿Cómo sabe el Product Owner cuales son los objetivos y misiones? Yo te lo digo, preguntando continuamente a los interesados.
  • Ensuring that the Product Backlog is visible, transparent and clear to all: ¿Ha dicho a todo el mundo? ¿No sólo al equipo? Claro que ha dicho a todo el mundo. Los interesados deben estar perfectamente informados en todo momento de lo que se hace y se va a hacer.
  • The product owner may represent the desires of a committee.

Desde mi humilde punto de vista no dice en ningún momento que actúa por libre. Lo que dice es que es la puerta de entrada para hablar con el equipo. Si se necesita algo, se pide al product owner.

Conclusiones

El product owner es un facilitador y comunicador. No debe tomar decisiones unilaterales, sino ser capaz de entender a todo el mundo y alinearlo. Es un mix entre las responsabilidades de gestión de alcance e interesados de un jefe de proyecto clásico.

Aún así, es una figura clave.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

1 comment

Post a new comment