Cuando una solicitud de función es en realidad un bug
5 min de lectura
“¿Podéis añadir un ajuste para aumentar el límite de exportación?” se lee como una solicitud de función, y la mayoría de sistemas de triaje la etiquetan así en el acto. A veces lo es. A veces la exportación falla en un número por debajo del límite documentado por culpa de un bug, y la clienta, incapaz de ver el código, se ha inventado la solución más plausible que puede describir: dadme un número más grande y a lo mejor funciona. Qué etiquetas merecen la pena cubre la etiqueta de tipo que divide un backlog en solicitudes de función y bugs; este es el caso en que las propias palabras de una clienta apuntan la etiqueta en la dirección equivocada, y el coste de equivocarse es una deriva lenta hacia un backlog lleno de peticiones que nadie quiere de verdad en cuanto se mira debajo.
¿Cómo es una solicitud de función que en realidad es un bug?
Nombra un workaround en vez del problema. Una solicitud de función genuina suele describir un resultado que el producto no soporta en absoluto: “dejadme programar esto para más tarde”, “añadid un modo oscuro”. Un bug mal clasificado describe un número, umbral o comportamiento específico que suena a ajuste faltante pero en realidad es un síntoma: “aumentad el timeout”, “añadid una opción de reintento”, “dejadme exportar más filas de una vez”. La señal es que quien lo pide propone una implementación, un ajuste, un interruptor, una anulación, en vez de describir un objetivo, porque ya probó la función tal como está documentada y no hizo lo que la documentación dice que debería.
| Señal | Solicitud de función | Bug disfrazado de solicitud de función |
|---|---|---|
| Qué describe quien lo pide | Un resultado que el producto no puede hacer | Un parámetro que quiere cambiar |
| Si el comportamiento documentado ya cubre esto | No, falta de verdad | Sí, pero no funciona como está documentado |
| Si más esfuerzo hace que la petición desaparezca | No | A veces, si el bug depende de un umbral |
| Adónde debería enrutarse | Backlog de producto | Cola de bugs |
¿Por qué importa esto más de lo que parece?
Porque las dos colas tienen dueñas, plazos y criterios de éxito distintos, y un bug archivado como solicitud de función se prioriza frente a solicitudes de función, compitiendo por atención con lagunas de producto reales en vez de arreglarse en el plazo que merece un bug. Cómo rastrear solicitudes de función cubre por qué mezclar bugs y funciones en una sola cola deja que las quejas más ruidosas desplacen a las peticiones reales; una solicitud de función que en secreto es un bug causa el daño contrario, se queda en el backlog de producto acumulando votos para una “función” que desaparecería en cuanto se arreglara el bug de fondo, lo que desperdicia la señal de priorización para todo el que lea ese backlog.
¿Cómo se distingue cuando las propias palabras de la clienta apuntan en la dirección equivocada?
Pregunta qué esperaba que pasara, no qué quiere que añadáis. “La exportación se topó en 500 filas y necesito 2.000, ¿podéis subir el límite?” suena a solicitud de función de subida de límite hasta que la pregunta de seguimiento, “¿500 es el límite documentado?”, revela que el número documentado era 5.000 y la exportación falla antes de tiempo. Esa única pregunta, qué esperaba frente a qué pasó, hace la mayor parte del trabajo de clasificación, porque una solicitud de función genuina no tiene un comportamiento documentado del que quede por debajo; no hay nada que esperar porque la capacidad todavía no existe.
¿Deberían decidir esto los agentes de soporte o las ingenieras?
Los agentes de soporte hacen la primera pasada, porque ven el ticket primero, pero la etiqueta debería ser fácil de cambiar y barata de equivocar, no una decisión de una sola vez que fija el elemento en la cola equivocada para siempre. Una segunda comprobación ligera, una ingeniera que revise semanalmente las nuevas etiquetas de “solicitud de función” buscando algo que huela a bug disfrazado, atrapa las que un agente de soporte sin contexto del código no podría haber identificado. No hace falta que sea formal; es más un vistazo de cinco minutos que un proceso de revisión.
¿Cambia el cierre del ciclo una vez encontrado el bug real?
Sí, y mejora el mensaje que podéis enviar. Cerrar el bucle de feedback del cliente cubre avisar a quien pidió algo cuando se lanza; un bug recategorizado recibe una versión mejor de ese mensaje, porque “encontramos y arreglamos el bug detrás de esto” suena a competencia, mientras que “construimos la función que pediste” habría sido cierto solo por accidente, porque la solicitud de función real, un límite de exportación de verdad más alto, puede que nunca llegue a construirse una vez que el bug desaparece y el límite original de 5.000 filas es suficiente.
¿Qué pasa si nunca se detecta la mala clasificación?
El backlog se llena de peticiones que parecen demanda real y no lo son, y las decisiones de priorización tomadas contra ese backlog heredan la distorsión. Una “función” con cuarenta votos podría ser en realidad cuarenta personas topándose con el mismo bug, y construir la petición literal, un ajuste para subir un límite que nunca fue la verdadera restricción, entrega complejidad que no arregla nada, mientras el bug de fondo sigue generando nuevas “solicitudes de función” de clientas que aún no han encontrado este hilo.
FAQ
¿Vale la pena añadir un paso formal para comprobar cada solicitud de función contra bugs conocidos? No un paso formal, más bien un hábito: quien triaje una nueva solicitud de función debería preguntar “¿el comportamiento documentado ya dice que hace esto?” antes de poner la etiqueta, porque esa sola pregunta atrapa la mayoría de las mal clasificadas sin añadir sobrecarga de proceso.
¿Y si la clienta insiste en que es una solicitud de función incluso después de encontrar el bug? Explicad qué encontrasteis y por qué el ajuste que proponía ya no haría falta una vez arreglado el bug. La mayoría de clientas piden un workaround porque asumieron que el arreglo real no estaba disponible, no porque quisieran específicamente ese ajuste.
¿Un elemento recategorizado pierde los votos o comentarios que acumuló como solicitud de función? Debería conservarlos, visibles, porque esos votos son la evidencia que llevó a encontrar el bug en primer lugar, y esconder ese rastro hace más difícil detectar la misma mala clasificación la próxima vez, en un ticket distinto.
¿Puede pasar al revés, un bug que en realidad es una solicitud de función? Menos a menudo, pero sí: “esto está roto” a veces significa “esto no hace lo que asumí que haría”, que es una capacidad faltante, no un defecto. La misma pregunta, qué esperaba frente a qué está documentado, clasifica también en esta dirección.
Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.