Comment mettre en place une gouvernance efficace dans un projet de déploiement applicatif à fort enjeu business, alliant agilité et cycle en V dans un contexte international ?

En construisant son parcours entre cursus métier et prisme IT, Anthony cherche à allier valeur business et mise œuvre concrète afin d’accompagner la transformation des organisations. Convaincu de l’atout que représente la transversalité dans la gestion de projet, c’est pour lui l’humain qui va infuser le changement et garantir la mise en mouvement à la suite du projet ! S’il est attiré par le mode produit qui permet de créer par incrément de la valeur et de vivre en tant que Product Owner une connexion forte avec les métiers, son expérience l’a confronté à la nécessité de s’adapter à des contextes qui permettent ou non l’agilité. Parfois, il faut savoir allier et composer avec les deux ! Dans cette interview, Anthony nous partage ses retours d’expérience sur un projet à fort enjeu business. Celui-ci impliquait de composer aussi bien avec la méthode agile que le cycle en V, et donc de mettre en place une gouvernance spécifiquement adaptée.  

Quel est le contexte de ce projet et les enjeux business de l’application dont tu étais Product Owner ?

Le projet a été initié dans un contexte de crise sanitaire, avec une baisse de trafic en magasin. Parmi les axes d’optimisation, un enjeu important était d’améliorer le taux de transformation de chaque personne se rendant en boutique. Dans le domaine du prêt-à-porter, si la bonne taille n’est pas disponible lorsque le client se déplace, il va se tourner vers une boutique concurrente. C’est alors une perte nette comme le besoin sera satisfait ailleurs.  L’objectif de l’application était de contourner les ruptures de stocks pour les clients se déplaçant en magasin en offrant un catalogue XXL basé sur les produits disponibles sur le web. Grâce à cet outil, les vendeurs peuvent accompagner le client à l’instant T en passant la commande ou en l’aidant à le faire. Bien sûr, proposer une expérience sans couture et omnicanale est obligatoire : c’est la simplicité de l’acte d’achat qui est recherchée. Les use cases prenaient aussi bien en compte les clients qui disposaient d’un compte web de ceux pour lesquels il fallait en créer un facilement. Le gain recherché représentait plusieurs pourcentages d’augmentation de parts de marché, et donc du chiffre d’affaires ! C’était ainsi le Commerce Physique qui était le client interne du projet, même si la direction de la transformation pilotait la mise en œuvre dans le cadre du programme digital.

Quels sont les défis que ces enjeux métiers posaient sur la gouvernance du projet ?

Le premier défi, c’était le timing très serré, avec une pression forte due à l’importance business du projet, et à sa dimension internationale ! Il fallait assurer le respect de la feuille de route Produit et des échéances de delivery. Le projet bénéficiait d’une forte dimension digitale, mais également d’un lien direct avec la direction commerce et les équipes en magasins. La réussite du projet ne pouvait pas en effet se passer de l’appropriation par les équipes en boutique. Les objectifs posés en interne avec par exemple des incentives sur les volumes d’affaires générés créaient une émulation positive auprès des équipes de vente. Cependant, cette dynamique positive nécessitait une réactivité importante. Pour l’accompagnement au changement, nous pouvions nous appuyer sur les responsables de magasin et directeurs de région. Ils jouaient un rôle prépondérant dans l’animation. De notre côté, nous devions montrer que nous étions disponibles et également assurer la prise en main de l’application, et aussi sa stabilité !  Cette forte composante « commerce physique » avait des impacts au niveau de la gestion de projet. Anticiper les formations impliquait d’être dans les délais sur toute la chaîne amont avec des contraintes fortes en bout de cycle. Développement web et Android, partenaires externes pour le matériel, le Payment Service Provider ou Prestataire de Services de Paiement (PSP), la préparation des équipements… tout était intimement lié !    

Ce lien avec les magasins a nécessité de prendre en compte des composantes qui sortaient du périmètre prévu initialement. La disparité du WiFi selon les magasins par exemple ! Nous avons ainsi dû être force de proposition avec les équipes infrastructures pour apporter des réponses. Réaliser le paiement en mobilité alors qu’il y avait des difficultés à stabiliser la connexion réseau fut un défi notable dans le projet.

C’était donc un projet transversal, avec de multiples interlocuteurs impliqués, en interne et en externe et au niveau international : les déploiements de l’application se sont, en effet, réalisés dans plusieurs pays.  Cette dimension internationale soulevait bien sûr des enjeux spécifiques. Les comportements d’achat des consommateurs sont différents selon les pays, et, en conséquence, les attentes vis-à-vis de l’application aussi. La culture du paiement en espèces ou les ajustements sur les devises sont des cas typiques. Les différences culturelles influent aussi sur la gouvernance du projet et la communication.

Comment étaient mises en place l’agilité et la gouvernance dans ce projet ?

Comme je l’expliquais, le projet intégrait beaucoup de parties prenantes, avec des fonctionnements et des attentes différentes. En complément des équipes digitales, métiers, flux et infrastructures, il y avait trois parties prenantes en externe : un partenaire pour le développement sous Android, un acteur pour le PSP (Payment Service Provider) et un autre pour les terminaux de paiement mobile. Ces différents acteurs apportaient de la complexité à la gestion du projet. L’équipe de développement digital fonctionnait en agilité avec toutes les instances habituelles SCRUM : daily pour la fluidité dans les échanges dans l’équipe, sprint planning pour notamment valider les fonctionnalités à embarquer dans le sprint, sprint review pour présenter les fonctionnalités aux métiers, rétrospective pour l’amélioration continue des prochains sprints… L’équipe externe qui pilotait le développement autour du versioning Android était aussi en mode Agile, mais dans un cycle parallèle. Comme les instances étaient différenciées, à chaque release et mise en production, nous devions aligner nos deux cycles agiles au travers de Comités Projet dédiés. Le projet dépendait aussi d’équipes qui ne fonctionnaient pas en agilité. C’était le cas pour l’orchestration en amont avec les équipes de mise en œuvre (MOE) autour du référencement produit et les équipes flux ou en aval avec les équipes MOE du domaine vente, logistique ou encore de la comptabilité. Dès lors qu’il y avait des impacts sur le Système d’Information et de nouveaux flux, cela impliquait donc une forte anticipation comme les équipes fonctionnaient en mode projet classique. En termes de gouvernance, en plus des rituels agiles, nous avons, de manière assumée, mis en place un Comité Projet Hebdomadaire avec les partenaires internes, afin de donner entre autres de la visibilité au Commerce. Nous avons également instauré un Comité Projet avec les partenaires externes, juste après l’instance interne, afin de challenger et décliner le discours aux différentes parties prenantes. Nous avions moins la main mise directement sur les équipes externes, mais les animer était malgré tout essentiel ! Nous avons également pris le parti de mettre en place un Comité de Pilotage tous les 2 mois, avec des interlocuteurs internes des différentes directions impactées par le projet.  

Avec la diversité d’interlocuteurs et de modes de fonctionnement, nous avons fait cohabiter à la fois des cycles agiles et des méthodes projets en cycle en V !

Quelles étaient les étapes clés, liées au cycle agile ou au mode projet, lors du lancement du déploiement sur un nouveau pays ?

Tout commençait par un kick off où nous identifions les interlocuteurs clés afin de garantir que pour chaque décision stratégique ou opérationnelle, nous aurions l’interlocuteur adapté. Un enjeu était également de trouver rapidement les relais plus opérationnels sur lesquels s’appuyer pour les phases de test. La première étape était, ensuite, de recueillir les besoins de la direction commerce du pays concerné, à la fois au travers de points structurés et en accueillant les demandes de manière plus informelle. L’objectif était de s’assurer d’embarquer dans la backlog toutes les évolutions fonctionnelles attendues, avec le bon niveau de priorisation. En tant que Product Owner, je représentais la vision client ! Nous prenions, à la suite, contact avec les sachants IT pour vérifier la faisabilité des attentes et identifier s’il y avait d’autres éléments à prendre en compte. Réaliser une analyse des écarts au niveau du Système d’Information du pays, en particulier au niveau des flux comptables et logistiques était un prérequis pour anticiper les développements à mener et assurer la gestion de bout en bout du cycle de commande. Nous déroulions ensuite les cycles agiles, avec le Sprint Planning qui regroupait tous les PO sur tous les domaines du digital. Nous présentions chaque User Story au tech lead, lead dev et aux développeurs afin d’avoir un chiffrage validé au global et confirmer si la fonctionnalité était embarquée ou non. Si ce n’était pas le cas, nous devions rapidement confronter la décision aux directeurs métiers et identifier des plans B pour traiter malgré tout le besoin. Les partenaires externes n’étaient pas intégrés systématiquement : cela dépendait des besoins spécifiques autour d’Android par exemple. Cependant, un aspect essentiel en mode projet était d’anticiper les impacts pour le PSP. Nous réalisions à ce sujet un kick-off dédié afin de présenter au partenaire les enjeux, le nombre de comptes à créer et dimensionner les équipes. Comme le rapport de force n’était pas évident, il fallait éviter au maximum les décalages lors des tests en phase de delivery et jouer de diplomatie pour les faire avancer…  

Pourquoi mettre en place une gouvernance qui allie le mode agile et des Comités Projets plus classiques ?

C’est un fonctionnement et une gouvernance logiques étant donné que suivant les domaines concernés, la méthode de delivery diffère. La culture des équipes digitales est par essence agile : le site web et les applications évoluent en continu et les équipes sont dimensionnées en conséquence pour être réactives aux évènements. Au contraire, sur des domaines liés au matériel ou au système d’information historique, la fréquence des variations est bien moindre, et les interdépendances plus nombreuses. La complexité était que nous avions deux vitesses différentes et pas les mêmes enjeux au même moment. En tant que PO, je devais être proactif pour anticiper les échéances, avec la marge adéquate. Cette anticipation impliquait aussi d’identifier très en amont les évolutions potentielles des briques du Système d’information. Impossible de découvrir un impact important quelques jours avant la mise en production !  

Il n’était pas question, et tout simplement pas possible, de forcer toutes les équipes à entrer dans la même méthodologie. C’était à nous de faire coexister efficacement ces deux mondes en adaptant la manière d’animer, de communiquer et d’être à l’initiative pour homogénéiser des plannings interdépendants au niveau du projet global. 

Qu’est-ce que cela impactait en termes d’arbitrage ? Pourquoi savoir challenger le métier était essentiel ?

J’étais garant du projet et de sa viabilité. En termes de posture, je ne peux pas répondre à une demande par l’affirmative si je ne suis pas convaincu qu’elle est réalisable dans de bonnes conditions. C’est une exigence pour conserver la cohérence et être à l’aise pour piloter le projet. L’enjeu est donc d’être en capacité de dire non lorsque c’est nécessaire et de le justifier. Bien sûr, avec la forte pression métier et les attentes business, c’est loin d’être évident ! Une conséquence de cette posture, c’est d’être ensuite fortement attendu sur la livraison. Comme on justifie d’un côté de ne pas pouvoir répondre positivement à certaines demandes, il faut de l’autre assurer le respect du planning une fois ces décisions prises ! Faire du dégradé, après l’avoir testé, n’est pas une option viable. Si cela nous fait économiser du temps au niveau projet, comme la maintenance niveau 1 était externalisée, cela engendre des appels qui auraient pu être évités. Ce coût et cette charge supplémentaires pour les équipes RUN n’étaient pas tenables. Cependant, une fois le produit suffisamment stable déployé, je suis convaincu qu’il ne faut pas hésiter à prononcer la VSR (vérification de service régulier) dans ce contexte multi pays et multi projets. En tant que PO, on transmet ainsi une part de la charge aux équipes RUN pour se concentrer sur les autres sujets : il ne faut pas endosser toutes les casquettes ! Pour conclure, les arbitrages, c’est aussi nous, en tant que Product Owner, qui les subissons lors des Sprint Planning ! Il faut parfois admettre qu’en dépit de toute l’énergie et de la présentation précise des sujets, nous pouvons avoir un No Go technique. En mettant trop d’engagement personnel, le risque, c’est de percevoir ces refus comme des échecs. L’humilité fait partie du rôle du PO !  Bien sûr, avoir créé du lien avec des ambassadeurs techniques est un vrai appui lorsqu’on présente des sujets. Le poids d’un sachant peu faire infléchir certains avis du Tech Lead ! Accepter les No Go finaux n’est pas contradictoire avec le fait de tout faire pour les éviter.