Radar de Seis Dimensiones de Rendimiento

¿Te ha pasado alguna vez que tu equipo celebra porque la velocidad subió un 20%, pero resulta que los bugs en producción también subieron un 30%? A mí sí. Y es que medir equipos con una sola métrica es peligroso — creas incentivos perversos sin darte cuenta. El radar de seis dimensiones nace de esa frustración. Se inspira en frameworks como el Balanced Scorecard y las métricas DORA, pero lo simplifica todo a seis preguntas fundamentales que cualquier equipo puede responder en 10 minutos. La gracia está en que al visualizarlo como radar, las zonas hundidas saltan a la vista. No necesitas ser analista de datos para ver que si tu hexágono parece una estrella deforme, algo va mal. Y la posibilidad de guardar y superponer evaluaciones históricas es donde realmente brilla — porque un snapshot aislado puede ser engañoso, pero una tendencia de seis meses te cuenta una historia que no puedes ignorar.

Vamos una por una, que es importante entender qué estás midiendo. Calidad: ¿hacéis las cosas bien a la primera? Pocos bugs, código limpio, tests que cubren lo que tienen que cubrir. Capacidad de Respuesta: ¿cuánto tardáis en reaccionar cuando cambian las prioridades o llega algo urgente? Porque en entornos volátiles — y seamos honestos, ¿cuál no lo es? — responder rápido vale oro. Previsibilidad: ¿los stakeholders pueden fiarse de vuestras fechas? Está es la que más duele, porque muchos equipos no la quieren medir. Pero claro, si no la mides no la mejoras. Productividad: cuánto entregáis en relación a los recursos. Importante, sí — pero solo en contexto con las demás dimensiones. Un equipo que entrega mucho pero todo roto no es productivo, es destructivo. Flujo: ¿hay atascos, interrupciones, cambios de contexto constantes? Y finalmente Valor: la más difícil y la más importante. ¿Lo que construís realmente le importa a alguien? He visto equipos con un 9 en todo excepto en Valor. O sea, hacían cosas perfectas que nadie necesitaba.

Esto es lo que la mayoría de equipos hace mal: se obsesionan con una métrica y el resto se va al garete. Es la Ley de Goodhart en acción — cuando una medida se convierte en objetivo, deja de ser una buena medida. He visto equipos inflando story points descaradamente solo porque les evaluaban por velocidad. ¿El resultado? Los números subían, pero el software entregado era el mismo o peor. El radar mitiga esto porque no puedes inflar seis dimensiones a la vez sin que alguien se dé cuenta. Otra trampa gordísima: comparar puntuaciones entré equipos. Mira, el equipo A se pone un 5 en Calidad y el equipo B se pone un 7 — pero eso no significa que B sea mejor. Cada equipo tiene su propio contexto, sus propios estándares, su propia honestidad. Las únicas comparaciones válidas son las longitudinales: el mismo equipo consigo mismo a lo largo del tiempo. Usa el radar para dialogar, para reflexionar en la retro. Nunca — y esto es importante — nunca como herramienta de castigo o ranking. El momento que los equipos sientan que les van a penalizar por una puntuación baja, dejarán de ser honestos.

El mejor momento para rellenar el radar es al final del sprint, durante la retrospectiva, cuando todo está fresco. Pero hay un truco que marca la diferencia: cada persona puntúa las seis dimensiones de forma independiente antes de compartir. ¿Por qué? Porque si alguien dice 'Calidad: 8' primero, el resto se ancla a ese número y ajusta poco. Es sesgo de anclaje puro. Cuando todo el mundo ha puesto sus números, se revelan. Y ahí es donde empieza lo bueno — si tú has puesto Flujo en 3 y tu compañera en 7, hay algo que uno de los dos no está viendo. Esa conversación vale más que el número en sí. Después, escoge como mucho dos dimensiones para mejorar. No más. Si intentas mejorar las seis a la vez, no mejorarás ninguna. Guarda la evaluación con un nombre descriptivo — 'Sprint 14' o 'Enero 2025' — y a las pocas semanas tendrás una línea temporal que te dirá si las acciones que tomasteis están funcionando o eran humo.