Solicitudes duplicadas: fusionar sin perder la voz original
6 min de lectura
Tres clientas piden la misma capacidad en tres semanas distintas, con tres redacciones distintas, y un proceso de triaje construido para atrapar duplicados hace su trabajo: las agrupa, las cuenta como una sola solicitud con tres votos, y el backlog queda limpio. Esa es la parte fácil. Qué etiquetas merecen la pena cubre agrupar por capacidad subyacente antes de triagiar por redacción como la solución mecánica a los duplicados; lo que no cubre es qué pasa con las palabras mismas una vez que tres solicitudes se convierten en una sola línea, y esa pérdida suele ser mayor que el problema de contar duplicados que resolvió.
¿Qué se pierde realmente cuando se fusionan duplicados?
La redacción específica que usó cada solicitante, que a menudo es más informativa que el recuento de votos en el que colapsa. Una clienta podría pedir “una forma de exportar resultados filtrados”, otra “exportación CSV que respete mis filtros guardados”, y una tercera “exportación que no incluya columnas ocultas”. Las tres son la misma solicitud subyacente, agrupada correctamente, pero cada redacción lleva un énfasis ligeramente distinto sobre lo que le importa a esa persona, y una fusión que solo conserva la redacción de la primera petición descarta por completo las otras dos. El recuento sobrevive; la textura que ayudaría a alguien a construir la versión correcta de la función, no.
¿Por qué importa la textura si el recuento de votos ya dice que existe demanda?
Porque demanda y diseño son preguntas distintas, y solo la redacción específica responde la segunda. Diez votos en “exportación” le dice a un equipo que vale la pena construir la función; no dice nada sobre si “exportación” significa CSV, PDF, un email programado o un endpoint de API, y una fusión que descarta nueve de las diez peticiones originales a favor de la redacción de la primera puede estrechar en silencio la especificación a lo que fuera que pidiera esa primera solicitante, aunque las otras nueve quisieran algo sutilmente distinto. Qué debería registrar realmente una solicitud de función cubre este mismo hueco desde el lado de la recepción; fusionar duplicados es donde vuelve a aparecer después de la recepción, justo en el punto donde un equipo más necesita el rango de lo que realmente se pidió.
¿Cómo es un proceso de fusión que conserva la redacción en lugar de descartarla?
Añadir en lugar de reemplazar. El elemento canónico conserva un único título para la vista del backlog, pero la redacción original de cada petición fusionada queda adjunta a él, ya sea como lista de citas o como tickets fuente enlazados, para que cualquiera que revise el elemento más tarde pueda ver el rango real de lo que la gente pidió en lugar del resumen de una persona del equipo. Esto cuesta casi nada de construir, un campo en el ticket en lugar de un sistema nuevo, y es la diferencia entre una fusión que comprime información y una que solo comprime cómo se muestra.
Función: Exportación CSV filtrada
Votos: 12
Solicitudes fusionadas:
- "una forma de exportar resultados filtrados" (acct_4421)
- "exportación CSV que respete mis filtros guardados" (acct_8832)
- "exportación que no incluya columnas ocultas" (acct_1097)
...¿Todo duplicado merece fusionarse, o hay coincidencias falsas?
Algunas son coincidencias falsas, y tratar “suena parecido” como “es la misma solicitud” es su propio modo de fallo. “Déjame exportar mis datos” y “déjame exportar solo la vista filtrada” pueden agruparse por una coincidencia de palabra clave en “exportar” mientras en realidad describen dos alcances distintos de la misma capacidad general; fusionarlas o infla el recuento de votos para la cosa equivocada o, peor, lanza la versión más estrecha porque llegó primero por casualidad. Una pasada humana sobre la agrupación, aunque sea rápida, atrapa esto antes de que se acumule; una coincidencia automática por similitud sola fusionará de más por vocabulario y de menos por intención.
¿Cuándo debería ejecutarse realmente la detección de duplicados, al recibirlos o después?
Ambos, por razones distintas. Comprobar al recibirlos atrapa el caso obvio, una solicitud nueva que repite algo ya abierto, antes de que se convierta en su propia línea sin rastrear; una búsqueda por similitud contra las solicitudes abiertas en el momento del envío resuelve la mayoría de estos casos sin que intervenga ninguna persona. Un segundo pase más tarde, con un ritmo más lento, atrapa el caso que la comprobación inicial se pierde: dos solicitudes que usaron un lenguaje lo bastante distinto como para escapar en su momento a una coincidencia por palabra clave o por embedding, pero que resultan, una vez que un equipo ha visto una docena de variaciones, describir la misma capacidad subyacente. Saltarse el segundo pase deja casi-duplicados dispersos bajo títulos separados indefinidamente, cada uno con su propio recuento pequeño de votos que nunca suma el número que habría conseguido que se construyera.
¿Debería saber la solicitante que su petición se fusionó en un elemento existente?
Sí, y esta es la misma disciplina que cerrar el bucle de feedback del cliente aplicada un paso antes de lo habitual: una solicitante que envió algo y nunca vuelve a saber nada concluye que su petición no fue a ningún lado, aunque se fusionara correctamente en un elemento con otros once votos que acabó lanzándose. Un reconocimiento breve, “hemos combinado esto con una solicitud existente que otras personas también han hecho”, cuesta un mensaje y evita que una clienta reenvíe la misma petición cada pocos meses porque no tiene visibilidad de si alguna vez se rastreó de verdad.
¿Fusionar cambia a quién se le da crédito cuando la función se lanza?
Debería incluir a todo el mundo, no solo a quien la envió primero. Cerrar el bucle de
feedback cubre avisar a quien pidió algo cuando se lanza; para
un elemento fusionado eso significa cada cuenta adjunta a la fusión, no solo aquella cuya
redacción se convirtió en el título canónico, porque desde la perspectiva de cada solicitante ella
pidió esto y se lanzó, sin importar de quién fuera la redacción que un proceso de triaje decidiera
conservar. Con changeloop eso significa que el pull request nombra cada issue vinculado
(Fixes #142, fixes #187); un issue que no nombra no recibe ningún comentario.
FAQ
¿Cuánta redacción vale la pena conservar por solicitud fusionada, una cita o un enlace completo al ticket? Una cita corta suele bastar para el caso común, ya que su propósito es dejar que quien revisa vea el rango de redacciones de un vistazo; conservad también el enlace completo al ticket cuando el original tuviera contexto extra significativo, como una captura de pantalla o una descripción detallada de flujo que una cita de una línea aplanaría.
¿Conservar la redacción de cada duplicado hace más difícil escanear el backlog? No, si está colapsada por defecto. El título canónico es lo que ve quien revisa por encima; la redacción fusionada está a un clic o un despliegue de distancia, presente para quien hace investigación más profunda pero sin saturar la vista de quien solo cuenta votos.
¿Qué pasa si dos solicitudes parecen idénticas pero resultan querer cosas distintas una vez construidas? Volved a separarlas en cuanto quede claro, y tratad la fusión original como una decisión razonable tomada con la información disponible en ese momento, no como un error que evitar repetir. Un sistema de agrupación que nunca deshace nada acabará teniendo unas cuantas fusiones equivocadas horneadas permanentemente.
¿Hay un umbral de votos a partir del cual una solicitud fusionada debería recibir una revisión humana de la redacción subyacente? No un número fijo, pero cualquier solicitud que se acerque a una decisión de construcción lo merece sin importar el recuento de votos, porque ese es el punto donde la diferencia entre “exportación” y “exportación como CSV con filtros guardados” deja de ser un matiz y empieza a ser la especificació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.