Suivre les demandes de fonctionnalités sans les perdre

Le suivi des demandes de fonctionnalités échoue presque toujours d’une de deux façons. Soit les demandes n’ont nulle part où aller, et vivent dans des boîtes mail et des fils Slack où elles sont oubliées une par une, soit elles ont un endroit où aller que personne ne revisite, et sont oubliées collectivement. Un système qui fonctionne doit résister aux deux échecs : il faut un seul endroit où chaque demande atterrit, et une raison de rouvrir cet endroit le mois prochain.

D’où viennent vraiment les demandes de fonctionnalités ?

De plus de canaux que la plupart des systèmes de suivi ne le prévoient. Un ticket de support qui inclut un « ce serait bien si ». Un commentaire sur une roadmap publique. Un appel commercial où une prospecte nomme la seule chose qui bloque la vente. Un widget dans le produit. Chaque canal a sa propre responsable et ses propres outils, et c’est justement pour ça que les demandes se dispersent : la file de tickets du support et le backlog de l’équipe produit sont rarement le même système, et une demande qui n’atteint qu’un des deux n’a, en pratique, atteint qu’un seul département.

La solution n’est pas un formulaire d’entrée unique pour chaque canal, que personne n’adopte. C’est une destination où chaque canal se déverse, même si le routage se résume d’abord à cinq minutes de copier-coller par jour jusqu’à ce que ce soit automatisé.

Qu’est-ce qui casse vraiment le suivi des demandes ?

Presque toujours deux choses. La première est une destination manquante : les demandes obtiennent une réponse dans le canal où elles sont arrivées et ne sont jamais enregistrées durablement nulle part, si bien que la même demande venant de trois clients différents ressemble à trois réponses isolées sans lien plutôt qu’à un seul signal. La seconde, plus fréquente, est une destination qui se remplit et cesse d’être lue. Un tableur de 400 lignes sans filtrage n’est plus un système de suivi ; c’est une archive qui se trouve être modifiable.

Le second échec est le plus dangereux, parce qu’il donne l’impression que le suivi fonctionne. Les demandes sont enregistrées. Rien ne semble cassé jusqu’à ce que quelqu’un demande « combien de personnes ont demandé X » et que la réponse honnête soit « il faudrait lire les 400 lignes pour le savoir ».

Que devrait vraiment enregistrer une demande de fonctionnalité ?

Assez pour répondre à trois questions plus tard sans relire le message d’origine : ce qui a été demandé, si possible avec les mots exacts de la demandeuse ; qui a demandé, et comment la contacter si la réponse finit par être « on l’a construit » ; et ce qu’il faudrait pour savoir si c’est une demande courante ou un cas isolé. Une citation exacte vaut plus qu’une paraphrase, parce qu’une paraphrase écrite par qui a trié la demande porte déjà sa propre lecture, et c’est justement cette lecture qu’une deuxième personne ne peut plus vérifier six mois plus tard.

Quelles étiquettes valent la peine ?

Deux, et elles répondent à des questions différentes. Une étiquette de type distingue une demande de fonctionnalité d’un rapport de bug, parce que les deux ont besoin de responsables et de délais différents, et les mélanger dans une seule file laisse les plaintes les plus bruyantes passer devant les demandes. Une étiquette de priorité, limitée à un petit ensemble comme low, medium et high, distingue « bloque quelqu’un dans l’usage du produit » de « ce serait sympa », parce que les deux méritent des délais de réponse très différents et qu’aucune ne devrait hériter du rythme de l’autre. Bien mettre l’étiquette de type suppose que la demande est ce qu’elle prétend être ; quand une demande de fonctionnalité est en fait un bug couvre le cas où les mots mêmes d’une cliente pointent cette étiquette dans la mauvaise direction.

Le triage automatisé peut appliquer les deux dès que la demande arrive. Chez changeloop, une soumission via le widget reçoit l’étiquette feature-request ou bug et une étiquette priority:low|medium|high dans la même passe, plus un tag from-widget pour que la source soit visible sans ouvrir l’élément. Cela suffit pour filtrer le backlog en une minute plutôt qu’un après-midi : montre-moi chaque demande de fonctionnalité haute priorité venue du widget ce mois-ci.

Une troisième étiquette vaut la peine dès qu’il existe une roadmap publique : un statut que la demandeuse peut vérifier elle-même. Roadmap publique couvre en entier les statuts planned, building et shipped ; en bref, cette étiquette transforme une file privée en quelque chose que la demandeuse peut consulter sans redemander.

Comment décide-t-on ce qu’il faut construire ensuite ?

Regrouper avant de compter. Dix demandes formulées différemment pour la même capacité sous-jacente se lisent comme dix lignes éparpillées dans un tableur, et comme un signal fort une fois regroupées, et ce regroupement est généralement l’étape manquante, pas le comptage. Un compte brut sans regroupement tend à récompenser la fonctionnalité au nom le plus accrocheur, pas celle qui a la plus forte demande réelle derrière elle.

Pondérer selon qui demande, pas seulement combien demandent. Une demande venant d’un compte proche du renouvellement porte une urgence différente de la même demande venant d’un essai gratuit, et un système de suivi qui jette ce contexte au profit d’un chiffre brut optimise pour le nombre le plus facile à calculer, pas le plus utile.

Chaque décision ici produit aussi des demandes qui perdent, et elles méritent une réponse aussi ; comment refuser une demande de fonctionnalité couvre quoi dire à celles dont la demande n’a pas été retenue. Regrouper et pondérer n’est que la moitié de “quoi construire ensuite” ; prioriser les demandes de fonctionnalités couvre les vrais cadres, RICE, la pondération par revenu et les comptes bruts, et où chacun se casse.

Comment boucler la boucle une fois qu’une fonctionnalité est livrée ?

C’est l’étape que les systèmes de suivi sautent le plus souvent, et celle que les demandeuses remarquent vraiment. Boucler la boucle de feedback avec le client couvre le mécanisme en entier ; ce qui revient ici : boucler la boucle ne fonctionne que si la demande d’origine est restée liée à la personne qui l’a faite. Un modèle de demande de fonctionnalité construit à partir d’une issue GitHub, avec l’identité de la demandeuse attachée à l’issue plutôt qu’enterrée dans un commentaire, est ce qui rend possible une notification automatique « livré » plutôt qu’une que quelqu’un doit se rappeler d’envoyer. Modèle de demande de fonctionnalité montre le modèle concret et à quoi sert chaque champ.

FAQ

Quel outil utiliser pour suivre les demandes de fonctionnalités ? Ce que l’équipe consulte déjà quotidiennement bat n’importe quel outil dédié que personne n’ouvre. Un tracker d’issues GitHub fonctionne bien si l’ingénierie vit déjà là ; un tableau léger fonctionne bien si le produit vit là. L’outil compte moins que le fait d’être rouvert.

Comment éviter que les demandes de fonctionnalités se dupliquent ? Regrouper par capacité sous-jacente avant de trier par formulation. Une recherche dans les demandes existantes avant d’en créer une nouvelle intercepte la plupart des doublons ; un regroupement mensuel intercepte le reste. Fusionner les doublons sans perdre la voix originale couvre quoi faire de la formulation une fois le regroupement lui-même fait, pour que la fusion ne rétrécisse pas discrètement la demande à quelle que soit la soumission arrivée en premier.

Chaque demande de fonctionnalité devrait-elle recevoir une réponse ? Chacune devrait recevoir un accusé de réception, même court, mais pas chacune n’a besoin d’une décision immédiate. Un statut visible, comme une étiquette de roadmap que la demandeuse peut vérifier elle-même, remplace la plupart des réponses individuelles qu’une équipe devrait sinon.

Quelle est la différence entre le suivi des demandes et une roadmap publique ? Le suivi est le registre interne de chaque demande, y compris celles qui ne seront jamais livrées. Une roadmap publique est le sous-ensemble auquel une équipe s’engage publiquement, avec un statut que la demandeuse peut voir sans redemander.

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