15

Jun

Publicado por: Xavi Hidalgo | desarrollo | product owner | software development | Working software

El Product Owner en el desarrollo de Working Software

El Product Owner cumple uno de los roles más importantes dentro del Agile, por no decir que es el más importante. Su fuerza, se puede ver reflejada en el impacto negativo que podría provocar tener un “mal” Product Owner o en algunos casos, el no tenerlo.

Es por eso que este artículo del blog quisiera hablar sobre el Product Owner y los deberes que conlleva este rol.

¿De qué se encarga específicamente el Product Owner?

El Product Owner es el responsable del producto y hasta podría decir que es el “emprendedor” de ese producto, dado que él es quien manda y dispone sobre cómo va a ser. Es quien mantiene la integridad funcional, conceptual e incluso técnica del producto.

Entre sus grandes responsabilidades, se encuentran dos indispensables: redactar historias de usuario y priorizar estas historias para darles un orden en el tiempo. Tareas que parecen sencillas pero que son terriblemente críticas para garantizar el éxito del proyecto.

El Product Owner hace también de intermediario entre el equipo y el cliente. Se encarga de la calidad del producto y determina qué criterios debe cumplir el producto para estar en situación de salir al mercado.

Las responsabilidades del Product Owner y cómo afectan en la entrega de working software

Crea y redacta las historias de usuario

El PO es quien entiende lo que el cliente quiere para dar valor a sus usuarios. Esta comprensión va ligada a una mentalidad crítica y analítica que interactúa con los deseos del cliente. El PO tiene que saber decir que “no” cuando el cliente pide funcionalidades que están fuera del alcance del producto, teniendo en cuenta muchas y variadas fuentes de información. También saber decir que sí si es importante, porque hay que adaptar esa petición del cliente a algo realizable y que aporte valor, muchas veces lejos de la primera versión de la idea que el cliente ha concebido.

Crear historias de usuario siempre que el cliente pida algo nuevo ha de hacerse según los criterios del PO porque muchas veces, se tiene la conciencia de que esas historias de usuario nunca se van a realizar y esto solo puede causar frustración y generar ruido innecesario.

Una vez creadas las historias de usuario, el PO organiza esta información en forma de Epics o Componentes. Una Epic podría ser entendida como una historia de usuario que puede ser troceada en historias más pequeñas. Un componente debe entenderse como una parte autónoma de la aplicación que puede desarrollarse y deployarse unitariamente, es decir, sin tener conocimiento del resto.

Luego viene la redacción. Un PO sabe redactar historias de usuario, y más allá del enunciado que todos conocemos.

[Como Usuario] [Quiero logearme en la aplicación] [para acceder a los servicios de la parte privada de la web]

Prioriza las historias de usuario según valor de negocio

Si le preguntamos al cliente qué funcionalidades son indispensables, seguramente nos contestaría que que todas lo son por igual. Esta es una situación de bloqueo, porque no permite determinar por cuál historia de usuario empezar. Un buen ejemplo de ello son las prioridades por categorías (baja, media, alta, urgente). Priorizar por categorías no tiene mucho sentido, de hecho, porque siempre alguien tiene que venir a concretar dentro de las urgente, cuál es la más importante y por tanto, la que tenemos que desarrollar en primer lugar.

El PO prioriza por orden, es decir, el backlog es una lista de historias de usuario en donde la que aparece en primera posición es la que realizaremos primero, y así sucesivamente. Aunque la literatura nos dice que se debe priorizar según unos criterios establecidos:

• Valor para el usuario

• Recursos (tiempos / hombre)

• Innovación

En la mayoría de los casos, el criterio más importante es siempre el valor de negocio, es decir, el valor que le aporta al usuario.

Un PO también tiene que tener en cuenta las dependencias entre las historias de usuario para utilizar este conocimiento en la priorización. De manera que cuando tengamos historias de usuario que son dependientes, el PO gestione su desarrollo para que salgan a producción de manera coordinada.

Transmite la visión del producto al equipo

Es muy importante que el PO le transmita a todos los miembros del equipo correctamente la visión del producto, hacia dónde camina y en última instancia, por qué se crea el producto. Para esto, el PO coordina reuniones con todos los actores involucrados. En esta aproximación se diferencia claramente la metodología Agile. El equipo deja de ser simplemente la “fábrica” para transformarse en parte activa del desarrollo, aportando y confrontando ideas.

Que el equipo tenga clara la visión, la filosofía del producto, que estén impregnados de ilusión y por lo tanto motivados, es tarea del PO.

Crea los sprints y los da por concluidos

Luego de redactar las historias de usuario y priorizarlas, el PO se encarga de crear los sprints cuando sabe que cada historia dentro del sprint está suficientemente clara y explicada. Posteriormente, el PO gestionará con el cliente los tiempos para que las expectativas del cliente estén alineadas con el incremento de producto que tendremos al final del sprint.

Además, el PO determinará qué historias de usuario va a contener el sprint. Esta es una gran responsabilidad que tiene que estar alineada con los deseos del cliente para con el producto. En muchas ocasiones el deploy de funcionalidades también tiene otras consideraciones en el campo del marketing o la venta, porque el cliente coordina en su empresa el deploy con acciones comerciales o de otra índole (eventos, presentaciones, demos a clientes…)

El PO no tiene que forzosamente testear el producto, para ello está el equipo de QA. Pero el PO controla que los tests sean los correctos y que el producto tenga la calidad suficiente como para ser puesto en producción después del sprint.

Dado que el PO escribe los criterios de aceptación de cada historia de usuario, es solamente el PO el que está en situación de determinar si el sprint ha llegado a buen término. Él tiene la última palabra, aunque delegue la responsabilidad en el responsable de QA. Como siempre, por la diferencia de capacidades y cultura Agile de cada equipo y cliente, el PO decidirá para cada proyecto, cuáles son las mejores prácticas en base a su efectividad, siempre teniendo muy presente que el objetivo último es entregar working software, es decir, software que funciona y que representa un incremento funcional para el usuario.

Involucra a todas las partes interesadas

La única manera de saber que estamos creando el producto correcto es obtener feedback. Es necesario saber qué opina el cliente de las entregas y su grado de satisfacción para transmitirlo al equipo y que actúe en consecuencia.

El cliente es una parte muy activa y se deben establecer canales de comunicación entre el cliente y el equipo. Es el PO el que vela porque esta comunicación sea efectiva y fluida y actuará para mejorar o modificar los canales de manera creativa para cada circunstancia que lo requiera.

El PO también será el responsable de comunicar al cliente las limitaciones del producto, o aquellas parcelas funcionales a los que, por los motivos que sean, no se podrá llegar. Tiene que ser un gran comunicador y empatizar con el cliente y el equipo, pues será el nexo de unión de ambas partes.

Controla la calidad del producto

El PO determinará para cada proyecto cuál es la “definición de acabado” y si la historia de usuario cumple efectivamente con lo establecido en los criterios de aceptación.
Cuando una historia de usuario se da por finalizada, solamente el PO puede darla por válida y por
consiguiente, cambiar su estado a “acabado”. El PO podrá implementar sistemas de calidad funcional en caso de ser necesario y también puede utilizar estas métricas de calidad para subir a producción únicamente las historias de usuario que el considere.

El PO decidirá cuándo un bug es bloqueante o no y qué hacer en estas circunstancias.

Genera valor para el usuario

Dada su proximidad con el cliente, el PO será el responsable de optimizar la inversión y obtener el mayor valor posible. También gestionará el estudio sobre qué indicadores son los adecuados para cada producto y mantendrá los indicadores del producto para comunicarle al cliente cuál es el estado de la inversión, qué hacer para mejorar el sistema y obtener mayor ROI.

Controla los tiempos de entrega

Los tiempos de entrega están basados generalmente en el calendario de los sprints, pero también pueden estar sujetos a hitos y fases. Es el PO el encargado de coordinar los tiempos, estableciendo deadlines y fechas de entrega.

El PO debe estar al tanto del progreso de sprints para gestionar los retrasos, por lo que tendrá que comunicarle al cliente y dimensionar el alcance para reducirlo, si es necesario.

Participa en las reuniones de producto

El Scrum prescribe ciertos tipos de reuniones, cada una con un objetivo muy concreto y que son parte integrante del proceso de desarrollo. El PO es un participante activo de estas reuniones:

• Daily: La reunión diaria donde el PO participa y se informa del estado del sprint. Además, puede responder a dudas puntuales que puedan surgir.

• Sprint Planning I: El PO utiliza esta reunión para conocer el tamaño de las historias de usuario y si estas deben trocearse en otras más pequeñas. En el SPM-I se piden estimaciones a alto nivel en puntos de historia. El PO puede utilizar estos datos para el factor “coste” en el establecimiento de prioridades.

• Sprint Planning II: En esta reunión, el equipo baja a tareas técnicas y establece horas ideales de ingeniería para cada tarea. La suma de todas las tareas de una historia de usuario determina su tiempo. La tarea del PO está en participar activamente en esta reunión y estar a disposición del equipo para esclarecer dudas.

• Sprint Demo: En esta reunión, el PO es quien pilota y muestra al cliente los avances hechos. También recoge el feedback y aplica las acciones correctivas necesarias.

• Retrospectiva: A diferencia de las demás reuniones, en esta el PO solo participa como un miembro más, opinando sobre los puntos de mejora y proponiendo soluciones.

Resuelve los conflictos

Como ya te debes haber dado cuenta, la presencia del Product Owner es decisiva en el desarrollo de un proyecto. Es un arte y honestamente, en mi carrera, muy pocas veces he visto a un PO que lo consiga de manera incontestable.

Por esta actividad tan compleja y por todas las responsabilidades que tiene el PO, este rol es crucial. Son muchos y variados los dotes que debe cumplir para poder resolver los conflictos internos y buscar soluciones mediante la argumentación y trabajo activo que se focaliza en el único en el objetivo de llevar el producto al estado de acabado.

¡Si te ha parecido interesante este artículo, puedes suscribirte a nuestro blog o seguirnos en nuestros canales sociales!

CTA-careers-geenral-justdigital

 

Barcelona
Passeig Gaiolà 13
+34 933 801 144
Lleida
Carrer Agustins 7
+34 973 988 222
Andorra
(Escaldes-Engordany)
Parc de la Mola 10, AD700
Bogota
Carrera 9A #99-07 Piso 9. Despacho 02
Torre la Equidad