Fermer la boucle de feedback depuis le changelog

Une boucle de feedback client se ferme quand la personne qui a donné le feedback apprend ce qui en a été fait. Pas quand c’est classé. Pas quand c’est priorisé. Même pas quand c’est livré. Quand on le lui dit. La plupart des équipes réussissent bien les trois premières étapes et pas du tout la dernière, puis se demandent pourquoi les gens qui envoient du feedback arrêtent d’en envoyer.

Cet article traite de cette dernière étape, et d’une affirmation concrète : le changelog est le bon endroit pour fermer la boucle, parce que c’est le seul artefact qui existe déjà exactement au moment où la boucle peut être fermée.

Qu’est-ce qu’une boucle de feedback client ?

Une boucle de feedback client est le chemin d’une utilisatrice qui vous dit quelque chose jusqu’à cette utilisatrice apprenant ce que vous en avez fait. Elle a quatre étapes : collecter le feedback, décider quoi en faire, livrer le résultat, et prévenir la personne qui a demandé. La boucle est ouverte jusqu’à ce que la quatrième étape arrive. Une équipe qui collecte du feedback et livre des corrections mais ne prévient jamais personne a une boîte de réception, pas une boucle.

La quatrième ligne est celle dont traite cet article. Elle casse pour une raison structurelle, pas culturelle : le temps qu’une fonctionnalité soit livrée, la demande qui l’a causée vit dans un système différent de la chose livrée, et ce n’est le travail de personne de les connecter. La boucle commence plus tôt, avec la façon dont la demande est formulée au départ ; comment demander un feedback client couvre les mots et le moment.

Pourquoi les boucles de feedback restent-elles ouvertes ?

Les boucles de feedback restent ouvertes parce que la demande et le changement livré vivent à des endroits différents et que le lien entre les deux est fait à la main, si tant est qu’il le soit. La demande est dans un outil de feedback, une boîte de support ou un tableur. Le changement est dans une pull request. L’annonce est dans un changelog ou un email. Trois systèmes, trois propriétaires, et le lien du troisième vers le premier est une personne qui se souvient, des mois plus tard, qui a demandé.

Il y a une seconde raison. L’étape de prévenir est généralement cadrée comme une tâche marketing (“annoncer la fonctionnalité”) plutôt qu’une tâche de support (“répondre à la personne”). Les annonces vont à tout le monde et n’atteignent personne en particulier. La personne qui a demandé la fonctionnalité en mars lit l’annonce en juin, si elle la lit, comme une actualité, pas comme une réponse. La boucle se ferme seulement si le message lui est adressé.

Pourquoi fermer la boucle depuis le changelog ?

Parce que l’entrée de changelog est le seul artefact qui existe exactement au bon moment, contient exactement les bons mots, et est écrite par exactement la bonne personne. Elle existe quand le changement est en prod et pas avant. Elle dit ce qui a changé dans les termes de la lectrice, ce qui est le message dont la demandeuse a besoin. Et elle est écrite par quelqu’un qui vient de lire la pull request, ce qui est le seul moment où le lien vers la demande originale est encore visible.

Comparez les alternatives. Fermer la boucle depuis l’outil de feedback signifie que l’outil de feedback doit savoir quand la fonctionnalité a été livrée, ce qui signifie que quelqu’un met à jour un statut à la main. La fermer depuis la pull request signifie prévenir la cliente au merge, avant que le changement soit en prod, une promesse rompue avec horodatage dès que le déploiement se retarde. La fermer depuis l’annonce marketing signifie en attendre une, et la plupart des changements livrés n’en ont jamais.

Le changelog se trouve au milieu : après le merge, au moment de la livraison, avec la formulation prête.

Comment se ferme la boucle, étape par étape

Voici le mécanisme qu’on exécute. Il est décrit ici comme une spécification plutôt qu’une visite de produit, parce que chaque étape peut se faire à la main ou avec d’autres outils ; ce qui compte, c’est l’ordre.

1. Le feedback devient une issue dans le repository qui va la corriger. Une soumission de widget est classée comme issue étiquetée sur GitHub (feature-request ou bug, une priorité, et from-widget), avec l’adresse email de la personne qui l’a envoyée tenue hors du corps de l’issue. L’issue vit à côté du code, pour que l’étape trois puisse la trouver. Une issue créée à la main, par exemple depuis une template de demande de fonctionnalité, est hors de ce chemin : l’étape cinq ne la commente pas, alors fermez cette boucle vous-même.
2. La correction référence l’issue. La pull request dit Fixes #142, le propre mot-clé de fermeture de GitHub. Rien de nouveau à apprendre, et c’est la même phrase que les développeuses écrivent déjà.
3. L’entrée de changelog est rédigée à partir de la pull request mergée et porte le lien. Au merge, le brouillon est créé et #142 est lu depuis le corps de la PR et attaché au brouillon. Le lien est créé pendant qu’il est encore bon marché, par une machine, à partir de données déjà là.
4. Une personne relit l’entrée. Formulation, audience, si ça devrait être publié du tout. Un brouillon jeté ne ferme rien, ce qui est correct : un refactor interne qui a par hasard référencé une issue n’est pas une actualité.
5. À l’approbation, la demandeuse est prévenue. Un commentaire est posté sur l’issue qu’est devenu son feedback, “Shipped —” suivi du titre de l’entrée et d’un lien vers l’entrée publiée, et le widget montre à la personne qui l’a envoyé la même entrée livrée. Une fois, jamais deux, et seulement après qu’une personne a publié l’entrée. La même entrée sort via feed et widget vers tous ceux qui n’ont pas demandé.

L’ordre dans l’étape cinq est tout le design. Prévenir la demandeuse au merge serait plus tôt et plus facile, et serait faux à peu près aussi souvent que les déploiements se retardent. Un feature flag casse même cet ordre, parce qu’approuvé et publié peut se produire pendant que la fonctionnalité reste invisible pour le compte de la demandeuse ; feature flags et demandes de fonctionnalités couvre la vérification supplémentaire dont cette étape a besoin dès qu’un flag entre en jeu.

À quoi ressemble une boucle fermée pour la cliente ?

Ça ressemble à une réponse. La cliente a envoyé une demande via un widget, et un jour le widget l’affiche comme livrée, avec un lien vers une entrée qui la décrit dans ses termes ; sur GitHub, l’issue reçoit la même nouvelle sous forme de commentaire. Elle ne s’est pas abonnée à une newsletter, n’a pas vérifié une roadmap, n’a pas cherché dans le changelog. On le lui a dit.

C’est l’expérience qui provoque le prochain morceau de feedback. Les gens envoient du feedback à des produits qui répondent. La page exemples de changelog inclut des entrées d’équipes dont les utilisateurs reviennent visiblement avec des demandes, et le fil commun n’est pas l’outil ; c’est que les entrées se lisent comme des réponses.

Comment mesure-t-on une boucle de feedback ?

Mesurez la fraction des changements livrés qui ont prévenu au moins une demandeuse, et le temps entre la livraison et l’avis. Deux chiffres, tous deux faciles une fois que le lien existe et impossibles avant.

• Taux de fermeture : des entrées de changelog publiées ce mois-ci, combien liaient au moins une demande, et parmi celles-ci, combien ont prévenu la demandeuse. Si le second chiffre est bien plus bas que le premier, les notifications échouent ; si le premier est bas, les demandes ne sont pas référencées depuis les pull requests, et la correction est une phrase dans le template de PR.
• Temps de livraison à avis : combien de temps entre l’entrée qui passe en prod et l’avis à la demandeuse. Avec le mécanisme ci-dessus, c’est des secondes. À la main, c’est typiquement des semaines, ou jamais, et “jamais” est le chiffre qui compte.

Ne mesurez pas la boucle par le volume de feedback collecté. Collecter est l’étape facile, et une équipe qui la mesure va l’optimiser, ce qui produit plus de boucles ouvertes.

Où s’insère la roadmap ?

Une roadmap publique est une façon de fermer la boucle tôt : elle dit à la demandeuse que sa demande a été entendue, avant qu’elle soit livrée. C’est utile, et ça ne remplace pas la dernière étape. “Planifié” est une promesse sur l’avenir ; “Livré” est un fait sur le présent. Exécutez la roadmap publique depuis les mêmes issues, avec un label par colonne, pour que la même demande passe de planifiée à livrée sans être ressaisie nulle part. Le passage à livrée est un changement de label (roadmap:shipped) que personne ne fait à votre place quand l’entrée est approuvée, alors faites-le dans la même relecture.

FAQ

Quelles sont les quatre étapes d’une boucle de feedback client ? Collecter, décider, livrer, prévenir. La boucle est ouverte jusqu’à ce que la quatrième étape arrive. La plupart des cadres ajoutent des étapes d’analyse et de priorisation au milieu ; ce sont des raffinements de “décider”, et aucune d’elles ne ferme rien.

Devrait-on prévenir les clients quand une demande est refusée ? Oui, et c’est le message le plus négligé de la boucle. Un clair “on ne va pas faire ça, et voici pourquoi” met fin à l’attente. Le silence laisse la boucle ouverte pour toujours et la cliente à vérifier.

En quoi fermer la boucle diffère-t-il d’annoncer une fonctionnalité ? Une annonce va à tout le monde. Fermer la boucle est une réponse aux gens qui ont demandé, sur le canal par lequel ils ont demandé. Faites les deux ; ce sont des messages différents pour des lectrices différentes.

Et si la demandeuse n’est pas sur GitHub ? La plupart n’y sont pas, et ce n’est pas grave. Le widget continue de leur montrer le statut de ce qu’elles ont envoyé, y compris l’entrée livrée et son lien, donc elles n’ont besoin de rien d’autre que la page depuis laquelle elles ont écrit. Le commentaire sur l’issue est pour les personnes qui peuvent voir le repository.

Est-ce que cette boucle fonctionne sur GitLab ou Bitbucket au lieu de GitHub ? Le widget et le changelog, oui ; le commentaire automatique de l’étape cinq, pas encore aujourd’hui. Une équipe sur GitLab ou Bitbucket reçoit quand même chaque soumission, la classe quand même comme une issue, et montre quand même à la demandeuse un statut dans le widget, mais refermer cette boucle précise jusque sur l’issue elle-même est une étape à faire à la main tant que cette intégration n’existe pas.

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, Exemples de changelog