Introducción
Un producto tiene muchas formas de ser concebido, a veces proviene de la idea de un soñador y otras de una concepción colectiva, pero sin importar su origen necesita de alguien que se encargue de llevar la idea a través de un viaje para que se torne en un producto viable en el mercado.
Haciendo una analogía, un producto es como un barco que navega pero precisa de alguien que pueda ver la costa en el horizonte y diga hacia allá vamos. Continuando la analogía, la linea recta hacia el objetivo no siempre es el mejor camino o el más seguro, por lo cual a medida que se navega se van haciendo adaptaciones sin perder de vista el objetivo.
Un Product Owner tiene dentro de su rol trazar la vision del producto, descubrir un propósito inspirador, y concebir una estrategia que sea lo suficientemente flexible y adaptable que permita evolucionar el producto escuchando al mercado.
Como cualquier otro de los roles que Scrum propone, el rol del Product Owner no es para cualquier persona pues ciertas características, experiencias, y rasgos de personalidad preparan mejor a un individuo para triunfar en este rol.
Estrategia del Producto
La visión de un producto es la que permite tener un propósito articulador, algo que ayuda a que la gente que trabaja en el producto entienda que están construyendo algo que tendrá un gran impacto y no simplemente perdiendo el tiempo construyendo algo que nadie vaya a utilizar.
Descubrir la visión de un producto es el primer paso para poder entender porque haremos lo que haremos, a quienes servirá el producto, qué causa defenderemos, y que problema queremos resolver o cambiar.
Existen varias formas de descubrir la vision, una de las más sencillas pero a la vez eficientes que he encontrado es utilizar la metáfora del Circulo Dorado [Sinek11] que permite encontrar el porque antes que el cómo y el que.
He utilizado el Circulo Dorado en múltiples contextos, países y organizaciones, y estos son algunos consejos que puedo proveer:
- Tener un grupo diverso y multidisclinario fisicamente presente en el mismo lugar
- Utilizar un papelógrafo, post-its y marcadores
- Poner un timebox de no mas de 15 minutos
- Incluir en la articulación del porque frases incluyentes como “nosotros creemos” o “nosotros queremos”
- Incluir en la articulación del porque palabras que toquen sentimientos como por ejemplo “familia”, “madre tierra”, “vida”, “salud” o “comunidad”
El poder del Circulo Dorado está en que él porque descubierto con esta técnica debe resonar con quienes los escuchen; dicho de otra forma ésta será la causa inspiradora que motivará al grupo de personas a perseguir una vision de un futuro mejor.
Según Pichler [Pichler16] una vision efectiva tienen cuatro características principales:
- Es amplia lo cual permite al producto tener grados de maniobrabilidad y hacer adaptaciones para de todas maneras alcanzar el objetivo
- Es compartida por toda la gente que trabaja en el desarrollo del producto y quienes lo consumirán
- Es inspiradora pues busca hacer una diferencia en el mundo a través de un producto o servicio
- Es concisa y fácil de comunicar con palabras simples y consecuente todos la entienden
Una vision clara es la que permite derivar una estrategia más concisa y realista. La estrategia trazará el camino para alcanzar la vision, es decir del cómo la vision se hará realidad.
Para que la estrategia cobre vida ésta necesita de pasos más concretos y es ahi donde interviene la táctica. A nivel táctico también se incluyen los detalles necesarios para desarrollar el producto, muchas veces al hacer el desglozamiento en lo táctico detona un descubrimiento que acaba haciendo que la estrategia cambie.
Por tanto, de la vision se deriva la estrategia y de la estrategia la táctica. Lo anterior es de vital importancia para un Product Owner que no debe perderse solamente en la escritura de historias de usuario.
Planificación y Pronóstico de Productos
La planificación de cuando se entregará un producto tiene mucho que ver con el ciclo de lanzamientos que este tendrá. Si el producto es software no buscamos una sola entrega del producto cuando esté completamente terminado, por el contrario, buscamos hacer lanzamientos parciales en ambientes de producción reales para que los usuarios puedan proveen retroalimentación realista.
Como parte de la planificación el Product Owner deberá decidir con el resto del equipo y los stakeholders la frecuencia con la cual se pondrá en producción. La periodicidad de estos lanzamientos dependerá de varios factores y en muchos casos puede verse una correlación directa entre la capacidad técnica del Equipo de Desarrollo y la frecuencia con la cual este puede llevar código a producción.
Algunos ejemplos típicos de periodicidad puestas en producción incluyen:
- Una vez al año
- Una vez por semestre
- Una vez por cada trimestre del año
- Una vez al final de cada mes
- Al final de cada Sprint de dos semanas (dos veces al mes)
- Una vez cada semana
- Una vez cada día
- Varias veces al día
Desde luego la periodicidad que se escoja puede estar desasociada de las lanzamientos formales [Forsgren18]. Así por ejemplo el equipo puede tener la capacidad de poner código varias veces al día en producción pero el Product Owner puede decidir lanzar el producto formalmente en un ciclo de cuatro meses.
El punto anterior es especialmente importe porque muchas veces he encontrado la confusion entre el concepto de lanzamiento (release) y puesta en producción. Un lanzamiento puede implicar cosas como marketing, aspectos legales, difusión en redes sociales, etc. y una puesta en producción es una práctica ingenieríl que permite validar las hipótesis de que el producto que construye el Equipo de Desarrollo es el correcto y funciona en un ambiente real.
Ejemplos típicos de ciclos de lanzamiento incluyen:
- Oportunista, es decir cuando una condición externa o de mercado disparan la necesidad de lanzar inmediatamente el producto
- Tiempo fijo, que implica que se lanzará el producto en una fecha especifica
- Multi-Sprints, es una variación de Tiempo Fijo pues implica que después de X Sprints que equivalen a N meses se lanzará el producto
- Alcance fijo, que solamente permitirá lanzar públicamente un producto cuando todas sus características se hayan implementado. Desde luego esto es no solo costoso y riesgoso, sino que también desvirtúa el principio de porque usar un enfoque ágil de alcance adaptativo y tiempo finito
Un Product Owner tiene a su disposición varias técnicas y herramientas para planificar el desarrollo y entrega de un producto a través de un horizonte de tiempo definido.
La herramienta más básica es un Product Backlog que se ordena constantemente en base al descubrimiento de nuevas prioridades/items, retroalimentación de los stakeholders y capacidad técnica del equipo.
Los mapas de impacto [Adzic12] son otra valiosa herramienta que permite ir analizando que items del producto están causando que impacto en que stakeholder y hacer adaptaciones en el producto en función de ese análisis.
Priorizar y repriorizar con los stakeholders una hoja de ruta del producto es una otra herramienta muy valiosa a la hora de tratar de definir que es importante y que no, que debe incluirse en el lanzamiento actual y que podría esperar para futuro.
Las tres técnicas anteriormente mencionadas en su esencia buscan adaptar el alcance en función de que tiene sentido, desde la perspectiva de los usuarios finales, incluir o no en el producto.
Este tipo de pronóstico se distancia de la forma tradicional de tratar de predecir sí vamos a llegar a la fecha X con todo el alcance completado que se descubrió inicialmente.
La gran labor del Product Owner es precisamente convencer a los stakeholders de que para construir un producto que tenga alguna chance en un mercado cambiante y evolutivo, es necesario adaptar el alcance multiples veces dentro de un tiempo finito, descubriendo en cada ciclo como el producto puede aportar mas valor.
Conclusiones
Un Product Owner es en esencia un estratega y un visionario; como estratega su mente debe estar abierta a cambiar la estrategia con tal de llegar al objetivo del producto, como visionario descubre cual es la visión del producto y los traza los objetivos que ayudaran a materializarla.
Si bien el trabajo del Product Owner no lo distancia de lo táctico pues hay un artefacto con el cual debe trabajar, el Product Backlog, su trabajo con el no debe se al nivel de detalle minucioso sino más bien orientado al ordenamiento que busca major impacto con menos funcionalidad implementada.
Finalmente, la efectividad de alguien en rol del Product Owner no debe medirse por que tan bien hizo ejecutar un alcance descubierto pues eso seria un indicador de que su rol ha sido completamente mal entendido.
Bibliografia
Sinek11 Sinek S., 2011. Start with Why: How Great Leaders Inspire Everyone to Take Action, Portfolio
Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting
Forsgren18 Forsgren N., Humble J, Kim G., 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, IT Revolution Press
Adzic12 Adzic G., 2012. Impact Mapping: Making a Big Impact with Software Products and Projects, Provoking Thoughts
