Tribune – Il est des habitudes qui ne sont jamais remises en question. À tort. Par Frédéric Leguédois, directeur du pôle agile chez Cloud Temple Grand Ouest.
Prenez les estimations sur les projets de développement logiciel ; Les estimations de charges pour prédire les coûts, et les estimations de délais via le “sacro-saint planning”, constituent le socle de la gestion de projet. La tradition est telle, que nous considérons qu’il s’agit là d’un impératif, d’une obligation. Or la question mérite d’être posée.
Doute sur la pertinence des estimations
Les estimations sont présentes partout :
– avant même le début d’un projet, pour concrétiser la vente, tout prestataire s’engage à respecter des
coûts et des délais ;
– en phase de contractualisation, avec l’exercice de fixation des pénalités de retard ;
– et à l’issue du projet, lors de la vérification du respect des engagements.
On s’aperçoit alors que le principal critère de succès d’un projet est le respect des engagements initiaux. A-t-on été bon dans l’estimation initiale ? Le succès d’un projet ne serait donc pas lié au bon fonctionnement du livrable ? Ni à l’adoption en masse de l’outil par les utilisateurs ? Ni à l’aspect financier présentant un fort et rapide retour sur investissement ?
Un projet hors délais et hors budget, largement adopté par les utilisateurs, avec un ROI exponentiel, serait-il véritablement un échec ?
Les méthodes afin de réaliser des estimations sont pléthoriques
Depuis plus d’un demi-siècle, constatant que les méthodes précédentes étaient peu fiables, chacun a proposé la sienne. Elles ont toutes un point commun, ce sont des prédictions sur l’avenir… Des activités irrationnelles. Parmi les plus connues, il y a celle où après avoir pris connaissance d’un cahier des charges, l’estimateur met en œuvre les deux seuls processus intellectuels disponibles à cet instant : le “doigt mouillé” et “le pifomètre”, pour vous annoncer un nombre de jours de charge et un planning précis. Certaines méthodes d’estimations sont très élaborées, Cocomo par exemple qui comporte moult formules mathématiques pour paraître éminemment scientifique. Néanmoins, cela suppose que ces informaticiens connaissent, avant de commencer à développer, le nombre de lignes de code qu’il y aura à la fin du projet… Un
défi que ne renierait ni les cartomanciens, ni les oracles.
Les méthodes agiles ont, elles aussi, apporté leurs méthodes de prévision, tel le planning poker, les rendant
moins hasardeuses :
– les estimations sont faites par les développeurs, expert dans la réalisation de travail à effectuer ;
– en discutant directement avec le client ;
– sur un périmètre fonctionnel très délimité.
Pour autant, le planning poker reste inutilisable avant d’avoir commencé le projet. Il est chronophage, et donc coûteux. Par ailleurs, quel est l’intérêt de deviner ce qui sera livré dans deux semaines ?
Les inconvénients des estimations
Lorsque l’échéance est atteinte et que le travail n’est que partiellement réalisé, deux possibilités s’offrent aux développeurs : annoncer qu’ils ont besoin de plus de temps, ou livrer au client en l’état avec tous les bugs que cela implique. Plus la date butoir est forte, moins la qualité sera au rendez-vous. Quant à la dette technique, à défaut de pouvoir réaliser le travail correctement, de nombreux raccourcis seront pris. Résultats :
– une diminution des évolutions du logiciel ;
– une perte de connaissance technique et fonctionnelle ;
– des évolutions plus longues, coûteuses et risquées ;
Le meilleur arrive quand il est annoncé au client “qu’il coûte moins cher de tout redévelopper que de réaliser une modification sur le logiciel”, symptôme de la perte complète de la maîtrise du projet.
L’environnement dans lequel évoluent les organisations est fluctuant
Un concurrent lance un nouveau produit, les décrets d’applications de loi sont publiés, une opportunité de croissance externe surgit, etc. Autant d’événements, non planifiables, qui peuvent nécessiter d’adapter les applications rapidement. Dans le même temps un client qui aura exprimé le souhait d’un logiciel ayant telles ou telles fonctionnalités, sera amené à changer d’avis car il devra réfléchir à son besoin, le concerter et le mûrir. Si les estimations paraissent rassurantes de prime abord, si elles donnent une impression de maîtrise, elles sont un piège qui se referme progressivement sur le client. Finalement, le prestataire rejette toute proposition d’évolution du logiciel sous prétexte de respecter ses engagements.
Le besoin d’estimation n’est-il pas tant une nécessité métier que le signe d’une défiance (du client vers son prestataire ou du manager vers ses équipes) ? Si la “deadline”, la limite mortelle, n’est pas respectée des mails “assassins” partirons parce que des personnes “ont la tête sur le billot”. Une culture mortifère, où la peur est le fondement du management. À l’opposé d’une culture basée sur la prise d’initiatives individuelles, sur l’envie, sur le renforcement positif dont les sociétés ont tant besoin dans leur organisations.
Le mouvement “no estimate”
Le mouvement “no estimate” n’est pas une utopie, et ceux qui le pratiquent au quotidien le savent. L’important est la pertinence des fonctionnalités pour les utilisateurs et la valeur créée par le logiciel pour le client. Mais cela nécessite du courage afin de remettre en cause l’ordre établi et beaucoup d’imagination pour tout réinventer : la vente, la contractualisation, les interactions entre clients et prestataires, mais aussi le management des développeurs et la gestion du projet.
Avec le “no estimate”, les clients pourront piloter leurs projets très finement afin d’avoir les fonctionnalités dont ils ont vraiment besoin. Ils bénéficieront d’un accompagnement tout au long de la vie du projet, quelle que soit la direction prise.
Redonnons au client le pouvoir trop longtemps confisqué : changer d’avis sur son projet.
