Self-Learning > Product Management

¿Cómo medir el éxito en la creación de productos con Scrum?

5 min de lectura

¿Nos habremos equivocado durante tantos años? Es simplemente una pregunta que se me viene a la mente de manera recurrente con respecto a la forma en la que medimos el progreso de nuestros proyectos, tanto sea de la forma tradicional como desde el punto de vista Ágil. (Artículo publicado originalmente el 20 Septiembre de 2015 bajo el título "Más allá del producto funcionando" como parte de la serie #enloqueando).

Creación de productos con Scrum

¿Nos habremos equivocado durante tantos años? Es simplemente una pregunta que se me viene a la mente de manera recurrente con respecto a la forma en la que medimos el progreso de nuestros proyectos, tanto sea de la forma tradicional como desde el punto de vista Ágil.

Habitualmente medimos el progreso de lo hecho

Desde un enfoque tradicional, me animaría a decir que todas las organizaciones con las que me he relacionado y que utilizan un enfoque de cascada en la gestión de sus proyectos, definen el éxito de su trabajo mediante la entrega del alcance estipulado, en tiempo y dentro del presupuesto, es decir: alcance, tiempo y costo.

En la vereda de enfrente está la Agilidad y su Manifiesto Ágil, mediante el cual define que la principal medida de progreso es el software funcionando. Extrapolado a otros ámbitos fuera del software, sería algo así como "la principal medida de progreso es el producto funcionando".

Yo últimamente me estoy encontrando más y más en desacuerdo con ambos puntos de vista. Desde siempre estuve en desacuerdo con la interpretación de éxito de las maneras tradicionales de gestión que miden el cumplimiento del alcance, el tiempo y el costo, sin importar qué tan robusto, integrado, funcional y útil es lo que se está construyendo. Y además, creo que la definición de progreso Ágil (software funcionando) responde a una necesidad coyuntural de los equipos de desarrollo: la postergación de la integración y pruebas punta a punta del software siendo construido. El hecho de no ver software funcionando sino hasta el final de los proyectos hace que el riesgo de re-trabajo por falta de calidad sea demasiado grande como para considerar que se está avanzando. Este síntoma también conocido como el síndrome del 90%, una falsa sensación de progreso.

Ahora, lo que a mí me parece es que ambas medidas hablan de las actividades que estamos haciendo y no del qué tan útil es el producto que estamos construyendo. Por lo tanto, yo puedo entregar en tiempo, en forma y cumpliendo con el alcance un producto inútil. Inclusive, aunque lo construya en iteraciones (sprints) y me asegure que ese producto funciona al final de cada iteración.

En un contexto en el cual no tengo feedback real del negocio y/o no mido el impacto del producto en mis objetivos de negocio, voy a seguir teniendo una falsa sensación de progreso, seguramente no con respecto a los aspectos técnicos del producto, pero posiblemente si con respecto a los objetivos de negocio que estoy buscando alcanzar.

Mejor, midamos el éxito del producto

¿Y entonces? Y entonces yo creo que debemos medir el cumplimiento de los objetivos de producto además del software funcionando. ¿Cómo sería eso? Vamos con un ejemplo concreto:

En una empresa cliente estaban desarrollando un producto web con el objetivo de incrementar las ventas mediante el canal digital-online de ciertos productos. El alcance constaba de la adición de una propiedad a ciertos productos para que aparezcan como destacados en el sitio web, algo común, nada de otro mundo.

Si midiéramos de manera tradicional, el éxito estaría alcanzado al lograr el desarrollo de esta funcionalidad, dentro del tiempo y presupuesto esperado. Punto.

Si midiéramos de manera ágil, el éxito estaría alcanzado al entregar esta funcionalidad funcionando en el sprint comprometido. Punto.

¿Y qué pasa si esa funcionalidad no incrementa las ventas? ¿Realmente fue un trabajo exitoso? Yo lo dudo.

Cada vez me resulta más natural preguntarme: ¿cuál es la hipótesis en la cual me estoy basando para llevar adelante esta iniciativa? ¿cómo voy a medir el impacto de mis acciones y corroborar mi hipótesis?

En el caso de los productos destacados, sería algo así como:

  • ¿cuál es la hipótesis en la cual me estoy basando para llevar adelante esta iniciativa?: No logramos vender la cantidad esperada de ciertos productos porque las personas que visitan la página no los encuentran o no se sienten atraídas por la manera en la que los estamos presentando. Si los destacamos y hacemos más accesibles, las ventas se van a incrementar.
  • ¿cómo voy a medir el impacto de mis acciones y corroborar mi hipótesis?: al destacar ciertos productos, debería incrementarse en un 20% las ventas de los mismos por el canal digital-online al cabo de un mes.

Entonces, al cabo de un mes voy a poder decir si mi proyecto fue exitoso al corroborar el incremento mayor al 20% en las ventas de los productos destacados, y ya no voy a pretender que el éxito haya sido alcanzado solo por entregar el alcance, dentro del tiempo y el presupuesto, ni tampoco por haber entregado un incremento funcionando del producto.

Formas de medir estos impactos hay muchas, por citar algunas: Impact Mapping u OKRs - Objectives and Key Results (la medida de objetivos impulsada por Google).

En definitiva, la pregunta sigue viniéndome a la cabeza cada vez que leo el Manifiesto Ágil: "la principal medida de progreso el el software/producto funcionando"... ¿Nos habremos equivocado durante tantos años?