Existe t-il une gestion de projet web ou logiciel qui soit une garantie de réussite, car répondant au plus près des attentes des utilisateur.trice.s en étant particulièrement réactifs, tout en respectant les budgets fixés ? Oui, et voici la recette.
La gestion de projet de nouvelles applications innovantes
Les développeur.euse.s créent des applications nouvelles qui n’existent pas encore : c’est de la création, quelque chose de nouveau que personne n’a encore jamais fait. Il ne s’agit donc pas d’actes répétitifs, connus et réutilisables, en face desquels on peut mettre un tarif parce qu’on sait exactement combien ça a coûté dans le passé : aucune application web n’est construite en copiant collant des fonctionnalités entières déjà existantes dans d’autres applications.
L’équipe technique ne sait donc pas encore avec quelles briques elle va construire ces nouvelles applications qui veulent se démarquer des autres sur le marché, ni comment elle va pouvoir agencer ces briques. Ce n’est qu’en démarrant le code, en écrivant les premières lignes des algorithmes, en testant plusieurs options, qu’elle réalise que certains outils choisis au départ ne sont pas adéquats pour certaines fonctionnalités, que l’organisation du code initiale doit être modifiée si on veut pouvoir maintenir l’application à l’avenir.
Une gestion de projet réactive aux attentes des utilisateur.trice.s
Plus encore, l’entreprise ne sait pas d’avance ce dont elle aura besoin dans un an, et souvent même dans les mois à venir. C’est normal. Seule l’utilisation des premières fonctionnalités livrées permet d’avoir des retours des utilisateur.trice.s. L’entreprise pourra alors réorienter différemment les objectifs au fil de l’eau en fonction de l’expérience qu’ils/elles viennent de vivre. L’objectif c’est la traction utilisateur. La priorité c’est de répondre à une réelle problématique, une réelle difficulté. C’est livrer des fonctionnalités à haute valeur ajoutée, au point de ne plus vouloir se passer de cette application web.
Les demandes de fonctionnalités initialement imaginées par l’entreprise ne cessent donc de changer en continu, leur priorité est sans arrêt revue. Suite aux retours des derniers tests utilisateur, certaines fonctionnalités prévues initialement sont abandonnées, de nouvelles émergent, et l’ordre dans lesquelles les développer en fonction de leur priorité est sans arrêt modifié.
C’est pourquoi, toutes les tentatives de planning et d’estimations sont vouées à l’échec. Personne n’est en mesure de chiffrer en amont une longue liste de fonctionnalités qui, de plus, pour certaines d’entre elles, ne seront peut-être jamais développées lorsqu’on réalisera qu’elles ne sont finalement pas souhaitées par les utilisateur.trice.s de l’application.
Chez Squadracer, on pense que la gestion de projet au forfait est vouée à l’échec
Le forfait est un faux moyen de se rassurer, qui se retourne invariablement contre l’entreprise en créant de faux espoirs, et qu’elle utilise ensuite pour assigner des pénalités de retard qui dégradent les relations avec l’équipe technique : toute estimation étant fausse, tout budget et deadline fixés sur la base de ces estimations seront forcément dépassés.
https://www.commitstrip.com/fr/2012/04/24/the-wheel-of-estimation
Du coup, de nombreuses ESN ont pris le parti de surestimer, parfois même, de façon démesurée, les montants au forfait, afin de se couvrir un maximum.
C’est ce que certaines appellent : la contingence.
https://www.larousse.fr/dictionnaires/francais/contingence/18607
Des entreprises, non sans avoir essayé de nombreuses méthodes d’estimations sur de longues années, ont fini par le comprendre. Comme le coach Agile et Craft Frédéric Leguedois l’explique : le principal problème des méthodes d’estimation est qu’elles ne sont jamais fiables. Des chefs de projet estiment les délais en relisant plusieurs fois le cahier des charges (la fameuse méthode du doigt mouillé). Des clients présentent trop brièvement leurs besoins pour qu’une estimation cohérente soit effectuée. « On veut d’abord connaître le budget nécessaire, on précisera nos spécifications plus tard. Essayez cette méthode avec votre épicier, passez le voir en lui demandant simplement combien cela va vous coûter sans lui dire précisément ce que vous souhaitez acheter. Il n’y a que dans l’informatique que ce genre de méthode perdure ».
https://www.commitstrip.com/fr/2018/02/05/it-project-estimates/
La gestion de projet avec la méthode agile : fixer le budget => adapter le périmètre fonctionnel
La seule façon de garantir la réussite d’une gestion de projet en respectant le budget fixé au départ, c’est de jouer sur le périmètre des fonctionnalités développées.
La solution c’est donc de demander à l’entreprise, pour chaque fonctionnalité ou pour de très petits lots de fonctionnalités, combien elle souhaite mettre en face : quel est le budget ou le délai que l’entreprise ne veut pas dépasser pour ce lot de fonctionnalités ? Il convient donc de découper le périmètre de l’application en fonctionnalités les plus petites possibles. Une fois le budget et/ou les délais fixés pour un petit lot de fonctionnalités, l’équipe technique sait qu’elle a tant de jours pour livrer la meilleure version possible de ces fonctionnalités. Elle va faire en sorte de livrer dans tous les cas un produit de qualité qui fonctionne et qui répond à l’objectif principal, en essayant d’inclure un maximum d’UX/UI ou d’autres fonctionnalités qui améliorent l’expérience utilisateur (mais dont l’absence n’empêcherait pas les utilisateur.trice.s de bénéficier de l’essentiel).
Le budget et les délais fixés au départ seront donc respectés. Le produit livré correspondant permettra de recueillir les retours des utilisateur.trice.s qui orienteront à leur tour l’application vers de nouveaux lots de fonctionnalités prioritaires qui ne seront pas forcément ceux imaginés au départ. Seule la réalité des tests et de l’expérience des utilisateur.trice.s peut diriger les objectifs de l’entreprise.
La gestion de projet agile permet de changer d’avis
Aucun engagement n’étant pris sur le périmètre fonctionnel, tout changement de ce périmètre sera alors possible. L’entreprise a ainsi un sentiment de liberté qui lui permet de changer d’avis chaque fois que nécessaire. Il est normal de changer d’avis. La réactivité de l’application est alors à son maximum, totalement orientée vers l’objectif de répondre rapidement aux attentes des usagers, donc sur la traction utilisateur.
Je laisse Frédéric Leguedois conclure :
« Ceux qui ont connu les projets non-satisfaisants au forfait vous comprendront. La variable d’ajustement doit toujours être le périmètre d’un projet et non pas sa qualité, son coût ou son délai. Rien n’est indivisible, tout constitue un ensemble de fonctionnalités. Quand on commence par les fonctionnalités prioritaires, quand on a confiance dans les développeurs, quand on arrête de faire des promesses, quand on s’adapte au contexte, on est vraiment dans l’agilité et les projets réussissent ».
?">