Camille
Mettre en production n’est jamais une mince affaire, surtout lorsque celle-ci est conséquente et risque d’impacter grandement l’expérience utilisateur. Dans le cadre de changements majeurs, il est primordial de suivre quelques étapes essentielles, permettant de limiter les risques et de n’impacter ni le business, ni la conversion sur la plateforme. La bonne conduite de ces étapes permettra de rassurer les sponsors, d’envisager des stratégies de roll-back mais aussi de mesurer le succès de la mise en production !
Mettre en production : certes, mais pour quoi faire ?
Avant toute mise en production importante (refonte d’une page, changement dans le tunnel de conversion, nouvelle expérience utilisateur), il est nécessaire d’en établir la vision produit et d’en expliquer les enjeux. Le Product Manager, afin de justifier sa décision de mise en production, peut s’appuyer sur différents constats ou hypothèses produit. Par exemple :
Le rôle du Product Manager sera alors de définir, à travers la rédaction d’une documentation précise, les objectifs de la mise en production, le différentiel entre l’existant et la version future, les nouveaux parcours utilisateurs. Cette vision produit viendra alimenter l’équipe technique et permettra de convaincre les sponsors.
Cette documentation permettra aussi de définir les critères de succès de la mise en production.
Ainsi, le Product Manager pourra formaliser les objectifs qualitatifs de la mise en production.
Par exemple, pour un site de e-commerce : « Permettre aux utilisateurs de retrouver sur la landing page les derniers articles consultés ».
La définition de ces critères de succès permet de structurer les objectifs de la mise en production, mais aussi de donner de la visibilité aux parties prenantes. Par ailleurs, ces critères doivent mettre en exergue le bénéfice utilisateurengendré par la mise en production.
Une fois la vision, les objectifs, les critères de succès et les bénéfices utilisateurs définis, il est désormais possible pour le Product Manager de rentrer davantage dans les détails, et d’orchestrer la mise en production.
Pour ce faire, le Product Manager peut tout d’abord faire un story mapping, permettant de mettre en exergue le nouveau parcours utilisateur et les nouvelles fonctionnalités.
Ces fonctionnalités peuvent ensuite être regroupées sous forme d’EPICs. L’ensemble des étapes du parcours utilisateurs est ensuite découpée en User Stories, intégrées dans chaque EPIC.
Le Product Manager orchestre alors sa roadmap, en veillant à mentionner les dépendances avec d’autres équipes, et en faisant un planning prévisionnel des sprints. Des logiciels tels que Miro permettent de lier ses User Stories écrites dans Jira à sa roadmap. Cela permet de voir le statut des User Stories (ready, dev, done…), mais aussi d’obtenir le détail de chaque fonctionnalité, ainsi que la stratégie technique pour la mettre en place.
Le Product Manager peut aussi rédiger les SPECs de chaque fonctionnalité, en mentionnant le chemin à parcourir pour permettre son implémentation. Afin d’intégrer les détails techniques à ces SPECs, le Product Manager peut s’accompagner du Tech Lead, et indiquer ainsi quelle stratégie technique est à mettre en œuvre pour chaque fonctionnalité (connexion aux APIs, actions enclenchées côté back par l’utilisation d’un CTA…).
Le Product Manager veille aussi à travailler main dans la main avec les QA, afin de définir les critères d’acceptance de chaque fonctionnalité et chaque user story. Cela permet de couvrir l’ensemble des cas de tests, et de s’assurer que la fonctionnalité remplit bien sa fonction. L’établissement d’un cahier de recette permet aussi de s’assurer qu’il n’y a aucun effet de bord, et que la structure reste stable, malgré les nouvelles implémentations. Les QA pourront ainsi travailler avec les équipes techniques pour faire des tests de non-régression.
La stratégie de tests est indissociable de la définition des environnements de déploiement. En concertation avec l’équipe technique et les QA, le Product Manager définit les environnements de développement, permettant de tester en condition semi-réelle les fonctionnalités déployées et de s’assurer que la mise en production se fera sans encombre.
Il est souvent bénéfique d’avoir 2 à 3 environnements de développement, dont un très similaire à l’environnement de production, permettant de simuler dans des conditions quasi-identiques l’impact d’une mise en production sur le reste des fonctionnalités. Par ailleurs, cet environnement quasi-identique peut servir de back-up en cas de problèmes majeurs en production.
Le Product Manager définit alors avec les QA les conditions de passage d’une fonctionnalité d’un environnement à l’autre. Les QA testent d’abord dans le premier environnement, mènent ses tests de non-régression, le Product Manager teste lui aussi les aspects fonctionnels. Chacun donne son aval pour pousser la fonctionnalité dans l’environnement suivant.
Les tests de non-régression sont particulièrement importants dans le dernier environnement, censé être l’équivalent de l’environnement de production.
Une fois l’ensemble de ces tests effectués et validés, la mise en production peut s’effectuer. Pour plus d’assurance, il est possible de tester en production cachée, à travers une URL uniquement accessible au Product Manager et aux QAs dans un premier temps. Puis de déployer progressivement à l’ensemble des utilisateurs, en utilisant un système de double-run, et ce afin de mesurer les premiers résultats de la mise en production, et de voir si elle s’avère concluante.
Afin de mesurer si la mise en production s’avère concluante, le Product Manager définit avec le Data Product Managerles indicateurs de contrôle. Ces indicateurs sont des KPI à suivre, permettant de vérifier que les objectifs de la mise en production sont bien atteints, et que le business n’a pas été impacté négativement.
Le Product Manager et Data Product Manager s’accordent sur une liste de KPI primaires et secondaires.
Les KPI primaires sont les plus prioritaires : ce sont les indicateurs de contrôle, permettant de décider si la mise en production peut être ouverte à 100% des utilisateurs ou non. Les KPI secondaires permettant d’affiner la connaissance du Product Manager de ses utilisateurs : ils donnent des informations précises sur leur comportement, permettant d’envisager les futures mises en production.
Le Product Manager et le Data Product Manager peuvent réunir au sein d’une seule et même documentation :
Cette étape accomplie, le Product Manager, conjointement avec le Data Product Manager, doit s’assurer que la donnée recherchée est bien disponible.
Pour ce faire, il faut s’assurer que le plan de tracking est bien mis en place. Le Product Manager peut alors consulter l’équipe tracking, afin de leur présenter l’ensemble des données à récupérer, et identifier ainsi les tags manquants.
Une stratégie de tracking est alors décidée par l’équipe tracking, conjointement avec le Data Product Manager. Maintenant que les données sont à même d’être récupérées, le déploiement en production peut s’effectuer : l’intérêt de déployer d’abord en production cachée est aussi de s’assurer que le dashboard de données mis en place par le Data Product Manager fonctionne bien et est bien alimenté, et que le plan de tracking est opérationnel.
Afin de réussir une mise en production conséquente, ayant de forts impacts utilisateurs, certains pré-requis sont à respecter :
