Pourquoi les développements sont plus longs que prévu ?

Il est bien connu que les projets informatiques ne respectent pratiquement jamais leurs délais. La loi de Hofstadter indique non sans humour :

« Une tâche prends toujours plus de temps que prévu, même si vous prenez en compte cette loi ».

Plusieurs des lois de Golub reviennent aussi sur ce phénomène:

« Aucun grand projet informatique n'est jamais mis en place dans les délais, dans les limites du budget, avec le même personnel qu'au départ, et le projet ne fait pas ce qu'il est censé faire non plus. Il est fort improbable que le nôtre soit le premier. »

« Un projet mal planifié prendra trois fois plus de temps que prévu. Un projet bien planifié prendra seulement deux fois plus de temps. »

Une fois la satisfaction de l’ironie, du cynisme et de l’autodérision passée, la vraie question à se poser est : pourquoi ?

Même si les chefs de projets rejettent en général la faute de ces dérives sur les dépendances externes, ou sur les modifications demandées en court de route par le client, il faut aussi admettre qu’une des causes principales est la mauvaise estimation des délais nécessaires aux tâches de programmation. Dans un récent article, j’ai lu une explication que j’ai trouvée un peu rapide, et qui m’a amené à réfléchir aux nombreux cas que j’ai dû traiter avec des équipes projets en difficulté.

En effet, il est vain de chercher une explication générale, car de très nombreux phénomènes sont à l’œuvre pour induire ces retards :

• La perspective : de même qu’une montagne lointaine parait petite, une tâche éloignée parait plus simple, car on n’en voit pas tous les détails. Quand on estime une tâche, on fait une simulation mentale de ce qu’il y aura à faire. On ne rentre pas dans les tous les détails car sinon, cela revient à pratiquement à la réaliser complètement d’avance. Donc par conséquent, si on s’en tient aux charges imaginées, on en néglige nécessairement une partie …
• La sous-estimation par fierté: les développeurs technophiles sont en général très optimistes sur leur capacité de réalisation des développements informatiques. Ils sont très fiers de leurs connaissances et de leur capacités, se croient en général plus compétents que leurs collègues et donc sous-estiment chroniquement le temps qu’il leur faut pour réaliser une tâche. Si la tâche est estimée par eux, et réalisée par leurs collègues, la dérive dans le temps de la réalisation les conforte dans leur croyance de supériorité. Ceci relativise d’ailleurs les techniques d’estimation collective comme le poker planning de scrum si les groupes impliqués sont trop marqués par cette tendance.
• « Cà va marcher du premier coup ». Les tâches de développement ont cette particularité qu’elles ne sont finies que quand le programme fonctionne. Il faut donc aménager du temps dans l’estimation pour vérifier que le résultat produit par le développement est conforme à ce qui est attendu (les tests unitaires). Or il est très difficile dans certains cas de prévoir combien de fois il faudra revenir sur le programme et refaire le test pour qu’il finisse par marcher, ou combien d’effort il faudra pour corriger certains problèmes. Face à cette difficulté, la tendance est d’imaginer que le développement marchera du premier coup, ce qui est bien sûr faux en moyenne.
• Le peaufinage. Comme ils prennent du plaisir à programmer et aiment leur métier, certains développeurs ne voient pas le temps passer, s’intéressent à des détails peu importants, refont plusieurs fois une partie de code pour parvenir à un résultat parfait, bref dépassent allègrement leur estimation initiale, mais bien sûr pour d’excellentes raisons …
• La loi de Parkinson, qui stipule que
  

  « le travail s’étale de façon à occuper le temps disponible pour son achèvement. »

  En effet, la tendance naturelle face à une situation confortable est de prendre son temps, de ralentir en quelque sorte suffisamment pour vérifier la prédiction. Toute tâche remplit donc au minimum le temps prévu initialement. Ceci annihile toute chance de rattrapage des dérives calendaires d’un projet par des tâches surestimées et explique pourquoi les provisions de délais ou les marges sont systématiquement consommées.
• La procrastination, c'est-à-dire la propension à remettre systématiquement au lendemain les tâches difficiles. Ceci se produit quand les tâches élémentaires sont trop longues, ce qui amène le développeur à pouvoir choisir par quoi il va commencer. La tendance naturelle sera alors de repousser les tâches apparemment plus complexes à la fin, pour commencer par les plus simples. Ceci n’est pas forcément conscient, et s’apparente à un déni : la peur d’affronter une tâche difficile crée une angoisse, et c’est bien le report le plus tard possible qui permet de l’oublier un temps pour la contrôler. L’estimation du reste à faire s’en trouve faussée, car au début le développeur accordera faussement à la tâche repoussée la même difficulté que les autres, et les tâches simples avanceront à un bon rythme. Ce n’est qu’en approchant de l’échéance qu’ils reprendront conscience du problème et que l’angoisse renaîtra. Le reste à faire remontera donc, mais trop tard pour pouvoir réagir.
• Une variante de ce phénomène est la dissimulation: les développeurs peuvent rester bloqués sur un problème sans le signaler. Soit par timidité, soit par peur de critiques. Ils préfèrent parfois attendre le moment où il est évident qu’ils n’auront pas fini à temps pour le signaler. Ce problème est typique des situations de management où les gens sont jugés uniquement sur le résultat et non sur la méthode employée pour y parvenir, ce qui arrive quand le chef ne comprend pas le travail concret de ses subordonnés.

Et cette liste n’est sûrement pas exhaustive... Les deux derniers points expliquent d'ailleurs une autre des exagérations humoristiques des lois de Golub :

« Les projets progressent rapidement jusqu'à 90%, puis ils restent achevés à 90% pour toujours. »

Il n’est donc pas surprenant que les projets ne soient pas à l’heure. Ce qui est surprenant, c’est quand le contraire arrive parfois … Peut-être que certains chefs de projet ont trouvé des solutions à tous ces problèmes ?