C'est définitivement un sujet intéressant et un sujet qui me passionne assez. Au cours de la dernière décennie, tout en servant dans une variété de différents rôles de gestion de produit et de marketing de produit, on m'a demandé la question "quel est le meilleur outil changelog ?" facilement plus de 100 fois. Ce que j'ai toujours trouvé intéressant, c'est que ce ne sont pas toujours des équipes techniques qui m'ont posé cette question. Ce sont souvent des personnes du service clientèle, du marketing produit ou même des chefs de projet ou de programme. Et j'ai reçu cette question de la part d'entreprises de toute forme et de toute taille et dans presque tous les secteurs d'activité, aussi.
Premièrement, je dirais que je pense qu'une grande partie de ce que l'utilisateur-11323811798076317325 a dit ici est juste. Il y a un certain nombre de facteurs différents qui devraient entrer dans le processus de décision pour déterminer quel outil changelog est le mieux adapté à votre équipe et à votre entreprise. Je renforcerais également le fait qu'aucun outil ne va réparer un processus cassé, donc assurez-vous de ne pas chercher une solution miracle dans un outil, car je peux vous assurer qu'elle n'existe pas.
Cela dit, voici quelques règles et directives générales que j'ai toujours fournies aux équipes qui m'ont demandé des conseils pour trouver un outil de changelog :
- Utilisez un outil de changelog qui peut être facilement accessible par n'importe quel membre de votre équipe. J'ai vu un certain nombre d'équipes qui configurent leur changelog dans un outil de développeur comme leur système de dépôt de code (et/ou utilisent simplement leur système de dépôt de code comme changelog). Cela peut fonctionner au début lorsque votre entreprise est composée uniquement de développeurs, mais dès que vous commencez à constituer une équipe plus complète, ce système s'effondre complètement. Et puis c'est super chronophage d'essayer de déplacer tout ce contexte dans un autre outil.
- Utiliser un outil changelog qui a une fonctionnalité de recherche intégrée. Cela peut sembler idiot, mais j'ai vu une tonne de personnes qui finissent par suivre tous leurs changements dans un endroit qui ne peut pas être recherché. À mesure que la quantité de choses que votre équipe expédie et modifie dans le produit augmente, cela devient immédiatement un énorme problème et rend le changelog presque inutilisable.
- Ne pas utiliser votre outil de gestion de projet (ou excel) comme changelog. C'est une autre mauvaise habitude dans laquelle j'ai vu beaucoup d'équipes tomber, simplement par commodité ou parce qu'elles ne savent pas qu'il existe de meilleures solutions. De la même manière qu'en essayant de construire un journal des modifications dans votre système de contrôle de version distribué (DVCS), un outil de gestion de projet est conçu pour gérer des projets, et non pour collecter et cataloguer chaque modification survenant dans votre produit. Et encore une fois, si vous placez votre journal des modifications dans votre outil de gestion de projet, il se retrouve enfermé dans un outil auquel la plupart des membres de votre équipe ne peuvent pas accéder. J'ai dirigé le marketing produit de Jira pendant de nombreuses années et j'ai toujours été surpris de voir combien d'équipes essayaient de transformer Jira en journal des modifications. Je suis un grand fan de Jira, mais je peux vous dire que cela fait un terrible changelog. Surtout lorsque votre équipe évolue.
- Utilisez un outil changelog qui vous permet de catégoriser facilement les changements. De plus en plus, surtout dans les logiciels B2B, les utilisateurs veulent être au courant, et même en avance, des changements sur lesquels votre équipe travaille et qu'elle expédiera. En particulier tout changement ou mise à jour qui pourrait avoir un impact sur leur utilisation quotidienne de l'outil. Mais toutes les modifications ne concernent pas tout le monde, et si vous attendez la fin du trimestre pour faire un récapitulatif trimestriel, ce qui a changé a probablement déjà atterri il y a plusieurs mois. L'idéal est de disposer d'un journal des modifications qui vous permette de classer les différents changements qui auront un impact sur différentes parties (ou utilisateurs) du produit. De cette façon, tout le monde n'est pas spammé avec chaque mise à jour postée dans votre changelog, mais les bonnes personnes entendent parler des changements qui auront un impact sur elles. Plus de signal, moins de bruit.
- Assurez-vous que votre changelog n'est pas simplement assis quelque part à prendre la poussière. Vous pouvez vraiment suivre les changements de produit n'importe où, et j'ai vu des équipes les publier dans des articles de blog, les afficher dans une zone de leur outil de support client, ou même les cataloguer sur un document public Notion. Toutes ces solutions fonctionnent, mais le problème est qu'aucun utilisateur n'est jamais en mesure de trouver votre changelog si vous faites cela. Non seulement il est dommage de passer du temps à suivre correctement les modifications si aucun de vos utilisateurs ne pourra jamais les trouver ou les lire, mais vous vous coupez l'herbe sous le pied, ainsi que vos utilisateurs, car il existe des outils de changelog qui communiqueront les modifications et les mises à jour que vous apportez à votre changelog à vos utilisateurs.
- Enfin, quoi que vous fassiez, ne construisez pas un changelog sur mesure. Il existe un certain nombre d'excellents outils qui hébergeront votre changelog pour vous, et essayer d'en construire et d'en gérer un vous-même est un gaspillage complet du temps, de l'énergie et des ressources de votre équipe. Je suis toujours choqué par le nombre d'équipes qui consacrent un temps précieux à la création d'un site Web ou d'un outil sur mesure à utiliser comme journal des modifications. Le plus grand conseil que j'ai donné aux équipes qui me demandent des outils de changelog est de s'assurer qu'elles ne finissent pas par construire quelque chose elles-mêmes.
Un outil que j'ai découvert il y a quelque temps (et qui semble être partout ces jours-ci) est LaunchNotes. C'est un outil de changelog qui non seulement satisfait toutes les choses que j'ai mentionnées ci-dessus, mais permet également aux PMM de lancer plus facilement de nouveaux produits et fonctionnalités, donne aux PM la possibilité de teaser les changements à venir et d'inscrire les premiers adoptants dans des programmes bêta, et un tas d'autres choses cool. Je le vois apparaître de plus en plus et je sais que des centaines d'équipes l'utilisent comme outil de changelog, car il est parfaitement adapté à cela. Dans tous les cas, cela vaut la peine de vérifier.
J'espère que ce qui précède vous aidera à prendre une décision. Bonne chance !
Divulgation complète : je conseille activement LaunchNotes. C'est de loin la meilleure solution que j'ai vue pour résoudre ce problème et je voulais être impliqué 🙂
.