Sélectionner une page

S’il est bien une tâche difficile, c’est d’estimer le temps que prendra la conception d’un logiciel. On ne parle pas ici des « petits » logiciels qui prennent moins de 3 semaines de travail pour une seule personne mais de tous les autres qui font intervenir plusieurs personnes et nécessitent une vraie gestion de projet. Dans ce second cas, celui qui arrive à estimer les temps de développement est une super star.

Le développement de logiciel c’est comme l’exploitation d’un puit de pétrole : il faut des plans de départ très précis, un personnel bien outillé et dôté de compétences pointues, de managers qui sachent tenir leurs équipes et imposer leur visions et objectifs. Malgré cela, on ne sait jamais sur quoi on peut tomber. Les meilleures prévisions peuvent être mise en faillite parce qu’un petit grain de sable (façon de parler) vient tout perturber. En informatique, ce peut être une technologie limitante sur un point de détail qui n’en est finalement pas un, une nouvelle percée technologique qui bouscule tout le projet, un aspect « évident » dans le cahier des charges mais qui a été interprété différemment par le prestataire ou le client, un problème de licence qui prend du temps et qui bloque la progression de tous ou encore un vilain bug qui joue à cache-cache avec l’équipe technique.

Il faut savoir qu’historiquement, 95% des projets informatiques sont des échecs (car ils dépassent le budget initial prévu et/ou le temps estimé et/ou ne sont pas satisfaisants d’un point de vue fonctionnel). À relativiser en fonction de la taille et la complexité des projets, des compétences de chacun, du calendrier imposé et des livrables attendus…

La règle pour le chef de projet débutant (mais qui a déjà prouvé son expertise technique), c’est d’estimer large – très large. Après avoir décortiqué le projet au mieux, il suffit de faire x2 puis encore x2. Avec ça, le projet devrait à peu près être réalisable.

Cette approche à la louche (qui n’est jamais donné aux clients) n’est quand même pas très pro. C’est pour ça qu’elle est de plus en plus mise de côté et remplacée par une approche agile : on se met d’accord sur un montant max, un coût jour/homme et on avance au fil de l’eau. Ça permet de faire des modifications en cours de route et surtout ça permet de travailler au mieux. C’est la garantie pour le prestataire d’être payé et de ne pas bacler le boulot. Et pour le client, c’est la sécurité de ne payer que ce qui est réalisé tout en pouvant demander des ajustements en cours de route.

Photo : PL Conseil