Agile promueve que el equipo trabaje manteniendo en forma continua el feedback con el cliente mediante un proceso iterativo dividido en sprints.
Aquí, en el feedback, entra en juego el product owner (P.O). Su función principal es negociar desde la visión del cliente, tanto con el scrum master como con el equipo, cuáles son las prioridades dentro de todas las tareas a realizar, pensando siempre en la priorización que otorgue un retorno de inversión. Por lo que debe conocer muy bien el negocio a fin de poder decidir entre las prioridades y tomar decisiones sobre lo que NO debe hacerse ya que no aportará valor a la empresa.
Se trata de un intermediario; en un extremo se encuentran los interesados: directores de marketing, de finanzas, otros directivos, etc y en el otro extremo se encuentra el equipo. El P.O. debe intermediar eficazmente entre ambos, es un mediador que debe mantener siempre como punto de referencia el valor para el negocio. Dependiendo de la visión o tamaño de la empresa puede o no ser recomendable que sea parte del equipo y tampoco que sea el Scrum Master, ya que se producirían choques por intereses encontrados. La mayoría de las veces el P.O. , o al menos en los proyectos que he trabajado, surge como un rol proveniente del cliente.
Tareas que debe desempeñar el Product Owner
Suponemos que es el único interlocutor ante el equipo representando a las personas interesadas en los resultados del proyecto. Aunque en la práctica esto no es una norma que yo vea usualmente en las empresas y tampoco creo que debe ser de este modo, aunque sí debiera ser consultado y tomar decisión sobre las preferencias en las tareas.
1- Definir las características del producto o proyecto. Es el propietario de la planificación del proyecto.
2- Establecer las fechas de lanzamiento y contenido. Esto lo hace repartiendo al equipo los objetivos y requisitos en iteraciones y definiendo el plazo de entrega.
3- Es el responsable de la rentabilidad del producto (ROI).
4- Debe tener en cuenta las características del producto en función del mercado. Para ello tiene en cuenta: los requisitos que aportan más valor al producto/proyecto, los requisitos completados en la iteración anterior y también el contexto del momento, o sea tener en cuenta los requerimientos del mercado, movimientos de la competencia, etc.
5- Debe participar en la reunión de planificación de iteración, para colaborar con el equipo, exponiendo los requisitos más importantes, respondiendo dudas, etc. Además, estar disponible durante el curso de cada iteración. Podrá ajustar las características y prioridades
6- Participar en la reunión de demostración de la iteración, controlando los requisitos alcanzados. En esta instancia puede aceptar o rechazar los resultados del trabajo o proyecto.
¿Cómo sería el P.O. ideal?
Es sin dudas un rol bastante complicado en dónde creo que la virtud está en las habilidades de comunicación y buena relación con todas las partes. El conocimiento del negocio y las habilidades comunicacionales, a mi criterio, las principales aptitudes, sin olvidar la capacidad para distinguir entre lo que realmente aporta valor al negocio y lo que no.
Es muy común encontrarse con una gran lista de funcionalidades deseadas que han ido llenándose a partir de las distintas conversaciones con los departamentos de IT, marketing, ventas, etc. inclusive con items añadidos a partir de los usuarios finales del producto. La capacidad de distinguir entre todas ellas, encontrar puntos en relación y priorizarlas será fundamental para el éxito del proyecto.
Su buen criterio y su capacidad para comunicarse con el equipo teniendo en cuenta siempre la capacidad del mismo ayudarán a crear un entorno ameno y bien dirigido.
Obviamente el P.O. no es un “puedelotodo” necesita indefectiblemente de los distintos roles del equipo y su colaboración, el scrum master, el team, etc.