Clientes ágiles: Los retos del Product Owner y de los que trabajamos para los Product Owners
- Escrito por Vanessa Amaya
- Publicado en Blog
- Visto 3488 veces
Creo que quien más se queja de un cliente(a) o de un jefe(a) es quien menos tiempo invierte en orientarlos/educarlos. Con la transición que estamos viviendo hacia la agilidad he notado que el conocimiento y la conciencia de Scrum Masters y Desarrolladores está evolucionando porque hemos estado invirtiendo tiempo en orientarlos pero ¿y qué hay sobre los clientes? ¿también los estamos guiando?
Nos quejamos de que los clientes no nos permiten cambiar y que no se suben al barco de la agilidad y me pregunto ¿qué estamos haciendo para que se suban?
|
Aclaración: en este blog doy ejemplos sobre proyectos de desarrollo de software, pero si no trabajas en este tipo de proyectos, aún así considero que te va a hacer sentido lo que te cuento. |
La ironía es que es por ellos por quienes estamos cambiando, para entregarles valor frecuentemente y la mayor ironía es que no se los explicamos.
La responsabilidad de Product Owner para mí representa un llamado de urgencia para que alguien se tomara en serio la priorización de la demanda y se asegurara de que todos los involucrados entienden hacia dónde vamos y para qué vamos ahí, que realmente alguien se adueñe de eso pero más desde un punto de vista de compromiso.
En el 2013 Javier Garzás escribió en su Blog las 7 responsabilidades vitales de un Product Owner, yo lo leí hasta el 2015 y hasta ahora para mí ha sido de los materiales más claros donde se explica este rol.
A continuación pongo el extracto al que haré referencia en este artículo:
Para ayudar a su correcta ejecución, aquí tienes una lista de 7 responsabilidades vitales de un product owner:
1 Escribir buenas historias de usuario (de dejo un post sobre historias de usuario)
2 Decidir qué construir… ¡y qué no!
3 Fijar criterios de aceptación para cada historia de usuario.
4 Definir “productos mínimos viables”.
5 Priorizar historias de usuario, y para ello tener claro el valor de las mismas y el valor que necesita el producto en cada momento (que diferirá a lo largo de su vida).
6 Estar accesible, y disponible, para explicar al equipo técnico dudas funcionales, para validar entregas y participar en reuniones.
7 Definir el plan de releases (o la visión estratégica).
Ahora bien, yo al leer la definición del rol y las 7 responsabilidades vitales que describió Javier Garzás inmediatamente pienso: El Product Owner es mi cliente (interno o externo) que me da los requerimientos para el proyecto, no (necesariamente) es el Patrocinador(a) (Sponsor) del proyecto, sino quien trabaja en el área de negocio donde el desarrollo de software que se está solicitando va a implementarse y aunque esa persona involucre a más gente de su equipo, es solo esa persona y nadie más quien toma decisiones con respecto a priorización.
Los 4 escenarios que me encuentro más comúnmente son:
1) El Product Owner no redacta sus historias de usuario ni ningún otro tipo de especificación.
En la Guía de Scrum se establece que “El Dueño de Producto podría hacer el trabajo anterior o delegarlo en el Equipo de Desarrollo. Sin embargo, en ambos casos el Dueño de Producto sigue siendo el responsable de dicho trabajo”. Este caso es muy común cuando quien porta el rol de Product Owner es una persona con baja disponibilidad y es entonces cuando ocurren los siguientes escenarios:
* El Product Owner recibe apoyo de un Business Analyst
* El Product Owner le delega esa responsabilidad al Scrum Master y realmente valida a conciencia las historias generadas
* El Product Owner le delega esa responsibilidad al Scrum Master y ya no se involucra en validar las historias generadas.
* El Product Owner se apoya de varios involucrados de su área para proveer de los requerimientos pero se queda con la toma principal de las decisiones sobre la priorización del backlog.
Independientemente del escenario que esté sucediendo, es vital concientizar al Product Owner sobre la importancia de su involucramiento y COMPROMISO.
2) Se asignala responsabilidad a alguien que está en el área de TI y que sabe poco del negocio.
Como de repente somos muy literales y como se dice que en el Scrum Team hay un Product Owner y el Scrum se aplica en el área de desarrollo entonces ahí bautizan a alguien con ese rol, comunmente a quien antes portaba el rol de Analista, Levantador de Requerimientos, Business Analyst o Delivery Manager, esta decisión afecta enormemente porque el tema no es la experiencia sobre requerimientos o entregas, sino la experiencia en el negocio del cliente ya que de esta experiencia se derivan decisiones correctas para priorizar.
3) Se le asigna la responsabilidad al Scrum Master.
Podría parecerse al primer escenario, pero este va mas allá de solo las especificaciones, se le da la responsabilidad completa con todo lo que esto implica. Y el Scrum Master termina siendo poco eficiente en lo que realmente le tocaba y poco eficiente en lo que no le tocaba.
4) Se asume la responsabilidad como debe de ser.
¡Si! ¡Si pasa! Ya me tocó trabajar con una clienta que sí asumió su responsabilidad y fue una Product Owner como debe de ser y los resultados fueron mágicos, se cumplió lo que se dice: es la pieza clave porque de sus decisiones y apoyo se deriva mucha sinergia con el equipo.
Capacitando a los Clientes
Es un hecho que la certificación que más atrae en México es la relacionada con la responsabilidades del Scrum Master. Comprendo que culturalmente un cliente podría pensar ¿cómo me van a certificar como cliente de negocio? Pero considero que la capacitación diseñada para el Product Owner tiene como principal valor que la implementación del marco ágil fluya de una manera más eficiente, considero que ya que se quiera certificar o no, no es tema relevante, lo importante es que se capacite.
Ahora bien, un curso formal no es la única manera:
Puedes explicarle el cómo se trabajará con el marco ágil y lo importante de su rol en las interacciones que se tengan con tu cliente: si inviertes de 5 a 10 minutos para enseñarle algo sobre agilidad desde el rol de Product Owner, conforme pasen los Sprints habrás logrado HORAS conciencia con tu cliente.
Si es un cliente sumamente resistente al cambio, te sugiero no le pongas nombres a las nuevas prácticas, es decir, no digas "Ahora usaremos Scrum" "Vamos a implementar Kanban" "Ya no va a haber Project sino Trello", sino dile "Ahora te estaremos entregando avances frecuentemente para asegurar juntos que estamos dandole valor a tu negocio, serán periodos de 3 semanas", "Ahora utilizarremos una mejor gestión de la demanda de tus requerimientos", "Tendremos una herramienta que te permitirá visualizar en cualquier momento el avance del equipo y podrás verificar que estemos trabajando en lo que más te importa".
Conclusión:
Sin requerimientos no hay software, sin priorización de los requerimientos no hay forma de entregar valor al negocio, así que es NECESARIO que ayudemos a nuestros client@s a subirse al barco de agilidad y cumplir lo que la filosofía ágil nos señala: QUE LOS CLIENTES SEAN PARTE DEL EQUIPO. Si seguimos viendo a los clientes como ajenos a los proyectos, los problemas continuarán.
¿Quieres saber más?
Escúchame en: