Claves para implantar el rol de Product Owner, uno de los roles clave en un desarrollo ágil (2/2)

Este post es la segunda y última parte del la serie sobre consideraciones a la hora de implantar el rol de product owner. Te dejo el enlace a la primera parte.
—

Cuando el cliente toma el rol de product owner

Esta es una de las maneras más comunes, pedir al cliente que tome el rol de product owner. Así trabajan normalmente las empresas que desarrollan software a medida o “llave en mano”, y con proveedores externos (y métodos ágiles, claro).
En esta situación, el cliente, que toma el rol de product owner, dirige y controla el desarrollo del software directamente. Esto acelera la toma de decisiones y aumenta la posibilidad de crear un producto que responde a sus necesidades.
El problema, muchas veces, viene de que el cliente debe estar altamente disponible, cualificado para esta tarea y con ganas de que se desarrolle un producto de éxito. Cliente y el equipo deben desarrollar una relación sana y de confianza.
Pero muchas veces, en esta situación, sobre todo cuando el proveedor es externo, no es tan fácil, ya que suelen aparecer diferentes intereses. En proyectos tipo “llave en mano”, muchas veces el proveedor de desarrollo quiere terminar cuanto antes y el cliente obtener la máxima funcionalidad.

Cuando una persona que representa al cliente (o clientes) toma el rol de product owner

Como es sabido y antes mencioné, uno de los problemas de los product owners es la dedicación, ya que en los proyectos ágiles la figura del product owner debe estar altamente disponible para el equipo, y esto no es siempre posible. Para ello, si el cliente no tiene mucha disponibilidad, muchas veces asigna una persona totalmente dedicada a representarle.
Otras veces también ocurre que el software es para varios clientes, y un único product owner suele actuar como representante de los mismos, escuchando ideas y necesidades de varios clientes y usuarios, y decidiendo cuándo estas debieran implementarse.
En esta situación, en la que un product owner representa al cliente, son gerentes, comerciales, o analistas de negocio los que suelen tomar este rol. Lo que no quita que muchas veces, junto con el product owner, los clientes y usuarios participen en reuniones puntuales con el equipo de desarrollo, como, por ejemplo, aquellas para revisar las entregas.
El reto en esta tipología es lograr tener un product owner con conocimiento funcional, y la confianza y apoyo de clientes, usuarios o directivos, así como la capacidad de poder tomar decisiones.
Por problemas como los anteriores, este tipo de implementación “proxy” del product owner es criticada en ciertos foros más puristas, pero el mundo real es el mundo real, y esta segunda tipología se observa cada vez más.

Algunas fuentes para continuar…

Hay mucho escrito sobre este tema. El post es solo un resumen de lo mucho que se podría hablar. No obstante, por si quieres continuar, te recomiendo Product owners not proxies de Ken Schwaber, The Product Owner Role: A Stakeholder Proxy for Agile Teams de Ambler y Two Common Ways to Apply the Product Owner
Cualquier copmentario.. aquí o en twitter (@jgarzas)

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
• Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
• Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024