En el artículo Métricas – Cómo medir la agilidad de su equipo hablamos de por qué y cómo medir un equipo ágil utilizando las 4 Áreas de la Agilidad. Allí usamos una de nuestras frases favoritas y que es un aviso: “Las métricas moldean los comportamientos”. Este aviso es importante, pues hay que tener mucho cuidado con métricas que pueden ser insignificantes o incluso obstaculizar nuestro trabajo. En el presente artículo nos referiremos a las métricas tóxicas que contaminan el ambiente de trabajo y reducen la agilidad y la motivación del equipo.
Medir al individuo
Algo que es habitual encontrar en las empresas es la medición de los individuos del equipo. Ya hemos visto tablas con cosas del tipo: Total de tareas entregadas por Fulano, cantidad de errores corregidos por Mengano. Hemos visto hasta la foto del "Empleado del mes", la persona que entregó más funcionalidades en Sprint. Al principio parece una buena métrica, pues estimulará a las personas a entregar más y más. Como si fueran dependientes de una tienda tratando de alcanzar metas.
El problema es que estamos hablando de ambientes complejos y de trabajadores del conocimiento. Saber compartir información y ayuda mutua es fundamental para que el equipo desarrolle y perfeccione el producto. La medición individual estimula la competición y reduce la cooperación. Si me evalúan por entregar tareas, funcionalidades o por corregir defectos, no tengo tiempo para detenerme y ayudar a otro miembro del equipo. Tampoco dispongo de tiempo para detenerme y evaluar si estamos alcanzando los objetivos de negocio o si el producto realmente satisface las necesidades de mis usuarios y clientes.
Comparar Equipos
Otro error común es intentar utilizar métricas para comparar equipos que actúan en diferentes productos y contextos. Por ejemplo: imagine dos equipos, uno de los cuales es responsable del portal de ventas y el otro de la asistencia al cliente, y que ambos utilicen el Net Promoter Score (NPS) para evaluar la satisfacción del usuario. Comparar el NPS de estos dos equipos no es una buena idea, pues cuando el cliente compra un producto está de buen humor y satisfecho con la adquisición. Cuando alguien entra en contacto con el servicio al cliente es porque algo no funciona bien. Puede que el problema radique en el portal de ventas, como falta de información, pedidos equivocados, etc. Sin embargo, el reflejo acaba alcanzando negativamente al NPS de atención al cliente.
Comparación de equipos con User Story Points
Emplear User Story Points (Puntos por Historia de Usuario) o cualquier otra métrica de esfuerzo para comparar el rendimiento entre equipos es una abominación. A menos que usted quiera engañarse, no lo haga en ningún caso. El propósito de esta estimación es hacer que el equipo descubra cuál es la velocidad del equipo y que eso le ayude a discutir y negociar qué historias entrarán y cuáles quedarán fuera del próximo Sprint.
Comparar las especialidades del equipo
Asistí asimismo a otra comparación con efectos nefastos. Fue un equipo en el que los desarrolladores de aplicaciones para Apple competían con los desarrolladores de aplicaciones para Google. Las notas en la App Store y en Google Play eran la medida primaria de esa lucha. Resultado: los desarrolladores no se ayudaban por nada. En realidad, cuando se estaban juntos, uno le daba la espalda al otro. Parecía que iban a batirse en duelo.
¿Quiere decir que si la nota de una aplicación en la App Store es muy alta y la nota en Google Play muy baja no debo tomarlo en consideración?
De ninguna de las maneras, las notas son importantes para medir la satisfacción de sus clientes. En lugar de utilizarlas para promover la competencia, úselas para promover la cooperación. Por ejemplo: ¿qué sabemos y qué hacemos para que una nota sea alta en una tienda de aplicaciones y baja en la otra? ¿Cómo pueden encontrar los desarrolladores una forma de mejorar la experiencia del usuario en la tienda con la nota más baja? ¿Son los mismos tipos de cliente? Y este es el camino.
Métricas de la vanidad
Hace algún tiempo recibí un correo electrónico de una empresa donde me decía cuántas de sus aplicaciones eran exitosas. Habían logrado millones de descargas. Por curiosidad decidí ver los números de esas aplicaciones en Google Play y me encontré con una escena muy negativa. La nota media de las aplicaciones era 2,7 y la cantidad de personas que las habían instalado apenas llegaba a miles. La gente bajaba las aplicaciones, veía que no era lo que esperaban de ellas, les daban una mala nota y las desinstalaban de sus smartphones.
Como afirma Eric Ries en el libro A Startup Enxuta, la cantidad de descargas normalmente es una métrica de vanidad. Solo nos indicaba que la empresa estaba muy bien, pero, en realidad, la tasa de rechazo (que no es una métrica de vanidad) era superior al 90%.
Otras métricas de la vanidad pueden ser: Número de visitantes en el sitio, número de usuarios registrados, cantidad de login en la aplicación, cantidad de accesos, etc.
Utilice métricas que permitan identificar escenarios y adoptar acciones de negocio. En este artículo hablamos de algunas de ellas.
Medir cosas de más
Ya he pasado por empresas con una cantidad enorme de números indicadores. El tiempo de medición, evaluación, soporte y análisis era muy grande y los resultados pequeños. El coste de mantenimiento de esas métricas pesaba más que los beneficios que reportaban.
Sus métricas deben centrarse siempre en acciones. Medir solo por medir, no tiene sentido. Es un aumento de coste innecesario.
Dejar de medir una de las áreas de la agilidad
En la entrada Métricas – Cómo medir la agilidad de su equipo hablamos sobre la importancia de medir cada área de la agilidad. Medir una e ignorar otra es una señal de que el equipo no tardará en romperse. Algunos ejemplos ya vistos:
-
- Eficacia sin Calidad: el equipo entregaba mucho y facilitaba un rendimiento significativo a la empresa. Pero la calidad era muy baja, muchos bugs por entrega y muy pocas pruebas automatizadas. Con el tiempo esa mala calidad se cobra su precio y el equipo se vuelve extremadamente ineficaz.
- Eficiencia sin Eficacia: el Equipo entregaba bastante con Sprints semanales. El problema era que la cantidad de usuarios y el rendimiento eran ridículamente bajos.
- Eficacia y Eficiencia sin buen Ambiente: un equipo que entregaba mucho y facilitaba mucha recuperación a la empresa, pero los miembros se llevaban a matar. Las reuniones diarias y retrospectivas ya habían sido suprimidas y, con el tiempo, las personas empezaron a salirse del equipo. El resultado fue que la eficacia y la eficiencia cayeron en picado.
- Calidad sin eficiencia o eficacia: una empresa tenía como métrica la cantidad de errores en producción. Cuanto menor, mejor. El problema era que el “campeón” también era el campeón de la NO entrega.
Conclusión
Las métricas siempre van a cambiar el comportamiento de las personas, escójalas muy bien para no intoxicar su producto o a su empresa.
