Indice
- Introducción
- Comprender y Definir "Valor"
- Priorización del Backlog
- Comunicación Clara y Constante
- Aumentar el Engagement del Equipo
1. Introducción
En los últimos días, no han sido pocas las ocasiones en las que he oído o leído acerca de cómo este gran TSUNAMI de la IA, que está llegando a nuestras vidas de todas formas posibles, puede revolucionar nuestro día a día como Product Owner. Es por ello que considero relevante recordar las bases de nuestras funciones y dónde reside nuestro valor como Product Owners para que, a la hora de aprovechar esta tecnología en nuestro día a día, no nos perdamos en su uso y se desvirtúe esta figura.
Dado que una de las funciones del Product Owner es, de alguna manera, que todos tenemos claro de lo que estamos hablando, vamos a comenzar por definir este rol. Personalmente me ciño a la definición dada por la última actualización de la “Scrum guide” la cual dice así:
“El Propietario del Producto es responsable de maximizar el valor del producto resultante del trabajo del equipo de Scrum. La forma en que esto se hace esto puede variar ampliamente entre organizaciones, equipos Scrum e individuos.”
Obviando que la traducción oficial de la Scrum Guide parece estar realizada por el traductor de un buscador web famoso, me quiero centrar en esa responsabilidad que se asigna, ese “maximizar el valor del producto resultante del trabajo del equipo de Scrum”.
Pequeña anotación para seguir alineados: Aunque en algunas organizaciones el término de “Equipo de Desarrollo” (Development Team en inglés) y “Equipo de Scrum” (Scrum Team en inglés) se utilicen como si se hablara de lo mismo, he de aclarar que cuando se habla de “Equipo Scrum” se refiere al “Equipo de Desarrollo”, al “Scrum Master” y al “Product Owner”, es decir, que el producto resultante del cual como Product Owners se tiene que encargar de maximizar su valor, también es responsabilidad de este.
2. Comprender y Definir "Valor":
El primer paso para cualquier Product Owner es entender y profundizar en el producto en el que está o se va a comenzar a trabajar, así como el entorno en el que este se está desarrollando (sector, competidores, noticias que puedan afectar a dicho producto…). A menudo, las labores del día a día del Product Owner, nos pueden hacer perder el horizonte hacia el que se está remando y empecemos a realizar prácticas más asociadas a las de un Project Manager que las de un Product Owner. Es por ello que, como Product Owners, tenemos que tener siempre en mente que nuestra responsabilidad es la de maximizar el valor para los clientes y stakeholders, y no la de perdernos en métricas de proyecto como pueden ser la velocidad, número de tests realizados, líneas de código, etc…
- Si estas son las métricas con las que actualmente estás trabajando y quieres saber cuáles se pueden incorporar para centrarnos en el valor, no te preocupes que en las próximas semanas subiré un post hablando de este tema en concreto.
Por ello, el segundo paso para cualquier Product Owner es comprender qué significa "valor" para el negocio, es decir, para los stakeholders y usuarios finales o clientes. Esto implica una colaboración constante y efectiva con todas las partes interesadas para definir y tener claras las necesidades y prioridades. Para ello, Scrum nos da las herramientas necesarias, en forma de eventos como la Sprint Review, para esta colaboración y comunicación constante sobre la cual ahondaremos más adelante (ya que nos hemos aprovechado de su definición de Product Owner, vamos a aprovechar también los eventos que propone).
Finalmente, y tras conocer los entresijos del negocio y las necesidades del mismo, un Product Owner debe ser capaz de traducir estas necesidades en historias de usuario claras y priorizadas en el Product Backlog, lo que nos lleva al siguiente punto en el que un Product Owner, como persona y no como IA, puede aportar valor.
3. Priorización del Backlog:
Nuestra responsabilidad clave como Product Owner, es el Backlog, ya que es de este del que saldrá el trabajo del Equipo de Desarrollo. Es una práctica habitual en las empresas que esta priorización se haga a través de medidas como “High, Medium or Low; o MoSCoW (Must, Should, Could, Won´t)” pero, las últimas actualizaciones de Scrum han cambiado la palabra “priorización” por la palabra “orden” para evitar este tipo de actuaciones que, aunque siguen siendo en cierta medida válidas, no “especifican” en qué o cómo afectan a las diferentes variables que aportan valor al negocio.
Para poder utilizar la IA como ventaja y que no nos utilice a nosotros, tenemos que poner el foco en las diferentes áreas que son importantes para nuestro negocio o producto. Si bien cada uno tiene sus necesidades específicas, te dejo por aquí una buena forma de empezar a ordenar nuestro Backlog:
- Valor de Negocio: Haciendo referencia al valor creado por la implementación de la prestación, desarrollo o característica en el que se esté trabajando.
- Riesgo: Esta variable hace referencia a lo expuestos que nos deja a una situación de desventaja en caso de no implementar esta característica o funcionalidad. Hay dos tipos de riesgos:
- Riesgos de negocio (por ejemplo, el regulatorio).
- Riesgos técnicos (por ejemplo, implementar una nueva tecnología en el proyecto).
- Coste/Tamaño: Tiempo y esfuerzo que el Equipo de Desarrollo necesita para construir e implementar dicha funcionalidad.
- Dependencias: Funcionalidades que dependen de otras para poder implementarse (burocracia, negocio, tecnología, etc.).
Estas son solo unas de las muchas variables que se pueden utilizar a la hora de ordenar nuestro Backlog, por lo que no solo están abiertas a cambio y debate, sino que deberían ser cambiadas y debatidas para saber si son las que mejor aplican a nuestra realidad.
4. Comunicación Clara y Constante:
Con todo lo mencionado anteriormente, se hace necesario hacer hincapié en este punto ya que es, junto con el siguiente y último punto que trataré, el más humano de todos. No tenemos que perder de vista que trabajamos con personas y tener una comunicación transparente y constante es fundamental para que, como equipo, se consigan los objetivos que realmente hay que conseguir.
¿A qué me refiero con esto? Bueno, creo que todos estamos de acuerdo en que, en el mundo actual, de nada vale meterse en el garaje de tu casa o “la cueva” durante 12 meses y desarrollar el próximo gran producto, ya que para cuando salgas, el mundo no será el mismo. Por esta razón, como Product Owners debemos estar en constante comunicación con el negocio, los clientes, stakeholders y el propio equipo, para conseguir los objetivos que realmente hay que conseguir.
Como Equipo de Scrum, y en especial como Product Owners, tenemos que estar buscando constantemente feedback de los stakeholders principales para comprobar y reafirmar que se está avanzando en el buen camino. Hay algunas líneas de pensamiento que incluso consideran que un incremento no está finalizado hasta que no se ha probado contra el mercado o cliente en cuestión.
Este involucrar a los stakeholders en el desarrollo de la funcionalidad, ya no solo hace que se avance en el camino correcto, sino que les responsabiliza y empodera sobre el resultado final, lo que reducirá en gran medida los típicos señalamientos con el dedo o la búsqueda de culpables.
5. Aumentar el Engagement del Equipo
Finalmente y seguramente el punto más importante en esta vuelta a los orígenes del valor del Product Owner, es el equipo. Sin el equipo, da igual que se conozca el negocio, que se tengan claras las prioridades o se sepa la definición exacta de valor. Si tengo que elegir una cosa con la que os tenéis que quedar, es con este punto.
Fuera de quedar muy poético, vamos a aterrizar esto tal y como hemos hecho en los puntos anteriores. Es importante, al igual que hemos hecho con los stakeholders, promover la autonomía, responsabilidad y empoderamiento del equipo. El backlog, aunque nuestra responsabilidad como Product Owners, no es de nuestra propiedad y es por ello que debemos y tenemos que fomentar que el equipo tome decisiones y opine acerca del mismo. Para esto, promover un entorno de colaboración, transparencia y confianza es fundamental.
En mi experiencia profesional, no han sido pocas las veces que he visto que el Product Owner se siente como alguien que no forma parte del equipo de Scrum, sino que incluso se siente que está por encima, como si fuera su responsable. Es nuestra responsabilidad como Product Owners el fomentar la colaboración, el hacer que el equipo nos sienta cerca, el fomentar un entorno de reconocimiento y motivación… en resumen, ser parte del equipo.
"Es nuestra responsabilidad como Product Owners el fomentar la colaboración, […] ser parte del equipo."
Como conclusión, tenemos que tener en cuenta que, aunque si bien la IA ya está con nosotros en nuestro día a día para mejorar y hacer más eficientes nuestros procesos (y en ningún momento este post pretende ser un post anti-IA) podemos aprovechar esta oportunidad para conectar más aún con las personas que componen los equipos y utilizar nuestro humano pensamiento crítico para tomar decisiones que generen un mayor valor en nuestro día a día.
Si quieres ahondar más en los conocimientos de este post, te recomiendo la lectura del libro “The Professional Product Owner: Leveraging Scrum as a Competitive Advantage” ya que lo considero una buena introducción a las buenas prácticas como Product Owner.
