El triaje de bugs es el trabajo que va de «llegó un reporte» a «alguien lo está corrigiendo». La mayoría de los equipos no son lentos en la parte de decidir. Son lentos en todo lo que la rodea.
Observa una pasada normal. Abres un reporte. Lo lees. Vuelves a la lista. Buscas por dónde ibas. Abres el siguiente. Vuelves otra vez. Cada decisión lleva segundos; la navegación se come el resto de los diez minutos. Peor aún, cada ida y vuelta es un pequeño cambio de contexto, y con suficientes el triaje se convierte en esa tarea pesada que se aplaza hasta que el backlog es ilegible.
Este es un flujo de trabajo que elimina la navegación en lugar de pedirle a nadie que piense más rápido.
Qué es de verdad el triaje de bugs
El triaje hace tres preguntas a cada reporte que llega:
¿Es nuevo? O es el reporte número cuarenta de algo para lo que ya tienes una tarea.
¿Es real? Reproducible, o respaldado por evidencia lo bastante concluyente como para actuar.
¿Cuánto urge? Frente a todo lo demás que está abierto, no de forma aislada.
Todo lo demás (asignar, etiquetar, escribir los pasos para reproducirlo, avisar a quien se encarga de esa parte del código) se deriva de esas tres respuestas. Una sesión de triaje que produce respuestas funciona. Una que produce una lista más larga de cosas para mirar después, no.
La ida y vuelta es el coste real
Un reporte solo vale la pena leerlo en contexto: la descripción, los errores de consola que lo rodean, la solicitud que falló, el navegador y el viewport, lo que el usuario pulsó en los segundos antes de que se rompiera. Ese contexto vive en una vista de detalle.
Así que el ciclo se convierte en lista, detalle, lista, detalle. Cada salto recarga una página, pierde tu posición de scroll y olvida en qué elemento estabas. Diez reportes son veinte navegaciones, y para el sexto ya has dejado de leer con atención.
La solución no es una página más rápida. Es no salir de la lista.
Trabaja columna a columna
Antes de abrir nada, reduce el tablero a una sola cola. En BugDump eso significa filtrar por una prioridad, un navegador o una búsqueda de texto, y luego trabajar una sola columna de arriba abajo.
Al hacerlo pasan dos cosas. La cola tiene un final definido, y eso es lo que hace que una sesión se pueda terminar en lugar de no acabar nunca. Y cada tarea es comparable con la anterior, así que la prioridad relativa deja de ser adivinanza: ya no comparas a la vez un bug crítico del checkout con una errata en un texto.
Además, el ojo ya lee un tablero por columnas. Trabajar saltando entre columnas obliga a reorientarse todo el tiempo.
Avanza, no navegues
Abre la primera tarjeta. En lugar de una página nueva, la tarea se abre en un panel junto al tablero: la descripción, cada reporte adjunto con sus logs de consola y de red, los comentarios y los controles de estado, asignado y prioridad.
Desde ahí, todo con el teclado. J pasa a la siguiente tarea de esa columna. K vuelve atrás. Lee, fija la prioridad, asigna, mueve la tarea, pulsa J. El tablero nunca se recarga ni pierde su sitio, así que el ciclo se reduce a una tecla entre decisión y decisión.
Dos detalles importan más de lo que parece:
El avance se queda dentro de la columna en la que empezaste. Se detiene en los extremos en lugar de dar la vuelta o pasar a la columna siguiente, así que terminar una columna es un acontecimiento real y no algo de lo que te das cuenta tres tareas después.
El avance respeta los filtros. Filtra por bugs críticos y «Siguiente tarea» solo recorre bugs críticos. La cola que definiste es la cola que recorres.
Los atajos tampoco estorban mientras escribes: una j en un comentario es una j en un comentario.
Agrupa las decisiones que ya son obvias
Parte del triaje no necesita leer nada. Un despliegue malo produce treinta reportes del mismo fallo. Una ola de spam produce veinte reportes de nada.
No los recorras uno a uno. Selecciona las tarjetas directamente en el tablero (Cmd o Ctrl más clic para elegirlas una a una, Shift más clic para un rango) y mueve o elimina toda la selección de una vez.
La regla práctica: si ya sabes la respuesta antes de abrir la tarea, va en un lote. Avanzar tarea a tarea es para los reportes que piden criterio, y el sentido de agrupar es que esos reciban tu atención y no lo que te sobra de ella.
Agrupar primero los duplicados es el hábito que más rinde en el triaje. Suele convertir cuarenta elementos de la bandeja en seis tareas reales, y todo lo que viene después cuesta menos. La guía del flujo de triaje cubre la rutina diaria completa.
Pasa el trabajo con un enlace, no con una descripción
El triaje termina con trabajo que pasa a otra persona, y ahí es donde suele escaparse el tiempo que ahorraste. Volver a escribir un bug en Slack (medio resumen, unos pasos aproximados, una captura de pantalla) es más lento que el propio triaje y pierde más información que el reporte que acabas de mirar.
Copia el enlace de la tarea. Un enlace lleva la descripción, cada reporte adjunto, la salida de consola, la actividad de red, el entorno y la conversación hasta ese momento. Quien lo recibe ve lo que tú viste, no tu recuerdo de ello.
Si tu equipo depura con un asistente de IA, el mismo ID público es todo lo que hay que pasar: dirige a Claude Code a la tarea a través de MCP y leerá los reportes, los logs y las trazas directamente en lugar de que se los cuenten.
Con qué frecuencia hacer una pasada
De diez a quince minutos, una vez al día. Dos o tres veces al día en una semana de lanzamiento.
Hacerla a diario importa más que hacerla larga. La deuda de triaje se acumula de una forma concreta: cuanto más antiguo es un reporte, más cuesta reproducirlo, más probable es que quien lo reportó ya se haya ido y más probable es que duplique algo que llegó después. Un backlog que te saltas una semana no es el mismo backlog una semana después: es uno peor.
Los errores que conviene nombrar
Hacer el triaje en el orden de llegada. El orden de llegada no es el orden de importancia. Filtra primero y luego trabaja una cola.
Leerlo todo antes de decidir nada. Una pasada en la que nada cambia de columna no ha ocurrido.
Una columna «Falta información». Se convierte en el sitio al que van las tareas para que las olviden. O le preguntas ahora a quien lo reportó, o la cierras.
Todo es crítico. Un backlog en el que todas las tareas son urgentes lleva exactamente la misma información que uno en el que no lo es ninguna.
No cerrar nunca nada. El fallo de triaje más común no es priorizar mal: es un recuento de abiertas que solo crece hasta que el tablero deja de describir la realidad.
Pruébalo en tu tablero
Si ya usas BugDump, el flujo está disponible: filtra el tablero, pulsa la primera tarjeta y usa J y K para recorrer la columna. En Trabajar con tareas y el tablero tienes el resto de los controles del panel.
Te puede interesar
Cómo escribir un buen reporte de bug (con checklist) — por qué a la mayoría de los reportes les faltan los detalles que importan y qué lista usar para que no falten.
De 40 reportes a 6 bugs: cómo debería funcionar el triaje — cómo separar los reportes de las tareas convierte los duplicados en tu mejor material para depurar.
Métricas de bugs que de verdad importan — cuatro números que dicen si tu equipo va al día con los bugs y una revisión semanal de cinco minutos basada en ellos.