11 lois de l’estimation pour les travaux complexes

Les mauvaises estimations ne sont pas de votre faute, mais elles sont définitivement votre problème

Nous sommes au début des années 2000. J’étais assis seul dans une salle de réunion et j’attendais avec impatience l’entrée de mon manager.
J’avais été convoqué pour une réunion soudaine. Mon manager m’avait dit que la réunion était urgente et importante, et que je devais abandonner tout ce que je faisais pour y venir.
J’étais depuis cinq mois dans mon premier emploi en tant que Product Owner. Ma période d’essai était presque expirée, alors j’étais assis là, inquiet et je réfléchissais à mon avenir au sein de cette organisation.
Finalement, la porte s’ouvrit et il arriva avec un sourire radieux. Immédiatement je me suis détendu. Je me souviens encore de ses premiers mots : “Nous venons de décrocher l’un des plus gros contrats de l’histoire de notre entreprise. J’ai besoin que tu travailles sur un nouveau projet passionnant.”
Quand j’ai entendu les mots “passionnant” et “nouveau”, je me suis crispé de nouveau. J’ai commencé à me demander: “Où est le piège?”.
Il a déclaré: “Pour conclure l’affaire, nous avons promis au client un développement personnalisé sur notre produit. Je vous fais confiance pour livrer ces fonctionnalités à temps afin que nous puissions finaliser l’accord.”
“Ah… voilà le hic”, ai-je pensé.
La conversation s’est terminée par les fameux derniers mots : “Ne t’inquiète pas, ce qu’ils veulent, c’est vraiment basique.”
Ce qui s’était passé, c’est que nos CTO et CEO avaient décidé ensemble que ce que le client demandait était simple et facile à produire. Ils ont également conclu que cela serait bénéfique pour de nombreux autres clients.
En tout et pour tout, j’ai reçu une liste de sept bullet points. C’est tout. Je devais livrer ces sept fonctionnalités en douze semaines. Je n’avais pas été impliqué dans l’estimation, ni aucun membres des équipes.
Je me suis immédiatement mis au travail. Après avoir discuté quelques minutes avec un développeur senior, j’ai ressenti un sentiment de malheur imminent : il n’y avait aucun moyen de respecter le calendrier promis. J’ai été surpris que nous signions un accord promettant quelque chose que nous ne pourrions jamais livrer. Si quelqu’un avait parlé à un seul développeur, il serait arrivé à la même conclusion.

Les commerciaux avaient fait les estimations sans impliquer aucune équipe… aucun équipiers. Ceux qui étaient au sommet ont frotté leur boule de cristal, inventé une date et l’ont jetée par-dessus la clôture aux équipes.
Maintenant, c’était notre problème de respecter ce calendrier fou. Et quand j’ai confronté mon manager à la pure folie de ce qu’il me demandait, il m’a dit : “Vous compliquez trop les choses. Restez simple.”

Des estimations insensées nous ont condamnés dès le départ

Nous ne pouvions pas livrer à temps : ces nouvelles fonctionnalités nécessitaient de faire évoluer l’ensemble de notre produit. Il y avait des impacts chez une dizaine d’équipes différentes.
Après une courte discussion avec les équipes, nous pensions que la première de ces sept nouvelles fonctionnalités prendrait au moins deux mois à produire. Après cela, nous aurions une fondation, un socle, et nous serions en mesure d’estimer avec un peu plus de certitude les autres fonctionnalités. Mais je pouvais déjà garantir que cela ne prendrait jamais douze semaines au total. Il y avait trop de travail et trop d’équipes différentes impliquées.
Ce qui était encore plus intéressant, c’est que même si la mauvaise estimation n’était pas de ma faute, c’était définitivement mon problème maintenant.
Ceux qui ont créé ce gâchis m’ont dit de “comprendre” et de “faire en sorte que ça marche”. J’avais beaucoup de questions sur les fonctionnalités à créer. On m’a répondu “Je n’ai pas le temps pour ça. Faites ce que vous pensez être le mieux !”.
Génial, comme si ce n’était pas déjà assez difficile !
Lors de la première conversation avec le client, j’ai immédiatement annoncé la mauvaise nouvelle. J’ai fait une contre-proposition pour livrer la première fonctionnalité plus tôt que prévu. J’ai également promis de travailler activement avec eux pour inclure leurs retours dans des développement ultérieur. Je leur ai également fait savoir que le reste des développements prendrait probablement plus de temps, et qu’après avoir livré cette première pièce, j’aurais une meilleure idée de combien de temps.
Heureusement, le client a accepté, même s’il n’aurait en aucun cas été obligé contractuellement d’accepter.
En fin de compte, l’ensemble du projet a pris plus d’un an à livrer. Heureusement, nous avons pu satisfaire le client car nous avons travaillé en étroite collaboration avec lui et géré ses attentes.
Que pouvons-nous faire pour éviter de nous retrouver dans des situations douloureuses et difficiles comme celle-ci ? Pourquoi nos estimations sont-elles souvent erronées ? Que pouvons-nous faire pour les rendre aussi précises que possible ? Comment tirer le meilleur parti d’un mal nécessaire ?
Après avoir créé des logiciels pendant plus de dix ans, j’ai essayé de formaliser tout ce que j’ai appris dans ces onze lois énumérées ci-dessous. Prêts à les découvrir ? Allons-y !

1. Le travail prend toujours le même temps quelle que soit la précision de votre estimation.

Permettez-moi de vous poser la question suivante : “Combien y a-t-il de centimes dans ce bocal ?”.

Très probablement, votre estimation serait erronée. Vous ne pouvez même pas déterminer la hauteur du pot à partir de la photo. Cependant, votre estimation n’influence pas le nombre de centimes présents. La réalité n’est pas affectée par votre supposition.
La même logique s’applique à l’estimation ou à la prévision des délais. La livraison d’une fonctionnalité prend toujours le même temps, quelle que soit votre estimation. Ce sont nos attentes en matière de délais qui créent une perception de retard de livraison.

2. Vos estimations ne seront JAMAIS totalement fiables.

Que ce soit des estimations classiques ou agile, une estimation, individuelle ou faite de manière collective est une supposition. C’est une prédiction de devin que nous faisons avec trop peu d’informations.
Lorsque nous effectuons un travail complexe, nous savons que nous manquons d’informations. Nos informations et notre compréhension sont limitées dans la mesure où obtenir la bonne estimation signifie que nous avons eu de la chance, tout comme lorsque nous devinons le nombre de centimes dans le pot en nous basant sur cette image.
S’attendre à ce que vos estimations soient exactes, c’est comme s’attendre à prédire l’avenir en lisant des motifs dans les feuilles de thé. Lorsque vous manquez de signal, vous ne pouvez pas tirer de conclusions sur l’avenir en vous basant sur le bruit.
C’est pourquoi vous ne devriez jamais vous fier à vos estimations. Vous faites des estimations avec les meilleures informations dont vous disposiez à l’époque, ce qui est insuffisant pour tirer des conclusions définitives lorsque vous effectuez un travail complexe.
Ne vous fiez pas à vos estimations et sachez qu’elles reflètent votre compréhension actuelle, généralement terrible. Cependant, c’est un début et c’est mieux que rien.

3. Imposer des estimations aux autres est LA recette pour du désastre.

Rien n’est plus frustrant que de forcer les estimations pour un travail que l’équipe doit exécuter. Un “chef/senior/équipier” décidant seul de l’estimation pour l’ensemble de l’équipe, c’est terrible ! La valeur de l’estimation collective se trouve dans les discussions provoquées par la divergence des estimations.

Étant donné que ces estimations se révéleront souvent incorrectes, l’équipe qui essaie de les mettre en œuvre développera des sentiments de ressentiment envers ceux qui ont produit les estimations initiales.
Si vous voulez l’adhésion et de meilleures estimations, laissez les personnes qui exécutent le travail proposer les estimations. Ensuite, si les estimations sont erronées, ce qui sera invariablement le cas, l’équipe ne peut que se pointer du doigt.
Jeter des estimations par-dessus la clôture est une recette pour un désastre et un moyen infaillible de commencer un jeu de blâme où tout le monde se blâme.

4. Les estimations deviennent plus fiables à l’approche de l’achèvement du projet. C’est aussi à ce moment qu’elles sont le moins utiles.

Au début d’un projet, vous en savez le moins, donc vos estimations sont les moins précises. C’est aussi le moment où vous aimeriez en savoir le plus sur l’effort requis pour votre projet.
Au fur et à mesure que le projet progresse, vous comprendrez mieux et aurez plus d’informations sur ce qui doit se passer. Vos estimations deviendront plus précises. Cependant, au fur et à mesure que le projet est achevé, la précision de vos estimations devient moins importante. De plus, en raison du temps que vous avez déjà investi dans le projet, les entreprises sont moins susceptibles d’abandonner le développement.
Mais ne soyez pas dupe. Même lorsque vous avez presque terminé, vous pouvez toujours découvrir quelque chose qui fait exploser tout le projet. Dans le développement de logiciels, des problèmes apparemment mineurs peuvent avoir des conséquences massives.

5. Plus vous vous souciez de vos estimations, plus cela signifie que vous devriez plutôt vous préoccuper de choses plus importantes.

Les estimations sont un faux-fuyant. Il est facile de se laisser distraire et de croire que des estimations précises et des délais sont ce qui compte le plus. Cependant, comme dit précédemment, cela prend le temps qu’il faut, et votre estimation n’y joue aucun rôle.
Lorsque les équipes tentent de respecter la chronologie imaginaire produite par la boule de cristal, la vision en tunnel s’insinue.

Les discussions se centrent sur “Comment pouvons-nous respecter ce délai ?” , plutot que sur “livrons nous de la valeur” ou encore “est-ce assez bien pour nos utilisateurs ?”. Une concentration obsessionnelle sur « Quand cela sera-t-il fait ? » garantit que vous mettrez au second plan les questions sur la valeur.

6. Lorsque vous êtes nul pour créer des logiciels, vos estimations seront nulles. Lorsque vous êtes doué pour créer des logiciels, vos estimations seront médiocres.

Quoi que vous fassiez, vos estimations ne seront jamais exactes. La capacité d’estimer avec précision n’a que peu d’incidence sur votre capacité à créer de bons logiciels. Les meilleures équipes produiront généralement de meilleures estimations, mais ces meilleures estimations ne sont toujours pas assez bonnes..
Comme le météorologue qui ne peut pas prédire le temps avec précision plus d’une semaine à l’avance, les équipes de développement de logiciels atteignent rapidement un plafond quant à la précision avec laquelle elles peuvent estimer.
Quoi que vous fassiez, vous ne pouvez pas garantir que vos estimations seront exactes ou que vous serez en mesure de livrer à temps.

7. La plus grande valeur dans l’estimation n’est pas l’estimation mais l’émergence d’une compréhension commune.

Lors d’une session d’estimation, une estimation différente signifie généralement qu’il existe une compréhension contradictoire de ce qui doit se produire. En parlant du travail à faire, des divergences d’opinions sur ce qui doit arriver font surface.
La création d’une compréhension commune est la plus grande valeur de l’estimation, pas l’estimation elle-même, qui se révélera encore souvent fausse.

8. Garder les choses simples est la meilleure façon d’augmenter la précision des estimations.

Supprimer la complexité et l’incertitude, soit en faisant le travail, soit avant de commencer à le faire, est le meilleur moyen d’augmenter la précision des estimations. Garder les choses simples est le meilleur moyen d’éviter que vos estimations ne gonflent et ne vous explosent au visage.

Cependant, gardez à l’esprit que si vous rendez les choses trop simples, vous vous retrouverez avec le même genre de problèmes que lorsque vous compliquez trop les choses.

[new_royalslider id=”35″]

9. Construire quelque chose augmente la précision des estimations plus que parler de le construire.

Il est attrayant de parler, d’analyser, de concevoir, de débattre et de faire des recherches infinies avant de commencer le travail pour abolir toute incertitude et tout risque. Cependant, peu importe ce que vous faites, vous êtes toujours limité à la connaissance préalable : ce que vous pouvez savoir avant de commencer les travaux. Vous rencontrez rapidement des rendements décroissants en essayant de tirer des conclusions basées sur des informations inadéquates.
En faisant le travail et en commençant, vous découvrez plus tôt les vrais problèmes qui comptent.
Travaillez avec ce que vous savez pour découvrir ce que vous ne savez pas.

10. Décomposer tout le travail dans les moindres détails pour arriver à une meilleure estimation signifie que vous livrerez le projet plus tard que si vous ne l’aviez pas fait.

Notre réponse habituelle pour produire une meilleure estimation est de rester assis sans fin dans les salles de réunion et de tout décomposer dans les moindres détails. De découper en tranches fines les éléments qui composent le backlog. Ce faisant, nous perdons un temps précieux que nous pourrions passer à faire le travail. Comme indiqué précédemment, c’est là que vous découvrez les problèmes qui comptent. En plus de cela, tous ces plans élaborés sont détachés de la réalité et finiront par nous ralentir de plus en plus au fur et à mesure que le projet avance.
S’en tenir au plan alors qu’il dévie de plus en plus est une chose dangereuse. Il est préférable de commencer par des plans plus simples et plus faciles à ajuster. Lorsque vous décomposez l’ensemble du projet dans les moindres détails, au moins maintenant vous pouvez vous tromper en ayant une meilleure idée de combien de temps le projet sera livré plus tard.

11. Punir les mauvaises estimations revient à punir un enfant pour quelque chose qu’il ne peut pas savoir.

Certaines entreprises pensent qu’il est possible de produire des estimations parfaites à mesure que les équipes mûrissent et se renforcent. Par conséquent, toute équipe qui n’est pas en mesure de produire des estimations précises est incompétente.
Lorsque vous punissez des équipes pour avoir fait des estimations inexactes, vous les pénalisez pour des choses qui échappent à leur contrôle.
C’est comme punir un enfant pour quelque chose qu’il ne comprend pas encore. C’est une forme d’intimidation qui mène à la panique et à l’anxiété sans produire aucun avantage tangible.

Arrêtez de perdre du temps avec l’illusion que vous ne pourrez jamais produire des estimations précises

En résumé, voici les 11 lois de l’estimation logicielle pour les travaux complexes :

• Le travail prend toujours le même temps quelle que soit la précision de votre estimation.
• Quoi que vous fassiez, les estimations ne sont jamais totalement fiables.
• Imposer des estimations aux autres est une recette pour le désastre.
• Les estimations deviennent plus fiables à l’approche de l’achèvement du projet. C’est aussi à ce moment qu’ils sont le moins utiles.
• Plus vous vous souciez de vos estimations, plus vous pouvez être certain que vous devriez plutôt vous préoccuper de choses plus importantes.
• Lorsque vous êtes nul en matière de création de logiciels, vos estimations seront nulles. Lorsque vous êtes doué pour créer des logiciels, vos estimations seront médiocres.
• La plus grande valeur dans l’estimation n’est pas l’estimation mais pour vérifier s’il y a une compréhension commune.
• Garder les choses simples est le meilleur moyen d’augmenter la précision des estimations.
• Construire quelque chose augmente la précision des estimations plus que parler de le construire.
• Décomposer tout le travail dans les moindres détails pour arriver à une meilleure estimation signifie que vous livrerez le projet plus tard que si vous ne l’aviez pas fait.
• Punir de mauvaises estimations revient souvent à punir un enfant pour quelque chose qu’il ne sait pas et ne peut pas encore savoir.

Les performances passées ne sont pas une garantie des résultats futurs, en particulier lorsqu’il s’agit d’estimation de logiciels. En 1943, dans un casino aux États-Unis, la couleur rouge gagne 32 fois de suite. Il est facile de se tromper qu’il existe une sorte de modèle, mais c’est un exemple classique de l’erreur du joueur :
“Une incapacité à reconnaître l’indépendance des événements fortuits, conduisant à la croyance erronée que l’on peut prédire le résultat d’un événement fortuit sur la base des résultats d’événements fortuits passés.” – Définition du dictionnaire APA
“La croyance erronée qu’en estimant fréquemment et en travaillant ensemble sur une plus longue période de temps, à un moment donné, vous serez en mesure de produire des estimations précises.”
– Erreur d’estimation du travail complexe par Maarten Dalmijn
Quoi que vous fassiez, vous ne pourrez jamais rendre vos estimations exactes. Ne vous trompez pas en agissant sous l’illusion que vous pouvez.
Posez-vous la question suivante : est-ce important si vous êtes capable de prédire exactement quand quelque chose est terminé ? Si vous êtes sûr de faire les meilleurs progrès possibles pour livrer quelque chose de précieux, cela fait-il une différence si c’est plus lent que prévu si cette attente a toujours été imparfaite et imprécise au départ ?
Ajustez vos voiles, faites face à l’inattendu et à l’incertain, au lieu d’être en colère contre les vents, vous ne pourrez jamais prévoir et contrôler.