“si no tenemos datos, entonces tenemos opiniones, y en ese caso, vayamos con la mía” – Management 3.0
Hoy en día, hay muchas frases sobre las métricas: “lo que no se mide no se mejora”, “mide aquellos que quieres que ocurra”, “tenemos que ser data-centric”… Además, con los cambios de paradigma que nos proporcionan el BigData o el IoT, está claro que los datos importan. Los datos les ocurre algo parecido a Scrum o Agile, el hecho de que los tengan no sirven de mucho sin el mindset adecuado. Vamos a dedicar este post a repasar algunas métricas de producto que son clave para nuestros equipos. ¡Comenzamos!
¿Qué solíamos medir?
Las métricas actuales que rigen la mayoría de empresas están muy relacionadas con el project management. Los proyectos tienen como función equilibrar el alcance (requisitos), el coste (presupuesto) y el tiempo (cronograma). En general, las métricas habituales de proyecto son derivadas de estos factores:
- Cumplimiento de la fecha
- Porcentaje de cumplimiento
- Cumplimiento del presupuesto
- Rendimiento de los recursos (personas)
Este tipo de métricas acaba derivando en situaciones más complicadas. Es muy habitual estimar tareas y medir su cumplimiento, para lo que imputamos el tiempo dedicado. Además, estas imputaciones acaban por volverse un poco “locas”. ¿Cómo se imputa el tiempo dedicado a formación? ¿un desayuno? ¿y si ayudo a un compañero?
Además, estas métricas se centran mucho en acabar, en tener un proyecto construído, independientemente del resultado real de lo que hemos construido. Hemos heredado estas métricas porque necesitamos controlar el trabajo de las personas y nos centramos en el resultado de construir ¿Y si nadie quiere lo que construimos? ¡No es problema del jefe de proyectos!
Value Thinking
Hoy en día, cuando estamos en el mundo del conocimiento y nos enfrentamos a un problema complejo (cuya solución no es trivial), usamos la estrategia de prueba-error. En Scrum lo traducimos por inspección-adaptación. En estos contextos, el auténtico éxito no está en la construcción de un producto, sino en el valor que dicho producto aporta.
Puede parecer sencillo de entender, pero es treméndamente complicado de implantar. Las empresas no tienen el value thinking entre su ADN, porque genera mucha incertidumbre. Es más fácil medir el estado de un proyecto que va a tener diez features, que un producto cuya misión es aumentar un 30% los usuarios. Lo primero está claro y definido, lo segundo es ambiguo y, por tanto, transmite descontrol.
Me duele en el corazón cuando una empresa dice frases como “negocio no le ve valor a Scrum”. Es curioso, Scrum es un marco que se centra en generar valor, que se puede traducir en dinero. ¿Por qué no le gusta al negocio entonces? Pues porque seguimos con la mentalidad de construir y desarrollar sin mirar los resultados. Además, creemos que el software no es más que un “canal de venta” sin entender que la tecnología debe fusionarse con el negocio, para poder generar valor en todos los sentidos.
¿Para qué hacemos esto?
Antes de definir métricas, debemos tener un “para qué” definido. En Scrum, se introdujo el concepto de Product Goal. Este objetivo debe marcar el futuro a medio-largo plazo de nuestro producto. Cuidado, debemos evitar definir un determinado alcance, del tipo “hacer X en seis meses”.
Además, hay equipos que trabajan el concepto de “visión de producto”. La visión es un objetivo a largo plazo, pero que quizás nunca se cumpla. Por ejemplo, “ser los mejores en el sector”.
Tener un Product Goal o una visión de producto consensuado es clave porque la necesitamos para definir las métricas de producto clave.
Métricas de Producto de éxito
Existen muchas maneras de clasificar métricas de producto. Para mí, las podemos diferenciar en dos grandes grupos: las de éxito y las de valor.
Las métricas de éxito son las que sirven para decirnos si estamos alcanzando nuestros objetivos. Si tengo un e-commerce, las ventas pueden ser nuestra métrica de éxito. Si tenemos un producto que sirve para recuperar deuda bancaria, el éxito será la cantidad de deuda que somos capaces de conseguir. Si tenemos un producto que eficiente las reuniones, la métrica de éxito puede ser el tiempo ahorrado en cada reunión.
Una vez, trabajábamos para digitalizar un proceso muy largo en una empresa de ropa. Le preguntamos al stakeholder más importante que cuál era el éxito. Nos respondió: “poderme ir a mi casa temprano”. ¡Podemos medir el número de días que esto ocurre!
Hay que tener un poco de cuidado con las métricas de producto de éxito. Centrarse en una sola métrica puede ser peligroso. Imagina que eres la Ministra de Empleo de un país y decides que tu métrica es reducir el número de personas “paradas”. Podrías reducirlo a cero en un solo día, contratando a todas en el Ministerio. Eso sí, esta medida acabaría hundiendo el presupuesto del gobierno.
Por tanto, es útil definir varias métricas de éxito que nos permita entender sí estamos funcionando.
Métricas de Producto de Valor
Para definir las métricas de producto de valor utilizamos Evidence Based Management (EBM). EBM es una propuesta de métricas que desarrolló Scrum.org para mostrar métricas de producto que pueden ser útiles si queremos evolucionar de las clásicas métricas de proyecto y control a producto y valor. Algunas métricas interesantes de EBM que podemos destacar:
- Beneficios, ingresos y gastos: cualquier producto debería contar con esta métrica, como mínimo, medir el coste y entender si está siendo rentable.
- Métricas de Uso: entender cómo se comporta el usuario, qué features son más utilizadas y cuáles no están funcionando.
- Satisfacción de usuarios y del equipo: es clave saber cómo de contentos están las personas afectadas por nuestro producto. Además, saber el estado del equipo es esencial para tomar decisiones.
- Time to Market: medir los tiempos del equipo es clave. Podemos medir el lead time, el cycle time o el time to learn.
- Errores / Bugs: podemos medir tanto los errores como la tendencia de los mismos. Podemos clasificarlos de muchas maneras para tener información más rica.
- Versiones: muchas veces tratamos de mantener muchas versiones de nuestro producto, lo que lo convierte en costoso. Por ejemplo, si medimos los navegadores de nuestros clientes y una determinada versión es muy poco usada, quizás debamos descartar ser retrocompatibles con ella.
- Dedicación del equipo: una de mis favoritas es medir en cada Sprint a qué hemos dedicado el tiempo. Para ello, pintamos todo el trabajo que hemos completado (en items) y vemos el porcentaje que hemos dedicado a cada tipo. Por ejemplo: hemos dedicado un 30% a errores.
Y tú, ¿qué métricas de producto utilizas?
