El lunes la cola parecía sana
¿Quieres hablar de este ensayo? Escríbeme: amitkvint@gmail.comcopiado· o escríbeme por LinkedIn
Durante unos años en WPML, los números de soporte llegaban una vez por semana, en un informe.
El informe estaba bien. Tenía volumen de tickets, tiempo medio de espera, tiempo de resolución, satisfacción. Era el tipo de cosa que podías poner delante del equipo ejecutivo sin que nadie hiciera preguntas.
El problema era la distancia entre cuándo se producía el informe y cuándo lo leíamos. Para cuando un número aparecía en la página, describía la semana pasada. Y lo usábamos para tomar decisiones sobre esta semana.
Quién cubre el fin de semana. Si bajar a un supporter de segundo nivel a primer nivel durante unos días. Si el backlog que acaba de aparecer es un bache o el comienzo de algo. Esas son decisiones de martes. Nosotros las tomábamos con datos que se detenían el domingo.
Lunes: sano. Miércoles: bajo el agua.
El momento en que dejó de ser un problema teórico fue bastante normal, porque pasaba una y otra vez. Cada pocas versiones de WordPress, algo se rompía. La que recuerdo es una versión, creo que de 2023, que rompió el CSS del selector de idioma de WPML en algunos sitios. Nada espectacular visto desde fuera, pero cada uno de esos sitios era de alguien que lo estaba viendo.
El informe del lunes mostraba una cola sana. Tiempos de espera normales, backlog pequeño. Para el miércoles, estábamos bajo el agua, y nadie se había dado cuenta el martes porque no había nada con qué darse cuenta. Los supporters podían ver sus propios tickets. Los responsables de equipo podían ver su nivel. Nadie podía ver el conjunto entero, en tiempo real.
Salimos de eso como se suele salir: la gente trabajó hasta tarde, alguien se saltó un día libre, un par de clientes enfadados recibieron disculpas personales. Y luego salió el siguiente informe semanal y confirmó, en retrospectiva, lo que ya habíamos vivido.
Esa es la parte a la que sigo volviendo. El informe no estaba mal. Solo llegaba tarde. Y un número tardío es una cosa distinta de un número equivocado, porque todo el mundo confía en él.
La propuesta
Yo estaba en el equipo ejecutivo, así que se lo llevé al CEO y a mis compañeros de la misma forma que llevábamos todo lo demás: como una propuesta con un coste asociado.
Seis diapositivas. El problema, que era que tomábamos decisiones de capacidad con datos de una semana atrás. La evidencia, que era la historia del lunes al miércoles. Qué quería construir y qué se vería en tiempo real. Las opciones, incluyendo no hacer nada. El coste: seis semanas de tiempo de desarrollo más dos semanas de QA. Y la petición.
Creo que incluir "no hacer nada" como una opción real importó más que cualquier otra cosa en esas diapositivas. Hizo explícito el coste de la situación actual en lugar de darlo por hecho. Cada pico que se notaba tarde tenía un precio en horas extra, en tiempo de resolución, en algún reembolso ocasional. Una vez que eso estuvo en una diapositiva al lado de ocho semanas de ingeniería, la decisión prácticamente se tomó sola.
Lo que construimos
Una pequeña aplicación en Python sobre nuestros datos de soporte, que se actualizaba de forma continua en lugar de semanal. No era la capa de análisis de la que hablé en Tu cola de tickets es un registro de defectos. Aquella ordenaba los problemas recurrentes para poder arreglarlos en origen. Esta iba de la cola en este momento.
La construyó Otto Wald, uno de mis lead supporters y un compañero muy querido. Yo probaba y especificaba cambios. Yo no escribía el código, y no creo que debiera haberlo hecho. Lo que hacía era decidir qué tenía que estar en la pantalla, y al lado de qué.
La especificación estaba ordenada por tiempo.
Primero, la vista larga. Reportes nuevos, chats y tickets contados juntos, por mes durante los últimos tres años. Del último mes: la media por día de la semana, la media por hora, el volumen por foro, la tasa de resolución, los tiempos de resolución de tickets, de chats y de ambos, y cuán contentos estaban los usuarios con el soporte.
Después, la semana pasada. Tickets por día, chats iniciados, total de reportes, chats que acabaron convertidos en tickets, feedback positivo, tasa de resolución, tiempos de resolución, tiempo de primera respuesta.
Después, hoy. El mismo tipo de números otra vez, más cuántos chats convertidos esperaban en la cola sin asignar. Y al lado de casi todos, un más o un menos frente a la media de la semana pasada.
Y por último, una fila por supporter, en vivo. Si estaba trabajando o no, horas que le quedaban de turno, si estaba en el chat, tickets asignados, respuestas a tickets hoy, chats en curso, tickets esperando al usuario, feedback negativo hoy, tiempo de primera respuesta hoy, reportes resueltos hoy.
Esa última parte solo la veían los responsables de equipo, y servía para repartir el trabajo, nunca para las evaluaciones. Una fila de números en vivo sobre una persona se convierte en un ranking en cuanto aparece en una evaluación.
Así que los números semanales no desaparecieron. Cambiaron de sitio. Antes el informe era la noticia, con una semana de retraso. En la pantalla, la media de la semana pasada pasó a ser la vara con la que se medía el día de hoy, y las medias mensuales por día y por hora te decían cómo tenía que ser un martes por la tarde normal.
Eso es lo que el informe viejo nunca podía hacer. Podía decirte que la semana pasada había sido movida. No podía decirte, un martes, que ese mismo martes ya iba camino de algo peor.
Lo que cambió
La usaba todos los días.
Desde que estuvo en marcha, un problema grande en la cola ya no podía esconderse hasta el siguiente informe. Si ese día faltaban unas cuantas personas, o de repente empezaban a acumularse tickets o chats, aparecía en la pantalla en el momento. Podía cambiar el foco enseguida, pedir ayuda, abrir los tickets y ver exactamente qué estaba pasando.
La sorpresa del lunes al miércoles no se repitió.
No recuerdo los números de esa época, así que no voy a poner ninguno.
El otro cambio fue en lo rápido que me llegaban las cosas. Antes, la imagen completa existía una vez por semana, en un documento, para la gente que lee documentos. Después, los responsables de equipo miraban la misma imagen en vivo, y cuando algo no cuadraba, me avisaban mucho antes.
Esa es la versión de "basado en datos" en la que de verdad creo. No más números. Los mismos números, más cerca del momento en que alguien tiene que decidir algo, y al lado de lo que es normal.
La parte que no es sobre Python
Las herramientas cambian. Construimos esto en Python porque era lo que Otto y yo dominábamos los dos; hoy probablemente tendría una versión básica funcionando con datos de ejemplo en uno o dos días con una herramienta de IA para programar, y le entregaría a Otto algo que ya funciona en vez de una especificación.
El objetivo no cambia. Si diriges un equipo de soporte y tus números llegan después de la semana que describen, no tienes un problema de medición. Tienes un problema de tiempos, y cada decisión intermedia se toma a ojo.
Pon en vivo los números de hoy, y al lado de cada uno la media de la semana pasada. No hace falta tirar el informe semanal. Simplemente deja de ser la noticia y pasa a ser la referencia.
Y si lo estás proponiendo hacia arriba, pon "no hacer nada" en la diapositiva. Suele ser la opción más cara, y la única que nadie ha calculado :-)