Compartilhe

Polémica: el mejor Product Owner no es el cliente

15/03/18 - 3 minutos de leitura

El Product Owner (PO) es ciertamente el más olvidado de los tres papeles del Scrum. Exactamente por esa razón, muchas organizaciones acaban por adoptar un camino aparentemente más fácil que el formar o contratar a un buen PO: le dan ese papel al propio cliente.

En función de esto, hemos escuchado mucho por ahí la propagación de la idea de que el mejor Product Owner es el cliente. Las principales justificaciones para esa afirmación incluyen el interés del cliente en el éxito del proyecto y su conocimiento sobre el negocio y sus propias necesidades.

¿Pero, será esta realmente una buena idea? Por el contrario. En muchas de las empresas que visitamos en nuestro día a día como asesores, encontramos proyectos en serios apuros, como consecuencia de una profunda falta de armonía entre el PO y el Equipo de Desarrollo. Estas empresas tienen justamente esa característica en común: el PO es el cliente. ¿Pero entonces, por qué tener un PO.-cliente es un problema?

1) El PO-cliente piensa en funcionalidades y no en problemas

El cliente raramente sabe lo que quiere: los clientes generalmente tienen dificultad para entender los propios problemas que hay que resolver y, como consecuencia de eso, no es nada raro que haya clientes que traigan soluciones «hechas» para problemas que ellos aún no han entendido. Un PO-cliente causa la siguiente disfunción en este caso: en vez de llevar problemas de negocio para resolverlos con el equipo, él lleva propuestas de soluciones hechas y que a final de cuentas no aportan mucho valor. El equipo puede hacer exactamente lo que el cliente pidió, pero como los problemas reales no se resuelven, ese cliente no queda satisfecho. ¿Quién no ha visto que esto suceda?

2) ¿Relación de equipo o de cliente-proveedor?

La relación del PO-cliente con el equipo es tensa: en el Scrum, PO, Scrum Master y Equipo de Desarrollo forman parte del Equipo de Scrum, que debe unirse para el proyecto. Solo que cuando el PO es el cliente, la relación deja de ser de equipo y pasa a ser de reclamar. En vez de colaborar con el equipo, el PO pasa a asumir la postura de gestor de proyectos, dado que él mismo es quien está «pagando» por el producto que se está construyendo.

Es bastante común en ese caso ver al PO usando la Daily Scrum como status report, la Retrospectiva para presionar al equipo y el Sprint Planning para empujar «solo una historia más». Además de eso, el PO-cliente, sufre una presión directa y constante de sus stakeholders por resultados. Así pues, en vez de proteger y colaborar con el equipo para organizar el trabajo, el PO-cliente quiere sacar el máximo rendimiento de su «proveedor». Un efecto directo de esto es que para ese PO-cliente todo es prioridad, comprometiendo una de las prácticas esenciales del Scrum: la priorización.

3) Ausencia frecuente

El PO-cliente raramente tiene disponibilidad para estar con el equipo, para resolver dudas y para colaborar para perfilar los ítems de trabajo. De hecho, cuando el PO es cliente, él probablemente está en otro lugar físico, lo que dificulta la comunicación, causando diversas disfunciones en el proyecto. Aliando esta cuestión al problema número 2, la vida del equipo se ve realmente complicada. Incluso cuando el proyecto es interno, el PO-cliente acaba teniendo otras actividades y prioridades, dejando el equipo muchas veces perdido.

Si tu equipo tiene un PO-cliente y tú estáis seguros de que no se enfrentan a esos tres problemas... excelente, pero que sepas que sois una excepción. En el caso general, en Knowledge21 defendemos que el mejor Product Owner NO es el cliente.

Es fundamental que la elección del Product Owner se haga con buen criterio, de manera que se trabaje con alguien que entienda de gestión ágil de productos, que tenga disponibilidad para el papel, que se sepa comunicar con el cliente y las partes de forma eficiente y que trabaje con el Equipo de Desarrollo en un régimen de colaboración continua. Solo así será posible formar un verdadero «Equipo de Scrum», según lo definen Jeff Sutherland y Ken Schwaber, los creadores del Scrum.

Si desea explorar este universo y profundizar en scrum le sugerimos que eche un vistazo a nuestros cursos:
● Certified ScrumMaster (CSM)
● Certified Scrum Product Owner (CSPO) 

Compartilhe

Escrito por

Rafael Sabbagh

Cofundador y Trainer en K21


Rafael Sabbagh, cofundador de K21 y miembro de la Junta Directiva de Scrum Alliance entre 2015 y 2017, es Certified Scrum Trainer (CST) por Scrum Alliance y también Accredited Kanban Trainer (AKT) por Kanban University. Actuando como Ejecutivo, tiene una amplia experiencia en Transformación Digital y Gestión de Productos. A lo largo de su carrera, ha formado a miles de Scrum Masters, Product Owners y Team Members en más de 15 países de Europa, América y Asia.
Esta postagem se encontra sob a licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Artigos relacionados

Inicio del proyecto: la visión del producto
21/11/22
4 minutos de leitura
Métricas de Productos Digitales: cómo crear y rastrear tu producto
08/09/22
4 minutos de leitura
¿Qué es un producto digital?
05/04/21
3 minutos de leitura
Product Backlog: Épico, Historia de Usuario y Tareas
26/05/20
4 minutos de leitura

    ¿Quieres recibir nuestro contenido?

    Escribe tu nombre y correo electrónico para que te informemos todo lo que sucede por aquí.