L'estimation est fausse parce que le travail reste à découvrir

L'affirmation

Quand une estimation logicielle se révèle valoir la moitié du coût réel du projet, l'explication habituelle — la marge était insuffisante, l'équipe était optimiste — rate le mécanisme. L'estimation n'était pas trop basse ; c'était l'estimation d'un autre projet, plus petit, car l'essentiel du vrai travail n'avait pas été découvert quand le nombre a été produit. On ne peut pas estimer un travail qu'on n'a pas encore trouvé, et en logiciel, la découverte est l'essentiel du travail.

Pourquoi les estimations logicielles se comportent autrement

Estimer une construction physique fonctionne parce que les unités sont connues : un mur d'une longueur donnée exige une quantité connue de matériaux et un nombre connu d'heures, affinés sur des milliers de murs semblables. Le logiciel n'a pas d'équivalent, car si un travail était vraiment identique à quelque chose de déjà fait, vous le copieriez au lieu de le rebâtir. Chaque fonctionnalité réellement neuve est, par définition, un travail que personne n'a fait sous cette forme exacte, ce qui fait de l'estimation une prévision sur un territoire non cartographié.

La conséquence est une erreur systématique et unidirectionnelle. Le travail non découvert est presque toujours du travail supplémentaire — une intégration qui exige une étape de plus, une règle qui a une exception, un écran inutilisable jusqu'à sa refonte. La découverte révèle des choses à faire, rarement des choses qu'on peut sauter. L'erreur se compose donc dans le sens de la sous-estimation, de façon fiable, dans toute l'industrie.

L'estimation à trois points expose l'incertitude

Un seul nombre cache le peu qu'on sait. Demandez-en plutôt trois : le cas optimiste si tout se passe bien, le cas probable, et le cas pessimiste si le travail caché est important. Une pondération courante produit une valeur attendue utilisable :

attendue = (optimiste + 4 x probable + pessimiste) / 6

L'écart entre optimiste et pessimiste est le vrai résultat. Une fonctionnalité chiffrée à « 5 à 8 jours » est bien comprise. Une fonctionnalité chiffrée à « 3 à 30 jours » n'est pas une estimation — c'est l'aveu que le travail reste largement à découvrir, et la bonne réaction n'est pas de la moyenner mais de réduire l'incertitude avant de s'engager.

Rachetez l'incertitude par une exploration

Quand la fourchette est large, la réponse est une investigation limitée dans le temps — une exploration — dont le livrable est une meilleure estimation, pas du logiciel fonctionnel. Deux ou trois jours à bâtir un prototype jetable de la partie la plus risquée convertissent « 3 à 30 jours » en « on a trouvé les deux problèmes difficiles, c'est 9 à 12 ». Vous dépensez un petit montant fixe pour retirer un grand risque ouvert, ce qui est presque toujours un bon marché sur tout projet substantiel.

Cela recadre l'estimation, d'une supposition unique en un processus : estimer grossièrement, repérer les fourchettes les plus larges, dépenser un peu pour les resserrer, réestimer. Les projets qui dérapent sont habituellement ceux qui se sont engagés sur un nombre ferme et une date ferme alors que les fourchettes étaient encore larges.

Suivez votre propre ratio

Chaque équipe a un écart caractéristique entre ce qu'elle estime et ce que le travail prend réellement, et il est assez stable pour être utile une fois mesuré. Notez l'estimation et le réel du travail terminé sur quelques mois et calculez le ratio :

Une équipe qui tourne régulièrement à 1,7 n'a pas un problème d'estimation à réprimander ; elle a un multiplicateur connu à appliquer. Multipliez la prochaine estimation par le ratio mesuré et la prévision devient honnête. C'est plus fiable que de tenter de grossir les estimations brutes, car le multiplicateur capte le travail non découvert empiriquement plutôt que de demander aux gens de l'imaginer.

Ce que cela implique pour vos engagements

La conclusion pratique est d'ajuster l'engagement à la connaissance. Pour un travail bien compris à fourchette étroite, une estimation ferme convient. Pour un travail à fourchette large, engagez-vous sur l'exploration, pas sur la date de livraison — promettez d'en savoir plus dans une semaine, puis engagez-vous sur la livraison une fois que vous saurez. Et structurez le mandat pour que la direction puisse changer à intervalles courts, car la découverte qui fait exploser l'estimation est aussi celle qui vous dit si la fonctionnalité vaut la peine d'être terminée.

Une estimation est une affirmation sur ce que l'on sait, déguisée en affirmation sur le temps. Lisez la largeur de la fourchette, pas le milieu, et dépensez sciemment pour la resserrer avant de transformer une prévision en promesse.