À un moment donné, dans la vie d’une startup ou d’un projet, on constate souvent un essoufflement. Dette technique, bugs qui s’empilent, équipe qui s’épuise : le produit n’évolue plus, l’entreprise n’innove plus, les équipes tech et produit ne se parlent plus. Et tout le monde perd confiance.
Vient le moment où ce contexte de défiance amène à chercher un prestataire externe, comme un salut vers l’efficience opérationnelle et la sortie de la dette technique et produit. Mais si on fait appel à un prestataire pour exécuter un plan, on risque de reproduire les mêmes erreurs.
Dans cet article, avec des exemples concrets, j’ai essayé d’identifier les raisons qui empêchent les projets de réussir. Mais surtout, je propose quelques méthodes, dont la Goal Oriented Roadmap, qui permettent, en s’écartant des méthodes classiques de gestion de projet, d’aligner les équipes et d’avancer de front autour d’objectifs communs.
Sommaire :
- Tout commence souvent par… un gros gâchis 💸
- La Roadmap Orientée Objectifs : un outil pour des projets qui réussissent 🎯
- Le sprint 0 pour aligner client et prestataire 🤝
Tout commence souvent par… un gros gâchis 💸
Lorsqu’une entreprise se tourne vers un prestataire comme theTribe, elle a parfois vécu des échecs traumatisants en amont, avec des millions investis dans son produit, pour rien.
Cela peut aller vite : rappelons qu’une équipe de 10 personnes travaillant pendant 6 mois et ayant chacun un salaire annuel de 50 000 € bruts représente un coût pour l’entreprise de 500 000€.
Imaginons une entreprise qui édite un produit SaaS, prisonnier d’une dette technique trop importante, qu’elle n’arrive plus à faire évoluer.
La défiance de l’équipe vis-à-vis de sa propre organisation, que l’on décrivait en préambule, peut conduire à des décisions délétères.
Par exemple, l’équipe aura préféré créer un nouveau produit en parallèle du produit existant, complètement siloté, car elle ne se sentait pas capable de refondre petit à petit l’existant tout en intégrant de nouvelles fonctionnalités.
Résultat : les équipes travaillent pendant des mois sur cette refonte sans sortir de nouvelle fonctionnalité. Dans le meilleur des cas, le nouveau produit finit par être fonctionnel et finit par remplacer l’ancien, au prix d’une migration coûteuse. Mais les équipes ont travaillé des mois pour ne produire aucune valeur ajoutée : uniquement pour refaire ce qui avait déjà été fait dans le passé.
Dans le pire scénario, le nouveau produit n’arrive pas à reproduire le périmètre fonctionnel de l’ancien. Les fonctionnalités sont dégradées, et il est impossible de basculer les utilisateurs sur la nouvelle version. Des mois et des mois de code finissent à la poubelle.
Le prestataire comme sauveur ⛑️
C’est donc souvent après avoir perdu beaucoup de temps et d’argent que les entreprises décident de se tourner vers un prestataire. Avec des attentes à la hauteur des enjeux et du stress vécu au sein de l’entreprise.
Car les équipes produit et tech de l’entreprise sont épuisées et soumises à une pression intense. Naturellement, cette pression va se reporter sur le prestataire. On va exiger de celui-ci qu’il s’engage sur sa capacité à livrer un certain nombre de fonctionnalités, dans un délai donné. Et généralement, comme on a déjà perdu beaucoup d’argent, on va négocier à la baisse les prix, et les délais. Le ver est dans le fruit.
Sauf que le prestataire, aussi motivé et compétent soit-il, va se heurter aux mêmes imprévus que les équipes internes : la dette technique, la dette produit, les bugs, l’inertie des décisions. La réalité va nécessairement amener, une fois le capot ouvert, à faire des concessions sur une des métriques du projet : la qualité, le périmètre fonctionnel, ou les délais.
Quand le sauveur se change en bouc émissaire 🐐
Il n’est pas rare alors que le client rejette la faute sur le prestataire : “Après tout, on les paye pour régler les problèmes !”
La défiance interne va donc se retourner contre le prestataire. Et en conséquence, le client va relever son niveau d’exigence. Il va, le plus souvent, être encore plus regardant sur les délais et le chiffrage, négocier à la hausse le nombre de fonctionnalités à livrer, et ne laisser passer aucune baisse dans la qualité. Parfois, un système de points est mis en en place pour représenter le temps ou l’effort nécessaire par fonctionnalité, ce qui ne manque pas de complexifier les tractations sur le nombre de fonctionnalités.
La relation entre l’entreprise et le prestataire va commencer à se tendre, les équipes du prestataire stressées par les deadlines de plus en plus courtes et la charge mentale qui augmente, vont se démobiliser. On va alors à nouveau rogner sur un des éléments du triptyque (qualité / délais / fonctionnalités), jusqu’à l’implosion pure et simple de la relation entre le client et le prestataire.
Et à nouveau on pourra se dire : quel gâchis !
Mais alors, comment éviter cette catastrophe ?
Comment cadrer les projets pour éviter qu’ils ne finissent mal ?
Peut-être en commençant par accepter, dès le démarrage du projet, que le plus important n’est pas d’exécuter un plan, de suivre une roadmap, de “produire des fonctionnalités”… mais d’atteindre des objectifs.
La Roadmap Orientée Objectifs : un outil pour des projets qui réussissent 🎯
Chez theTribe, lorsque nous sommes missionnés sur un projet pour aider une équipe technique à délivrer des fonctionnalités, nous aimons mettre en place une Goal Oriented Roadmap, ou “Roadmap orientée objectifs”.
Mais qu’est-ce que c’est ? On va y revenir plus en détails. Mais l’idée est de sortir de l’approche “projet” traditionnelle, qui prévaut souvent dans les projets techniques, et qui consiste à missionner un prestataire sur le développement d’une liste de fonctionnalités détaillées.
Cette façon de faire, qui peut sembler sécurisante pour le client, va à l’encontre de tous les fondamentaux de l’agilité. Elle fige un périmètre alors qu’il faudrait pouvoir le faire évoluer au fil des retours utilisateurs. D’ailleurs, elle a souvent pour conséquence le développement de fonctionnalités qui ne seront jamais utilisées. Et elle est à l’origine de la plupart des tensions qui peuvent intervenir sur un projet et qui mènent, in fine, à des déceptions des deux côtés.
Pour mettre au point une Goal Oriented Roadmap, on va accepter de laisser de côté les fonctionnalités qualifiées sous forme de user stories, pour les rassembler dans un sprint avec un objectif commun.
Par exemple, lorsque nous avons travaillé sur le MVP de Aerowork, l’objectif de l’un des sprints était : “Le candidat peut postuler et accéder à ses candidatures”.
L’objectif se rattache naturellement à l’objectif du MVP et cela permet, en continu, d’assurer le lien entre les fonctionnalités et le projet.
Avec cette méthode, pour chaque sprint l’équipe va concentrer toute son énergie autour d’un objectif, en précisant à chaque fois les KPI ou métriques de succès.
Cette façon de fonctionner peut paraître anecdotique. Et pourtant, elle induit un changement d’état d’esprit : en se concentrant non plus sur les fonctionnalités mais sur les objectifs à atteindre, on va réaligner toutes les parties prenantes du projet : équipe technique et produit, client et prestataire.
Un autre bénéfice de la Goal Oriented Roadmap, c’est qu’elle permet d’aller plus vite. Pour éviter tout dépassement dans les délais et le budget, on va fixer un nombre de sprints et les objectifs associés. Ce nombre de sprints étant fixe, pas de risque de dépassement.
En fonction des imprévus techniques, des réalignements nécessaires, le périmètre de chaque sprint pourra être amené à évoluer.
Mais peu importe finalement le nombre de user stories réalisées au sein d’un sprint par rapport à ce qui était prévu, tant que l’objectif est atteint ! Et à la fin du sprint, on passe à l’objectif suivant.
Prioriser pour mieux délivrer 🧠
La Roadmap orientée objectif peut être un exercice challengeant pour le donneur d’ordres. Cette approche implique d’accepter de renoncer à certaines fonctionnalités qu’on avait à l’origine prévues dans son plan.
Pourtant, toutes les parties prenantes s’accordent généralement à dire que l’atteinte de l’objectif du sprint – en d’autres termes la valeur fonctionnelle ajoutée – est bien plus importante que le nombre de “tickets” terminés.
Complémentaire à la Roadmap Orientée Objectifs, la priorisation intra-sprint prend alors tout son sens : si les fonctionnalités sont bien priorisées, ce sont les user stories portant le plus de valeur par rapport à l’objectif (”must-have”) qui seront réalisées de manière certaine, alors que les user stories secondaires (”nice-to-have”) seront éventuellement mises de côté pour une version ultérieure. L’essentiel, une fois de plus, c’est d’atteindre l’objectif du sprint et donc, que le produit remplisse son rôle.
Mesurer l’usage des fonctionnalités 📊
Mettre en place des métriques de succès ne suffit pas : encore faut-il être capable de mesurer concrètement l’atteinte des objectifs !
Il ne suffit pas de pouvoir dire “j’ai livré une fonctionnalité” pour atteindre un objectif. D’ailleurs, la notion du definition of done n’est pas la même d’une entreprise à une autre.
C’est pourquoi il est impératif d’intégrer un minimum de tracking au produit pour mesurer son usage.
Car se contenter de seulement livrer les fonctionnalités, c’est prendre un risque de ne pas mesurer la performance de ce qui est livré. C’est s’empêcher d’accéder à une des plus grandes ressources de l’approche “Produit” : la mesure, l’analyse et l’amélioration continue de la performance d’une nouvelle fonctionnalité.
Cela peut paraître étonnant, mais beaucoup trop d’entreprises ne mesurent pas l’usage des fonctionnalités de leur produit. Il existe pourtant de nombreux moyens de le faire, du plus simple au plus complet.
Pour aller plus loin, si le sujet vous intéresse, je vous conseille la lecture de notre guide pratique à télécharger : Comment utiliser la data pour maximiser l’impact de votre produit ?
Exemple de métriques de succès :
Reprenons l’exemple du projet Aerowork.
- L’objectif d’un des sprints était “Le candidat peut postuler et accéder à ses candidatures”.
- Les user stories (non exhaustives) étaient les suivantes :
- “En tant qu’utilisateur, je veux pouvoir choisir le type de contrat CDI / CDD”
- “En tant qu’utilisateur, je veux choisir le site ORLY ou CDG”
- “En tant qu’utilisateur, s’il y a au moins un poste disponible pour ce métier, je peux cliquer sur postuler. Sinon je peux demander à être alerté lorsqu’un poste se libère.”
- etc.
- Les KPIs (non exhaustifs) étaient : taux de clic sur le bouton “postuler” dans une fiche métier, taux de complétion du formulaire de recrutement.
Le sprint 0 pour aligner client et prestataire 🤝
Lorsque l’on a passé des années à gérer des projets avec une méthode classique de type “Cycle en V”, l’approche que propose theTribe peut faire peur. Et pourtant, quand on l’a adoptée, ça devient une évidence.
Chez theTribe, nous accompagnons nos clients dans l’adoption progressive d’une approche moins orientée “projet” mais plus orientée “produit”. En expliquant, en formant, en transmettant nos bonnes pratiques.
Mais le moment qui en général, met tout le monde d’accord, c’est le Sprint Zéro, qui intervient en amont des sprints. Il permet de définir les principes de priorisation et d’aligner toutes les parties prenantes sur l’objectif des sprints. Ensuite, la Roadmap Orientée Objectifs donne une forme à cet alignement. Elle servira de boussole dans toutes les discussions au fil de l’avancement du projet.
