Aprendizajes logrados y consejos para ser un buen Product Owner

Por Juan Arturo Bravo Aguinaga, Jefe de Soporte planeamiento e Inteligencia Comercial en MAPFRE

SCRUM (1) nos dice que el Product Owner (PO) es el responsable de maximizar la entrega de valor para el negocio. Dada su importancia, es un rol que cada vez se requiere más en las empresas guiadas por la agilidad; sin embargo, no hay que encasillarlo al ámbito digital, pues SCRUM puede ser aplicado en cualquier área y para cualquier fin siempre que se sigan las buenas prácticas que su marco de trabajo recomienda.

En esta oportunidad, te voy a compartir mi experiencia como PO de unas células (o mesas) ágiles(2) de aplicativos digitales durante los últimos años. En primer lugar, veamos los aprendizajes logrados:

- Ser ágiles no es sinónimo de ser rápidos, por el contrario, es un equilibrio entre flexibilidad y adaptabilidad, de tal forma que puedas responder a los cambios del entorno en el menor tiempo posible para generar valor a la compañía. Por eso mismo, como PO tienes que evangelizar a los stakeholders para que entiendan que si tienen una necesidad canalizada contigo se va a priorizar y trabajar en los tiempos que la metodología establece. No es válido decir que por trabajar con una mesa ágil todo estará listo en un par de días. Es un error.

- Si te vas a equivocar, hazlo, pero hazlo pronto. Ser ágiles implica muchas veces prueba y error. Y es que tienes que validar hipótesis que te planteas y no hay mejor forma de hacerlo que pidiendo la mejora o cambio y testeándolo en producción. Obviamente, que detrás de todo esto hay una investigación de por medio, pero nada te garantiza que sea un éxito hasta que lo pruebes. En las mesas ágiles que lideré se trabajó mucho esto y para no depender de TI se manejaron “switches” para apagar o prender la funcionalidad en base a los resultados obtenidos.

- Si sabes del negocio te irá bien, pero si además conoces temas técnicos te irá el doble de  bien. Te preguntarás porqué un PO debe conocer temas técnicos si en teoría es el  representante de las necesidades del negocio, ¿Verdad? Pues bien, en mi experiencia me di  cuenta de que gran parte de los equipos de desarrollo hablan en términos técnicos y así es  como se expresan, es la naturaleza del perfil. Por ende, para llegar a ellos, negociar y  entender la magnitud del desarrollo debes saber de qué hablan. No tienes que ser erudito,  pero sí conocer terminología relevante como qué es un API, una base de datos, qué  tecnología usan los aplicativos, entender funcionalidades básicas como envío de correos,  notificaciones, etc. En mi caso como tengo un perfil técnico no me fue complicado lidiar con  los desarrolladores.

- Refina, refina, refina. Sin un buen refinamiento (3) , tu planning (4)  será un fracaso. En mi caso llegaba a solicitar hasta un refinamiento por semana antes de cada nuevo sprint (5) . A veces, cuando la funcionalidad era muy densa requería más. El fin de un refinamiento no es entorpecer o quitar tiempo a la labor del equipo de desarrollo durante el sprint, sino más bien que te ayuden a aterrizar la necesidad para que posteriormente sea más sencillo darle un peso (6)  según la complejidad. Recuerda que lo arduo del refinamiento se traduce en menos dudas en el futuro.

- Si no sabes algo, involucra al experto. Como PO eres la cara del negocio; es decir, canalizas las necesidades de las demás áreas, pero puede suceder que no entiendas un tema que vas a presentar en un refinamiento. Pues bien, lleva a esa reunión al experto que te trasladó la necesidad y que él te apoye en la explicación al equipo de desarrollo. Una vez comprendido el tema procedes a redactar la historia de usuario7y listo. Recuerda que el PO es el único que puede priorizar y redactar las historias, pero no significa que no deba recibir apoyo externo de otros stakeholders en el camino.

- En tus pruebas de usuario, valida hasta lo que no se ha modificado. Es muy común que cuando se hace un pase a producción falle algo que ni siquiera se modificó. Es más común de lo que puedes creer. Por eso mismo, es fundamental que en las sesiones de revisión al final del sprint hagas pruebas para asegurarte que no haya daños colaterales producto de la mejora solicitada. Una vez que estés seguro apruebas la historia de usuario.

- Muchas veces las dependencias con proyectos tradicionales aplazan los pases a    producción. Suele pasar que un aplicativo está siendo modificado por otra área al mismo  tiempo que tú como PO lo haces a través de una mesa ágil. Esto puede darse porque se  solicitó un proyecto tradicional hace un tiempo y aún no finaliza, por temas regulatorios,  entre otros motivos. Entonces, bajo ese escenario, a veces ambos equipos terminan  modificando las mismas funcionalidades y si el otro proyecto tiene más prioridad o es más  crítico tienes que esperar a que pase a producción primero. Esto retrasa días o hasta  semanas la visualización de tus cambios. Si bien esto no es muy usual, lo que debes hacer  antes de iniciar la mesa ágil es alinearte con TI para saber qué otros proyectos están  impactando el aplicativo con el objetivo de comprender los riesgos que implica.

- Lo que no se mide, no se puede mejorar. Cada vez que lances una mejora al mercado elabora una lista de indicadores de medición para saber si fue exitosa o no. Por ejemplo: Número de ventas, cantidad de visitas, tasa de rebote, ratio de conversión, número de leads generados, reducción del número de fraudes por venta digital, número de ventas que aplicaron el descuento/promoción habilitados, etc. Son innumerables y dependerán de la naturaleza del negocio. Un PO no solo busca crear nuevas características, sino también optimizar las existentes. Enfócate en el outcome esperado, no en el output. Tu mesa ágil debe generar un piloto ejecutable con ROI medible. Recuérdalo.

- Sé lo más detallista posible. Al momento de redactar la historia de usuario tienes que describir con el mayor detalle posible lo que necesitas, lo mismo con tus criterios de aceptación. De ese modo el equipo de desarrollo lo tendrá muy claro y sabrá todas las pruebas que debe hacer una vez terminada la funcionalidad. De lo contrario, el día de la revisión si quieres validar algo que no se incluyó será complicado hacerlo, lo mismo pasará si te olvidaste de incluir una funcionalidad que en realidad necesitabas. Por eso es fundamental analizar bien la problemática y tener varios refinamientos. Recuerda que en SCRUM lo que se pide en el planning ya no se puede modificar drásticamente en el camino.

Estos son los aprendizajes más relevantes de mi rol como PO en digital. Fácilmente se pueden extrapolar a otras áreas, pues el PO es transversal a cualquier unidad de negocio.

Finalmente, te comparto unos consejos prácticos para que el día a día de tu labor como PO sea productivo y eficiente:

- Sé comunicativo y empático. Practica la comunicación asertiva. Debes expresarte a tiempo y con propiedad de tal forma que seas claro con todos los stakeholders al recibir sus necesidades y al trasladarles los resultados de las mejoras realizadas.

- Aplica estrategias de negociación. Durante el planning tienes que defender tu posición con respeto y argumentar con claridad el porqué de las cosas. Asimismo, cuestiona el peso otorgado a cada historia de usuario de tal forma que tengas una explicación concreta de ello para que el puntaje sea debatido por el equipo de desarrollo.

- Instrúyete en temas técnicos básicos. Apóyate en el equipo de TI, averigua qué tecnologías componen el aplicativo cuya mesa ágil estás liderando y lee un poco sobre ello. Te servirá muchísimo más adelante, ya lo verás.

- Navega en la herramienta usada por el equipo ágil. Por ejemplo: Jira. Lee la documentación, las funcionalidades que tiene disponibles, los reportes, etc. Eso te permitirá consultar por información relevante para medir la velocidad del equipo o saber qué cuellos de botella se presentan en el camino, además que también será tu herramienta donde escribirás las historias de usuario para el planning.

Espero que estos aportes sean de mucha ayuda para ti como PO en formación o si ya lo eres y te ves envuelto en algunas circunstancias con las cuales resulta difícil lidiar o también para que sepas qué te espera si alguno de los puntos mencionados aún no los has vivido.

Glosario:
(1) SCRUM: Framework ágil de mayor uso a nivel mundial. Ver: https://www.scrum.org/

(2) Célula ágil: Equipo conformado por un Product Owner, Scrum Master y equipo de desarrollo quienes trabajan para lograr los objetivos esperados por el negocio.

(3) Refinamiento: Ceremonia donde se aterrizan las necesidades del negocio con el equipo de desarrollo para validar su factibilidad.

(4) Planning: Ceremonia donde el Product Owner presenta las necesidades priorizadas y refinadas con el equipo de desarrollo para que se comprometan a realizarlas en el sprint que está iniciando.

(5) Sprint: Unidad de tiempo en la cual el equipo de desarrollo se compromete a realizar las funcionalidades priorizadas por el Product Owner.

(6) Peso: El peso o puntaje son los puntos de historia; es decir, un número que representa la complejidad de la funcionalidad solicitada. Un sprint no puede tener infinitos puntos, sino que hay un límite establecido por el equipo de desarrollo en base a su experiencia y madurez.

(7) Historia de usuario: Funcionalidad requerida por el negocio y redactada por el Product Owner para ser presentada al equipo de desarrollo.