Enfoque de las Métricas

Por qué existe esta página

Una herramienta moldea las preguntas que haces. Abre un informe típico con story points, y la conversación gira en torno a estimaciones y "velocidad del equipo". Abre JMP, y la conversación gira en torno a cuánto tiempo pasan realmente las tareas en el proceso, y dónde esperan.

No es casualidad. JMP está construido sobre un enfoque de flujo — una manera de ver el trabajo como un flujo de tareas que atraviesan un sistema. Esta página explica los principios que están integrados en el producto, para que lo uses con intención y no solo "mirando gráficos".

Está pensada para cualquiera que intente mejorar cómo se hace el trabajo — el propio o el de su equipo: team leads, agile coaches, project managers, CTOs.

Medimos la realidad, no estimaciones

JMP no tiene story points, ni velocity, ni burndown charts — y eso es deliberado.

Una estimación es una opinión emitida antes de empezar el trabajo. El lead time es un hecho medido después. Los equipos pasan horas en planning poker y luego comparan su avance contra sus propias suposiciones. JMP propone otro camino: mirar cuánto tiempo tardan realmente las tareas en atravesar el proceso. Estos datos ya existen en Jira — no hay que pedírselos a nadie, y no se pueden "sobreestimar" ni "subestimar".

Cómo se ve esto en el producto: todos los informes están construidos sobre el historial real de movimiento de las tareas — Lead Time, Throughput, WIP, CFD. No hay ni un solo campo para introducir estimaciones a mano.

Distribuciones, no promedios

"La tarea tarda 8 días en promedio" es una frase que oculta más de lo que revela. Detrás de ese promedio puede haber la mitad de las tareas resueltas en 3 días y una cola de tareas que llegan a 40.

JMP muestra distribuciones y percentiles en todas partes: P50 (mediana), P85, P95. En lugar de un "estará listo en 8 días" falsamente preciso, obtienes un honesto "el 85% de estas tareas se completa en 12 días o menos". Es una promesa probabilística, y es la única honesta: el futuro no es determinista, y hay que hablar de él en el lenguaje de las probabilidades.

Cómo se ve esto en el producto: el histograma de Lead Time con líneas P50/P85/P95, el Control Chart con bandas de percentiles, y el informe Percentile Trend, que apunta justamente a cómo se mueven los percentiles a lo largo del tiempo.

Los datos deben ser honestos

El historial de transiciones de Jira a veces está incompleto. La mayoría de las herramientas dibujan con toda confianza una cifra exacta encima de esos huecos. JMP hace lo contrario: si parte del timeline de una tarea tuvo que reconstruirse, verás una marca de "reconstruido" y una advertencia de "lead time aproximado".

El principio es simple: una cifra honestamente aproximada es mejor que una que parece exacta pero no es confiable. Las decisiones tomadas sobre una precisión bonita pero falsa salen más caras que trabajar de forma consciente con la incertidumbre.

Cómo se ve esto en el producto: marcas de reconstrucción y advertencias en el diálogo Task Flow, y un conteo separado de tareas excluidas en los informes en lugar de descartarlas en silencio.

Hechos, no acusaciones

JMP evita deliberadamente poner etiquetas. Una tarea que retrocede en el tablero se muestra como un "retorno" — no como "retrabajo": puede ser un defecto, o puede ser una iteración normal de revisión. Una columna donde las tareas se quedan mucho tiempo se muestra como la "etapa más larga" — no como un "cuello de botella": un diagnóstico requiere contexto que la herramienta no tiene.

La herramienta muestra lo que pasó. Qué significa y qué hacer al respecto lo decide el equipo, que conoce su propio contexto. Las métricas son material para una conversación, no un veredicto.

Y lo más importante: las métricas no son un látigo. Los datos de flujo existen para mejorar el sistema de trabajo, no para presionar a las personas. En el momento en que una métrica se convierte en una herramienta de castigo, deja de reflejar la realidad — la gente empieza a optimizar el número en lugar del trabajo. Por eso JMP mide el proceso — columnas, colas, tiempo de espera — y no el rendimiento individual.

Métricas para decisiones, no para informes

Un informe que nadie discute y que no cambia nada es tiempo perdido, sin importar cuántos gráficos tenga.

JMP está diseñado para una práctica regular: abrirlo en una revisión de proceso, notar un cambio, discutir la causa, acordar un experimento, revisar el efecto un mes después. Cada informe responde a una pregunta concreta: "¿cuánto tarda?" (Lead Time), "¿cuánto logramos completar?" (Throughput), "¿dónde se acumula el trabajo?" (CFD, WIP), "¿qué está atascado?" (Aging). Si un informe no lleva a una pregunta o a una decisión, no hace falta — por bonito que se vea.

Cómo se ve esto en el producto: el diálogo Task Flow con un botón para copiar el resumen para retros, los dashboards como panel permanente para reuniones recurrentes, y las tendencias respecto al período anterior en cada métrica.

Se puede empezar hoy

La mejora de procesos suele posponerse hasta "primero pongamos orden en Jira" o "implementemos el proceso correcto". El enfoque de flujo te permite no esperar: tu tablero ya está generando datos de flujo — cada vez que una tarea se mueve entre columnas, queda registrado.

JMP toma esos datos tal cual son: sin infraestructura dedicada, sin un administrador de Jira, sin cambiar el proceso de tu equipo. Instalas la extensión y, un minuto después, ya estás viendo el panorama real. Puede que no te guste lo que ves — pero eso ya es el comienzo de una mejora, no su aplazamiento.

Por dónde empezar

1. Inicio Rápido — abre tu tablero y mira el Lead Time y el Throughput.
2. Encuentra algo que te sorprenda — una cola larga en la distribución, un WIP que crece, una tarea atípica.
3. Llévalo a tu próximo retro — no como una acusación, sino como una pregunta.

Lo demás es cuestión de hacerlo con regularidad.