Quand une demande de fonctionnalité est en fait un bug
6 min de lecture
« Pouvez-vous ajouter un réglage pour augmenter la limite d’export ? » se lit comme une demande de fonctionnalité, et la plupart des systèmes de triage l’étiquettent ainsi sur le champ. Parfois c’en est une. Parfois l’export échoue à un nombre inférieur à la limite documentée à cause d’un bug, et la cliente, incapable de voir le code, a inventé la solution la plus plausible qu’elle sait décrire : donnez-moi un nombre plus grand et peut-être que ça marchera. Quelles étiquettes valent la peine couvre l’étiquette de type qui divise un backlog en demandes de fonctionnalités et bugs ; voici le cas où les mots mêmes d’une cliente pointent l’étiquette dans la mauvaise direction, et le coût de se tromper est une dérive lente vers un backlog plein de demandes que personne ne veut vraiment une fois qu’on regarde en dessous.
À quoi ressemble une demande de fonctionnalité qui est en fait un bug ?
Elle nomme un contournement au lieu du problème. Une vraie demande de fonctionnalité décrit généralement un résultat que le produit ne supporte pas du tout : « laissez-moi programmer ça pour plus tard », « ajoutez un mode sombre ». Un bug mal classé décrit un nombre, un seuil ou un comportement spécifique qui sonne comme un réglage manquant mais qui est en fait un symptôme : « augmentez le timeout », « ajoutez une option de retry », « laissez-moi exporter plus de lignes à la fois ». Le signe révélateur est que la demandeuse propose une implémentation, un réglage, un interrupteur, une surcharge, plutôt que de décrire un objectif, parce qu’elle a déjà essayé la fonctionnalité telle que documentée et elle n’a pas fait ce que la documentation dit qu’elle devrait faire.
| Signal | Demande de fonctionnalité | Bug déguisé en demande de fonctionnalité |
|---|---|---|
| Ce que décrit la demandeuse | Un résultat que le produit ne peut pas faire | Un paramètre qu’elle veut changer |
| Si le comportement documenté couvre déjà ça | Non, vraiment manquant | Oui, mais ça ne fonctionne pas comme documenté |
| Si plus d’effort fait disparaître la demande | Non | Parfois, si le bug dépend d’un seuil |
| Où ça devrait être routé | Backlog produit | File des bugs |
Pourquoi est-ce plus important que ça n’y paraît ?
Parce que les deux files ont des responsables, des délais et des critères de succès différents, et un bug classé comme demande de fonctionnalité est priorisé contre les demandes de fonctionnalités, rivalisant pour l’attention avec de vrais manques produit au lieu d’être corrigé selon le délai qu’un bug mérite. Comment suivre les demandes de fonctionnalités couvre pourquoi mélanger bugs et fonctionnalités dans une seule file laisse les plaintes les plus bruyantes passer devant les vraies demandes ; une demande de fonctionnalité qui est secrètement un bug fait le dommage inverse, reste dans le backlog produit à accumuler des votes pour une « fonctionnalité » qui disparaîtrait dès que le bug sous-jacent serait corrigé, ce qui gaspille le signal de priorisation pour quiconque lit ce backlog.
Comment distinguer quand les mots mêmes de la cliente pointent dans la mauvaise direction ?
Demandez ce qu’elle s’attendait à voir se passer, pas ce qu’elle veut que vous ajoutiez. « L’export plafonnait à 500 lignes et j’en ai besoin de 2 000, pouvez-vous augmenter la limite » sonne comme une demande de fonctionnalité d’augmentation de limite jusqu’à ce que la question de suivi, « 500 est-elle la limite documentée », révèle que le nombre documenté était 5 000 et que l’export échoue tôt. Cette seule question, ce qu’elle attendait contre ce qui s’est passé, fait la majeure partie du travail de tri, parce qu’une vraie demande de fonctionnalité n’a pas de comportement documenté auquel elle manque ; il n’y a rien à attendre parce que la capacité n’existe pas encore.
Les agentes de support ou les ingénieures devraient-elles trancher ?
Les agentes de support font le premier passage, parce qu’elles voient le ticket en premier, mais l’étiquette devrait être facile à changer et bon marché à se tromper, pas une décision unique qui fixe l’élément dans la mauvaise file pour toujours. Une seconde vérification légère, une ingénieure qui parcourt chaque semaine les nouvelles étiquettes « demande de fonctionnalité » à la recherche de ce qui sent le bug déguisé, attrape celles qu’une agente de support sans contexte du code n’aurait pas pu reconnaître. Ça n’a pas besoin d’être formel ; c’est plus un coup d’œil de cinq minutes qu’un processus de revue.
Boucler la boucle change-t-il une fois le vrai bug trouvé ?
Oui, et ça améliore le message que vous pouvez envoyer. Boucler la boucle de feedback client couvre le fait d’avertir la demandeuse quand ce qu’elle a demandé est livré ; un bug recatégorisé reçoit une meilleure version de ce message, parce que « nous avons trouvé et corrigé le bug derrière ça » sonne comme de la compétence, alors que « nous avons construit la fonctionnalité que vous avez demandée » n’aurait été vrai que par accident, parce que la vraie demande de fonctionnalité, une limite d’export vraiment plus haute, pourrait n’être jamais construite une fois le bug parti et la limite originale de 5 000 lignes suffisante.
Que se passe-t-il si la mauvaise classification n’est jamais repérée ?
Le backlog se remplit de demandes qui ressemblent à une vraie demande et qui n’en sont pas, et les décisions de priorisation prises contre ce backlog héritent de la distorsion. Une « fonctionnalité » avec quarante votes pourrait en réalité être quarante personnes tombant sur le même bug, et construire la demande littérale, un réglage pour augmenter une limite qui n’a jamais vraiment été la contrainte, livre de la complexité qui ne corrige rien, tandis que le bug sous-jacent continue de générer de nouvelles « demandes de fonctionnalités » de clientes qui n’ont pas encore trouvé ce fil.
FAQ
Vaut-il la peine d’ajouter une étape formelle pour vérifier chaque demande de fonctionnalité contre les bugs connus ? Pas une étape formelle, plutôt une habitude : quiconque trie une nouvelle demande de fonctionnalité devrait demander « le comportement documenté prétend-il déjà faire ça » avant d’appliquer l’étiquette, parce que cette seule question attrape la plupart des mauvaises classifications sans ajouter de surcharge de processus.
Et si la cliente insiste que c’est une demande de fonctionnalité même après que le bug a été trouvé ? Expliquez ce que vous avez trouvé et pourquoi le réglage qu’elle proposait ne serait plus nécessaire une fois le bug corrigé. La plupart des clientes demandent un contournement parce qu’elles ont supposé que le vrai correctif n’était pas disponible, pas parce qu’elles voulaient spécifiquement ce réglage.
Un élément recatégorisé perd-il les votes ou commentaires qu’il a accumulés en tant que demande de fonctionnalité ? Il devrait les conserver, visibles, parce que ces votes sont la preuve qui a mené à trouver le bug en premier lieu, et cacher cette trace rend la même mauvaise classification plus difficile à repérer la prochaine fois, sur un ticket différent.
Ça peut arriver dans l’autre sens, un bug qui est en fait une demande de fonctionnalité ? Moins souvent, mais oui : « c’est cassé » signifie parfois « ça ne fait pas ce que j’ai supposé que ça ferait », ce qui est une capacité manquante, pas un défaut. La même question, ce qu’elle attendait contre ce qui est documenté, trie aussi dans cette direction.
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.