Existen muchos roles dentro de un Equipo Scrum. Uno de ellos, el Product Owner (PO), es responsable de dirigir el backlog del producto para conseguir el resultado deseado por el equipo. El rol del PO (Dueño del Producto, en castellano) es muy importante si atendemos a la calidad del producto. Es el único miembro del equipo que tiene el poder para aceptar cualquier historia.
Para muchas compañías que están haciendo la transición al método Ágil, el rol del PO es nuevo y crucial. Muchas empresas contratan a un Product Owner a tiempo completo para ayudar al Equipo Ágil. Las relaciones del PO y sus responsabilidades no son solo significantes, sino que se extienden más allá del equipo local.
Los PO también trabajan con el resto del Equipo de Dirección del Proyecto, con los consumidores, y con los inversores.
El product owner es un líder; normalmente, alguien con experiencia en marketing, dirección de proyectos, o que tiene conocimientos sobre el mercado y sus usuarios. Deben tener un claro entendimiento sobre la competitividad y las futuras tendencias del dominio y los tipos de sistema que se están desarrollando.
El rol del product owner se creó inicialmente para abordar los desafíos a los que muchos Equipos Scrum se enfrentaban. Muchos equipos tenían dificultades para elegir qué dirección tomar. Esto tenía como resultado una dirección conflictiva, varias direcciones, o ninguna dirección.
El product owner invierte mucho tiempo con el equipo, aclarando los ítems del backlog de producto y decidiendo cuáles llevar a cabo, basándose en las especificaciones del producto.
Puede resultar un desafío el realizar el trabajo del product owner. Ellos tienen que tomar todas las decisiones sobre el producto, conocer las necesidades empresariales de producto, e invertir un tiempo considerable con el Equipo Scrum.
Debido a la cantidad de trabajo, las responsabilidades se dividen a menudo entre varios miembros del equipo. Las empresas están comenzando a utilizar un equipo de valor para manejar la carga de trabajo. Si tú, como dueño de una empresa, decides usar este método, necesitas nombrar una única persona para tomar las decisiones.
La proporción ideal de Product Owner para un Equipo Scrum es 1:1 - un Product Owner por cada Equipo Scrum. Esta proporción se rompe si más de un equipo trabaja simultáneamente en el mismo producto. El product owner acaba trabajando con muchos equipos. El problema es que el PO acaba normalmente ignorando a algún equipo.
Si el product owner tiene muchas responsabilidades, no están completamente disponibles para el Equipo Scrum. Esto puede ocasionar muchos problemas y retrasos en el equipo, ya que no pueden solucionar sus dudas o tomar decisiones a tiempo. Esto se conoce como un product owner ausente.
Los equipos que necesitan más del producto owner de lo que este puede dar, pueden nombrar un product owner representante. El producto owner representante puede ser consultado por el product owner o por el equipo.
Sin embargo, a muchos equipos no les gusta este método, ya que el product owner puede ignorar las decisiones del representante en cualquier momento.
Normalmente, el PO actual ignorará al representante en un momento inconveniente para el equipo.
Los roles y responsabilidades pueden variar según el producto y el ambiente de desarrollo, pero hay muchos factores comunes para cada posición. Cada PO tiene todas las responsabilidades, pero debe colaborar con el equipo y delegar la carga de trabajo de acuerdo a las necesidades del equipo.
Hay siete responsabilidades comunes para cada Product Owner:
El Product Owner es responsable de establecer los objetivos y crear la visión de equipo. Se necesita que esta visión se comunique claramente a todos aquellos envueltos en el proyecto, incluyendo: el Equipo Scrum, los inversores y el equipo de dirección. Esta visión se usa para priorizar y dirigir las decisiones del equipo.
El Product Owner genera y gestiona la lista de trabajos que deben ser realizados por el Equipo Scrum. Tienen que escribir los ítems del backlog del producto y los criterios de aceptación para cada uno de ellos y, después, solicitar el trabajo para garantizar que se cumple la visión del producto.
El backlog del producto debe hacerse visible para que todo el mundo envuelto con el equipo pueda verlo. De esta manera, el product owner puede optimizar el rendimiento del trabajo y asegurarse de que las partes interesadas comprenden la estrategia y el mapa de ruta del desarrollo.
El backlog es una fuente que se actualiza continuamente. El backlog muestra todo el trabajo que ha de completarse durante el desarrollo. Se usa para garantizar que el equipo finaliza siempre las tareas más importantes de manera iterativa e incremental.
El product owner es responsable de proporcionar el mejor beneficio o inversión. Son responsables de tomar todas las decisiones económicas durante el Sprint de release y el nivel de producto. El triángulo de hierro del alcance - presupuesto, tiempo y calidad - se puede ajustar según la necesidad. Los costes y beneficios de cada backlog de producto pueden ser usados para determinar el orden de trabajo.
El product owner debe involucrar al equipo scrum. Deben compartir la visión de la organización, responder las preguntas del equipo, y escuchar sugerencias como añadir, eliminar, cambiar o mejorar el objetivo del usuario. El product owner motiva al equipo y busca feedback.
El product owner también define los límites y las restricciones para conseguir los objetivos. Las restricciones deben ser alcanzables. Pueden incluir plazos para completar el producto, limitaciones en los costes, límites de memoria, y mínimos de velocidad.
El PO debe tener cuidado de no establecer objetivos irreales o técnicamente imposibles de conseguir. Si se establecen objetivos irreales, una buena comunicación entre el usuario, el representante del usuario y el Equipo Scrum es clave para detectarlo de manera temprana.
Priorizar tareas durante el sprint es también importante para alcanzar los objetivos del equipo. Los equipos deben trabajar primero en los segmentos más importantes. Cuando estén completados, pueden entregar estos segmentos al usuario o al cliente. Segmentar trabajos puede crear valores de producto más altos y resultados de ROI positivos. Esto también puede ayudar a introducir partes del producto en el mercado más pronto.
Los proyectos pueden tener una larga duración; por tanto, todo el feedback es importante. Sea bueno o malo, el feedback generalmente significa alterar, eliminar o añadir objetivos al proyecto. Ya que los cambios se realizan cuando el proyecto todavía está en progreso, los costes serán menores que si el proyecto ya estuviera finalizado.
El product owner juega un importante rol en los eventos de desarrollo, como los planes, el perfeccionamiento, las revisiones y la retrospectiva del sprint y los scrum diarios.
Trabajan con todas las partes durante las actividades de planificación para determinar qué etapas y contenido deben ser elegidos para entregar en la siguiente iteración, lanzamiento o nivel de producto y en la siguiente iteración.
Durante las sesiones semanales de perfeccionamiento, el PO trabaja con el Equipo Scrum para definir, elaborar, estimar, ordenar y eliminar artículos del backlog.
Colaboran con el equipo para determinar las acciones necesarias para mejorar el trabajo. Durante el sprint, el PO trabaja con el Equipo Scrum; respondiendo preguntas y aceptando los backlogs de producto completos. Sin embargo, el product owner es el único con autoridad para añadir o quitar trabajo, cancelar el sprint, o detener el desarrollo del proyecto.
Pueden asistir a los scrum diarios para coordinar y colaborar con el equipo en el trabajo que se está haciendo en el sprint.
Los Product Owners comparten cinco características comunes:
El product owner está completamente comprometido con el proyecto. Trabajan con el Equipo Scrum a diario; respondiendo preguntas, y están disponibles cuando aparecen problemas que pudieran retrasar el proyecto.
La organización empodera al product owner para tomar decisiones y ser responsable de estas. Todas las decisiones deben tomarse al nivel del producto para mantener la velocidad del desarrollo. La organización debe tener cuidado de no anular al product owner o correr el riesgo de que el equipo ignore la jerarquía de la empresa.
El product owner debe responder las preguntas del equipo rápidamente y con autoridad. Las esperas pueden hacer que el trabajo no se complete a tiempo. Revertir decisiones pasadas creará una falta de confianza.
El rol del product owner es el mejor para tomar decisiones basadas en el conocimiento del cliente y en el soporte de todas las partes.
El product owner comprende las necesidades del cliente. Posee un fuerte conocimiento del mundo de los negocios para liderar el equipo de desarrollo del producto y, al mismo tiempo, coordinar a todas las partes interesadas.
El PO debe ser un excelente comunicador, colaborador, y “persona de gentes”. Pueden compartir su visión, alinear personas, concentrar sus esfuerzos, y motivar al equipo. Su alta inteligencia emocional ayuda a la colaboración y orienta el desarrollo del producto hacia buen puerto.
Los productos owner no son solo administrados, sino que también son la delicia de los clientes. Aunque es importante escuchar a las partes interesadas y cambiar el backlog del producto de acuerdo a ello, es también esencial escuchar al cliente y descubrir sus necesidades.
Los grandes product owners hacen más que seguir la mecánica de añadir una historia de usuario al backlog de un producto antes de mandarla a los desarrolladores. Piensan sobre las maneras de transformar la historia de usuario en una funcionalidad del producto que guste al usuario.
Por ejemplo, imaginemos que un artículo del backlog de una compañía de vehículos compartidos es enviar a los usuarios un recibo por email. ¿Está el usuario ocupado? ¿Necesitan crear un informe en Excel para el recibo? ¿Hay más información - método de pago, opciones del documento, lugar de recogida o de entrega, distancia - que pudiera ser útil? Un buen product owner miraría este enfoque más amplio.
Sinceramente, aunque el rol del Product Owner debe ser llevado a cabo por una persona en la estructura Scrum, es imposible para una sola persona encargarse de todo. Si el trabajo empieza a fallar, muchos equipos crearán un rol adicional y paralelo. Por ejemplo, algunos equipos añadirían product owner técnico para compensar al product owner que no se ve como un líder.
Los equipos deben delegar y construir un equipo informal y útil si quieren sobrevivir y prosperar. Espera, ¿no suena eso como un Equipo Scrum? Sí y no. Puedes elegir incluir un Scrum Master y varios miembros del Equipo Scrum si así lo deseas. Pero un equipo informal de Product Owner podría ayudarte en varias responsabilidades, sobre todo si no eres un experto en ciertos campos.
No hay nada malo en decir que también eres desarrollador. En Scrum, los equipos se ven obligados a delegar roles. Aunque es útil para enseñar el método Scrum, no es siempre del todo recomendable. Los roles pueden volverse sobrevalorados, lo que aparta el foco del valor de la entrega con respecto a quién hace qué.
En el caso del product owner, es fácil pensar que “Yo poseo el backlog de producto. Poseo las historias de usuario. Se las doy al Equipo Scrum y ellos las desarrollan”. Esto puede ser cierto, pero tú también eres parte del equipo, no solo el líder.
El equipo entero entrega agrega valor. Cuando ves tu rol como un miembro del equipo, guiando al resto de miembros en qué debería ser creado, la colaboración con los demás será mejor.
Aunque eres un desarrollador, también eres un distribuidor de conocimiento. Puede que representes el backlog del producto, y actúes como la interfaz entre el Equipo Scrum y los inversores, pero esto no significa que seas un experto en el producto. Si los desarrolladores se encuentran escribiendo código, puede que no vayan muy lejos hablando contigo.
En lugar de esto, deberían hablar con los expertos: los inversores que representan a los usuarios. Parte de tu trabajo es colaborar y empoderar a los desarrolladores encontrando los expertos a los que dirigirse. Si estas discusiones resultan en que se requieren cambios, se te debería informar. Si eso no es viable, pon a los desarrolladores a cargo para que puedan obtener la información necesaria.
Cualquier que no pueda gestionar correctamente un conflicto no debería ser product owner. En el desarrollo de productos, lidiarás con situaciones llenas de conflictos, especialmente cuando la gente discuta por los recursos y las políticas. Tener buenas habilidades para resolver conflictos es importante para que estas disputas no vayan a mayores.
Los product owners deben tener coraje, confianza, y ser capaces de manejar situaciones cuando se ponen tensas. Y deberías saber que normalmente tienes que pasar por algún conflicto para llegar a una solución. Saber medias y colaborar minimizará la parte negativa.
No importa lo bueno que seas resolviendo conflictos, en algún punto tendrás que escalar una situación en la cadena de mano. Escalar no está relacionado con pequeñas disputas, es un feedback que la dirección ha dado en relación a los objetivos en conflicto. Por ejemplo, si dos partes han asignado al mismo equipo dos tareas diferentes que no encajan, tienes un conflicto.
Los mejores product owners tienen listos mecanismos para escalar conflictos. Sin duda, tratarás de resolver los conflictos entre las partes interesadas de la mejor manera que puedas, pero necesitarás las habilidades para subir y descender en la cadena de mando. En lugar de esperar que llegue una crisis, deberías poner a prueba tu plan de escalada.
Puedes hacer esto buscando oportunidades para escalar pequeñas interacciones, de manera que domines tus competencias. En el momento en que ocurran grandes problemas, estarás preparado y cómodo para lidiar con ellos.
Hay muchas habilidades que puedes cultivar siendo un product owner, pero estas siete cualidades te darán una ventaja en tu papel.
Uno de los primeros desafíos a los que se enfrentan las compañías que hacen la transición al modelo Ágil es entender los nuevos roles necesarios para apoyar la iniciativa. El papel del product owner es el más importante, sin embargo, el más nuevo para las empresas.
Una pregunta que las compañías hacen normalmente es: “¿en qué se diferencia el papel del Product Owner del papel del Analista de Negocios Ágil?” Las diferencias entre los dos puestos son importantes, y entenderlas es esencial para alcanzar el éxito.
El papel de un Product Owner es la unión de muchos roles - representante comercial, analista de negocios, gestor de proyecto, y otros roles. Estos papeles se fusionan en uno para apoyar el método Scrum. Está diseñado para proporcionar un cierto nivel de responsabilidad que de otra manera no existiría.
Ya que es un rol nuevo, es importante identificar a las personas que tienen potencial para desarrollar las aptitudes necesarias para llevar a cabo este trabajo. Te recomiendo escoger alguien del mundo de los negocios, no del mundo de la TI. Deberías elegir a alguien al que se le pueda enseñar a escribir historias y definir los criterios de aceptación.
También debes escoger a alguien que tenga el apoyo y la comprensión de la dirección de que el compromiso elegido en ese rol es mucho mayor que cualquier cosa que hay experimentado anteriormente. También me gustaría recomendarte que el director transfiera muchas de las responsabilidades de la persona a otro equipo.
Entonces, ¿por qué enseñar a un Product Owner a escribir historias y definir los criterios de aceptación si ya tienes un Analista de Negocios que cumple con esta función? La respuesta es la responsabilidad. Cuando alguien del mundo comercial posee el contenido de cada sprint, no hay nadie para jugar al juego de la culpa, por lo que hay menos encontronazos entre los gestores de IT y del Proyecto.
Al desarrollar un rol responsable de aceptar las historias, nadie en el TI tiene autoridad de aceptar las historias. Solo el negocio en sí mismo puede decidir si el trabajo completado es aceptable y encaja con los propósitos establecidos.
En Scrum, solo una persona es responsable de definir y aceptar las historias. Y no puedo insistir lo suficiente en la importancia de no dividir estas responsabilidades.
Junto a la responsabilidad, la comunicación es también importante. Cuando el Product Owner viene de los negocios, hay una mayor probabilidad de que la comunicación entre este y los Directores de Producto sea natural y fluida. Esto hará que sea más fácil para el equipo solucionar problemas, manteniendo la alineación con los objetivos de la empresa.
También habrá menos sorpresas durante las demostraciones de requisitos completados. Un Product Owner puede literalmente “sentarse” con el Equipo Scrum y después informar al Director de Producto; reduciendo la brecha entre el departamento de negocios y de TI.
Cuando la empresa trabaja con el Product Owner y el Analista de Negocios Ágil, pueden adquirir una perspectiva holística para solucionar los problemas. El Product Owner pone el enfoque sobre el usuario, mientras que el Analista de Negocios lo pone sobre el sistema.
El product owner descubre qué quiere el usuario, para luego decidir la mejor manera de entregar el valor, mientras que el Analista de Negocios identifica los casos, condiciones de error, dependencias, e impactos sobre otras áreas del sistema u otros sistemas.
No hay ninguna duda de que el Analista de Negocios proporciona un gran valor al equipo, pero el Product Owner debe poseer derechos exclusivos de aceptar historias y gestionar las prioridades para mantener la responsabilidad.
Debido a que el Product Owner es un rol nuevo para muchas organizaciones, recomendamos que identifiques a las personas que tienen las capacidades necesarias para desempeñar este papel.
Estas incluyen: buenas habilidades de comunicación, buen sentido comercial, rápida toma de decisiones, base técnica y, lo más importante, alguien que pueda desarrollar un nivel de confianza del equipo y la Dirección de Producto. Una vez que hayas identificado a la persona idónea, recomiendo enviar a este candidato a las primeras prácticas, las prácticas de herramientas, y coaching continuo.
Para que este nuevo rol tenga éxito, la organización al completo debe respetar las decisiones del Product Owner. Todas estas decisiones deberían ser visibles en los pedidos de contenido y backlog de producto.
Espero que este artículo te haya servido para conocer las responsabilidades y las habilidades del Product Owner. Si te ha sido útil, por favor compártelo con tus amigos y compañeros.