Dans les produits qui évoluent en suivant le cycle en V, l’étape de mise en production est confondue avec la mise à jour ou release du produit. Il n’y a aucune ambiguité sur ce point, et c’est assez rassurant de ne pas confronter un produit non fini au client.
En Product Management Agile, et surtout avec la vision CI/CD, une mise en production n’est pas égale à une release (activation des fonctionnalités pour les utilisateurs). Un produit de qualité est régulièrement mis en production, même si certains morceaux ne sont rendu visibles que plus tard. Cela garantit une intégration continue, et non une intégration compliquée après plusieurs mois de travail hors production.
Contrairement aux idées reçues, ce mode de fonctionnement ne concerne pas que le monde du logiciel. Vous avez sans doute déjà acquis des produits qui pocédaient des boutons ou des ports inutilisés jusqu’à la sortie d’une nouvelle fonctionnalité autour du produit. J’ai eu l’exemple récent autour d’une tablette dont le clavier est sorti deux années après son achat.
Il est nécessaire de distinguer quatre états : Mise en Production, Roll-out, A/B Test et Release.
Mise en Production (MeP)
La Mise en Production consiste à déployer en environement de production les nouveautés. Elle est régulière et suit le rythme des sprints dans le monde du logiciel. Toutes les fonctionnalités, même celles non accessibles au client sont intégrées en continu pour garantir un haut niveau de qualité et éviter les problématiques d’intégration (de Merges notamment) trop tardives.
La Mise en Production est exprimée du point de vue du business (l’entreprise réalisatrice de la mise à jour).
Roll-Out
Le Roll-Out consiste à sélectionner une catégorie de population (clients/utilisateurs), et d’activer une feature (fonctionalité) pour cette population. Le roll-out est à la fois technique dans le sens où il faut implémenter les outils nécessaires à l’activation partielle, mais également marketing puisqu’il est nécessaire de communiquer de façon ciblée.
A/B Test
Le A/B Test consiste à mettre à disposition de deux groupes de population différents, deux versions d’une même feature pendant une durée donnée. L’approche utilisateur ressemble à celle du roll-out dans le sens où pour l’utilisateur, il ne s’agit pas d’un test mais d’une évolution, jusqu’à ce qu’il accède à la version finalement choisie de la feature si celle-ci aboutit. Il arrive en effet qu’à l’issue du A/B test, la feature soit tout simplement arrêtée.
Release
La Release à l’état pour lequel tous les utilisateurs ciblés par une feature (fonctionalité) peuvent y accéder. Elle conclut le ou les Roll-Out. Lorsqu’un unique Roll-Out a lieu en ciblant directement la cible d’une feature, alors il est fréquent de nommer tout le processus Release et d’oublier le mot « Roll-Out ». Dans tous les cas, il est important de ne pas oublier les actions de communication interne et externe associées.
La Release est exprimée du point de vue du client ou du consommateur (celui qui bénéficie de la mise à jour).
Les niveaux de Release
Dans tous les cas, l’objectif ultime est de proposer de nouvelles releases aux clients pour constamment faire croitre la valeur du produit. D’après Martina Lauchengco, dans son ouvrage Loved (p101), les Releases peuvent être organisées par niveau d’impact client. Elle propose le tableau suivant :
Comment organiser le Product Management ?
Nous découpons le Product Management en blocs qui représentent chacun des cycles de travaux asynchrones, avec des aller-retours nombreux : Customers & Users Management, Business & Shareholders Management, Team Empowerment & Continuous Improvement, Vision & Strategy, Discovery, Delivery, Operations & Distribution, Launch & Updates, et End of Life. L’ensemble de ces blocs permet d’aboutir à des produits qui émergent et évoluent avec le temps, et qui peuvent déboucher sur des écosystèmes de produits…
