×
×

Producto, resultado, impacto, métricas y contexto

Output, Outcome, Impact y Process

En 2014 leí el excelente libro User Story Mapping de Jeff Patton, con el que aprendí muchas cosas más allá de la propia técnica de mapeo de historias, especialmente la importancia de diferenciar las consecuencias del desarrollo:

  • Producto (output): todo aquello que podemos medir sobre el producto entregado, como funcionalidades, características o defectos.
  • Resultado (outcome): todo aquello que podemos medir sobre los cambios (positivos o negativos) en la vida de los usuarios del producto, como ahorro de tiempo, aumento de ingresos, reducción de incertidumbre, etc.
  • Beneficio (impact): todo aquello que podemos medir sobre que lo obtiene la organización que desarrolla (u opera) el producto, como aumento de ventas, recurrencia de clientes, defenderse de otros competidores, etc.

Este video lo explica muy bien, con el arte de Jeff Patton explicando mientras dibuja.

 

Además habría que medir otro grupo de métricas para tener un tablero "balanceado" de métricas, como son las que hablan del proceso de trabajo, p.e. velocity, lead time, tasa de errores y retrabajos, etc. 

En los cursos Professional Scrum Product Owner y Professional Agile Leadership suelo explicarlo con este cuadrante, donde se clasifican métricas que:

  • Suelen ser más significativas para la organización (internas) y aquellas que son más importantes para el usuario o clientes (externas).
  • Son previas en el proceso de desarrollo (Lead), más fáciles de manipular con consecuencias más inciertas, y aquellas que describen las consecuencias (Lag) pero son difíciles de manipular.

P46_ProcesoProductoImpactoResultado.jpg

 

Durante el curso pido a los alumnos que identifiquen métricas que se toman y, dicho a ojo de buen cubero, los resultados suelen ser del estilo:

  • Proceso: 70% de las métricas propuestas.
  • Producto: 20% de las métricas propuestas.
  • Resultados e impacto: 5% cada uno de las métricas propuestas.

 

Como consecuencia, la inercia organizativa (centrada en sus operaciones y procesos, en vez de en el cliente) hace que se midan aspectos fáciles de manipular pero que nos dicen poco sobre el valor. Esto nos puede ayudar a inspeccionar y adaptar para mejorar el resultado e impacto:

  • Producto: ¿Se usan las funcionalidades desarrolladas? ¿Cuáles sí y cuáles no? A partir de estos datos se puede hacer una investigación cualitativa.
  • Resultado: ¿Conocemos el problema que queremos solucionar? ¿Como podemos medir el resultado con perspectiva de usuario?
  • Impacto: ¿se está convirtiendo el valor para el usuario en beneficio para la organización? ¿se debe perseverar en la dirección actual del desarrollo o pivotar? 

 

Desarrollos centrados en el usuario o en el cliente

Hace poco asistí al curso Professional Scrum with UX (PSU) con Jeff Patton, paso necesario para poder impartir este curso. Además del interés lógico de saber como integrar bien el trabajo de los especialistas en experiencia de usuario (UX), tener la perspectiva del desarrollo centrado en UX te hace reforzar la importancia de:

  • Entender (y si se puede cuantificar) los problemas del usuario.
  • Plantear hipótesis de solución y testearlas de la manera más barata posible.
  • Medir si las soluciones aportadas influyen en la conducta del usuario.
  • Basar la gestión del backlog según los resultados medidos.

 

Cuando reflexionamos sobre UX, podemos plantear adaptaciones de Scrum realmente intrigantes como:

  • Done es "potencialmente entregable", pero ¿es suficiente en desarrollos centrados en el usuario?
  • ¿Se pueden medir los resultados sobre el usuario durante el Sprint?
  • ¿Cómo podemos visualizar en el backlog el trabajo de investigación y de validación de hipótesis?

Dado que no quiero hace "spoiler" del curso, dejare estas reflexiones en el aire.

 

Hace también poco leí esta muy buena presentación de Manel Ibáñez sobre OKRs. Abunda en la importancia de medir más aquello que le importa al usuario:

  • Utilizando los OKR como método para retar más al equipo y buscar su implicación en la búsqueda de soluciones, en lugar de "limitarse a entregar lo que le piden".
  • Calibrar los retos que nos proponemos respecto al cliente, para evitar el conformismo o las expectativas irreales.

 

Una cosa de las pocas cosas que no me convenció de la presentación (posiblemente me haya perdido algo al ver solo las slides) es esa falsa dicotomía y asociación entre el "mal agile" (proyecto, taylorismo, fábrica de features) y el agile genuino (no-proyecto, decisiones totalmente distribuidas, orientación total a valor, etc.). El contexto es importante, y fijar expectativas alcanzables también lo es.

 

Contextos

Hace poco vi un tweet genial de Neil Killick:

P46_ContextlessAdvices.JPG

 

Aunque me gustaría desarrollar más el argumento, por que lo merece, quiero expresar algunas ideas sobre las expecativas y el enfoque de la agilidad según su contexto:

  • No puede funcionar igual un "proyecto ágil" donde conocemos al cliente, y podemos interactuar con éste, que un desarrollo para una audiencia desconocida y grande (tanto en tamaño como en subtipos).
  • En algunos contextos medir las cosas será imprescindible. En otros puede bastar co-desarrollar requisitos y validar cara a cara.
  • El manifiesto ágil no está muerto. La métrica de software funcionando no tiene porqué estar reñida con que sea útil.
  • El UX y Scrum no tienen porque estar reñidos, sino que pueden ser buenos aliados (y ayudar a colaborar a roles como UX y Dev). Eso queda claron en el curso Professional Scrum with UX.
  • Si tiene sentido y es posible, se debe comenzar investigando y cuantificando los problemas del usuario antes de plantear (y presupuestar) las soluciones.

 

Si te ha interesado este artículo

Publicamos un boletín mensual con entre 2 y 4 artículos y novedades sobre agilidad y temas relacionados. Nos esforzamos por seleccionar contenido de calidad y ser respetuosos con tu tiempo.