En una entrada anterior os hablé ya de algunas métricas, (ir a las de largo plazo) que bauticé así porque a mí me había servido ir recopilando datos y sacar tendencias. Tenerlas puede servir para deducir causas a ciertos problemas o bien encontrar con ellas objetivos de equipo.
¿Cómo surgieron las métricas de medio plazo?
En equipo establecimos aquellos puntos que nos ayudarían a medir nuestra evolución. Más allá de estar pendientes de los resultados a corto plazo e intentar mejorar a corto plazo, el objetivo era medir algunas casuísticas que nos podrían dar información en un término temporal más amplio.
¿Cuáles pueden ser estas métricas para un equipo de desarrollo de producto?
La velocidad del equipo
Medimos el lead-time (tiempo desde que una tarea se crea hasta que se termina), el cycle-time (tiempo desde que una tarea se empieza hasta que se termina) y como no, el throughput (tareas terminadas) mensualmente. Lo hacemos únicamente de las historias de usuario con la intención de encontrar la velocidad de entrega de valor tangible para el usuario final y poder predecir entregas de funcionalidades futuras.
El tipo de tareas
Se trata de intentar trabajar con tipos de tareas como historias de usuario, tareas (técnicas), incidencias, spikes (tareas de investigación)…. de esta forma vemos mensualmente la dedicación y tenemos visibilidad de si es necesario rectificar, de forma que no nos olvidemos de la innovación y el mantenimiento técnico, ni tampoco de poner foco en nuevas funcionalidades. En el caso de detectar un porcentaje de incidencias importante a lo largo del tiempo, tendremos que pensar en como reducirlas.
La calidad técnica
Para ello medimos la cobertura de código de la aplicación. También se pueden seguir los bugs, por ejemplo. La calidad técnica también es una métrica mensual y comparamos su evolución con el valor del mes anterior.
La calidad funcional
En este punto medimos las incidencias creadas vs las incidencias resueltas. También mensualmente. No diferenciamos entre incidencia detectadas por el cliente y detectadas por el equipo, pero es una idea que ha surgido hace poco y vamos a empezar a trabajar en ello.
La satisfacción del cliente
La forma más fácil de medir la satisfacción de alguien es a través de una encuesta. La encuesta se pasa cada tres meses y comparamos el resultado con la encuesta anterior.
La felicidad del equipo
También lo medimos con una encuesta, y también cada tres meses.
El análisis de las métricas
Disminuye el throughput y luego se mantiene
Al principio cuando todavía no controlábamos mucho las historias de usuario las hacíamos demasiado pequeñas, incluso para cosas que realmente no entregaban valor como ente unitario. Así que rectificamos y parece que estamos encontrando la medida adecuada.
Aumenta el lead-time y el cycle-time
El momento del gráfico en el que también aumenta el cycle-time, hubo un problema técnico que no nos dejaba desarrollar, y eso hizo que se vieran afectadas ambas mediciones.
Cuando se detecta que sólo aumenta el lead-time, hemos deducido que puede deberse a varias situaciones:
- porque cualquier idea que se nos ocurre la ponemos en el backlog como posible historia de usuario
- porque refinamos las épicas mucho antes de lo que necesitamos
Ambos casos estarían justificados viendo en el gráfico de dedicación, que efectivamente hay más historias en el backlog.
Aumenta la calidad técnica
Esta es fácil :-), el equipo revisa constantemente la calidad antes de subir algo a producción.
Disminuye la calidad funcional
Coincidió este aumento de incidencias con la presentación del producto al cliente y su puesta en marcha. Tras esta visión, ya se han analizado las causas y estamos tomando medidas para reducirlas en la próxima presentación. Acciones como revisar más los criterios de aceptación, realizar historias de usuario más claras cuando se trata de temas con muchas casuística, diferencias las incidencias técnicas de las que realmente son consultas del usuario por desconocimiento…
Aumenta la satisfacción del cliente y la felicidad del equipo
En este caso sólo puedo decir una cosa: que me siento orgullosa del equipo por estar asumiendo el mindset agile tan bien. Su implicación día a día se ha visto reflejada directamente en la satisfacción del cliente.
Casos hipotéticos
Si aumenta el throughput y disminuye la felicidad del equipo…
Habría que investigar qué punto de la felicidad del equipo es el dañado. Quizá pueda ser que el equipo esté haciendo horas extra, que hayan tenido alguna época de conflictos entre ellos por presión a entregas…
Ahora mismo no se me ocurre ninguno más…¿y a vosotros? Si se os ocurre algo no dudéis en añadir un comentario.
Otros usos
Analizando los datos, también se pueden usar estas métricas para ponernos objetivos de equipo, por ejemplo:
- Aumentar la satisfacción del cliente en X puntos más para la siguiente encuesta
- Hacer crecer el coverage de la aplicación hasta X% en un tiempo Y
- Aumentar la felicidad del equipo en un punto concreto para la siguiente encuesta
- Focalizarnos en resolver incidencias durante X sprints.
- etc, etc, etc, aquí la imaginación juega un gran papel.
Otro uso más; si por ejemplo estos indicadores se sacan para distintos equipos y vemos que todos coinciden en algo, quizá tenemos un problema a nivel organización. Por ejemplo:
- Todos tienen una puntuación muy baja en felicidad de equipo, a nivel técnico…puede ser que haya problemas con las subidas a producción desde un departamento común a todos.
- Todos tienen un coverage muy bajo…es posible que por mentalidad no se esté dando importancia a la calidad técnica.
- …
Una vez más, espero que esta información os sirva de ayuda, y como he dicho antes, comentad todo lo que se os ocurra, sin filtros ;-P
Descubre más desde CAMBIO Y EFECTIVIDAD
Suscríbete y recibe las últimas entradas en tu correo electrónico.