El mal Product Owner

El mal Product Owner

En el post sobre el Product Owner estuvimos hablando sobre qué se espera de un profesional que desempeñe este rol.

Ser Product Owner implica una gran responsabilidad y un profundo conocimiento, así que es fácil encontrarte con muchos Product Owners que no cumplen con todos los requisitos que se piden a este fundamental rol de Scrum.

Y por desgracia, es demasiado común encontrarte Product Owners reciclados a partir de puestos de negocio que no saben, o no quieren saber, y que pueden convertir tu proyecto en un auténtico desastre.

En este post analizaremos esta aciaga figura: la del mal Product Owner.

Si tuviésemos que describir todas las responsabilidades del Product Owner en una sola, diríamos que lo que se espera de él es que maximice el valor de producto.

Para ello, el Product Owner debe cumplir con una serie de tareas y no todos saben, o quieren, llevarlas a cabo…

Cómo actuará un mal Product Owner

Un Dueño de Producto que no actuará como tal adolecerá de una serie de defectos que te expongo a continuación.

No se hará responsable del ciclo de desarrollo del producto

Se comportará como un cliente de tecnología, a la vieja usanza del rol de negocio. Por tanto, si las cosas no van bien, culpará al Equipo de Desarrollo y considerará que es una pobre víctima de los informáticos. En resumen, actuará como los usuarios de negocio más rancios.

No tendrá un conocimiento profundo del negocio/mercado

No conocerá el negocio ni el mercado con la suficiente profundidad como para saber idear un producto que resulte rentable. Por tanto, será incapaz de orientar al Equipo de Desarrollo.

Al contrario, soltará perlas del estilo ¿Cómo hicisteis tal cosa en otros proyectos? Pues en éste hacedlo igual…

Por supuesto, esa falta de conocimiento le impedirá discernir qué es importante y qué son banalidades, de modo que le será imposible priorizar correctamente.

Además, su falta de liderazgo y de conocimiento en el negocio le dificultará reunir a las diferentes áreas de negocio y stakeholders como para poder sacar de ellos la información necesaria para idear un producto valioso y alineado con la legalidad o la normativa correspondiente.

Esto es un problema importante, ya que en cualquier momento durante los desarrollos, puede surgir un stakeholder, por ejemplo Asesoría Jurídica, que te obligue a cambiar el paso debido a que te falta, o te sobra, una o varias funcionalidades para cumplir con la ley.

No sabrá crear las historias de usuario

Será incapaz de crear un Product Backlog con un conjunto de historias que reflejen las necesidades de negocio de forma incremental.

Cada historia de usuario corresponderán a funcionalidades completas de forma que los desarrollos serán todo o nada, es decir, se perderá el sentido de desarrollo iterativo e incremental.

Además, no sabrá redactar las historias de usuario para que cualquier profano al negocio pueda entenderlas. No recogerán todos los criterios de aceptación y presentarán ambigüedades, lo que será una fuente continua de conflicto con el Equipo de Desarrollo.

No sabrá priorizar el Product Backlog

Desconocerá que el Product Backlog debe desarrollarse de los más importante a lo menos, e irá metiendo historias de forma discrecional sin cuestionarse su valor de negocio. Y pondrá como excusa que al fin y al cabo él o ella quiere que se haga todo.

Así que te encontrarás que funcionalidades triviales (y puede que incluso complejas de desarrollar) se terminan abordando antes que funcionalidades básicas.

No hará seguimiento de los desarrollos

Es imprescindible que el Product Owner detecte en el producto cualquier desviación respecto a las expectativas del usuario.

Y para eso tenemos la Sprint Review como evento especialmente pensado para ello. Este evento es vital de cara a inspección y la adaptación. No obstante no es necesario esperarse a la Review, cuanto antes inspecciones y adaptes cualquier posible desviación, tanto mejor.

Pero el mal Product Owner no realizará una buena inspección. De hecho, algunos ni se molestan en asistir a las Review.

¿Cuál será el resultado de esto? las desviaciones no se detectarán en el mismo Sprint. Así que el producto seguirá desviándose cada vez más hasta que se parezca a lo que espera el usuario como un huevo a una castaña. Entonces el mal Product Owner pondrá el grito en el cielo diciendo que el DevTeam son unos ineptos…

Créeme, hablo por experiencia.

Será mal comunicador

No sabrá transmitir al Equipo de Desarrollo las necesidades de negocio en un lenguaje que el equipo entienda. Los malentendidos con el Equipo de Desarrollo serán continuos.

No empatizará con el resto del Equipo Scrum

Su implicación dentro del Equipo Scrum será poca o nula y no empatizará con él. Se comportará como el clásico tipo de negocio que le dice a los informáticos, desde su púlpito, qué tienen que hacer. No se meterá en el barro junto a ellos ni tendrá espíritu de equipo.

No estará disponible

Estará perdido en combate cuando el resto del Equipo Scrum lo necesite. Esto es consecuencia del punto anterior. Los refinamientos serán para él una molestia o un capricho de los desarrolladores.

No tendrá autoridad

Esto no es un problema de falta de profesionalidad de la persona en particular, más bien se trata de una falta de compromiso por parte de la Organización.

Un Product Owner debe tener la suficiente potestad para poder desempeñar su rol: decidir sobre los requisitos que se desarrollarán, priorizarlos, etc.

Si en cambio pones en ese papel a un hombre de paja, alguien que no pinta nada, directamente te estás cargando las posibilidades de este rol.

Product Owner irresponsable, ¡tú no seas así!

Reflexión final

No es fácil encontrar buenos Product Owners. La mayoría de ellos son gente con bastante experiencia de negocio y con más o menos experiencia trabajando con equipos de desarrollo.

Un buen día les dicen desde la gerencia «mira, ahora está de moda esto de Scrum, así que a partir de hoy serás el Product Owner del proyecto».

En la mayoría de casos a los pobres los lanzan a la piscina sin darles la más mínima formación ni nociones de lo que se espera de ellos. Algunos ponen toda su buena voluntad y se dejan aconsejar por el Scrum Master y por el DevTeam y terminan siendo Product Owners más o menos solventes.

Y otros, negándose a bajarse de su pedestal, se ponen a la defensiva y no aceptan que un Product Owner no es lo mismo que hacían antaño, pero con un nombre más molón. Trazan una frontera insalvable entre ellos y tecnología y terminan siendo un problema más que una ayuda.

Y estos últimos, por desgracia, suelen cargarse el proyecto en el que caen.

Te puede interesar:

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario