Boucle de feedback

Demandes dupliquées : fusionner sans perdre la voix

6 min de lecture

Trois clientes demandent la même capacité sur trois semaines différentes, formulée de trois façons différentes, et un processus de triage construit pour intercepter les doublons fait son travail : il les regroupe, les compte comme une seule demande avec trois votes, et le backlog reste propre. C’est la partie facile. Quelles étiquettes valent la peine couvre le regroupement par capacité sous-jacente avant de trier par formulation comme solution mécanique aux doublons ; ce qu’il ne couvre pas, c’est ce qui arrive aux mots eux-mêmes une fois que trois demandes deviennent une seule ligne, et cette perte est généralement plus grande que le problème de comptage des doublons qu’elle a résolu.

Que perd-on réellement quand des doublons sont fusionnés ?

La formulation spécifique utilisée par chaque demandeuse, qui est souvent plus informative que le décompte de votes dans lequel elle s’effondre. Une cliente pourrait demander « un moyen d’exporter des résultats filtrés », une autre « un export CSV qui respecte mes filtres enregistrés », et une troisième « un export qui n’inclut pas les colonnes masquées ». Les trois sont la même demande sous-jacente, correctement regroupée, mais chaque formulation porte une emphase légèrement différente sur ce qui compte pour cette personne, et une fusion qui ne garde que la formulation de la première soumission jette entièrement les deux autres. Le décompte survit ; la texture qui aiderait quelqu’un à construire la bonne version de la fonctionnalité, non.

Pourquoi la texture compte-t-elle si le décompte de votes dit déjà que la demande existe ?

Parce que demande et conception sont des questions différentes, et seule la formulation spécifique répond à la seconde. Dix votes sur « export » dit à une équipe que ça vaut le coup de construire la fonctionnalité ; ça ne dit rien sur si « export » signifie CSV, PDF, un email programmé ou un endpoint API, et une fusion qui écarte neuf des dix soumissions originales en faveur de la formulation de la première peut discrètement rétrécir la spec à ce que la première demandeuse a demandé par hasard, même si les neuf autres voulaient quelque chose de subtilement différent. Ce qu’une demande de fonctionnalité devrait réellement enregistrer couvre exactement ce manque du côté de la réception ; fusionner les doublons est là où ça réapparaît après la réception, précisément au point où une équipe a le plus besoin de l’éventail de ce qui a vraiment été demandé.

À quoi ressemble un processus de fusion qui garde la formulation au lieu de la jeter ?

Ajouter plutôt que remplacer. L’élément canonique garde un titre unique pour la vue du backlog, mais la formulation originale de chaque soumission fusionnée reste attachée à lui, soit comme liste de citations soit comme tickets sources liés, pour que quiconque revoit l’élément plus tard puisse voir l’éventail réel de ce que les gens ont demandé au lieu du résumé d’une personne de l’équipe. Ça ne coûte presque rien à construire, un champ sur le ticket plutôt qu’un nouveau système, et c’est la différence entre une fusion qui compresse l’information et une qui compresse juste son affichage.

Fonctionnalité : Export CSV filtré
Votes : 12
Demandes fusionnées :
  - "un moyen d'exporter des résultats filtrés" (acct_4421)
  - "un export CSV qui respecte mes filtres enregistrés" (acct_8832)
  - "un export qui n'inclut pas les colonnes masquées" (acct_1097)
  ...

Chaque doublon mérite-t-il d’être fusionné, ou y a-t-il de fausses correspondances ?

Certaines sont de fausses correspondances, et traiter « ça sonne similaire » comme « c’est la même demande » est son propre mode d’échec. « Laissez-moi exporter mes données » et « laissez-moi exporter juste la vue filtrée » peuvent être regroupées par une correspondance de mot-clé sur « exporter » alors qu’elles décrivent en réalité deux périmètres différents de la même capacité générale ; les fusionner gonfle soit le décompte de votes pour la mauvaise chose, soit, pire, livre la version plus étroite parce qu’elle est arrivée en premier par hasard. Un passage humain sur le regroupement, même rapide, attrape ça avant que ça ne s’accumule ; une correspondance de similarité automatique seule sur-fusionnera sur le vocabulaire et sous-fusionnera sur l’intention.

À quel moment la détection de doublons doit-elle tourner, à la réception ou plus tard ?

Les deux, pour des raisons différentes. Vérifier à la réception attrape le cas évident, une nouvelle demande qui reformule quelque chose déjà ouvert, avant qu’elle ne devienne sa propre ligne non suivie ; une recherche de similarité contre les demandes ouvertes au moment de la soumission traite la plupart de ces cas sans aucune intervention humaine. Un second passage plus tard, à un rythme plus lent, attrape le cas que la réception rate : deux demandes formulées avec un vocabulaire assez différent pour échapper à une correspondance de mot-clé ou d’embedding sur le moment, mais qui s’avèrent, une fois qu’une équipe a vu une dizaine de variations, décrire la même capacité sous-jacente. Sauter le second passage laisse des quasi-doublons éparpillés sous des titres séparés indéfiniment, chacun avec son petit décompte de votes qui ne s’additionne jamais au nombre qui aurait suffi à le faire construire.

La demandeuse devrait-elle savoir que sa soumission a été fusionnée dans un élément existant ?

Oui, et c’est la même discipline que boucler la boucle de feedback client appliquée une étape plus tôt que d’habitude : une demandeuse qui a soumis quelque chose et n’en entend jamais reparler conclut que sa demande n’a mené nulle part, même si elle a été correctement fusionnée dans un élément avec onze autres votes qui a fini par être livré. Un accusé de réception court, « nous avons combiné ceci avec une demande existante que d’autres ont faite aussi », coûte un message et évite qu’une cliente resoumette la même demande tous les quelques mois parce qu’elle n’a aucune visibilité sur si elle a jamais été réellement suivie.

La fusion change-t-elle qui est crédité quand la fonctionnalité est livrée ?

Elle devrait inclure tout le monde, pas seulement qui a soumis en premier. Boucler la boucle de feedback couvre le fait d’avertir les demandeuses quand leur demande est livrée ; pour un élément fusionné, ça veut dire chaque compte attaché à la fusion, pas seulement celui dont la formulation est devenue le titre canonique, parce que du point de vue de chaque demandeuse, elle a demandé ceci et ça a été livré, peu importe la formulation qu’un processus de triage a choisi de garder. Avec changeloop, cela veut dire que la pull request nomme chaque issue liée (Fixes #142, fixes #187) ; une issue qu’elle ne nomme pas ne reçoit aucun commentaire.

FAQ

Combien de formulation vaut la peine d’être gardée par demande fusionnée, une citation ou un lien complet vers le ticket ? Une courte citation suffit généralement pour le cas courant, puisque son but est de laisser une relectrice voir l’éventail de formulations d’un coup d’œil ; gardez aussi le lien complet vers le ticket quand l’original avait un contexte supplémentaire significatif, comme une capture d’écran ou une description détaillée de workflow qu’une citation d’une ligne aplatirait.

Garder la formulation de chaque doublon rend-il le backlog plus difficile à parcourir ? Pas si c’est replié par défaut. Le titre canonique est ce que voit une relectrice qui parcourt rapidement ; la formulation fusionnée est à un clic ou un dépliage de distance, présente pour qui fait une recherche plus approfondie mais sans encombrer la vue de qui compte juste les votes.

Que faire si deux demandes semblent identiques mais s’avèrent vouloir des choses différentes une fois construites ? Reséparez-les dès que ça devient clair, et traitez la fusion originale comme une décision raisonnable prise avec l’information disponible à l’époque, pas comme une erreur à éviter de répéter. Un système de regroupement qui ne défusionne jamais rien finira par avoir quelques mauvaises fusions gravées en permanence.

Y a-t-il un seuil de votes à partir duquel une demande fusionnée devrait recevoir une revue humaine de la formulation sous-jacente ? Pas un nombre fixe, mais toute demande approchant une décision de construction le mérite peu importe le décompte de votes, parce que c’est le point où la différence entre « export » et « export en CSV avec filtres enregistrés » cesse d’être une nuance et commence à être la spec.


Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.

À voir sur changeloop : Documentation développeurs, Comparatif d'outils de changelog

changeloop
L'équipe qui construit un changelog qui boucle la boucle. Tes utilisateurs demandent, ton équipe livre, la personne qui a demandé est prévenue.