Actores del proceso de desarrollo, PO

Anamnesis de un motivado

Actores del proceso de desarrollo, PO

Resumiendo la anterior entrada, en ella os mencionaba la figura del PM. Un actor con don de gentes, capaz de empatizar al máximo con el cliente y el equipo. Habilidoso para ver y mostrar al cliente lo que realmente necesita sin dejar de mirar el lado de la rentabilidad y la oportunidad de negocio.

Y… ¿Todo esto para que vale?

Toda la información que el PM acumule es el guión para el siguiente actor, el PO o product owner. A este guión se le conoce como especificación funcional.

Ahora el PO tiene la ardua tarea de transformar ese texto que describe lo que el cliente necesita en una secuencia de tareas funcionales. Digo ardua porque el PO es la persona que se enfrenta a la disyuntiva entre lo que la especificación describe y lo que el equipo de desarrollo considera oportuno para materializarla. Para ello confecciona una secuencia de tareas en al que cada una de genere un resultado enseñable, una funcionalidad resuelta o una mejora.

Un ejemplo muy sencillo. Un cliente nos pide una hamburguesa. La primera tarea puede ser poner en un plato solo carne y pan, la siguiente agregarle lechuga, la siguiente tomate. Así sucesivamente hasta tener una hamburguesa completa con su huevo, salsas, patatas y refresco. Lo cierto es que el resultado obtenido tarea tras tarea es una hamburguesa. No ha empezado siendo un plato muy suculento, pero costó poquísimo y el PO pudo ir enseñando el resultado e ir refinandolo.

Es lógico pensar que un plato solo con lechuga, no es una hamburguesa. Así que, otra de las actividades es la priorización de tareas. El objetivo fundamental es que los resultados de cada tarea resuelta sea un MVP, minimum viable product. Está claro que es un ideal, no siempre alcanzable. Pero es lo deseable.

El PO no entra en el detalle de cómo se cocina la carne, ni si la lechuga viene de Almería o de Sudamérica. Pero si tiene el criterio y los conocimientos para saber cómo debe ser la hamburguesa. Ese criterio se traslada al equipo de desarrollo en la descripción de la tarea funcional como DOD, definition of done.

Sintetizando un poco la analogía. El PO se encarga de configurar la sucesión de tareas funcionales para que de forma incremental e iterativa el equipo pueda resolver un conjunto de funcionalidades.

Hasta ahora os he hablado sobre las obligaciones de este actor. Más allá de lo escrito en un papel… existen otras habilidades muy útiles, que son decisivas para el buen funcionamiento del equipo. Como por ejemplo, la capacidad de motivar. Ante un obstáculo, el equipo busca en el PO consejo, experiencia, sabiduría, motivos. Es una figura de autoridad que debe aportar el empuje preciso en la dirección correcta, para que todo avance. También debe ser conocedor de cuantas más metodologías de gestión de equipos, mejor. No es el encargado de seleccionar una de forma autoritaria, pero al tener esa figura de liderazgo, su opinión es tenida muy en cuenta. Y con ello puede proponer el uso de la metodología que más propicie el buen funcionamiento del equipo.