Ajedrez - antoniomartel.com

Archivos por Etiqueta: product owner

El Scrum Master y el Product Owner

El rol de Scrum Master en un equipo Scrum no es el de jefe de proyecto como suele suponerse equivocadamente. Es más bien el de un guía que ayuda a todos a entender cómo funciona Scrum y que intentan asegurar que las prácticas de Scrum son bien entendidas y funcionan de la mejor forma posible.

El Scrum Master ayudará a los Interesados y a otras personas fuera del equipo Scrum a entender cuáles con las mejores formas de interaccionar con el Equipo Scrum, por ejemplo, si un Interesado tienen una solicitud de mejora que hacer, el Scrum Master deberá hacerle saber que es mejor si se la comunica al Product Owner para que este la meta en la pila de trabajo y la priorice si así lo cree necesario.

El Scrum Master es un líder al servicio del Equipo Scrum. En concreto, el trabajo que realizará el Scrum Master para el Product Owner será:

  • Ayudarle a gestionar la Pila del Producto de manera efectiva, por ejemplo, facilitándole herramientas para gestionar los elementos de la pila (MS Excel, Trello, JIRA, etc.) o indicándole cómo y cuando debe priorizar entre las tareas.
  • Explicarle cuando debe entrar en más detalle en ellas para que el Equipo de Desarrollo las pueda entender correctamente con especificaciones claras y concisas.
  • Ayudarle a entender las estimaciones empíricas que haga el Equipo de Desarrollo, es decir las basadas en datos reales y experiencias pasadas y no sólo en predicciones.
  • Asegurarse de que el Dueño del Producto sabe cómo priorizar las tareas y funcionalidades a realizar basándose en el Retorno de Inversión y en el coste que tienen. Es decir si una funcionalidad tiene un coste o tiempo de realización de 5 y un valor para la organización de 8 quizás convendría hacerla después de una funcionalidad de coste 2 y valor 6 porque conseguiríamos un valor similar para la organización (6) en menos de la mitad de tiempo, tan sólo 2 (y la organización la disfrutaría antes también).
  • Entender y practicar la agilidad, es decir, explicarle las principios ágiles que hay detrás de Scrum como los del manifiesto ágil. Algunos de ellos son: Nuestra mayor prioridad es la de satisfacer al cliente, Aceptamos que los requisitos cambien, Entregamos software funcional frecuentemente entre dos semanas y dos meses, Los responsables de desarrollo y el equipo de desarrollo colaboran juntos estrechamente durante todo el proyecto, etc.
  • Facilitar los eventos Scrum según se requiera: Organizarlos, reservar las salas, convocar las reuniones, llevar los artefactos que sean necesarios, comunicar el orden del día y los puntos de la reunión, etc.
Estos son los servicios que el Scrum Master presta al Product Owner, en próximos posts explicaré los servicios que el Scrum Master presta al equipo de desarrollo y a la organización en su conjunto.

El Dueño del Producto

El Dueño del Producto (Product Owner) es el responsable de gestionar la Lista o Pila del Producto (Product Backlog) con la lista de funcionalidades que deberá tener el producto. La gestión de esa Pila del Producto implica que es también el responsable de que el producto final tenga el mayor valor posible y para ello deberá obtener el máximo valor del trabajo del Equipo de Desarrollo.

Para gestionar esa Pila del Producto deberá:

  • Expresar claramente los elementos de la Lista para que queden claros para todos y que esa Lista muestre  en qué estará trabajando el equipo en los próximos Sprints.
  • Asegurarse de que el Equipo de desarrollo entiende los elementos de la Lista con el detalle suficiente. El Dueño del Producto conoce bien su producto y lo que se quiere conseguir con él, por tanto es el responsable de que cada funcionalidad a implementar está bien detallada y explicada para el Equipo de Desarrollo.
  • Ordenar los elementos de la Lista de Producto para obtener los objetivos que tiene el producto lo antes posible, priorizando para ello los de más valor para el producto en el mercado o en su organización.
  • Optimizar el valor del trabajo del Equipo de Desarrollo. Para ello deberá hacer que mediante la Pila del Producto debidamente ordenada y priorizada el Equipo de Desarrollo trabaje en las funcionalidades de más valor en cada momento, evitando trabajo redundante o inútil en tareas de poco valor añadido.

Es además la única persona responsable de gestionar esa Lista de Producto. Eso implica que puede estar representando a varias personas o a un comité de Interesados (Stakeholders) en el producto en la empresa cliente que nos contrata o de la propia empresa que desarrolla el producto pero es sólo el Dueño del Producto el único responsable de expresar, detallar, optimizar y priorizar la Pila del Producto. Los Interesados en el producto pueden querer cambiar la Lista, añadir nuevas funcionalidades o darles otra prioridad pero deberán hablar primero con el Dueño del Producto para expresarle sus deseos y sólo él podrá cambiarla.

El rol del Dueño del Producto es un rol fundamental en todo proyecto (se llame como se llame según la metodología) por lo que toda la organización que contrata el desarrollo del producto debe respetar sus decisiones. Él es quién decide qué va a hacerse con el producto y que funcionalidades tendrá por lo que tiene un peso muy grande en que el producto final sea un éxito o no.

No se permite acceder al Equipo de Desarrollo para pedirle que realice funcionalidades distintas a las indicadas en la Lista de Producto. El Equipo de Desarrollo deberá actuar siempre en función de lo que diga el Product Owner y no cualquier otro Interesado en el producto.

Construir lo correcto, construirlo correctamente o construirlo rápido

Siempre que desarrollamos un producto, nos demos cuenta o no, estamos haciendo un balance entre construir lo correcto (la funcionalidad exacta que necesita nuestro cliente), construirla correctamente (siguiendo la mejor arquitectura o los mejores estándares), o construirla de la forma más rápida posible.

Por supuesto, todos queremos estar en el punto del centro de la imagen y conseguir los tres aspectos al mismo pero es muy difícil lograr el equilibrio perfecto, cuando no imposible. A menudo debemos ir hacia uno de los lados de la figura para sacar la mejor versión de nuestro producto adelante.

Si nos movemos hacia el punto 1, en la intersección entre construir lo correcto y construirlo correctamente tendremos un producto perfecto con una arquitectura también perfecta pero podemos haber tardado demasiado en construirlo y no tenerlo disponible cuando el cliente la necesita o cuando el mercado lo demanda. Construir un Whatsapp con interfaz web puede estar muy bien justo ahora y hacerse muy popular y hacerse muy popular en poco tiempo pero podría ser demasiado tarde si lo entregamos dentro de un año.

En cambio, si tendemos hacia la intersección del punto 2, crearemos muy rápido el producto correcto partiendo quizás de un prototipo evolucionado pero que podría llevarnos a arrastrar una deuda técnica muy grande. Esta deuda técnica podría hacer que termine siendo inabordable cada vez que queramos construir nuevas cosas sobre una arquitectura base tan pobre.

En la tercera y última de las opciones podríamos construir muy rápidamente un vehículo con una bonita línea deportiva y un gran motor pero olvidamos construir lo correcto: nuestro cliente en realidad necesitaba un producto con algo de capacidad de carga para su trabajo diario.

Según sea nuestro papel en el proyecto todos tenemos cierto sesgo hacia alguno de los círculos. Los dueños del producto, es decir nuestros clientes, tienden a poner todo el foco en construir lo correcto. A su vez los miembros del equipo de desarrollo tienden en cambio hacia construir correctamente, centrándose en las cuestiones de diseño de la arquitectura y de la solución técnica. Por último el Scrum Master tiende habitualmente hacia construir el producto de la forma más rápida posible.

Ese es el papel que suelo tener yo, el de Scrum Master o jefe de proyectos, que solemos andar preocupados por el tiempo en el que vamos a entregar las cosas. En nuestro descargo debo decir que la velocidad es siempre un aspecto importante. Iterar y entregar nuevas funcionalidades más pronto nos va a permitir aprender antes qué es lo más importante a construir ahora y cómo construirlo técnicamente de la mejor forma posible.

Todo esto que comento aquí lo puedes encontrar de forma muy condensada en el vídeo sobre Product Ownership de Henrik Kniberg. No sólo habla de este dilema entre construir lo correcto, construirlo rápido o de la mejor forma posible sino de muchos otros aspectos relevantes para los dueños del producto y directores de proyecto en el cliente. Échale un vistazo, es muy bueno.

El rol de Product Owner en Scrum

Hay muchas formas de denominar a la persona que cumple las funciones de Director del Proyecto en la organización que nos contrata. Aquel que tiene la visión del producto que necesita su compañía y que la representa ante el equipo de trabajo. Si pertenece a la organización externa que nos ha encargado el trabajo, el nombre que mejor se le ajusta es el de Dueño del Producto, como hace Scrum, porque es eso literalmente, el ‘Dueño’ de lo que se ha contratado. Si en cambio es una persona de nuestra propia organización la que va a representar al ‘negocio’ en el proyecto suele denominársele Product Manager o incluso Business Analyst según la empresa que le haya dado el cargo. Personalmente, quizás por el tipo de proyecto que habitualmente gestiono, me siento más cómodo llamándolo simplemente Director del Proyecto en el Cliente.

Lo llamemos como lo llamemos, cumple una función muy importante para el éxito de un proyecto. Es el encargado de decidir qué funcionalidades tendrá el producto que se está construyendo, cuáles son importantes y cuáles son prescindibles. Es posible que sea un usuario final del producto por lo que tendrá muy claro qué se necesita para obtener una herramienta útil en su trabajo diario, pero no debe ser útil solo para si mismo o su departamento, sino que deberá tener en cuenta los requisitos de toda su empresa.

Cuando comenzamos un nuevo proyecto, el Director del Proyecto en el cliente y todos los usuarios interesados en el producto final tienen un montón de ideas y grandes expectativas para el nuevo sistema. Lamentablemente, ningún proyecto, por grande que sea, puede contemplar todas y cada una de las sugerencias de sus usuarios. Algunas ideas serían irrelevantes para la mayoría, otras funcionalidades serán demasiado costosas de implementar o llevaría tanto tiempo desarrollarlas que retrasarían la puesta en marcha del producto. Es aquí donde el Director del Proyecto en el Cliente, que conoce bien el mercado y tiene una clara visión del producto, tendrá que priorizar las características más importantes y descartar aquellas que aportan menos valor al resultado final.

Para explicar hasta dónde llegan sus responsabilidades imaginemos que nuestra empresa decide contratar el desarrollo de un nuevo sistema de reserva de billetes de avión. En esta empresa han nombrado a Raúl como Dueño del Producto o Director del Proyecto y tendrá que trasladar a la empresa contratada todos los requisitos y necesidades que el nuevo sistema deberá cubrir.

Raúl tiene una visión muy clara de lo que quiere y está muy ilusionado con el proyecto. También lo están los responsables de IT, marketing y ventas que han elaborado una exhaustiva lista de funcionalidades a incluir en el nuevo producto. Incluso en conversaciones informales, los que serán nuevos usuarios del sistema, le trasladan a diario peticiones de nuevas funcionalidades. Raúl no quiere que se le escape nada importante y anota cuidadosamente todos estos requisitos en un cuaderno.

Al segundo mes de comenzado el proyecto Raúl se da cuenta que el Equipo de Trabajo en la empresa desarrolladora está entregando de 4 a 6 nuevas funcionalidades a la semana y que esta parece su capacidad máxima de trabajo. Está contento con el trabajo que están haciendo pero tiene un problema: en su libreta anota una media de 10 nuevos requisitos a la semana. La lista está creciendo y pronto necesitará un nuevo cuaderno.

Primero solicitó al Equipo de Trabajo que hiciera un esfuerzo para entregar estas diez funcionalidades cada semana. Lamentablemente, no muchas más funcionalidades eran entregadas y, lo que es peor, se comenzaba a percibir que la calidad de las mismas había bajado. En ocasiones incluso había que parar todo para corregir defectos en entregas previas. Si seguían así, la desmoralización y el estrés iban a dominar el proyecto.

Raúl iba a decidir a partir de ahora qué se hacía y qué no. Todas las funcionalidades no iban a poder se desarrolladas, por lo menos no ahora. Algunas tendrían que esperar a una futura versión. Desde luego, la funcionalidad similar al Clippy de Windows para asistir en la compra de los billetes de avión era un claro ‘No’.

 

Pero ¿cuáles desarrollar primero? ¿qué criterio seguir? Raúl se dio cuenta de que no había relación directa entre el coste de las funcionalidades y su valor para el producto final. Algunas funcionalidades eran fáciles de construir pero otras, en cambio, llevaban mucho tiempo de desarrollo pero no por ello eran las que más valor aportaban. Si preguntaba directamente al Equipo de Trabajo en cuantos días podría estar hecha cada una de las funcionalidades sabría su coste aproximado y si preguntaba a los usuarios por una valoración del 1 al 5 para cada funcionalidad sabría calcular el valor para su empresa.

Si había dos funcionalidades que tienen el mismo coste aproximado pero una tiene valor 1 y la segunda valor 3 estaba claro que se construiría la segunda funcionalidad. Si en cambio, había dos funcionalidades de aproximadamente el mismo valor para la empresa pero tardaríamos 5 días en desarrollar una de ellas cuando la segunda podría estar desarrollada en una horas, también estaba claro en cuál se trabajaría primero.

Raúl sabía que el coste y el valor de cada funcionalidad no eran números absolutos sino solo una aproximación. No sabemos cuánto pesa una manzana pero sí sabemos que es aproximadamente 5 veces más grande que una fresa y que la fresa gusta más (para los que van a pagar por ella al menos) por lo que la fresa se construiría primero. Es un modo fácil de decidir qué aporta más valor y más rápido a nuestro proyecto.

La comunicación es una parte importante de las responsabilidades de Raúl. Deberá estar en contacto directo con el Equipo de Trabajo pero también con las personas de su empresa que tienen algo que decir sobre el producto que se va a construir. Debe ser hábil para saber decir ‘no’ cuando sea necesario. Debe ser práctico también para tomar esta decisión de forma rápida y directa y, además, conocer muy bien su negocio para asegurarse de que se construye lo que realmente aportará valor a su empresa. Todo un papel para Raúl ¿no creen?

Este artículo se publicó por primera vez en el número 3 de la revista IT Proiectus. Puedes encontrar este artículo y muchos otros en la web de Proiectus, consultoría y formación en dirección de proyectos.

Suscríbete