Vous avez passé 3 à 12 mois à peaufiner votre cahier des charges pour être sûr de ne rien oublier, en dédiant des séances de travail régulières vous demandant des efforts de projection.
Vous avez listé toutes les fonctionnalités dont vous avez besoin dans un tableau Excel de 200 lignes.
Vous avez fait des maquettes détaillées de chaque écran, dans Figma ou Powerpoint.
Vous avez défini un budget, nommé un chef de projet en interne, consulté des prestataires, épluché des devis.
Vous êtes certain que votre projet est sur de bons rails et vous êtes confiant dans sa réussite.
Et pourtant, ça dérape. Qualité, délais, budget, au bout de quelques mois, rien ne va plus.
Cette histoire vous parle ? C’est normal : vous êtes nombreux à être passés par là.
Mais alors, comment éviter que l’histoire ne se répète ?
Souvent, le mal est à la racine. Quand on lance un projet, on passe du temps à peaufiner les détails et on néglige le plus important. On croit gagner du temps en prenant des raccourcis, et ça peut coûter cher.
Dans cet article, je décortique les 10 erreurs le plus souvent commises par les équipes projet web et IT au lancement d’un projet. Connaître ces erreurs et les corriger, c’est le meilleur moyen d’atteindre vos objectifs !
1- Faire une liste de fonctionnalités sur Excel
Souvent, lorsqu’on planche en équipe sur le cahier des charges d’un nouveau site, d’un nouvel outil ou logiciel, on aboutit à un tableau Excel qui liste l’intégralité des fonctionnalités que l’on souhaite intégrer à ce nouveau projet.
Pour établir cette liste, on a parfois sollicité les futurs utilisateurs, et on a listé toutes les demandes, sans les prioriser. Dans le cas d’une refonte, on a établi toutes les fonctionnalités absentes du produit actuel et dont on pense avoir besoin. On n’est même pas certain que toutes ces fonctionnalités soient réellement utiles, mais on les met “au cas où” ou parce que les concurrents les proposent. Et on demande à un prestataire de chiffrer le projet sur la base de ce tableau.
Pourquoi c’est une erreur ?
Parce que ce mode de fonctionnement ne laisse pas la place à l’agilité, aux itérations qui permettront d’améliorer graduellement le produit développé.
Il vaut mieux se lancer sur un périmètre restreint et obtenir très vite des retours utilisateurs : cela permet souvent de se rendre compte que certaines fonctionnalités qu’on croyait indispensables ne le sont pas, et qu’à l’inverse, de nouveaux besoins qu’on n’avait pas anticipés apparaissent. Cela évite ainsi des dépenses inutiles.
Pour prioriser les sujets à lancer en premier, il ne faut pas partir de ce que l’on croit nécessaire dans le futur produit, mais identifier ce qui apportera réellement de la valeur aux futurs utilisateurs.
Plutôt qu’écouter l’intuition des sponsors du projet et développer votre produit sur la base d’un cahier des charges, il vaudrait donc mieux mettre très vite ce produit, même imparfait, dans les mains des utilisateurs.
Chez theTribe, il nous arrive de questionner les utilisateurs 30 jours après leur prise en main d’un nouveau produit. Et nous utilisons un outil, l’AttrakDiff, qui permet de mesurer l’usabilité du produit en se basant exclusivement sur la perception de l’utilisateur.
À lire aussi : Pourquoi vos supers fonctionnalités ne seront probablement jamais utilisées
2- Exiger un chiffrage détaillé avant d’avoir cadré le projet
Une fois que vous avez écrit votre cahier des charges et listé toutes les fonctionnalités dont vous pensez avoir besoin, vous contactez des prestataires et vous leur demandez un devis. C’est normal, vous avez besoin de savoir si le projet rentre dans votre budget, et de comparer différentes propositions.
Pourquoi c’est une erreur ?
Parce que cela sous-entend que ce cahier des charges est suffisant pour établir un chiffrage détaillé, fiable et ferme. Or, ce n’est jamais le cas.
Pour cela, il faudrait déjà avoir les réponses à toutes les questions… qui n’ont pas encore été posées !
En effet, pour pouvoir fournir un chiffrage fiable, il faut d’abord avoir soulevé le capot et identifié les risques potentiels.
Est-ce que l’infrastructure cible est la bonne ? Est-ce que les outils peuvent communiquer entre eux ? Est-ce qu’il y a des données à récupérer ? etc.
C’est pourquoi chez theTribe, nous aimons commencer les projets par un sprint d’investigation technique ou encore un POC.
Ce cadrage préalable n’a que des avantages. Car si votre prestataire s’engage sur un prix et que ça dérape, il sera obligé de faire des concessions :
- Soit sur la qualité (les choix techniques, les tests, l’architecture, la gestion des mises à jour…)
- Soit sur le périmètre fonctionnel (et au bout du 4e sprint, vous allez devoir renoncer à des fonctionnalités que vous pensiez avoir).
Certes, cela veut dire qu’il faut se lancer sans savoir exactement où l’on va du point de vue budgétaire. C’est moins rassurant que d’avoir un prestataire qui s’engage sur un forfait… Sauf que d’expérience, lorsqu’on s’engage sur un forfait sans avoir cadré le projet, ça dérape quand même toujours. En moyenne, on voit des coûts qui augmentent de 20 à 100% par rapport au devis initial proposé par le prestataire.
3- Cadrer le projet sans avoir parlé à vos utilisateurs de demain
Vous êtes spécialiste de votre métier car vous êtes présents sur le marché depuis de nombreuses années. Par conséquent, vous avez des convictions fortes sur ce qu’il faut apporter sur le marché. Vous faites alors l’économie d’aller rencontrer vos utilisateurs de demain. Puisqu’ils vont simplement valider vos intuitions, pourquoi dépenser entre 5 000€ et 10 000€ pour faire cet exercice ?
Pourquoi est-ce une erreur ?
Vous ne construisez pas forcément un outil numérique pour vos clients d’aujourd’hui. Vous construisez un outil pour de nouveaux utilisateurs. Quand, je dis utilisateurs, je parle des personnes physiques qui auront demain la main sur leur souris pour cliquer dans votre produit numérique. C’est à ces personnes-là qu’il faut plaire pour que votre produit fonctionne, et pas à vos interlocuteurs d’aujourd’hui et encore moins à vos clients ambassadeurs actuels, qui ne correspondent pas forcément à votre cible utilisateurs de demain.
Chez theTribe, aller à la rencontre de vos utilisateurs de demain est le point de départ de notre démarche d’accompagnement. C’est à partir des dires de ces personnes que nous allons concevoir, prioriser puis développer votre logiciel.
4- Faire ce que vos clients vous demandent
Vous êtes allé recueillir le besoin de vos clients et vous listez maintenant les réponses que vous pourrez leur apporter dans un outil web. C’est très bien !
Mais un piège se cache ici : vous construisez un produit qui répond non pas aux problèmes de votre cible idéale mais aux demandes de vos clients, souvent appelés “besoins”.
Pourquoi est-ce une erreur ?
Développer des fonctionnalités spécifiques (c’est-à-dire qu’elles sont mises à disposition d’un client pour répondre à son besoin), vous offre un gros avantage : votre client a exactement ce qu’il veut !
Les inconvénients : cela diminue l’évolutivité de votre produit, complexifie la maintenance, alourdit la compréhension de votre code et ralentit l’autonomisation de nouveaux développeurs qui arriveront sur le code informatique.
Chez theTribe nous travaillons la priorisation du développement de votre produit selon plusieurs critères pour vous prémunir d’avoir un produit qui ressemble à un cadavre exquis côté front et à un plat de spaghettis côté back :
- là où vous voulez emmener votre produit (la fameuse vision produit)
- les douleurs de vos utilisateurs
- l’offre concurrente sur votre marché
- la faisabilité technique et le coût associé
- les objectifs business que vous vous fixés
5- Faire des maquettes détaillées
On voit souvent des équipes projet qui présentent un cahier des charges accompagné de maquettes présentant les écrans du futur produit. Parfois, elles ont fait travailler un designer, et les maquettes sont très précises et détaillées, au pixel près.
Les personnes en charge du projet sont donc confiantes et ont l’impression qu’il n’y a plus qu’à transformer ces maquettes en fonctionnalités.
Pourquoi c’est une erreur ?
Le problème, quand on est déjà allés aussi loin, c’est qu’on a du mal à revenir sur ces maquettes, car on a beaucoup investi dessus. On a un rapport affectif aux maquettes qui empêche la remise en question. Sauf que lorsqu’on les teste auprès d’utilisateurs, on se rend compte que ça ne marche pas ! Parce qu’au lieu de questionner les problèmes des utilisateurs, on est directement passé à la phase “solution”.
Chez theTribe, nous designons des maquettes à la fin d’une étape de conception, pas au début du projet. Et nous les soumettons à plusieurs filtres.
D’abord, un exercice d’affinage, où Designer, Développeur et Product Manager apportent un regard croisé sur la solution. Chacun décortique et challenge le travail des autres et cela permet de s’assurer de deux choses : que les maquettes sont réalisables techniquement, et qu’elles répondent à un vrai problème utilisateur en se démarquant aussi des solutions existantes par ailleurs sur le marché.
Ensuite, lorsque nous avons réalisé des maquettes, nous organisons des entretiens avec des utilisateurs potentiels pour les challenger. D’expérience, au bout de 5 entretiens, on a déjà capté 80% des retours : on aurait donc tort de s’en priver !
À lire aussi : Quel rôle donner aux tests utilisateurs dans la conception d’un produit ?
6- Sous-estimer la charge de travail en interne
Souvent, les entreprises nomment un chef de projet ou PO (Product Owner) en interne, qui va être garant du bon déroulement du projet et de la relation avec le prestataire.
Cette personne peut être issue du métier (elle a donc des responsabilités opérationnelles à côté du projet tech), ou bien du département technique / IT (elle est donc souvent staffée sur d’autres sujets en parallèle).
On considère que cette personne est suffisante pour piloter le projet, et que le prestataire n’a pas besoin de nommer un Product Manager de son côté.
Pourquoi c’est une erreur ?
Malheureusement, cette personne n’est en général pas aussi disponible qu’il le faudrait.
Chez theTribe, nous mettons en place des rituels journaliers, nous communiquons de façon très soutenue pendant les sprints de développement et avons besoin de retours fréquents sur les développements en cours et les développements à venir. Nous demandons que la personne chargée du projet chez le client soit disponible 4 jours par semaine si elle souhaite prendre à sa charge l’intégralité des sujets produit à gérer : conception du produit, priorisation du développement, intégration des retours utilisateurs, mise sur le marché. Et c’est rarement le cas.
D’autre part, on demande à ces profils d’être compétents sur tous les sujets : design, développement, marketing, connaissance métier… C’est extrêmement rare dans les faits, et c’est normal.
Pour le bon déroulement du projet et la réussite du produit, il faut donc :
- Ne pas sous-estimer le travail du chef de projet ou Product Owner interne ;
- Accepter que le prestataire l’aide en nommant un Product Manager
7- Ne faire appel qu’à des profils techniques exécutants
Ce point rejoint le sujet précédent. Lorsque vous recevez le devis d’un prestataire pour le développement de votre produit, vous tiquez :
“Quoi, 10 jours d’UX design ? Mais on a déjà fait des maquettes !”
“Comment, 20 jours de Product Manager ? Mais on a déjà un Product Owner en interne !”
“Pardon, 5 jours d’architecte technique ? Mais on a déjà un CTO !”
Vous considérez que vous n’avez pas besoin de ces profils sur votre projet : vous avez déjà rédigé un cahier des charges, vous savez ce dont vous avez besoin. Ce qu’il vous faut, c’est une équipe de développement pour produire du code et exécuter votre plan.
Pourquoi c’est une erreur ?
Un produit numérique, ce n’est pas que du code. Pour qu’un produit existe, certes, il suffit de le coder. Mais pour qu’il soit désirable, viable, utilisable, il est impératif de faire intervenir d’autres profils : Product Manager, Product Designer. Dans les faits, 30% du coût d’un produit est créé par ces profils non techniques.
Mais à quoi servent-ils ? Entre autres, à penser à tout ce à quoi vous n’avez pas pensé. Désirabilité, déploiement continu, évolutivité, go to market, acquisition, viralité, rétention : vous ne pouvez pas avoir toutes les compétences en interne.
Le risque de se lancer tête baissée dans le développement d’un produit sans avoir fait intervenir des profils Produit, c’est de passer à côté de l’essentiel et de mettre sur le marché un produit à côté de la plaque où qui n’est pas dans les conditions nécessaires pour séduire ses utilisateurs.
À lire aussi : Notre métier, c’est de résoudre des problèmes, pas vendre des jours-hommes
8- Refuser les remises en question
Parfois, on voit des équipes qui refusent complètement d’être challengées sur leur cahier des charges et sur leur idée de ce que devrait être leur produit. Pas parce qu’elles sont sûres d’elles à 100% : justement, parce qu’elles ont peur de se tromper et ne se sentent pas prêtes à en assumer les conséquences.
Parce qu’elles ont passé tellement de temps à brainstormer en équipe, ont investi tellement d’énergie et d’argent sur ce projet, qu’elles refusent de se remettre en question : le risque leur semble trop grand.
Ces équipes sont confrontées au fameux biais cognitif des “coûts irrécupérables” : “Puisque j’ai déjà investi 10K€ sur ce projet, je refuse de tout reprendre à zéro, même si au bout du compte, cela me coûte plus cher au total.”
Pourquoi c’est une erreur ?
À toutes les étapes de la conception d’un produit, on peut être amené à découvrir que l’on s’est trompé quelque part.
Idéalement, il faut que cela intervienne le plus tôt possible : c’est justement pour cela qu’il est fortement conseillé d’interroger ses utilisateurs, de tester rapidement, et de bien s’entourer.
Cela veut aussi dire qu’il faut être capable d’écouter son prestataire, ne pas le considérer comme un simple exécutant, mais le laisser faire son devoir de conseil, dès le début du projet. C’est à la fois un enrichissement pour tout le monde, et la meilleure garantie contre une mauvaise surprise qui pourrait arriver trop tard.
In fine, accepter de se remettre en question, c’est le meilleur moyen à terme de maîtriser ses coûts et de garantir le succès du projet.
9- Ne pas avoir de stratégie de lancement
Ça y est, votre produit est en production !
Vous avez coché toutes les cases : vous l’avez testé auprès d’utilisateurs et tenu compte de leurs feedbacks, tous les bugs ont été corrigés, l’environnement technique est verrouillé, bref : maintenant, vous pouvez passer à autre chose.
Pourquoi c’est une erreur ?
Dans ce scénario, vous avez oublié quelque chose d’essentiel : la stratégie de lancement de votre produit.
Trop souvent, on voit des produits qui ne trouvent pas leur marché, qui ne sont jamais adoptés par les utilisateurs alors qu’ils apportent une vraie valeur, et ce pour une unique raison : leur lancement n’a pas été orchestré.
C’est en amont, dès la phase de conception qu’il faudrait penser au lancement du produit sur son marché :
- Comment va-t-on faire connaître le produit auprès de ses cibles ?
- Quelles stratégies d’acquisition ?
- Quel business model ?
- Comment va-t-on inciter les utilisateurs à utiliser le produit ?
- Quelle boucle de viralité et de recommandation peut-on mettre en place ?
- etc.
Si vous travaillez sur un produit qui sera utilisé en interne dans votre entreprise, vous pensez peut-être que vous n’êtes pas concerné, mais c’est une erreur.
Le lancement d’un outil interne doit aussi s’orchestrer : communiquer sur le produit, former les utilisateurs, mettre en place une documentation, identifier des “super-utilisateurs” et des promoteurs, mettre en place la collecte des feedbacks et le support… Tout cela se prévoit.
Chez theTribe, nous ne nous contentons pas de livrer des produits qui fonctionnent. Nous réfléchissons avec nos clients dès la phase de Design Sprint sur les aspects business et sur le go to market, parce que ce que nous voulons, c’est que nos clients réussissent à rendre leurs utilisateurs heureux. Ça sonne très marketing dit comme ça, mais c’est bien ce qu’on cherche à faire in fine.
À lire aussi : Design Sprint & Sprint 0 : l’importance de perdre du temps pour en gagner
10- Ne pas se projeter dans l’avenir du produit
Pour terminer, voici une dernière erreur, mais non la moindre, que nous tentons d’empêcher nos clients de commettre : et cette erreur, c’est de ne pas anticiper la suite !
Lorsque l’on travaille sur la conception d’un produit, on a tendance à se focaliser sur un seul horizon : celui de la mise en production. L’objectif, c’est de dérouler la feuille de route, et se concentrer sur celle-ci uniquement. On prend les sujets un par un, on les traite, sans prendre le temps de réfléchir : et demain ? Est-ce que ça marchera toujours ?
Pourquoi c’est une erreur ?
Lorsque vous lancez le MVP ou la V1 de votre produit, ce n’est que le début de l’histoire. Ce produit va évoluer, les utilisateurs vont demander de nouvelles fonctionnalités, il va peut-être falloir se connecter à des outils tiers, devoir supporter une charge de plus en plus forte, etc.
Si ces sujets ne sont pas anticipés en amont, on court à la catastrophe :
- Des bugs qui s’accumulent
- Une architecture pas suffisamment robuste
- Des problèmes de performances
- Des fonctionnalités qu’il va falloir casser et réécrire
- Des difficultés pour faire évoluer le produit
- Résultat, un produit bancal, avec une dette technique paralysante.
C’est le rôle du Product Manager que de vous aider à voir plus loin, à anticiper la suite et à vous projeter sur l’avenir de votre produit. Cela vous évitera bien des problèmes à l’avenir.
Chez theTribe, on vous évite de faire les erreurs qu’on a faites avant vous
Faire des erreurs, c’est humain. C’est normal et c’est comme ça qu’on apprend. Mais certains échecs n’apportent que de la frustration ; du temps, de l’argent et de l’énergie gâchés. C’est ce que chez theTribe, nous essayons d’éviter à nos clients.
Ces erreurs, nous les avons déjà faites nous-mêmes dans nos expériences professionnelles passées, nous les avons rencontrées chez des dizaines de clients. Le cumul de toutes ces expériences, nous le mettons à votre disposition, pour vous permettre de trouver le plus court chemin vers le succès.
