Cuando describimos las funciones del Product Owner siempre hablamos de que es el responsable de definir lo que se va a hacer. También gestiona el Product Backlog, que contiene todo aquello que nuestro producto podría llegar a incluir. Sin embargo, nos cuesta mucho romper la barrera mental que supone trabajar en modo predictivo (todo lo que haremos), versus modo adaptativo (escuchar de manera contínua a mi usuario), y esa es la verdadera potencia del framework Scrum.
Gracias al libro User Story Mapping de Jeff Patton, analizamos toda la potencia que tiene un Product Owner más allá de “escribir historias de usuario”. Os contamos a qué se dedica el Dueño de Producto.
¿A qué dedica su tiempo el Product Owner?
Siempre se dice que un buen Product Owner invierte la mitad de su tiempo con el equipo y la otra mitad de su tiempo con los usuarios. Scrum define muchos eventos en los que el Product Owner interactúa con su equipo. ¿Cuándo lo hace con los usuarios?
A medida que he ido ganando experiencia en Scrum, he ido viendo a más Product Owner tener conversaciones de manera continua con sus usuarios. Sin embargo, todavía la mayoría pasan más tiempo reportando a sus jefes, que pasando tiempo con las personas que van a recibir el software que están construyendo.
Seguimos viviendo en la cultura del control y no en la cultura del resultado y del beneficio. Parece que reducir costes es la única manera de mejorar los beneficios y, por eso, tenemos más métricas de rendimiento del equipo que métricas de valor.
El Product Owner como periodista
El Product Owner es un narrador de cómo el usuario utiliza su producto. Describe de qué manera esa persona consigue un objetivo gracias al uso de una herramienta (que todavía no existe). El software es un medio por el que la sociedad consigue cosas: vender productos, ser más eficiente, cumplir con la ley… un Producto Owner trata de describir a las personas que van a construir el producto, lo que el usuario siente, ve, dice, escucha y piensa.
Evidentemente, un buen Product Owner intenta adelantarse a las necesidades de sus usuarios o resolver problemas que todavía no saben que tienen para crear nuevas necesidades. Las redes sociales no las necesitábamos ni existía una demanda social. Pero, hoy en día, cubre muchas necesidades como las de estar informados de manera rápida, poder hablar con personas con las que no solemos hacerlo, mostrarnos habilidades en el mundo profesional, tener un lugar donde expresarnos, compartir archivos multimedia, divertirnos…
Un Product Owner debe pensar en futuro, en cómo ese usuario alcanza sus objetivos gracias al nuevo producto que estamos construyendo.
La historia de usuario es la crónica
Las historias de usuario nunca fueron concebidas como otra técnica de toma de requisitos más. Una buena historia de usuario no describe el software, describe cómo el usuario gana con esa nueva funcionalidad. Es una crónica que utiliza el periodista para transmitir lo que ha hablado y lo que ha visto con sus usuarios. De hecho, es muy buena práctica dejar que los usuarios escriban su propia historia. Centrémonos en el problema que tienen actualmente, cómo trabajan hoy y no tanto en la solución (visión prescriptiva).
Dado que un nuevo producto genera nuevas oportunidades, debemos tener en cuenta que la visión adaptativa es la que nos permita entregar valor de manera contínua, y esto nos genera un engagement del usuario con nuestro producto.
El usuario usa el producto, no nosotros
Os animamos a que probéis este pequeño ejercicio. En primer lugar, transparentar a vuestros usuarios las historias. Haced talleres de co-creación donde los usuarios, el Producto Owner y las personas del Development Team que consideremos participen. Visitad su lugar de trabajo si es posible, ver cómo trabajan hoy y qué realidad queréis cambiar.
Después, hacedlos partícipes en la Sprint Review. Cuando vayamos a inspeccionar nuestro producto, no abráis el Jira (u otro software) para analizar si cumplimos lo que pone la historia. En vez de eso, dejad el ordenador al usuario y que lo use. Solo tenemos que escuchar todo aquello que nos quiere decir, anotarlo y analizarlo para el siguiente Sprint Planning. Lo más importante es que obtengamos respuesta a la pregunta: ¿esto hace lo que esperabas?
Scrum es customer centric
Scrum está compuesto por muchos elementos, artefactos, eventos y roles, para unir a las personas que hacen software con las personas que tienen problemas. Se trata de solucionar problemas, no de hacer software. Todos los eventos que dispone el marco se centran en inspeccionar y adaptar nuestra realidad, para tomar decisiones que nos permitan crear software útil y de valor.
Y tú, ¿eres periodista o eres analista funcional?
