.svg)
Chez Driftrock, nous sommes une petite entreprise qui est passée de 8 à 18 personnes au cours des 9 derniers mois. Ce n’est pas énorme, mais cela a tout de même remis en question certaines de nos méthodes de communication existantes. L’une d’entre elles concernait la manière dont nous communiquions sur les nouvelles fonctionnalités récemment mises en ligne : à un moment donné, nous avons cessé de le faire.
Chut ! On sort un nouveau logiciel
Auparavant, lorsque nous déployions une mise à jour sur l’une de nos applications, nous n’en informions personne, sauf si cela permettait de résoudre un problème spécifique rencontré par un client. Du coup, nous ne recueillions pas beaucoup de retours sur les nouvelles fonctionnalités, et le reste de l’entreprise n’avait pratiquement aucune visibilité sur les progrès et les activités de l’équipe. Étant donné que notre logiciel est de plus en plus utilisé en interne, cela nous semblait être une véritable occasion manquée.
Entrer dans Release Crab
Nous disposons désormais d'un canal Slack dédié pour annoncer en interne la sortie de nouvelles fonctionnalités, les corrections de bugs et d'autres modifications. C'est généralement un développeur qui se charge de l'annonce après avoir déployé ses modifications en production, car c'est lui qui connaît le mieux le contexte. Nous adoptons toutefois une approche pragmatique et n'annonçons pas chaque petite modification ; par exemple, nous pouvons attendre d'avoir terminé une série de déploiements rapides. Cependant, nous accordons une grande importance aux retours d'expérience, c'est pourquoi nous annonçons régulièrement les mises à jour.
Voici quelques exemples de modifications qui seront bientôt mises en ligne pour Create (une application permettant de créer rapidement des publicités sur Facebook) :
(Remarquez l'émoji du crabe : il est désormais indissociable des annonces de sortie)
Cela peut sembler être un ajout simple et évident à un déploiement en production, mais son impact a été surprenant. Voici quelques-unes des améliorations qu’il a apportées :
- Une boucle de rétroaction plus étroite: une communication accrue entre l'équipe de développement produit (nous) et les autres équipes de Driftrock : le marketing de performance (utilisateurs internes), les ventes et les solutions clients.
- Responsabilité et appropriation accrues – nous pourrions automatiser la rédaction de ces notes de mise à jour, mais la touche personnelle apporte un sentiment de responsabilité et offre aux lecteurs un interlocuteur à qui adresser leurs commentaires. L'auteur doit donc savoir ce qui est mis en ligne et (si nécessaire) ce qui se passe au sein de l'équipe. Il est indispensable de recueillir ces informations pour aider l'auteur à présenter l'annonce de manière simple et concise.
- Cela permet de limiter la taille des déploiements – de la même manière, ce léger surcroît de travail manuel pour l'auteur nous donne une raison supplémentaire de limiter la taille des lots de déploiement et de veiller à publier les mises à jour rapidement et fréquemment.
Prochaines sorties
Nous sommes encore en train de nous familiariser avec ce processus, qui va certainement évoluer. Parmi les premières idées à développer, on peut citer l'automatisation des notes de mise à jour à partir des messages de commit, ainsi que la recherche de moyens pour proposer à nos clients une version similaire, voire la rendre publique.
