3 conseils d’un Product Owner pour réussir le passage d’une phase de build à une phase de run

Résumé de cet article par ChatGPT : 

"Cet article donne des conseils aux Product Owners pour gérer efficacement un projet de développement de logiciel. Les conseils comprennent la définition claire des objectifs du projet, la gestion des priorités et des attentes des parties prenantes, l'implémentation d'une méthodologie Agile, la communication régulière avec les membres de l'équipe et la mesure des résultats. L'article souligne l'importance d'impliquer les membres de l'équipe dans le processus de planification et de développement, et de leur donner la liberté de trouver des solutions créatives aux problèmes. Enfin, l'article encourage les Product Owners à être à l'écoute des feedbacks des utilisateurs finaux et à intégrer leurs commentaires dans le processus de développement."

Après 6 mois passés à construire une plateforme de prêt dans le secteur bancaire, en tant que Product Owner pour SICARA, j’ai dû relever l’exercice périlleux du passage en production.

L’excitation liée à l’arrivée des premiers utilisateurs, le stress de la gestion des premiers bugs, le challenge des premiers commentaires sur votre produit et enfin le plaisir de voir l’impact des features développées.

Le passage en production est un événement primordial, parfois difficile, de la vie d’un produit. J’espère, au travers de ces quelques lignes, vous transmettre mon expérience pour bien anticiper cette étape !

Le build, ou construire des fondations solides

Durant la période de build, le Product Owner mène des interviews et des tests utilisateurs. Il essaye de trouver la recette parfaite pour répondre aux besoins de ses futurs utilisateurs à partir des retours d’une poignée d’entre eux et d’une vision partielle du marché.

Selon les préceptes de la méthodologie Lean, théorisés par Eric Ries dans “Le lean startup”, il est recommandé de sortir son produit au plus vite, sous forme de Minimum Viable Product (MVP), pour se confronter à la réalité du terrain et des utilisateurs. L’objectif étant d’itérer rapidement sur les premières fonctionnalités pour tendre vers le produit qui répond le mieux aux problèmes utilisateurs.

Ce précepte est plus ou moins applicable en fonction du secteur. Dans le secteur bancaire, par exemple, la construction du MVP peut prendre plusieurs mois, car il faut intégrer des sujets complexes de conformité, de gestion des risques, d’assurance etc…

Pour résumer, la phase de build doit permettre de remplir tous les pré-requis indispensables au bon fonctionnement du produit.

Le run, ou courir après la satisfaction des utilisateurs

Après avoir passé des jours, voire des mois à développer et livrer sur des environnements intermédiaires, le moment est venu de livrer en production, de confronter votre travail aux utilisateurs réels.

En tant que Product Owner, l’enjeu est de transformer les retours, les incompréhensions et les bugs en autant d’améliorations pour le produit.

Évidemment, c’est plus facile à dire qu’à faire. Vous allez devoir travailler dans l’urgence, car il n’est pas question de laisser ses premiers utilisateurs bloqués et sans réponse ! Heureusement, je vous ai préparé une liste de conseils pour vous aider à anticiper cette période nouvelle et parfois difficile.

1. Tester l'environnement de production.
   Muscle ton jeu de recette !

   
   

   La recette est le moment où le Product Owner, ou l’équipe, teste en conditions réelles les développements livrés. L’usage veut que l’on recette assez rarement sur l’environnement de production, pour ne pas polluer les données, ou parce que ça prend beaucoup de temps, c’est une erreur !

   Lors de ma mission en tant que Product Owner, nous avons mis 2 plateformes en production. Sur la première, nous n’avons pas fait de recette en production. Les premiers utilisateurs en ont payé les pots cassés avec plusieurs bugs bloquants. Lors de la mise en production de la seconde plateforme, nous avons décidé de recetter au maximum l’environnement de production. Le constat est édifiant. Grâce à cet effort, deux incidents qui auraient bloqué l’ensemble de nos utilisateurs ont été évités.

   Saint Thomas disait “je ne crois que ce que je vois”. Avant une mise en production, assurez-vous d’avoir tout testé sur votre environnement final avant de l’ouvrir aux utilisateurs. Vous éviterez quelques mauvaises surprises.

   Petit tips pas piqué des hannetons : les écarts entre les différents environnements viennent souvent de la configuration d’API externes.

2. Réduire les livraisons de features et dédier du temps de développement à la gestion du run.
   Rien ne sert de courir, il faut partir à point.

   
   Lorsqu’on est Product Owner, on peut avoir tendance à vouloir livrer des features pour améliorer son produit. On subit aussi parfois la pression d’autres parties prenantes (partenaires, investisseurs, clients etc…). Pourtant l’enjeu majeur du passage en production est d’être capable de détecter et de résoudre les bugs rapidement pour préserver la relation avec ses premiers utilisateurs. Mon conseil est donc de dédier du temps de vos développeurs aux taches de suivi du run.
   
   Ce rôle est primordial dans une équipe avec un produit en production. Les taches de suivi du run sont les   suivantes :
   -  Détecter les bugs le plus tôt possible ;
   -  Débloquer les utilisateurs ;
   -  Investiguer pour comprendre l’origine du bug ;
   -  Résoudre le bug ou le transmettre à un autre développeur ;
   
   Lors de la mise en production de notre première plateforme, nous avons minimisé l’impact de la gestion du run. Nous accordions peu de temps à ces tâches. Résultat, les bugs se sont accumulés, les développeurs étaient stressés, nous délivrions moins et la satisfaction client était au plus bas. À partir du moment où un développeur a été dédié à 100% au suivi du run, l’équipe est rentrée dans le droit chemin, et nous avons pu, nous consacrer de nouveau à l’amélioration du produit.
   Avoir du temps de développement dédié au suivi du run vous permettra d’être beaucoup plus serein et d’éviter de désorganiser votre équipe de delivery en cas d’incident en production.

3. Préparer ses outils avant de mettre en production.
   Pourquoi les cordonniers devraient-ils être les plus mal chaussés ?

   Ce conseil peut sembler trivial, mais il faut préparer certains outils afin d’optimiser la gestion du run. Cette liste est non exhaustive et fondée uniquement sur mon expérience personnelle de Product Owner. Vous trouverez donc ci-dessous, pêle-mêle, une liste d’outils intéressants à préparer :
   
   - Développer des outils d’alerting pour détecter rapidement les premiers bugs (Sentry ou Kibana par exemple) . Cela facilitera les tâches de suivi du run et améliorera votre temps de résolution des bugs ;
   
   - Créer une matrice de priorisation des bugs en fonction de leur impact sur vos utilisateurs et votre activité. Cela permettra à votre équipe de se consacrer rapidement aux bugs les plus importants pour vos parties prenantes ;
   
   - Établir des process clairs et des rôles bien définis pour la gestion des incidents. L’équipe doit savoir qui communique auprès de qui, dans quel cas, et comment avertir les utilisateurs pour être la plus efficace possible ;
   
   - Avoir un outil de suivi des bugs (sur Notion ou Jira par exemple).Cet outil vous permettra de garder un historique et de communiquer facilement sur votre gestion du run ;
   
   - Installer des outils de tracking des comportements utilisateurs (Amplitude, Google Analytics ou Hotjar par exemple). Ces outils vous permettront de comprendre comment vos utilisateurs interagissent avec votre produit, et ainsi de l’optimiser ;
   
   - Mettre en place un suivi de la satisfaction client avec des moyens clairs pour récolter massivement les retours utilisateurs. Il faut également consacrer du temps à la compréhension et à l’exploitation de ces retours.

Bonus : Construire une communauté avec ses premiers utilisateurs
Chaque problème est une opportunité pour qui sait la saisir. 

Vous aurez des bugs, des problèmes en production qui vous feront prendre contact avec vos utilisateurs. Profitez-en pour les inclure dans votre projet, leur demander leur avis. Les impliquer vous permettra de créer du lien, de les valoriser et de créer une communauté. Un utilisateur écouté est un utilisateur heureux, un utilisateur heureux devient souvent un ambassadeur pour le produit.

Je vous ai livré ici mes principaux conseils. Si vous souhaitez créer un produit en machine learning, lancer un projet Big Data, ou échanger sur le challenge de la mise en production de votre produit, contactez-nous, ce sera un plaisir d’échanger avec vous !