El Product Owner y la importancia de la comunicación

Siempre que leo la guía de Scrum, veo un detalle, una sencilla frase que había pasado por encima y que me sigue ayudando a entender el framework para ayudar a los equipos con los que trabajo. En mi día a día, estoy muy cerca del rol de Product Owner, le observo con frecuencia y veo cómo su trabajo impacta en varios aspecto de la empresa. La guía de Scrum define responsabilidades y comportamientos de este rol, pero en ningún momento habla de las cualidades que le ayudan a hacer un mejor trabajo. Hoy quiero compartir con vosotros, desde mi punto de vista y experiencias vividas, la importancia de la comunicación en el rol del Product Owner.

Siempre he visto a este rol como alguien que está constantemente hablando, teniendo conversaciones con diferentes personas que trabajan alrededor del producto para maximizar el valor de éste fruto del trabajo del equipo de desarrollo. De cada conversación salen respuestas a preguntas y nuevas preguntas que necesitan respuesta. Siempre he sentido que estas conversaciones son como las piezas de un puzzle: salen unas y otras desordenadas y son varios ojos los que ven las conexiones para ponerlas juntas hasta tener una imagen clara. Esta persona, refleja lo más relevante de las conversaciones en artefactos como el Product Backlog, y según el entorno de la organización puede haber otros elementos como son un Product Roadmap, presentaciones u otra documentación. Siempre que diferentes elementos deben contener la misma información siento miedo, porque asegurar la consistencia no es algo que salga de forma natural a todo el mundo, y he aquí la clave de mi artículo, lo que dejamos escrito es una forma de comunicar, algo a lo que vamos a volver en otras ocasiones, que podemos usar en diferentes momentos y con diferentes personas, por lo que garantizar la consistencia en la información es fundamental si queremos que todo el mundo, al leerlo, entienda prácticamente lo mismo.

El teléfono escacharrado

La comunicación en el Product Owner es una navaja de doble filo, y si eliges el filo malo puede que acabes jugando al teléfono escacharrado. Cuando no respetas el mensaje original durante tus conversaciones con diferentes roles, lo que acaba ocurriendo es que cuando pones a todas las personas en la misma mesa tengas que invertir más tiempo en traducir de lo normal, en vez de ir al grano en la cuestión que corresponda: ¿qué significa eso que has dicho?, ¿cómo has llamado a qué?, ¿en qué idioma habla ese Stakeholder?, ¿qué lenguaje les enseñan a los desarrolladores?…

Cuántas veces he visto entre un Product Owner y un Stakeholder hablar de reducir tiempos entre ciertas páginas web, y por mucho que este Stakeholder tenga ciertos conocimientos técnicos, al equipo le llega un item en el backlog que dice: «Bajar caché XXX a 10seg» y este título es lo que se nos queda clavado en el cerebro, y no es el objetivo o impacto en el producto, es la acción, el cómo. Luego llevas al Stakeholder a la misma sala con el desarrollador y pueden surgir conversaciones como:

• Stakeholder – ¿Tenemos datos sobre los tiempos de las páginas tras la última entrega?
• Developer – ¿A qué te refieres? Hicimos varias cosas que afectan a los tiempos… ¿puede ser lo de la caché?
• Stakeholder – Uhmmm puede… Querido Product Owner ¿es lo de la caché?
• Product Owner – ¡Ah! si es eso lo de la caché…

Otro caso en el que he sido y sigo siendo cansina, es cómo redactar los títulos de los items en el Product Backlog. Cuando veo una lista de acciones o tareas en vez de los servicios que nuestro producto va a añadir para nuestros clientes, me pongo un poco nerviosa, es como si no pudieras leer la historia de tu producto, su futuro.

En mi empresa, la herramienta con la que trabajamos para manejar los Product Backlogs está configurada en dos niveles. El nivel de Product Roadmap donde están los objetivos e iniciativas descritas a alto nivel, y de las iniciativas cuelgan los items que el equipo va a llevar a cabo en sus iteraciones. Cuando un equipo no sabe a qué contribuye su día a día, tiene dudas y le cuesta enlazarlo todo, puedes ver que o bien los elementos no están vinculados, o que en alguno de los saltos no hemos respetado el nombre original de los items. Esto puede llevarnos a que en eventos como la Sprint Review, cuando el equipo de desarrollo demuestra el incremento del producto, hay Stakeholders que no saben a qué se refieren y en muchas de las preguntas es el Product Owner quien tiene que hacer la labor de aclaración: ¿esto quiere decir…?, ¿se refieren a…?.  Esto es tiempo y el tiempo es dinero, además el Product Owner puede parecer un impedimento en una conversación sobre algo común de todos, el producto.

Un vocabulario común

Respetar el mensaje en nuestras conversaciones es fundamental para que exista un vocabulario común alrededor del producto y en la organización. El producto se debe desarrollar entre todos, y aunque el Product Owner hace una gran labor de traducción para que los Stakeholders entiendan aspectos técnicos, así como que los técnicos entiendan más la perspectiva del Stakeholder, esta labor puede servir para crear un entendimiento común que facilita el trabajo entre diferentes roles o crear diferencias de entendimiento. Respetar el mensaje, repetirlo una y otra vez, copiar y pegar en diferentes formatos el mismo título, permite que la conversación fluya, favorece el trabajo en equipo de forma efectiva evitando así interrupciones, aclaraciones innecesarias y retrasos en la comprensión de los mensajes.

Nuestro producto, si es satisfactorio para los clientes, va a seguir creciendo, y ese crecimiento implica nuevos servicios, características, nuevos términos que al final todos los roles alrededor del mismo van a incorporar a su lenguaje en el día a día. Creo que el Product Owner debe garantizar que el conocimiento del producto es consistente, y para ello, la consistencia a la hora de comunicar en cada evento, conversación y artefacto es fundamental.