Notes de version et point pour les parties prenantes, une même fonctionnalité
6 min de lecture
La façon la plus rapide d’annoncer une fonctionnalité livrée est de copier le changelog d’ingénierie dans un e-mail et de l’envoyer à tout le monde. Cela fait partir l’information, mais cela signifie aussi que les utilisateurs reçoivent des détails d’implémentation dont ils n’ont pas besoin et que la direction n’obtient pas le cadrage business qu’elle veut vraiment. Un PM qui vient de livrer une fonctionnalité d’export en masse peut envoyer le même paragraphe, décrivant des points d’accès d’API et des limites de débit, aux notes de version destinées aux clients comme au canal Slack de la direction, et le voir mal passer aux deux endroits.
Attention
Un seul résumé technique envoyé à tous les publics n’est pas de la communication, c’est de la distribution. Un changelog écrit pour des ingénieurs passe pour du bruit auprès des utilisateurs et pour un hors-sujet auprès de la direction.
La fonctionnalité a été livrée une fois. Ce qu’elle signifie dépend entièrement de celui qui en lit la description.
Pourquoi un seul résumé dessert chaque lecteur
Un changelog est écrit pour être précis sur ce qui a changé techniquement. Cette précision est exactement ce dont un utilisateur n’a pas besoin et ce que la direction veut voir traduit en résultats, pas en implémentation. Un utilisateur qui lit « ajout de la prise en charge de la pagination au point d’accès d’export » n’a aucune idée que cela veut dire qu’il peut désormais exporter plus de 10 000 lignes d’un coup, et une direction qui lit la même phrase n’a aucune idée de savoir s’il s’agit d’un nettoyage technique mineur ou de la correction de la principale plainte client du trimestre.
Imagine une fonctionnalité d’export en masse livrée après des semaines de travail d’ingénierie pour supprimer une limite stricte de 10 000 lignes qui générait des tickets de support depuis des mois. L’entrée du changelog, exacte et précise, décrit le changement technique en termes de pagination et d’optimisation des requêtes. Ni l’utilisateur, qui veut juste savoir qu’il peut maintenant exporter tout son jeu de données, ni la direction, qui veut savoir que cela clôt une source récurrente de risque d’attrition, n’obtient ce dont il a besoin de cette même phrase.
Avant : copier le changelog d’ingénierie, le coller dans un e-mail, l’envoyer aux utilisateurs comme à la direction.
Après : donner à Claude le résumé technique une seule fois et demander une version remaniée pour chaque public : ce qui a changé et pourquoi cela compte pour eux en particulier.
Une méthode pour remanier une même information pour deux publics
- 1
Pars du vrai changelog, pas d’un souvenir de la fonctionnalité
Le changelog contient la portée réelle de ce qui a été livré. Travailler de mémoire risque soit de surestimer ce qui est nouveau, soit d’omettre un détail qui compte pour l’un des publics.
- 2
Nomme ce qui compte vraiment pour chaque public
Dis-le explicitement : les utilisateurs veulent savoir ce qui a changé pour eux et comment s’en servir ; la direction veut savoir ce que cela fait bouger, adoption, revenus, une métrique du document de feuille de route. Faute de le nommer, les deux versions glissent vers le cadrage technique.
- 3
Donne une vraie longueur à chaque version
Un nombre précis de phrases ou de mots force la compression vers ce qui compte le plus pour ce public, au lieu d’une version à peine raccourcie de la même explication.
- 4
Vérifie qu’aucune version ne surestime ce qui a été livré
Compare les deux résultats au changelog réel. Une note de version destinée aux utilisateurs en particulier peut dériver vers un langage marketing qui promet plus que ce qui est réellement en ligne.
Transforme ce changelog d’ingénierie de notre nouvelle fonctionnalité d’export en masse en une note de version de 3 phrases pour les utilisateurs et un point d’étape de 100 mots pour la direction.
”Si la fonctionnalité est directement liée à une métrique que la direction suit, volume de tickets de support, un risque d’attrition signalé lors d’une revue de feuille de route précédente, il vaut la peine de nommer ce lien explicitement pour que la version de la direction s’ouvre sur le résultat au lieu de l’enterrer.
Cette fonctionnalité répond précisément aux plaintes sur la limite d’export que nous avions signalées comme risque d’attrition lors de la revue de feuille de route du trimestre dernier. Assure-toi que la version pour la direction s’ouvre sur ce lien, et pas seulement sur une description générale de la fonctionnalité.
”
Dans Claude Tutorial
Remanier une information pour ce qui compte vraiment à chaque lecteur est transposable.
Adapter la même information de fond aux vraies préoccupations de lecteurs différents, au lieu d’envoyer une seule version à tous, vaut bien au-delà des notes de version. L’appli propose une leçon complète à ce sujet, avec une pratique qui s’applique à toute communication adressée à plus d’un public.
Quand la fonctionnalité n’a pas été entièrement livrée
Toutes les annonces ne sont pas un lancement net. Si une fonctionnalité a été livrée partiellement, derrière un indicateur, ou à un groupe limité, les deux versions doivent le dire honnêtement plutôt que de laisser croire à une disponibilité générale. Une note de version qui surestime la disponibilité engendre un coût précis et prévisible : des utilisateurs qui ne trouvent pas la fonctionnalité et ouvrent un ticket pour demander où elle est passée.
Astuce
Dis explicitement à Claude ce qui est réellement en ligne et ce qui est encore en cours de déploiement, et demande que les deux versions le reflètent avec exactitude. Une note de version qui promet trop sur la disponibilité crée plus de tickets de support qu’elle n’en évite.
Cette fonctionnalité est en ligne pour 20 % des utilisateurs derrière un indicateur, pas encore disponible pour tous. Réécris la note de version et le point pour les parties prenantes pour refléter cela avec exactitude, sans minimiser le fait que c’est un vrai progrès.
”Il vaut aussi la peine de préparer une courte note pour le support ou la réussite client avant un déploiement progressif comme celui-ci, afin qu’ils aient une réponse exacte prête quand un utilisateur qui n’a pas l’indicateur les interroge sur une fonctionnalité qu’il a vue mentionnée ailleurs.
Rédige une courte note interne pour l’équipe de support expliquant le déploiement progressif, afin qu’elle ait une réponse exacte prête si un utilisateur sans l’indicateur l’interroge sur cette fonctionnalité.
”Pour aller plus loin
- Rédiger un document de feuille de route qui explique les arbitrages : là où cette fonctionnalité livrée a commencé, comme élément de feuille de route classé et justifié.
- Transformer des tickets de support en thèmes priorisés : boucler la boucle avec les utilisateurs dont les tickets ont d’abord fait apparaître le besoin de cette fonctionnalité.
- Affûter un PRD avant de l’envoyer en relecture : la même discipline, tester auprès d’un lecteur qui n’a pas ton contexte, appliquée plus tôt dans la vie de cette fonctionnalité.