Lorsque j'étais un jeune développeur, je devais développer des fonctionnalités en fonction d'estimations qui étaient données par des développeurs plus expérimentés. Si j'avais besoin de plus de temps, je devais en fournir les raisons - et j'avais intérêt à être convaincant. Après quelques années, je suis devenu celui qui fournissait les estimations sur les fonctionnalités, mais cela n'a pas signifié que c'était devenu plus aisé : si l'équipe de développement prenait plus de temps, je devais le justifier à mon management. Maintenant, plusieurs années encore après, je dois fournir des estimations pour des projets entiers et non plus pour des fonctionnalités fines.
Mais au fond, pourquoi avons-nous besoin d'estimations ? Pour les sociétés suffisamment importantes, elles sont requises par les processus internes. Quelque soit le processus, il ressemble à peu près à ceci : afin de démarrer un projet, on a besoin d'une estimation pour faire la demande d'un budget, qui sera approuvé (ou pas) par le management.
Devinez quoi ? Ca ne fonctionne pas, ça n'a jamais fonctionné et je suis sûr que ça ne fonctionnera jamais.
Note : Certaines organisations sont suffisamment fines pour le reconnaître et associent un facteur de confiance aux estimations. Dommage que ce facteur n'ait pas sa place dans les feuilles Excel et qu'il se perde à un moment dans les aggrégations de données :-(
Malheureusement, mon expérience est la suivante : les estimations sont presque toujours sous-évaluées ! La plupart du temps, en voici les conséquences (qui ne sont pas forcément exclusives) :
- En général, la première option est d'annuler tous les congés prévisionnels des membres de l'équipe. La seconde étape est de les faire travailler plus longtemps, puis de réduire les week-ends pour qu'ils travaillent 6 jours sur 7. Bien qu'efficace sur le court-terme, cette tactique réduit la productivité de l'équipe très rapidement. Les gens ont besoin de repos et de moral - et les développeurs sont aussi des personnes !
- Après la pression sur l'équipe de développement, vient le temps de la négotiation. Dans cette phase, le management de projet va vers le client et tente de marchander pour supprimer des pans entiers du périmètre du projet (pour peu qu'il n'ait jamais été défini...). Toutefois, même si le périmètre est réduit, ce n'est en général pas suffisant pour finir celui-ci dans les temps et en respectant le budget.
- La dernière étape est la plus douloureuse : retourner vers le pouvoir en place et demander plus de budget. C'est douloureux pour le management, car cela revient à reconnaître leur échec. A ce moment, oubliez le planning initial.
- Pendant ce processus et bien après, le management communiquera que tout se passe bien et se déroule suivant ce qui était prévu. La nature humaine...
Dans certains cas (par exemple une réponse à appel d'offres), c'est encore pire car le chef de projet se plaindra fréquemment (toujours ?) que les estimations sont trop élevées et vous mettra la pression pour en avoir de plus basses, bien que la baisse des estimations ne diminue pas la charge de travail.
Vous pourriez vous demander pour quelles raisons sont-elles toujours erronées. Et bien, ce n'est pas le but de ce billet, mais ma réponse préférée est que l'Ingénierie Civile est vieille d'environ 5 000 ans et que les ingénieurs civils fournissent rarement des estimations correctes. Notre profession est vieille d'à peine 50 ans, alors que méthodologies et technologies changent tout le temps.
Je ne suis pas un méthodologue, pas un chef de projet, pas un Scrum master... juste un architecte logiciel. Je ne sais pas si l'agilité sauvera le monde ; toutefois, j'ai été le témoin direct que chaque estimation préalable s'est révélée un échec. Je ne peux participer à ce jeu de dupes qu'un moment, car nous sommes tous destinés à perdre en y prenant part.