A l’occasion du festival Web2day 2018 (Nantes), j’ai participé avec beaucoup d’enthousiasme à la délicieuse conférence de Frédéric Leguedois (Agile Evangelist) : « cessons les estimations ! ».
Les estimations ? Mais quelles estimations ? Un intitulé plein de suspense pour des réponses pleines de bon sens. Pendant 40 minutes, Frédéric nous a fait réfléchir sur cette idée trop répandue que la réussite d’un projet digital repose sur seul critère, pourtant bien arbitraire : son bon respect du planning prévisionnel et des délais annoncés ! Mais… se demande-t-on assez souvent si ce planning est vraiment fiable ? D’ailleurs, a-t-on seulement besoin de lui ? Allons même plus loin : et si ce planning était la cause de tous les ratés ? Ces questions méritent en tout cas d’être posées.
Un vrai show… et du vécu !
Pas de power point, pas de vidéos ou de gifs animés… dès le départ, la conférence s’annonce différente et notre animateur d’un jour ne manque pas d’en annoncer la couleur : « je me suis levé d’humeur taquine, ne vous attendez pas à du politiquement correct. Et je vous préviens, les chefs de projets vont en prendre pour leur grade ». Les voici prévenus.
Promesse tenue : pendant toute son intervention, Frédéric Leguedois occupe la scène avec habileté et un discours entraînant. Un véritable one-man-show avec du fond, des anecdotes et la porte ouverte à des réflexions qui nous renvoient forcément à notre quotidien, nous les professionnels de la com’ et du digital. Nous, les défenseurs de l’agilité et de la disruption. Parce que savoir prendre du recul et se remettre en cause est incontestablement le premier pas vers le changement.
Point de départ : les méthodes classiques, Agile, SCRUM… accordent trop d’importance aux estimations !
Les estimations sont la base de tous nos modèles. On estime des délais, des résultats, pour en faire des plannings. On va jusqu’à les contractualiser en prévoyant dans certains cas des pénalités de retards. Notre quotidien est une véritable dictature des estimations, qui gèrent nos projets, et même parfois notre management. Nous avançons jour après jour avec une question omniprésente : « où en est-on par rapport au planning estimé » ?
Le respect du planning, une garantie de réussite ?
C’est d’ailleurs cette estimation qui devient notre seule base pour juger si un projet est une réussite ou un échec. On se satisfait quand un logiciel est livré dans les temps, avec une formidable sensation de mission accomplie lorsque les délais sont tenus : mais peut-on considérer que le résultat est positif si personne ne se l’approprie ? S’il n’est pas complètement fonctionnel ? Est-ce que le fait de respecter ce qu’on a prévu il y a plusieurs semaines/mois est suffisant pour être satisfait ? Puisque rappelons-le : un planning n’est qu’une prévision qui repose sur des bases plus ou moins subjectives.
Le syndrome du : « mon planning était bon mais… »
On l’a tous déjà entendu. Lorsque le planning n’est pas respecté (ce qui arrive quand même régulièrement pour plein de raisons), plusieurs prétextes sont évoqués par le chef de projets, retranché dans ses bases et exaspéré que son planning, qu’il a pourtant fait avec soin et « méthode », n’ait pas été suivi.
Prétexte 1 : « le client a changé d’avis ! »
Oui, c’est vrai. Mais un client change toujours d’avis ! C’est presque une norme et il faut en tenir compte, on ne peut pas jouer les surpris à chaque fois que cela retarde un projet.
Et quand bien même ? Frédéric L. le souligne très justement : « un client qui change d’avis est un client qui réfléchit », alors peut-on lui en vouloir ? Cette réflexion, si elle est bien menée, bien accompagnée, ne peut être que bénéfique pour le produit et l’utilisateur… mais effectivement, incompatible avec un planning. Parce qu’elle ne peut pas être « prévue », « anticipée ».
Un client change toujours d’avis, c’est la norme… Mais c’est signe qu’il réfléchit !
Prétexte 2 : « l’équipe n’a pas respecté les délais ! »
Mauvaise réponse ! Selon Frédéric L., « le retard est toujours à imputer à ceux qui gèrent le planning et jamais à ceux qui produisent. Si on veut aller jusqu’au bout du raisonnement et le pousser à l’extrême, même si une équipe est sous-performante, cela doit être anticipé dans les estimations, en prédisant un délai plus long dès le départ. »
D’ailleurs, qu’est-ce qu’on entend par retard ?
« Le retard n’est rien d’autre qu’une différence de délais entre ce qu’on a prévu et ce qui s’est réellement passé. Autrement dit, entre le rêve et la réalité. Et dans ce contexte, comment pourrait-on donner tort à la réalité ? »
Mais quelles sont finalement les conséquences de la planification ?
« Les estimations sont la seule et unique manière de rater un projet avant même de le commencer ». OK, c’est peut-être un peu fort, mais prenons un exemple concret pour le justifier.
Nous sommes dans une agence digitale, et les développeurs ont une deadline fixée pour un gros projet, au hasard le vendredi soir. Nous sommes vendredi, fin d’après-midi et le projet est « à peu près fini ». Le « à peu près » a ici toute son importance.
2 situations :
1) Nous sommes dans un contexte où les développeurs risquent de se faire engueuler si ce n’est pas fini dans les temps : ils ne disent rien et envoient le lien, même s’il y a un risque de bugs. Comme ça, la « mission est accomplie ».
2) On leur fait une remarque bienveillante, en restant compréhensif : ils vont continuer de travailler sur le projet jusqu’à ce que le produit soit parfait, que tout fonctionne, bref : ils vont aller au bout de leur travail.
Quelle option sera la plus bénéfique pour le client ?
Le problème, c’est l’engagement.
A partir du moment où on a pris des engagements, on ne peut plus faire face à des imprévus. Parce qu’un imprévu, même si c’est une bonne idée, dès lors qu’il n’est pas dans le cahier des charges, fera forcément « planter » le planning.
« La planification est une lutte implacable contre l’intelligence. »
Et surtout on met les développeurs dans des positions de simples exécutants !
« Vous devez faire cela pour telle date, point. ». On s’embête donc à recruter des gens qui sont diplomés, avec de l’expérience et une logique normalement un peu meilleure que la moyenne, pour leur demander d’appliquer bêtement.
Alors que c’est normalement du développeur que peuvent venir les meilleures idées et optimisations, il sait mieux que personne ce qu’il peut faire et comment. « Un développeur c’est comme un dromadaire : il n’a pas besoin de grand-chose, un ordinateur, de l’électricité, un peu de clim… mais du temps ! »
Bref, on pourrait continuer ce débat encore longtemps, mais l’idée principale est bien transmise : et si on arrêtait d’avancer tête baissée pour se poser les bonnes questions ? Et surtout, si on cessait de tout faire reposer sur des estimations ?