Seguimiento de solicitudes de funciones, sin perderlas

El seguimiento de solicitudes de funciones falla casi siempre de una de dos formas. O las solicitudes no tienen adónde ir, así que viven en bandejas de entrada y hilos de Slack donde se olvidan una a una, o tienen un sitio al que ir que nadie vuelve a revisar, así que se olvidan todas juntas. Un sistema que funciona tiene que resistir ambos fallos: necesita un único lugar donde caiga cada solicitud, y una razón para volver a abrir ese lugar el mes que viene.

¿De dónde vienen realmente las solicitudes de funciones?

De más canales de los que la mayoría de los sistemas de seguimiento contemplan. Un ticket de soporte que incluye un “estaría bien si”. Un comentario en una roadmap pública. Una llamada de ventas donde una candidata nombra la única cosa que bloquea el trato. Un widget dentro del producto. Cada canal tiene su propia dueña y sus propias herramientas, y por eso las solicitudes se dispersan: la cola de tickets de soporte y el backlog del equipo de producto rara vez son el mismo sistema, y una solicitud que solo llega a uno de los dos, en la práctica, solo llegó a un departamento.

Un único formulario de entrada para cada canal no funciona, porque nadie lo adopta. Lo que funciona es un destino al que cada canal encamine, aunque el enrutamiento sean cinco minutos diarios de copiar y pegar hasta que se automatice.

¿Qué es lo que realmente rompe el seguimiento de solicitudes?

Casi siempre dos cosas. La primera es un destino inexistente: las solicitudes se responden en el canal donde llegaron y nunca quedan registradas en ningún sitio duradero, así que la misma solicitud de tres clientes distintos parece tres respuestas puntuales sin relación en vez de una sola señal. La segunda, más frecuente, es un destino que se llena y deja de leerse. Una hoja de cálculo con 400 filas sin filtrar ya no es un sistema de seguimiento; es un archivo que resulta ser escribible.

El segundo fallo es el más peligroso, porque parece que el seguimiento funciona. Las solicitudes se registran. Nada parece roto hasta que alguien pregunta “cuántas personas han pedido X” y la respuesta honesta es “tendríamos que leer las 400 filas para saberlo”.

¿Qué debería registrar realmente una solicitud de función?

Lo suficiente para responder tres preguntas más adelante sin releer el mensaje original: qué se pidió, a ser posible con las propias palabras de quien lo pidió; quién lo pidió, y cómo contactarla si la respuesta acaba siendo “lo construimos”; y qué haría falta para saber si es una petición habitual o un caso aislado. Una cita textual vale más que una paráfrasis, porque una paráfrasis escrita por quien triagió la solicitud ya lleva su propia lectura incorporada, y esa lectura es justo lo que una segunda persona no puede comprobar seis meses después.

¿Qué etiquetas merecen la pena?

Dos, y responden preguntas distintas. Una etiqueta de tipo separa una solicitud de función de un reporte de error, porque ambos necesitan dueñas y plazos distintos, y mezclarlos en una sola cola deja que las quejas más ruidosas desplacen a las peticiones. Una etiqueta de prioridad, reducida a un conjunto pequeño como low, medium y high, separa “bloquea a alguien el uso del producto” de “estaría bien”, porque ambas merecen tiempos de respuesta muy distintos y ninguna debería heredar el ritmo de la otra. Poner bien la etiqueta de tipo asume que la solicitud es lo que dice ser; cuando una solicitud de función es en realidad un bug cubre el caso en que las propias palabras de una clienta apuntan esa etiqueta en la dirección equivocada.

El triaje automatizado puede aplicar ambas en el momento en que llega la solicitud. En changeloop, un envío desde el widget recibe la etiqueta feature-request o bug y una etiqueta priority:low|medium|high en el mismo paso, más una marca from-widget para que el origen sea visible sin abrir el elemento. Eso basta para filtrar el backlog en un minuto en lugar de una tarde: muéstrame cada solicitud de función de alta prioridad llegada por el widget este mes.

Una tercera etiqueta merece la pena en cuanto existe una roadmap pública: un estado que la persona que pidió algo pueda comprobar por su cuenta. Roadmap pública cubre por completo los estados planned, building y shipped; en resumen, esa etiqueta convierte una cola privada en algo que quien pidió algo puede consultar sin volver a preguntar.

¿Cómo se decide qué construir a continuación?

Agrupar antes de contar. Diez solicitudes formuladas de forma distinta para la misma capacidad subyacente se leen como diez filas dispersas en una hoja de cálculo, y como una señal fuerte en cuanto se agrupan, y esa agrupación suele ser el paso que falta, no el conteo. Un conteo en bruto sin agrupar tiende a premiar la función con el nombre más pegadizo, no la que tiene más demanda real detrás.

Ponderar por quién pide, no solo por cuántos piden. Una solicitud de una cuenta cerca de renovar lleva una urgencia distinta a la misma solicitud de un registro de prueba, y un sistema de seguimiento que descarta ese contexto a favor de un recuento desnudo está optimizando por el número más fácil de calcular, no por el más útil.

Cada decisión aquí también produce solicitudes que pierden, y esas merecen respuesta también; cómo rechazar una solicitud de función cubre qué decir a quienes no lograron que su petición saliera adelante. Agrupar y ponderar es solo la mitad de “qué construir a continuación”; cómo priorizar solicitudes de funciones cubre los marcos reales, RICE, ponderación por ingresos y recuentos brutos, y dónde falla cada uno.

¿Cómo se cierra el círculo cuando algo se lanza?

Este es el paso que los sistemas de seguimiento más se saltan, y el que quienes pidieron algo realmente notan. Cerrar el círculo de feedback con el cliente cubre la mecánica completa; lo que corresponde aquí es que cerrar el círculo solo funciona si la solicitud original quedó vinculada a la persona. Una plantilla de solicitud de función construida a partir de un issue de GitHub, con la identidad de quien pidió el cambio ligada al propio issue en lugar de enterrada en un comentario, es lo que hace posible una notificación automática de “lanzado” en vez de una que alguien tiene que recordar enviar. Plantilla de solicitud de función muestra la plantilla concreta y para qué sirve cada campo.

FAQ

¿Qué herramienta debería usar para el seguimiento de solicitudes de funciones? Lo que el equipo ya revisa a diario supera a cualquier herramienta dedicada que nadie abre. Un tracker de issues de GitHub funciona bien si ingeniería ya vive ahí; un tablero ligero funciona bien si producto vive ahí. La herramienta importa menos que si se vuelve a consultar.

¿Cómo evito que se dupliquen las solicitudes de funciones? Agrupar por capacidad subyacente antes de triagiar por redacción. Buscar entre las solicitudes existentes antes de crear una nueva atrapa la mayoría de los duplicados; una agrupación mensual atrapa el resto. Fusionar duplicados sin perder la voz original cubre qué hacer con la redacción una vez hecha la agrupación en sí, para que la fusión no estreche en silencio la solicitud a lo que fuera que pidiera la primera petición en llegar.

¿Toda solicitud de función debería recibir respuesta? Toda debería recibir un acuse de recibo, aunque sea breve, pero no toda necesita una decisión de inmediato. Un estado visible, como una etiqueta de roadmap que la persona pueda comprobar por su cuenta, sustituye la mayoría de las respuestas individuales que un equipo debería dar de otro modo.

¿Cuál es la diferencia entre el seguimiento de solicitudes y una roadmap pública? El seguimiento es el registro interno de cada petición, incluidas las que nunca se lanzarán. Una roadmap pública es el subconjunto al que un equipo se compromete públicamente, con un estado que quien pidió algo puede ver sin volver a preguntar.

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.

Relacionado en changeloop: Documentación para desarrolladores, Herramientas de changelog comparadas