I. Introduction
Vous avez consacré de 3 à 12 mois à peaufiner votre plan de projet, vous assurant de ne rien laisser au hasard, en investissant des efforts considérables dans la planification. Vous avez minutieusement répertorié toutes les fonctionnalités nécessaires dans un tableau Excel comportant 200 lignes. Vous avez élaboré des maquettes détaillées de chaque écran, que ce soit dans Figma ou Powerpoint. De plus, vous avez établi un budget, nommé un chef de projet en interne, consulté différents fournisseurs et analysé des devis. Vous êtes convaincu que votre projet est sur la bonne voie et vous êtes confiant quant à sa réussite. Cependant, malgré vos efforts, les choses déraillent. La qualité, les délais, le budget – au bout de quelques mois, rien ne semble aller comme prévu. Cette situation vous semble familière ? Rassurez-vous, vous n’êtes pas seul dans ce cas. Mais alors, comment éviter que cette histoire ne se répète ?
Souvent, la cause des problèmes réside dans les fondations mêmes du projet. Lors du lancement d’un projet, on accorde une attention particulière aux détails, négligeant parfois l’essentiel. On croit gagner du temps en prenant des raccourcis, mais cela peut s’avérer coûteux. Dans cet article, nous examinerons les 10 erreurs les plus courantes commises par les équipes projet dans le domaine du web et de l’informatique lors du lancement d’un projet. Identifier et corriger ces erreurs constitue le meilleur moyen d’atteindre vos objectifs !
II.Dresser une liste exhaustive des fonctionnalités sur Excel
Lorsque nous travaillons en équipe sur le cahier des charges d’un nouveau site, d’un nouvel outil ou logiciel, nous aboutissons souvent à un tableau Excel répertoriant toutes les fonctionnalités que nous souhaitons intégrer à ce projet. Pour établir cette liste, nous sollicitons parfois les futurs utilisateurs et répertorions toutes les demandes sans les prioriser. En cas de refonte, nous listons toutes les fonctionnalités absentes du produit actuel dont nous pensons avoir besoin. Nous ne sommes même pas certains que toutes ces fonctionnalités soient réellement utiles, mais nous les incluons « au cas où » ou parce que nos concurrents les proposent. Ensuite, nous demandons à un prestataire d’estimer le projet sur la base de ce tableau.
Pourquoi est-ce une erreur ? Ce mode de fonctionnement ne favorise pas l’agilité ni les itérations permettant d’améliorer progressivement le produit développé. Il est préférable de démarrer avec un périmètre restreint et d’obtenir rapidement des retours des utilisateurs : cela permet souvent de réaliser que certaines fonctionnalités que nous pensions indispensables ne le sont pas, et que de nouveaux besoins auxquels nous n’avions pas pensé apparaissent. Cela évite ainsi des dépenses inutiles. Pour prioriser les sujets à lancer en premier, il ne faut pas partir de ce que nous croyons nécessaire dans le futur produit, mais identifier ce qui apportera réellement de la valeur aux futurs utilisateurs. Plutôt que de se fier à l’intuition des sponsors du projet et de développer le produit sur la base d’un cahier des charges, il est préférable de mettre rapidement ce produit, même imparfait, entre les mains des utilisateurs.
Chez notre Nxtya, nous interrogeons souvent les utilisateurs 30 jours après qu’ils ont commencé à utiliser un nouveau produit.
III. Exiger une estimation détaillée avant d'avoir défini le projet
Une fois que vous avez rédigé votre cahier des charges et répertorié toutes les fonctionnalités dont vous pensez avoir besoin, vous contactez des prestataires pour leur demander un devis. C’est compréhensible, car vous avez besoin de savoir si le projet rentre dans votre budget et de comparer différentes propositions.
Pourquoi est-ce une erreur ? Cela suppose que ce cahier des charges est suffisant pour établir une estimation détaillée, fiable et définitive. Or, ce n’est jamais le cas. Pour fournir une estimation fiable, il faut d’abord soulever le capot et identifier les risques potentiels. Est-ce que l’infrastructure cible est correcte ? Les outils peuvent-ils communiquer entre eux ? Y a-t-il des données à récupérer ? etc. C’est pourquoi nous aimons commencer les projets par un sprint d’investigation technique ou un POC. Ce cadrage préalable présente de nombreux avantages. Si votre prestataire s’engage sur un prix et que cela dérape, il sera contraint de faire des concessions soit sur la qualité, soit sur le périmètre fonctionnel. Certes, cela signifie se lancer sans connaître exactement le coût final, mais d’expérience, s’engager sur un forfait sans avoir cadré le projet entraîne toujours des dérapages. En moyenne, les coûts augmentent de 20 à 100 % par rapport au devis initial proposé par le prestataire.
IV. Définir le projet sans avoir consulté vos futurs utilisateurs
Vous êtes un expert dans votre domaine car vous êtes présent sur le marché depuis de nombreuses années. Par conséquent, vous avez de fortes convictions sur ce qu’il faut apporter sur le marché. Vous faites l’économie de rencontrer vos futurs utilisateurs. Puisqu’ils vont simplement valider vos intuitions, pourquoi dépenser entre 5 000 € et 10 000 € pour cet exercice ?
Pourquoi est-ce une erreur ? Vous ne construisez pas nécessairement un outil numérique pour vos clients actuels. Vous construisez un outil pour de nouveaux utilisateurs. Lorsque nous parlons d’utilisateurs, nous faisons référence aux 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 non à vos interlocuteurs actuels, qui ne correspondent pas nécessairement à votre cible d’utilisateurs de demain.
Chez nous, rencontrer nos futurs utilisateurs est le point de départ de notre démarche d’accompagnement. C’est à partir de leurs retours que nous concevons, priorisons et développons votre logiciel.
V. Répondre uniquement aux demandes de vos clients
Vous avez recueilli les besoins de vos clients et vous énumérez 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 pour répondre à un besoin client offre un gros avantage : votre client obtient exactement ce qu’il veut ! Les inconvénients : cela diminue l’évolutivité de votre produit, complique la maintenance, alourdit la compréhension de votre code et ralentit l’autonomisation de nouveaux développeurs.
Chez nous, nous travaillons sur la priorisation du développement de votre produit selon plusieurs critères pour éviter d’avoir un produit déséquilibré côté front et côté back. Nous prenons en compte la vision produit, les douleurs de vos utilisateurs, l’offre concurrentielle sur votre marché, la faisabilité technique et le coût associé, ainsi que les objectifs commerciaux que vous vous êtes fixés.
VI. Élaborer des maquettes détaillées
Nous voyons souvent des équipes projet présenter un cahier des charges accompagné de maquettes détaillées des écrans du futur produit. Parfois, elles ont fait appel à un designer et les maquettes sont très précises, au pixel près.
Pourquoi est-ce une erreur ? Le problème, lorsque nous sommes allés aussi loin, c’est que nous avons du mal à revenir sur ces maquettes, car nous y avons beaucoup investi. Nous sommes attachés émotionnellement aux maquettes, ce qui nous empêche de les remettre en question. Cependant, lors des tests auprès des utilisateurs, nous nous rendons compte que cela ne fonctionne pas ! Nous passons directement à la phase « solution » au lieu de questionner les problèmes des utilisateurs.
Chez nous, nous concevons des maquettes à la fin de l’étape de conception, pas au début du projet. Nous les soumettons à plusieurs filtres : un exercice d’affinage où différents membres de l’équipe apportent leur regard, suivi d’entretiens avec des utilisateurs potentiels pour les challenger.
VII. Sous-estimer la charge de travail en interne
Souvent, les entreprises nomment un chef de projet ou un Product Owner en interne, qui sera responsable du bon déroulement du projet et de la relation avec le prestataire.
Pourquoi est-ce une erreur ? Malheureusement, cette personne n’est généralement pas aussi disponible qu’il le faudrait. Nous avons besoin de retours fréquents sur les développements en cours et à venir, ce qui demande une disponibilité importante. Par ailleurs, cette personne doit être compétente dans divers domaines, ce qui est rarement le cas.
Pour le bon déroulement du projet et la réussite du produit, il est donc nécessaire de ne pas sous-estimer le travail du chef de projet ou du Product Owner interne et d’accepter l’aide d’un Product Manager de la part du prestataire.
VIII. Ne faire appel qu'à des profils techniques exécutants
Lorsque vous recevez le devis d’un prestataire pour le développement de votre produit, vous êtes surpris par certains éléments.
Pourquoi est-ce une erreur ? Un produit numérique ne se résume pas au code. Pour qu’un produit soit désirable, viable et utilisable, il est essentiel de faire intervenir d’autres profils : Product Manager, Product Designer. Ces profils apportent des compétences complémentaires nécessaires à la réussite du projet.
Le risque de se lancer tête baissée dans le développement d’un produit sans faire intervenir ces profils est de passer à côté de l’essentiel et de mettre sur le marché un produit qui ne répond pas aux attentes des utilisateurs.
IX. Refuser les remises en question
Parfois, des équipes refusent d’être challengées sur leur cahier des charges et leur idée de ce que devrait être leur produit.
Pourquoi est-ce 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. Il est nécessaire d’être capable d’écouter son prestataire, de ne pas le considérer comme un simple exécutant, mais de le laisser faire son devoir de conseil dès le début du projet.
Accepter de se remettre en question est le meilleur moyen de maîtriser les coûts et de garantir le succès du projet à long terme.
X. Ne pas avoir de stratégie de lancement
Une fois votre produit en production, vous oubliez l’importance d’une stratégie de lancement.
Pourquoi est-ce une erreur ? Un lancement bien orchestré est essentiel pour garantir le succès d’un produit. Il est nécessaire de réfléchir dès la phase de conception aux stratégies d’acquisition, au business model, à la rétention des utilisateurs, etc.
Nous réfléchissons dès la phase de conception sur les aspects business et sur le go-to-market, car nous voulons que nos clients réussissent à rendre leurs utilisateurs heureux.
Chez nous, nous mettons à votre disposition notre expérience pour vous éviter de commettre les mêmes erreurs que nous avons pu faire par le passé.
