Prioriser les demandes de fonctionnalités qui s'accumulent

Suivre les demandes de fonctionnalités résout où elles vivent. Ça ne résout pas laquelle sort en premier, et cette deuxième question est celle sur laquelle les équipes restent vraiment coincées. Un backlog de trois cents demandes, regroupées et étiquetées, a quand même besoin d’une règle de décision, parce que “construis la chose la plus demandée” ne fonctionne que jusqu’à ce que deux demandes soient proches et qu’une troisième ait une défenseuse bruyante, ce qui arrive la plupart des semaines. Les cadres ci-dessous ne sont pas des réponses concurrentes à la même question. Chacun convient à un type différent de demande, et en utiliser un seul pour toutes est généralement la vraie erreur.

Qu’est-ce qui rend prioriser les demandes de fonctionnalités différent de prioriser une roadmap ?

Une décision de roadmap part de la stratégie et demande quoi construire. Une décision sur une demande de fonctionnalité part d’une demande qui existe déjà et se demande s’il faut agir dessus, et les deux tirent dans des directions différentes assez souvent pour qu’une demande ait une forte demande et reste quand même mauvaise à construire, ou ait une faible demande et vaille quand même la peine parce qu’elle débloque un compte stratégique. Traiter chaque demande comme un vote de roadmap saute cette vérification.

Qu’est-ce que RICE, et ça marche pour les demandes de fonctionnalités ?

RICE note une idée sur la portée, l’impact, la confiance et l’effort, puis divise les trois premiers par le quatrième pour obtenir un chiffre comparable. C’était conçu pour des idées de roadmap auxquelles une équipe croit déjà, où la partie difficile est de comparer des paris différents entre eux. Les demandes de fonctionnalités arrivent déjà avec un chiffre de portée, le compte de gens qui ont demandé, ce qui est plus concret que la portée qu’a habituellement une idée de roadmap toute fraîche. Là où RICE est mis sous tension par une demande, c’est la confiance et l’impact : une équipe peut être sûre qu’une demande est réelle et n’avoir quand même aucune base pour savoir combien elle bougera une métrique, parce que “l’impact” pour une demande qui a déjà un nom et une trace d’utilisateurs réels est un type d’estimation différent de l’impact pour une idée que personne en dehors de la salle n’a encore vue.

Utilise RICE pour les demandes sérieusement envisagées et pas encore tranchées. Ne l’applique pas à chaque demande entrante ; l’effort de notation ne se justifie que sur celles assez proches pour avoir besoin d’un départage.

Faut-il pondérer par le revenu, ou par qui a demandé ?

Par qui a demandé, mais pas seulement par le revenu. Un compte proche du renouvellement, un compte qui a déjà fait une escalade, et un compte dont la demande débloque une affaire en cours portent une urgence qu’un chiffre de revenu plat ne capture pas à lui seul, et une demande venant d’un essai gratuit peut quand même compter si elle bloque une décision qui devient bientôt du revenu. La pondération par revenu est la plus facile à calculer de toutes celles-ci, et pour cette raison même la plus facile à surestimer : elle retire correctement le bruit des comptes sans véritable enjeu, et elle peut tout aussi facilement déclasser une demande qui amènerait un compte bien plus grand encore dans le pipeline.

Quel rôle jouent vraiment les votes ?

Un signal bon marché et continu pour des demandes qui existent déjà, et une mauvaise façon de découvrir quelles demandes devraient exister en premier lieu. Un compte de votes n’atteint que les utilisateurs qui ont déjà trouvé la demande et jugé qu’elle méritait un clic, ce qui veut dire que le total des votes d’une roadmap publique reflète autant la visibilité que la demande : une ancienne demande près du haut de la liste continue d’accumuler des votes en partie parce qu’elle est facile à trouver, et une demande plus récente et tout aussi réelle part de zéro. L’article sur la roadmap publique plaide pour laisser complètement les votes hors de la roadmap. Traite les votes comme un signal qui a besoin d’être regroupé et pondéré par récence, pas comme un classement à construire dans l’ordre. Tickets support vs. demandes couvre l’autre angle mort des comptes de votes : un vrai manque peut générer presque aucun vote si les utilisatrices qui y sont confrontées ne trouvent jamais le tableau, tout en apparaissant bruyamment dans le support.

Quand la cliente la plus bruyante gagne-t-elle, et est-ce un problème ?

Parfois, et ce n’est un problème que si personne ne le remarque. Une cliente qui fait souvent des escalades, écrit des tickets détaillés ou a une ligne directe avec quelqu’un de l’équipe verra ses demandes examinées plus vite qu’une cliente plus discrète avec une demande tout aussi valable, et un processus de priorisation qui ne le vérifie jamais favorisera systématiquement qui insiste le plus, pas qui a le dossier le plus solide. Les clientes bruyantes ne sont pas le problème à corriger ; leurs demandes sont souvent réellement importantes. La correction est une habitude : passer en revue le backlog par source périodiquement et vérifier si la même poignée de comptes explique la majorité de ce qui a été livré récemment, et se demander si ça correspond à où se trouve vraiment la demande.

Comment transformer une décision de priorisation en réponse ?

Chaque décision ici produit des gagnantes et des perdantes, et les deux méritent une réponse qui nomme le raisonnement réel, pas juste un changement de statut sans explication. Comment refuser une demande de fonctionnalité couvre quoi dire à une demande qui a perdu, d’une façon qui garde la relation intacte plutôt que de sonner comme un refus générique. Le travail de regroupement et d’étiquetage qui rend tout ça possible en premier lieu est couvert dans suivi des demandes de fonctionnalités ; la priorisation ne fonctionne que sur des demandes déjà enregistrées et regroupées assez bien pour être comparées.

FAQ

Quel est le meilleur cadre pour prioriser les demandes de fonctionnalités ? Aucun seul. Utilise les comptes bruts pour trouver le signal le plus bruyant, RICE pour comparer une courte liste de candidates sérieuses, et une vérification du revenu ou du compte pour repérer les cas où une demande silencieuse d’un compte stratégique pèse plus qu’un groupe plus bruyant mais moins important.

Les demandes de fonctionnalités devraient-elles être priorisées comme les idées de roadmap ? Non. Les idées de roadmap partent de la stratégie ; les demandes de fonctionnalités partent d’une demande qui existe déjà. Les noter ensemble fait qu’un pari stratégique bien argumenté mais avec peu de demande existante perd constamment face à une demande qui a simplement plus de gens qui l’ont formulée.

Les votes sur une roadmap publique reflètent-ils fidèlement la demande ? Seulement parmi les gens qui ont déjà trouvé la demande. Les demandes plus anciennes et plus visibles accumulent des votes plus vite, indépendamment de la demande réelle derrière une plus récente, donc traite les totaux de votes comme un signal, regroupé et pondéré par récence, pas comme un classement à construire dans l’ordre.

À quelle fréquence les priorités des demandes de fonctionnalités devraient-elles être réévaluées ? Selon un cycle fixe, pas seulement quand quelqu’un fait une escalade. Une passe mensuelle ou trimestrielle qui regroupe les demandes et revérifie la pondération détecte les dérives, comme une poignée de comptes qui domine ce qui est livré, qu’un processus purement réactif ne fait jamais apparaître de lui-même.

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