“Le Time To Market est trop long”, “Nous n’avons aucune idée du bénéfice apporté par ce projet”, “On commence plein de choses et on ne termine rien”...
Voilà des phrases que nous entendons tous les jours et qui font dire à toutes les entreprises impliquées dans la révolution digitale qu’il faut remettre en cause le paradigme projet.
L’enjeu de ces entreprises n’est plus le respect du fameux triangle périmètre-coût-délai mais bien d’optimiser l’impact business à long terme.
Que devient la traditionnelle date de fin de projet lorsque l’équipe commence à mettre en service rapidement de premières versions du produit qui seront complétées par les retours fréquents des utilisateurs ?
Nous devons alors changer de lunettes, passer du paradigme projet au paradigme produit pour s’assurer d’avoir le maximum d’impact sur le long terme, promouvoir une innovation efficace tout en “dé-silotant” l’entreprise.
En théorie
Ce changement de paradigme couvre 4 grands domaines :
Le pilotage par la valeur plutôt qu’une approche budgétaire
Des feedbacks clients nombreux et anticipés plutôt qu’en fin de projet
Des décisions rapides et fréquentes plutôt que lentes et anticipées
Une planification itérative plutôt qu’une planification complète
Du point de vue d’un gestionnaire de projet, cela revient à :
Limiter les risques liés aux engagements de délai par des livraisons fréquentes
Maîtriser la notion de coût par une équipe stable et dédiée à un sujet produit
Anticiper les bénéfices par la production de valeur pour les clients
Utiliser le périmètre comme seule variable d’ajustement
En pratique
Cela commence toujours par la mise en place d’une équipe Agile de 5 à 8 personnes, pluri-disciplinaire, durable et dédiée à un produit.
L’équipe met rapidement en place des moyens pour obtenir du feedback des utilisateurs : data, analytics, tests utilisateurs, immersions, observations…
Afin de gérer efficacement le build et le run, l’équipe va rapidement développer une stratégie sur la qualité logicielle afin de limiter l’impact des bugs : pyramide des tests en place, création de dette technique sous contrôle, tests automatisés et bugs priorisés.
La budgétisation d’une telle équipe devient glissante (en général sur 3 mois) afin de fréquemment se poser la question du “arrêter / continuer” en fonction du retour sur investissement espéré.
De fait, la roadmap devient dynamique tout comme la stratégie produit qui se base avant tout sur des hypothèses plutôt que des opinions.
La clé de voûte du mode produit est le Product Owner de l’équipe qui doit être capable de décisions rapides sur le produit mais aussi d’une bonne capacité à communiquer et challenger (avec l’aide de spécialistes de l’expérience utilisateurs) les besoins des clients et des parties prenantes de l’entreprise.
La FAQ
“Comment récupérer du feedback client ?”
Une session de tests utilisateurs (source : usability.de)
Par des contacts directs qualitatifs : observations et entretiens directs avec des utilisateurs
Des sondages quantitatifs : enquêtes satisfaction (de type Net Promoter Score), sondage de positionnement, benchmark concurrentiel
Les métriques quantitatives d’usage issues d’outil d’analytics, de logs internes ou de requêtes en base Les demandes client consultables dans les outils de ticketing
Des retours indirects par des experts internes : les commerciaux, le marketing, mais aussi le support ou le service formation
Des tests utilisateurs
Inviter des utilisateurs en démonstration
Organiser des ateliers de co-design avec des clients
Créer un comité / club utilisateur
“Comment faire quand nous n’avons pas accès aux clients / utilisateurs ?”
Avoir des contacts directs avec les utilisateurs est souvent difficile à obtenir par des équipes IT, bloquées par le marketing, les commerciaux ou les partenaires. Dans ce cas, vous pouvez utiliser un cheval de troie : partir d’une demande client urgente où il sera légitime de rencontrer le client directement, puis en profiter pour étendre la discussion sur d’autres sujets qui vous intéressent et demander au client de nouveaux contacts d’utilisateurs.
“Je dois refaire un produit qui existe déjà (comme celui d’un concurrent par exemple), je sais donc ce que je veux et j’ai peur que l’approche produit soit une perte de temps !”
Le meilleur contre-exemple est Google Music, une application qui aurait pu être un simple copier / coller de Deezer ou Spotify et qui a réussi progressivement à devenir un référent dans la recommandation musicale tout en négligeant certaines fonctionnalités de ses concurrents. Donc oui, l’approche produit est une perte de temps si vous souhaitez simplement vous mettre à niveau de la concurrence - mais cette situation est généralement le signe d’un retard difficile à rattraper, ce que l’approche produit pourrait transformer en opportunité !
“Comment tenir une roadmap quand on est monopolisé par les demandes urgentes des clients ?”
Être piloté par les retours utilisateurs ne veut pas dire être piloté par les utilisateurs !
Exemple : Pour une solution de partage de fichiers en cours de refonte, des clients importants demandaient à converser à tout prix une gestion de profil iso-fonctionnelle de la version précédente. Après des entretiens sur les besoins, le Product Owner a proposé une refonte de la gestion de profil plus simple pour les utilisateurs ... et les développeurs.
Les remarques des clients ne sont que inputs. Il faut remonter aux besoins profonds du client au-delà de la solution qu’il pousse spontanément,, par exemple avec la méthode des “5 pourquois”. Il reste ensuite évaluer leur pertinence par rapport à votre vision produit. Vous pourrez alors vous focaliser sur l’important sans être esclave de l’urgent.
un exemple d’analyse de 5 pourquoi :
“A cause de notre image de marque, nous ne pouvons pas sortir un produit incomplet, comment faire ?”
C’est effectivement un grand changement d’état d’esprit et dont l’impact est beaucoup plus interne à l’entreprise qu’externe. La plupart des clients d’aujourd’hui sont habitués à des produits incomplets et c’est une tendance qui va se renforcer de plus en plus. Le problème vient souvent des objectifs donnés aux salariés, plus fréquemment associés à de la réalisation de solutions abouties qu’à de la valeur créée pour les utilisateurs.
En cas de refonte d’une solution existante, la facilité est effectivement de reproduire le périmètre fonctionnel à l’identique sans se poser de questions mais ce serait passer à côté de l’opportunité de faire moins, plus vite et de meilleur qualité en supprimant tout le périmètre qui n’apporte pas de valeur (règle des 80/20).
“Certaines ressources (UX, QA, devops, …”) n’ont pas besoin d’être à temps plein dans les équipes ? Comment optimiser les ressources ?”
Vous avez besoin du “slack” : de la marge pour gérer les aléas, l’amélioration continue et les innovations
Les ressources sont en fait des humains … avec un cerveau souvent bien câblé. Chacun a une expertise, mais peu aider ses coéquipiers : un expert UX ou des développeurs peut aider à rédiger les User Stories ou les tests.
Optimiser les ressources n’a pas de sens en Agilité, c’est bien souvent contre productif car cela met le système complet en tension et le moindre imprévu fait dérailler la machine; c’est la souplesse du système qui permet d’absorber efficacement et au plus tôt les problèmes.
“Est-ce que le mode projet doit être interdit ?”
Non : le mode projet peut rester pertinent, notamment quand l’environnement est prédictible : il n’y a pas de débat sur le problème, le bénéfice et la solution.
Le mode projet peut être réalisé :
par des équipes projets temporaires en mode agile voire waterfall (si le plan de développement est prédictible)
par des équipes produit : par exemple la réalisation d’une feature / epic sur plusieurs sprints
un projet transverse à plusieurs équipes produit : par exemple le lancement à l’international pour un site de e-commerce organisé en 10 feature teams parallèles.
“Je suis Chef de Projet, qu’est-ce que je deviens ? ”
Comme vu dans le point précédent, il continuera à y avoir des projets, donc des besoins de chefs de projet. Cependant, il y en aura sûrement moins. Un repositionnement d’une grande partie des chefs de projets est nécessaire, souvent dans l’un de ces 3 rôles selon le profil de la personne :
Chef de Produit/ Product Owner, pour ceux qui sont issus du métier ou une bonne connaissance du marché
Tech leader, pour ceux qui ont une expertise technique et aiment aider l’équipe à monter en compétence
Scrum-master, coach agile ou facilitateur, pour ceux qui ont une appétence pour l’amélioration du relationnel et des process
Attention
Passer en mode produit n’est pas qu’une simple réorganisation de l’IT ou R&D, c’est un changement de culture qui implique toute l’entreprise (direction, RH, marketing, commerce, finances, métier…).
Même si nous recommandons de commencer progressivement par des expérimentations pilotes, il s’agit à terme d’une transformation d'entreprise qui exige dès le départ un sponsorship fort au niveau de la Direction Générale.
Recettes de Coach / Astuces
“Je passe beaucoup de temps avec le Product Owner pour lui expliquer l’importance de la communication avec les parties prenantes car souvent les entreprises ont peur de ce nouveau rôle qu’ils imaginent être un chef produit omnipotent. Mon truc, c’est de faire venir ces parties prenantes dans l’équipe pour qu’ils constatent de visu que celui qui décide dans une équipe produit, c’est l’utilisateur avant tout !” (Basile)
“J’aime demander aux dirigeants de raconter des gros échecs projets ; il y en a toujours et ils ont traumatisé l’entreprise ! Je m’appuie sur ces “blessures” et leur cri du coeur “plus jamais ça !” pour les inciter à expérimenter une autre façon de faire.” (Dominique)
“Une équipe produit doit être capable de mettre en production par elle-même, sans contraintes externes, rapidement et fréquemment. Pour cela, je consacre toujours les premiers jours (ou semaines) de l’équipe produit à valider cette capacité en faisant l’exercice de déploiement complet d’une pseudo-fonctionnalité (par exemple une page “Hello World”). Rien de pire qu’une équipe produit incapable de déployer son code, elle perd tout son sens” (Basile)
Je ne sais pas / j'aimerais essayer
Product Owner ou Product Manager, telle est la question ?
Voilà une question à la fois simple et compliquée. D’un côté on aimerait dire que c’est la même chose et qu’il n’y a pas de différence et de l’autre on constate que le premier est tourné vers l’équipe et le delivery et que l’autre est tourné vers les utilisateurs et la stratégie… mais quelle est la bonne réponse ? On ne sait pas encore !
Comment contester les idées des managers ou dirigeants ?
Il s’agit du principal frein culturel que nous ayons rencontré dans la diffusion du mode produit. Alors que la méthode présuppose la possibilité d’invalider les idées par des petites expérimentations, la culture hiérarchique empêche les Product Owners / Product Managers de challenger une fausse bonne idée d’un dirigeant parfois intimidant.
Voici nos pistes de solutions :
de la sensibilisation en amont des dirigeants sur le mode produit
demander aux dirigeants de se remémorer des histoires de précédents échecs de grands projets ayant eu peu d’impact
s’appuyer sur les données avant de s’engager
utiliser des canevas pour s’obliger à remonter au besoin avant la solution (par ex. le lean canvas)
Au-delà du produit, l’expérience client
Dans la perception des utilisateurs, l’expérience produit dépasse largement le cadre de la simple application informatique. Elle inclut l’expérience utilisateur avec le marketing, le commerce, la livraison, le support, ...Nous nous demandons encore comment inclure ces compétences. Comment les impliquer vraiment dans le développement alors qu’ils sont monopolisés sur de multiples sujets ? Voire, peut-on les inclure comme membres dédiés dans les équipes pluridisciplinaires? Ceci implique de décomposer l’entreprise en mini-PME autour d’offres d’expérience client...
Témoignages de nos clients
“Donner des objectifs dans le cadre d’entretiens annuels à quelqu’un qui travaille dans une équipe produit n’a pas de sens, il faut le voir plus fréquemment et lui donner des objectifs non plus en lien avec le périmètre à réaliser mais avec la valeur à produire, c’est un nouveau challenge !” (Manager DSI Commerce)
“Je comprends que je ne dois plus demander des solutions à l’équipe sans contexte, mais exprimer mes besoins sous forme de questions et d’hypothèses afin de les laisser me proposer la meilleure solution.” (Responsable Marketing)
“Pour la première fois depuis que je travaille ici, je comprends ce que je fais pour le client” (Développeur équipe produit)
“Je trouve que la communication est meilleure, et que les gens se sentent plus impliqués.” (Développeur - équipe produit pilote)
“Je me rends compte que les livraisons fréquentes ont grandement amélioré la confiance des clients en l’équipe et ce malgré l’absence d’engagement sur un périmètre précis.” (Responsable métier)
