Los secretos de una Product Owner - Entrevista a Vanesa Tejada

Hoy comienzo la que espero sea una larga serie de entrevistas con personas de carne y hueso que, trabajando en diferentes perfiles de diferentes organizaciones, nos ayudarán a conocer en detalle los distintos roles ágiles, o cómo son las relaciones entre los roles tradicionales con la Agilidad en aquellas empresas que ya trabajan con marcos ágiles.

En este caso he tenido la suerte de poder entrevistar a Vanesa Tejada (@vanesa_tejada‎), quien ocupa un rol que para mi es imprescindible en toda organización/proyecto ágil... pero mejor que seguir hablando yo de ella, será mejor empezar la entrevista dejando que sea ella quien se presente:

Hola Vanesa. Para empezar, y a modo de presentación, ¿podrías contar a los lectores de utopicainformatica.com quien eres y dónde trabajas?

Hola Raúl. En primer lugar quiero darte las gracias por brindarme la oportunidad de esta entrevista y te agradezco el interés por mi trabajo.
Me llamo Vanesa Tejada, y actualmente trabajo en Bravofly Rumbo Group.

¿Qué rol ocupas en dicha organización?

Mi rol principal es el de Product Owner de la aplicación de Backoffice que usan los operadores para gestionar las reservas de los clientes. Además de este papel, tengo otras responsabilidades que me hacen disfrutar mucho de mi trabajo, actualmente me encargo de coordinar la comunidad de Product Owners en la sede de Madrid, y tareas de organización e integración humana que estamos llevando a cabo entre las sedes de Madrid y Suiza.

¿Como PO, cuáles son tus responsabilidades principales?

Mi principal responsabilidad es mejorar mi producto, mi Backoffice. Para ello me centro principalmente en tener una buena relación con los usuarios de la herramienta, conocer sus necesidades, ofrecerles soluciones, priorizarlas e involucrar en este proceso a todo el equipo.

¿Desde cuándo trabajas con marcos ágiles? ¿Siempre has trabajado con estos márcos?

Llevo trabajando con metodologías ágiles desde hace 3 años y medio. Antes no trabajaba de esta manera, me auto-organizaba por mi cuenta bajo una lista de tareas que me habían mandado hacer y nada más.

¿Te sientes más cómoda con los marcos ágiles, con metodologías tradicionales, o no tienes preferencias?

Me siento mucho más cómoda trabajando con metodologías ágiles, principalmente por los valores que éstas conllevan. Formar parte de un equipo, trabajar codo con codo con otras personas que comparten tus objetivos y con los que juntos decides cómo vas a conseguirlos, es mucho mas gratificante, te hace sentir parte de algo, y antes no me sentía de esta manera.

¿Qué marco ágil utilizáis (XP, Scrum, Kanban...) en los proyectos de vuestra empresa?

Todos los equipos de desarrollo usan Scrum, y en la parte de sistemas trabajan con Kanban.

¿Qué beneficios crees que aporta la agilidad a las empresas, en comparación a los métodos de gestión de proyectos tradicionales?

Voy a centrarme en dos aspectos donde implícitos hay muchos beneficios para una empresa:

• Entregas periódicas y continuas del producto: esto permite adaptarte al mercado paso a paso, ver si tu producto se comporta como esperas, y si no es así poder cambiarlo y ver sus resultados a corto plazo. Los modelos de negocio están cambiando constantemente y las metodologías ágiles favorecen trabajar en estos entornos tan variables.
• Visión Compartida: todos los involucrados e interesados del producto forman parte del proceso, por lo que se comparten las perspectivas, opiniones, decisiones consiguiendo un resultado que satisface a todos.

Volviendo sobre tu rol como PO: ¿Con qué impedimentos te enfrentas más a menudo?

Lo más complicado en mi rol de PO es la priorización, ya no sólo por lo complejo que es llevar a cabo esta práctica en un backlog, sino porque además en mi producto hay varios stakeholders y a veces, algunas de las funcionalidades que se desean son queridas por todos pero en otras ocasiones cada uno necesita algo diferente y aquí viene la parte difícil. Ya no sólo hace falta priorizar, sino también negociar muy bien si es posible hacer todo, si hay que retrasar alguna petición o si podemos cortar alcance de los requisitos para poder tratar todas las peticiones. Cuando me enfrento a esta situación, lo que intento es satisfacer sus peticiones pero también que entre ellos se pongan de acuerdo para que la visión de las prioridades sea común y aceptada por todos.

¿Qué tipo de herramientas/prácticas utilizas en tu trabajo diario?

La herramienta con la que gestionamos los proyectos es JIRA, específicamente JIRA Agile, siendo ella vista de planning mi principal pantalla de trabajo, y la vista de trabajo en curso la principal para el equipo. Mientras que yo estoy pensando cuales son las siguiente prioridades para el producto, si éstas están bien definidas para el equipo y stakeholder, el equipo está enfocado en su sprint en curso.
Respecto las prácticas con las que trabajo, hago especial hincapié en las sesiones de Grooming, Planning y Retrospectiva.
En Grooming es donde puedo trabajar con el equipo las historias que deseo planificar en las siguientes iteraciones, ellos me ayudan a ver si existe más información que necesiten para entender la historia y proyecto que van a desarrollar. Sus dudas son siempre fundamentales y con ellas sigo trabajando la definición con los stakeholder, además, esta sesión permite compartir la visión desde negocio con el equipo y viceversa.
En las Planning elaboramos nuestro compromiso para la siguiente iteración, destacar aquí que el trabajo que hacemos en las sesiones de grooming hace que la planificación se haga en menor tiempo pues el equipo conoce los siguientes pasos que vamos a dar en el producto.
Finalmente en la Retrospectiva trabajamos juntos como mejorar cada uno de nosotros en nuestras responsabilidades para que depuremos más nuestro flujo y forma de trabajar juntos y para con el resto de interesados en nuestro producto. Tengo la suerte de trabajar con un equipo muy maduro y exigente, lo que hace que la mejora continua sea algo implícito en nosotros.
Lo más importante de todo esto es que estas sesiones las tenemos programadas en un calendario de forma periódica y fija, así hemos creado una rutina de equipo y respetado el tiempo que necesitamos para estas prácticas que son las que hacen que todo fluya.

¿Qué consejos darías a otras personas que vayan a asumir el rol de PO?

Mi primer consejo sería: "Sé el mejor en conocer tu producto". De esta manera podrás ser capaz de tener un buen criterio para aceptar o rechazar una petición, priorizarlo e incluso, ofrecer otras soluciones a los stakeholders que les resulten atractivas.
En segundo lugar: "No tengas miedo a decir NO". La principal responsabilidad de un PO es crear un buen producto que satisfaga las necesidades de sus usuarios, y eso no quiere decir que haya que hacer todo lo que te piden, por lo que a veces tendrás que rechazar algunas peticiones porque no sean buenas para el producto. Eso sí, mi tercer consejo: "Siempre que digas 'NO' explica claramente el porqué". Esto ayuda a que la relación entre el PO y el stakeholder madure.
Por último, creo que un buen PO también debe ser una persona que sepa organizarse bien, y que traslade su visión siempre al equipo pues al fin y al cabo sus compañeros son los que van a hacer realidad todas esas historias de usuario :) si todo el equipo comparte la visión, las soluciones que propongan y las decisiones de cómo harán las cosas, tendrán en cuenta no sólo el estado actual sino también, velarán por el futuro de su producto.

¿Y al resto de los miembros de los equipos de proyecto, qué consejos les darías sobre como tratar con el PO?

Deben tratarlo como un compañero más, con otra responsabilidad dentro de todas las que hacen falta para que un equipo sea autónomo. El PO en vez de implementar código, escribir en Java, Grails, escribe en historias de usuario :) La relación debe ser muy estrecha y debe haber mucha mucha comunicación.

Y respecto a la coordinación del resto de PO de tu empresa para crear esa comunidad de POs que comentabas, ¿podrías darnos algún detalle más sobre cómo llevas a cabo esa coordinación?

Digamos que este rol es como el de un Scrum Master dentro de los equipos, pero en este caso entre los PO de la empresa. Esta comunidad pretende dos cosas, la primera es que mejore la visión global de los productos en los que trabajamos y así coordinemos mejor los proyectos en los que tenemos dependencias. Por otro lado, dedicar tiempo a ser mejores PO, mejorar nuestras skills y compartir experiencias para seguir aprendiendo. Para conseguir esto, cada semana reservamos un tiempo de 2h para nosotros.
Además, también hay una comunidad de POs en la sede de Suiza, por lo que debo estar en contacto con mi otra colega que hace lo mismo pero allí, para que no se trabaje sólo en la comunidad local, sino a modo global.

No voy a robarte más tiempo, Vanesa. Estoy seguro de que los lectores de utopicainformatica.com tendrán mucho más claro cómo trabaja una Product Owner que, al fin y al cabo, era el objetivo de esta entrevista. ¡Muchas gracias!

Muchas gracias a ti, Raúl, y un saludo para los lectores de utopicainformatica.com