Abre la página de informes de casi cualquier bug tracker y encontrarás un montón de números. Total de incidencias registradas. Un gráfico circular de severidades. Un tiempo medio de resolución. Una barra por asignado.
Casi ninguno responde a la pregunta que un equipo se hace de verdad el lunes por la mañana: ¿vamos al día o nos estamos quedando atrás?
Esa pregunta tiene una respuesta corta, y hacen falta cuatro números para darla. Este artículo repasa esos cuatro, las métricas populares que engañan sin que se note y una revisión semanal de cinco minutos que puedes hacer con ellas. También es el razonamiento detrás del panel de pulso que acabo de poner en la parte superior del tablero de BugDump.
Las métricas que parecen útiles y no lo son
Total de bugs registrados. Solo sube. Un número que solo puede subir te dice cuántos años tiene el proyecto, no lo sano que está.
Número de reportes de bugs. Los reportes miden el tráfico tanto como la calidad. Un solo botón de pago roto puede generar cuarenta reportes en una tarde, y eso es un bug, no cuarenta. Si cuentas reportes, un lanzamiento popular parece un desastre; si cuentas bugs, parece un martes cualquiera.
Bugs por severidad, en un gráfico circular. Describe el backlog sin sugerir nada que hacer con él. Nadie ha cerrado nunca un ticket por mirar un gráfico circular.
Tiempo medio de corrección. Este hace daño de verdad, porque parece riguroso. Volveré a él más adelante.
Lo que tienen en común es que son stocks, no flujos. Describen una pila de bugs. Las preguntas que vale la pena hacerse son hacia dónde se mueve la pila y qué se ha quedado atascado en el fondo.
1. El backlog abierto, y hacia dónde se mueve
Empieza por el número más simple que hay: cuántos bugs están abiertos ahora mismo. En BugDump, son todas las tareas que no han llegado a una columna cerrada.
Por sí solo, el recuento dice poco. Veintinueve bugs abiertos están bien para un equipo y son alarmantes para otro. Lo que importa es la dirección, y la dirección es simple aritmética sobre un intervalo:
cambio neto = bugs abiertos − bugs resueltos, en el mismo periodo
Negativo significa que el backlog se reduce. Positivo, que crece. Cero con actividad significa que vas exactamente al ritmo; cero sin actividad significa que nadie tocó nada, que es otra situación y merece otra etiqueta.
Por eso el panel de pulso no muestra solo «29 abiertas». Dice pendientes bajan 4 este periodo, pendientes suben 6 este periodo, pendientes se mantienen o periodo tranquilo, nada se movió. El número da la escala; la frase da la dirección.
Un backlog que crece varios periodos seguidos rara vez es un problema de productividad de los desarrolladores. Casi siempre es un problema de triaje: los duplicados no se fusionan, nadie decide qué no se va a corregir y cada reporte se queda a vivir para siempre.
2. Resueltos frente a abiertos, comparados con el periodo anterior
El segundo número es cuántos bugs resolviste en el intervalo, junto al intervalo anterior de la misma duración.
Comparar con el periodo inmediatamente anterior, y no con un promedio histórico, importa por dos razones. Anula la estacionalidad: una quincena tranquila de vacaciones se compara con la quincena ajetreada de antes, no con tu mejor mes. Y hace legibles las semanas de lanzamiento: una versión que corrigió un grupo de bugs aparece como un salto, no como ruido.
Mejor todavía: mira los abiertos y los resueltos en el mismo gráfico. BugDump dibuja los bugs abiertos por encima del eje, los resueltos por debajo y el backlog como una línea que cruza ambos. Cuando las dos áreas son simétricas, vas al día. Cuando la de arriba gana una y otra vez, la línea sube, y ves exactamente qué días empezó.
3. La mediana del tiempo de corrección, no la media
El tiempo de corrección es la métrica que más equipos quieren y la que más herramientas calculan mal.
La definición es sencilla: para cada bug resuelto en el intervalo, mide el tiempo desde que se abrió hasta que se resolvió. La cuestión es cómo resumes esas duraciones, y la respuesta casi nunca debería ser la media.
La razón es esta. Supón que tu equipo corrige diez bugs esta quincena. Nueve se corrigen en menos de un día. El décimo es un bug de hace cuatro meses que alguien por fin cerró en una sesión de limpieza, 120 días después de registrarse.
Media: (9 × 1 + 120) ÷ 10 = 12,9 días
Mediana: 1 día
La media dice que tu equipo tarda dos semanas en corregir un bug. La mediana dice que tu equipo corrige los bugs al día siguiente, y acierta. Peor aún, la media castiga la limpieza: la semana en que por fin cierras tickets antiquísimos es la semana en que tu promedio se ve terrible, y eso enseña a todos a no tocar los tickets antiguos.
La mediana no se deja arrastrar por ese único valor atípico, así que refleja lo que vive un bug típico. Es lo que el panel de pulso muestra como Mediana de resolución, en minutos, horas o días según la escala.
Tiene un punto débil, y hay que reconocerlo: solo cuenta los bugs que de verdad se corrigieron. Un bug que nunca se resuelve nunca entra en el cálculo, así que un equipo podría tener una mediana preciosa mientras abandona en silencio sus problemas más difíciles. Justo por eso necesitas el cuarto número.
4. El bug abierto más antiguo
La mediana describe el centro. El bug abierto más antiguo describe la cola, y en la cola es donde se pierde la confianza.
Pon su antigüedad justo al lado de la mediana: 5 meses, con el ID y el título debajo. Haz que se pueda pulsar, para que mirarlo sea un solo paso y no una búsqueda.
Un bug abierto desde hace cinco meses casi nunca es un bug que nadie supo corregir. Es una decisión que nadie tomó. Mirarlo obliga a uno de tres desenlaces honestos:
Corregirlo, porque resulta que era pequeño.
Planificarlo, porque importa y se quedó sin dueño.
Cerrarlo a propósito, como «no se corregirá» u obsoleto, y explicarle el motivo a quien lo reportó.
Cualquiera de los tres es mejor que un cuarto mes de silencio. Y cuando el bug más antiguo queda resuelto, el siguiente más antiguo ocupa su lugar, así que el número sigue recortando la cola.
Extra: de dónde vienen los reportes
Los cuatro números de arriba te dicen si vas al día. No te dicen por qué una semana fue mal.
Para eso, desglosa los reportes del mismo intervalo por navegador, sistema operativo, tipo de dispositivo y página. Una regresión rara vez se reparte por igual. Cuando un tercio de los reportes de esta semana viene de Safari en iOS, o la página con más reportes es un paso del proceso de pago que salió el jueves, ya tienes la causa antes de abrir un solo reporte.
En BugDump, al desplegar el panel de pulso aparece exactamente este desglose junto al gráfico, con las páginas ordenadas por número de reportes. Al pulsar un chip de navegador, sistema operativo o dispositivo, el tablero se filtra por él, así que pasar de «algo pasa con Safari» a los bugs de Safari es un clic.
Aquí, además, contar reportes en lugar de bugs es lo correcto. Cuarenta reportes de un mismo bug son cuarenta datos sobre a quién le pasó.
Cómo elegir el intervalo
El intervalo cambia lo que los números pueden decirte, así que elígelo según la pregunta que te haces:
7 días para semanas de lanzamiento, cuando quieres ver el efecto de un despliegue.
14 días como valor por defecto razonable: lo bastante largo para suavizar el ruido diario, lo bastante corto para reaccionar.
30 o 90 días para preguntas de tendencia y retrospectivas.
Cuidado con las medianas en intervalos cortos y proyectos pequeños. La mediana de tres correcciones es un dato sobre tres bugs, no sobre tu equipo.
Define «resuelto» con honestidad
Cada una de estas métricas depende de qué cuenta como resuelto, y es ahí donde los dashboards mienten más a menudo.
Si Listo para QA o Fusionado cuentan como resuelto, tu mediana de resolución mide lo rápido que se escribe el código, no lo rápido que los usuarios dejan de toparse con el bug. Si No se corregirá no cuenta, tu backlog arrastra decisiones que ya se tomaron.
En BugDump, un bug está resuelto cuando entra en una columna cerrada, y sacarlo de ella lo reabre. Uses la herramienta que uses, comprueba que sus estados cerrados significan lo que tus usuarios entenderían por «corregido».
La revisión semanal de cinco minutos
Con esos cuatro números en una sola pantalla, la revisión semanal de bugs deja de ser una reunión y se convierte en una lista de comprobación:
¿El backlog baja o se mantiene? Si creció, mira lo que entró, no quién va lento.
¿Se resolvieron al menos tantos bugs como entraron, comparado con el periodo anterior?
¿Se movió la mediana de resolución? Si dio un salto, busca los uno o dos bugs que tiraron de ella.
Abre el bug más antiguo. Corrígelo, planifícalo o ciérralo con un motivo. No lo dejes para la semana que viene.
Revisa de dónde vinieron los reportes. Cualquier navegador, dispositivo o página con mucho más de lo que le toca es una regresión mientras no se demuestre lo contrario.
Esa es toda la revisión. Cabe en un standup, no necesita una hoja de cálculo y responde a la única pregunta que el dashboard debía responder desde el principio.
En BugDump, el panel de pulso muestra estos cuatro números en la parte superior de cada tablero y se actualiza cada minuto.
Te puede interesar
De 40 reportes a 6 bugs: cómo debería funcionar el triaje — por qué separar los reportes de las tareas evita que la bandeja de bugs se convierta en un cementerio.
Niveles de prioridad de bugs: por qué cuatro opciones fijas nunca encajan — para qué sirve una escala de prioridades, cuántos niveles necesitas y por qué los nombres tienen que ser tuyos.
Seguimiento de bugs ligero para equipos pequeños: cuando Jira es demasiado — qué necesita un bug tracker ligero y cómo elegir uno que los usuarios de verdad alimenten.