Coreografía: el backlog que se hace triage solo
La IA escanea un volumen de tickets que el equipo nunca cubriría a mano y enciende a los sospechosos: duplicado, severidad fuera de la curva, equipo equivocado en la cola. Tú sigues siendo quien confirma lo ambiguo y decide la acción.
Lunes por la mañana, y la cola de Jira amaneció con 340 tickets nuevos, entre bug, pedido de feature y reclamo de cliente reenviado por soporte. En medio de ellos, dos tickets abiertos por canales distintos describen el mismo error de checkout con palabras diferentes, uno de ellos marcado como "baja" porque quien lo abrió no sabía el tamaño del daño. Nadie va a leer las 340 descripciones línea por línea antes del daily de las 9h. La pregunta de esta lección es: ¿quién escanea ese volumen por ti, y quién confirma lo que aparezca antes de que se convierta en prioridad de la semana?
El estudio jurídico recibe notificaciones e intimaciones de fuentes distintas cada semana, cada una con su propio plazo. La IA agrupa las que parecen del mismo proceso, sugiere severidad por el tipo de pieza y rutea al abogado responsable. Marca como plazo "cómodo" una intimación cuyo texto es denso y formal, sin notar que el plazo procesal real, contado desde la fecha de publicación, vence en dos días, no en dos semanas como el texto sugería a primera lectura. Confiar en la severidad sugerida sin verificar la fecha de publicación casi cuesta un plazo perdido.
Al final de cada ciclo de evaluación, RRHH recibe decenas de solicitudes: pedido de ascenso, reclamo de clima, duda sobre beneficio. La IA agrupa los pedidos parecidos, sugiere prioridad para cada uno y rutea al analista correcto. Marca como "prioridad normal" un reclamo de clima que menciona, de pasada, un comportamiento de un gerente específico, porque el texto es educado y no usa palabras como "acoso" o "abuso". Solo que ese tipo de mención discreta es exactamente lo que suele anteceder a una denuncia formal semanas después. Tratarlo como prioridad normal y dejarlo en la cola común casi deja pasar una señal que debía haber ido directo al equipo de compliance de personas.
El board de feedback de producto recibe cientos de pedidos por mes, provenientes de soporte, de ventas y de investigación. La IA agrupa los pedidos parecidos, sugiere cuál dolor es más recurrente y propone prioridad para el roadmap. Marca como baja prioridad un pedido que aparece solo tres veces en el texto, porque el volumen bajo normalmente significa poco impacto. Solo que esas tres menciones vienen de los tres clientes más grandes de la base, cada uno valiendo más que cien clientes pequeños juntos. La prioridad sugerida por la IA, mirando solo volumen de mención, casi esconde el pedido que más valía en dinero.
Cada semana llegan decenas de objeciones y pedidos de descuento del equipo comercial al equipo de pricing. La IA agrupa los pedidos parecidos, sugiere cuál objeción es estándar de mercado y cuál se sale de la política, y rutea lo que se sale para aprobación del gerente. Marca como "dentro de la política" un pedido de descuento que, sumado a una cláusula escondida en el contrato anterior del mismo cliente, en realidad rompe el techo acordado en el board. El texto del pedido, aislado, parecía normal; solo cruzando con el historial del cliente aparece el problema. La ruta sugerida casi deja pasar un descuento que violaba el acuerdo del trimestre.
El panel de incidentes operacionales recibe quejas de varias plazas al mismo tiempo: retraso de entrega, avería, reclamo de conductor. La IA agrupa las quejas parecidas, sugiere severidad y rutea a la plaza responsable. Marca como severidad baja un conjunto de quejas de retraso en una plaza específica, porque cada queja aislada parece un caso puntual de tráfico. Solo que juntas, esas quejas apuntan a un problema estructural en el centro de distribución de esa plaza, que va a empeorar si nadie actúa esta semana. Tratar cada queja aislada como caso puntual casi esconde un problema estructural detrás del ruido del día a día.
El canal de denuncia interno recibe relatos de distintas áreas todo el tiempo, la mayoría son dudas de proceso, pero algunos son serios. La IA agrupa los relatos parecidos, sugiere severidad y rutea al responsable correcto. Marca como severidad baja un relato que usa lenguaje cauteloso e indirecto, porque el texto no contiene palabra de alarma. Solo que los relatos serios de compliance suelen venir exactamente así, cautelosos, porque quien denuncia tiene miedo de represalia. La severidad sugerida por la IA, calibrada solo por el tono del texto, casi clasificó como rutina el tipo de relato que más necesita atención rápida.
La investigación de usabilidad genera decenas de relatos de fricción cada semana, provenientes de sesión grabada, de NPS y de ticket de soporte. La IA agrupa los relatos parecidos, sugiere cuál fricción es más recurrente y rutea al equipo de diseño responsable de la pantalla. Marca como baja prioridad un conjunto de quejas sobre el flujo de registro, porque el volumen absoluto es pequeño comparado con otras colas. Solo que ese flujo específico es el primer contacto de todo cliente nuevo, y cada abandono ahí cuesta un cliente que nunca llega a conocer el producto. La prioridad sugerida, mirando solo volumen, casi esconde la fricción que más costaba ingresos.
Cada semana llegan decenas de pedidos y señales de mercado al comité de estrategia: un pedido de partnership por aquí, una mención de competidor por allá, un insight de analista más allá. La IA escanea todo, agrupa los pedidos parecidos, sugiere cuál merece atención del directorio esta semana y cuál puede esperar al próximo ciclo. Marca como "baja urgencia" una señal de que un competidor pequeño empezó a copiar tu posicionamiento, porque el texto suena como ruido de mercado común. Solo que ese competidor específico ya convirtió a dos clientes tuyos en el trimestre pasado, un dato que solo quien sigue el funnel de cerca sabe cruzar. La ruta sugerida por la IA casi entierra la señal correcta debajo del ruido.
Oye, quien ya fue dueño de una cola de tickets conoce la sensación: la bandeja de entrada nunca se vacía, y todos los días llega más rápido de lo que cualquier equipo logra leer. Entonces, en la práctica, el equipo hace lo que puede: mira los tickets más recientes, los que gritan más fuerte, los que alguien reclamó en el pasillo. El resto queda en la cola, esperando. Piensa conmigo: ¿y si se pudiera escanear la cola entera, y el equipo solo necesitara mirar de cerca los casos que realmente piden criterio? Es exactamente esa la coreografía de esta lección.
La idea central de esta lección. La IA no es quien decide qué importa en tu backlog. Es el primer triage: agrupa lo que es duplicado, sugiere la severidad y señala a qué equipo debería ir eso, en un volumen que ningún equipo cubriría leyendo ticket por ticket. Pero confirmar la severidad real, resolver la disputa de quién es el dueño del problema, y decidir la acción, eso sigue siendo del equipo. Y existe un costo real cuando la sugerencia se equivoca: severidad equivocada se convierte en prioridad equivocada, y ruta equivocada se convierte en confianza perdida entre equipos.
01Lo que la IA hace bien: dedupe, severidad sugerida, ruteo
Llamemos las cosas por su nombre. El cuello de botella de cualquier backlog nunca fue falta de inteligencia, fue volumen. Nadie tiene tiempo de leer 340 tickets línea por línea cada lunes, así que queda un triage por muestreo: los más recientes, los más ruidosos, los que alguien recordó reclamar.
La IA invierte esa cuenta. La apuntas a la cola entera y le pides que haga tres cosas al mismo tiempo:
- Dedupe. Encontrar los tickets que describen el mismo problema, aunque vengan de canales distintos (uno de Jira, uno de Zendesk, uno reenviado del WhatsApp de soporte) y con palabras diferentes.
- Severidad sugerida. A partir del texto y del sistema mencionado, proponer si eso parece crítico, alto, medio o bajo, y explicar el porqué de la sugerencia.
- Ruteo. Señalar a qué equipo debería ir ese ticket, por el componente o sistema que menciona.
La ganancia real aquí es de alcance. Pasas de "miramos los veinte tickets más recientes" a "pasamos por los 340, y tenemos una lista corta de casos que necesitan ojo humano". ¿Listo?
Cómo funciona el triage, en la práctica:
02Lo que sigue siendo del equipo: confirmar, resolver y decidir
Aquí está la parte que la IA no hace, y que es el corazón del triage. Agrupó, sugirió severidad y señaló ruta. ¿Y ahora? Ahora empieza el trabajo del equipo, y es todo criterio.
- Confirmar el dedupe. Dos tickets pueden parecer el mismo problema en el texto y ser, en la práctica, dos bugs distintos que solo ocurrieron en la misma pantalla. Juntarlos mal esconde el segundo problema detrás del primero. Alguien del equipo necesita mirar de cerca antes de cerrar como duplicado.
- Confirmar la severidad real. La IA lee el texto y el sistema mencionado; no sabe el impacto de negocio detrás. Un relato educado y sin palabra de alarma puede ser el más serio de todos, como el relato de seguridad que "suena parecido a casos anteriores" y en realidad expone dato de otro cliente. Solo quien conoce el sistema y el cliente sabe sopesar eso.
- Resolver la disputa de dueño. Un ticket que menciona autenticación y pago al mismo tiempo puede ser ruteado por la IA al equipo equivocado, porque el texto pesa más hacia un lado. Decidir de quién es el problema, cuando dos equipos tienen razón parcial, es conversación entre personas, no sugerencia automática.
- Decidir la acción. Confirmado el caso, alguien escala, prioriza en el próximo sprint, o le explica al cliente. La IA no cierra ticket, no cambia prioridad de producción sola. Quien decide, y responde por la decisión, es el equipo.
Nota el diseño: la IA reduce tu campo de búsqueda, no reemplaza el criterio de quien conoce el sistema. Convierte "leer todo" en "confirmar lo que importa".
03El costo a nombrar: severidad o ruta equivocada
Ahora la parte que no puedo dejar pasar, porque es donde esta coreografía sale mal si se acepta sin verificar. La IA sugiere, y no toda sugerencia es correcta. Eso tiene costo, y el costo tiene dos caras.
La primera cara es el ticket crítico rotulado como baja prioridad. Pasó en el ejemplo de la vulnerabilidad: una severidad sugerida "media", aceptada sin verificar, deja una falla grave esperando en la cola común por días, mientras el problema real sigue expuesto. La segunda cara es lo opuesto: una alarma tratada como urgente que en realidad no lo era, consumiendo al equipo equivocado a costa de una prioridad real que quedó esperando.
Ninguna de las dos es culpa de la herramienta. Es el costo de tratar la sugerencia como veredicto. Por eso la regla de esta coreografía: el equipo confirma antes de que cualquier severidad o ruta se convierta en acción. La sugerencia enciende al candidato; confirmar es lo que transforma al candidato en prioridad de verdad.
Sabe más: por qué la severidad "suena" equivocada con más frecuencia de lo que parece
La IA calibra la severidad principalmente por el tono y el vocabulario del texto: palabra de urgencia, mención a sistema crítico, repetición de término. El problema es que quien abre un ticket serio no siempre escribe con urgencia, a veces escribe con cautela, sobre todo cuando el tema es delicado (seguridad, dato de cliente, un relato del que la propia persona no está segura del tamaño). Y quien abre un ticket pequeño a veces escribe en mayúsculas. El resultado es que el texto engaña en ambas direcciones, hacia arriba y hacia abajo. Esto no es motivo para descartar la sugerencia, es motivo para saber dónde suele equivocarse: la severidad calibrada solo por tono necesita una segunda lectura siempre que el tema sea sensible por naturaleza (seguridad, dato personal, cliente grande), porque ahí es donde el texto cauteloso más se parece a la rutina.
04La coreografía, paso a paso
Junta todo y se convierte en un sistema simple, que corre en cada cierre de sprint o incluso todos los días, según el volumen de tu cola.
- La IA hace triage. Le pasas la cola entera y le pides dedupe, severidad sugerida con el motivo escrito, y ruta sugerida por el componente mencionado. Salida: una lista corta de casos que necesitan ojo humano, los demás siguen el flujo estándar.
- El equipo confirma los ambiguos. Toma la lista corta y mira caso por caso: el dedupe está bien, la severidad coincide con el impacto real, la ruta es del equipo correcto.
- El equipo decide la acción. Confirmado, el ticket se vuelve prioridad de sprint, escalación, o respuesta al cliente. La IA no cierra nada sola.
- El equipo registra el patrón. Cada vez que la sugerencia se equivocó (juntó lo que no debía, subestimó severidad, ruteó mal), eso se vuelve una nota para calibrar el próximo triage, el mismo tipo de fuente de la deuda técnica visible que vas a ver en la próxima lección.
Nota que la IA aparece en un solo paso, al principio. Amplía el alcance de quien hace triage, no decide en lugar de quien conoce el sistema. ¿Vamos?
05Dónde encaja esto
Esta coreografía es la misma lógica de portón de calidad que ya viste en la lección 6.1, solo que aplicada a la entrada del backlog, no a la salida del código. Allá, el portón decidía qué pasaba antes del deploy; aquí, la confirmación humana decide qué se vuelve prioridad antes de entrar al sprint. Mismo principio: la IA opera la cinta, el criterio que decide sigue siendo tuyo.
Hazlo ahora
Toma un lote real de tickets de tu backlog, tu tarea real o los últimos 30 abiertos en tu cola. Pídele a la IA que haga el primer escaneo:
- Que señale posibles duplicados entre ellos.
- Que sugiera la severidad de cada uno, con el motivo en una línea.
- Que sugiera el equipo o componente responsable de cada uno.
Ahora haz tu parte, que es la que importa: toma los cinco primeros ítems de la lista y clasifica cada uno en ruta correcta, severidad correcta, o necesitó corrección humana. Cuenta cuántos necesitaron corrección. Ese número es tu calibración: te muestra cuánto acierta el triage automático a la primera, y por qué la confirmación del equipo no es opcional.
Practica
1. En la coreografía de triage de backlog con IA, ¿cuál es el rol correcto de la IA?
2. La IA sugirió severidad 'media' para un relato técnico de vulnerabilidad, pero al investigar el equipo descubre que expone dato de otro cliente. ¿Qué muestra esto?
3. ¿Por qué la coreografía de triage de backlog se parece al portón de calidad de la lección 6.1?
Para la pizarra
Sobre la filasin barrido el equipo mira lo que llegó último y lo que gritó más fuerte. El resto espera a oscuras.
Sobre el papel de la IArecorre toda la fila y devuelve una lista corta con sugerencia y motivo, lista para confirmar.
Sobre la severidadcalibrada por el tono del texto engaña en las dos direcciones. Un asunto sensible pide siempre una segunda lectura.
Gracias por el feedback. Esto ayuda a afinar la próxima lección.