Déploiement en douceur

L’une des choses amusantes à propos de travailler sur un produit 1.0 est que vous pouvez recommencer avec votre communauté d’utilisateurs. Il est vrai que votre base d’utilisateurs est toujours influencée par d’autres produits et services auxquels ils ont été exposés, mais dans l’ensemble, vous n’avez pas à vous soucier de choses comme la compatibilité descendante ou le recyclage de vos utilisateurs. Cependant, pour la plupart d’entre nous, nous nous efforçons de créer des mises à jour ou de nouvelles versions de produits ou services existants.

Dans le passé, les éditeurs de logiciels pouvaient beaucoup plus facilement s’en tirer en envoyant des mises à jour largement incompatibles et perturbatrices, car même si les utilisateurs se plaignaient, ils n’étaient pas en mesure d’influencer d’autres utilisateurs potentiels dans le monde ou de mener leurs activités ailleurs. Aujourd’hui, avec l’internet omniprésent, si vous constatez une mauvaise version de votre produit (et que vous ne corrigez pas les problèmes rapidement – voir la dernière newsletter sur Rapid Response), vous feriez mieux de vous préparer à une réaction sérieuse de la communauté.

Pour les services Internet grand public à grande échelle, cette préoccupation est encore plus grave. Ces sites doivent tenir compte de l’impact sur la communauté dans tout ce qu’ils disent et font, en commençant par les mises à jour logicielles. J’appelle le processus de déploiement évolutif de manière intelligente et prudente auprès d’une large communauté d’utilisateurs un «déploiement en douceur».

Lorsque je regarde les PRD et les conceptions de nouvelles versions de logiciels, je suis toujours surpris de voir combien de changements sont soit inutilement incompatibles au mieux, soit gratuits au pire. Même si la base d’utilisateurs réclame une nouvelle fonctionnalité, cela ne signifie pas qu’ils attendent avec impatience de connaître les changements réels. En général, il est prudent de supposer que les utilisateurs n’aiment pas le changement, et tout ce que vous pouvez faire pour minimiser l’impact des changements sur eux sera grandement apprécié. Jetez donc un œil neuf aux modifications que vous prévoyez de déployer et demandez-vous si vous pouvez faire quelque chose pour minimiser les perturbations que vos mises à jour entraîneront.

Il est également essentiel de réaliser que tous les utilisateurs ne fonctionnent pas sur le même calendrier. Même en supposant que votre communauté attend avec impatience un changement, il se peut qu’ils ne puissent pas tous prendre le temps d’apprendre la nouvelle version en même temps. Pour de nombreux produits, en particulier les services Web, vous devrez fournir une fenêtre de temps où les gens pourront accéder à la fois à la nouvelle et à l’ancienne version.
Afin de minimiser les perturbations causées par le changement, il existe plusieurs techniques qui peuvent être utiles pour déployer les changements en douceur.

Tout d’abord, faites tout ce que vous pouvez pour communiquer les changements à l’avance, par le biais de véhicules tels que des newsletters, des formations sur site et des tutoriels. Mais rappelez-vous que beaucoup de gens n’auront pas le temps ou l’envie de lire ce que vous écrivez, donc cette technique ne peut vous emmener jusqu’ici.

Deuxièmement, s’il y a des questions sur le bon fonctionnement de la nouvelle version de votre produit, soit en raison de problèmes de fiabilité, soit d’évolutivité, soit de performances, vous devez redoubler d’efforts en matière d’assurance qualité pour essayer de vous assurer que vous n’aurez pas à revenir en arrière. vos mises à jour, ce qui aggrave considérablement l’angoisse de la communauté.

Troisièmement, si le changement est important, il est important de contenir le risque en poursuivant une certaine forme de déploiement en douceur – comme un déploiement parallèle, progressif ou incrémentiel.

Vous pouvez le faire en déployant une version parallèle de votre produit et en invitant les utilisateurs à «s’inscrire» et à essayer la nouvelle version lorsqu’ils en ont le temps. Permettez à ceux qui essaient d’utiliser la nouvelle version d’en faire leur défaut s’ils l’aiment. Une fois que vous êtes certain que la nouvelle version fonctionne bien et que la majorité de votre communauté s’est convertie à son utilisation, vous pouvez en faire la valeur par défaut et permettre aux clients de se «désinscrire» et de continuer à utiliser l’ancienne version pendant une période de temps s’ils n’ont pas le temps d’apprendre les changements immédiatement. Donnez à ces personnes un préavis suffisant pour savoir quand le support de l’ancienne version sera interrompu. Pour un client ou un service important avec une grande communauté, attendez-vous à ce que ce processus prenne plusieurs mois. Attendez-vous également à un peu de chaleur de la part de vos organisations d’ingénierie et d’exploitation du site car il n’est pas facile de prendre en charge des versions parallèles.

Une autre approche douce de déploiement consiste à déployer au niveau régional – essayez la nouvelle version dans une zone limitée du pays ou du monde, puis développez. Ou vous pouvez déployer les changements de manière incrémentielle – introduisez les changements dans les morceaux de taille de bouchée au fil du temps.

Quelle que soit votre décision, la clé est d’être aussi sensible que possible aux perturbations que vos modifications vont provoquer. Donnez aux gens l’occasion d’apprendre les différences quand ils en ont le temps et essayez de minimiser l’impact de tout problème ou problème que vos changements pourraient causer.