Comme beau­coup d’in­gé­nieurs, je suis réti­cent à donner des esti­ma­tions.

je ne sais pas esti­mer

Tous les jours, je résous des problèmes nouveaux, pour lesquels je n’ai encore jamais implé­menté de solu­tion.

Si vous n’avez jamais fait d’in­for­ma­tique, mettez-vous bien ça dans la tête : Contrai­re­ment au maçon qui peut construire des dizaines de maisons, l’in­for­ma­ti­cien ne fait jamais deux fois la même chose. Il peut réuti­li­ser la solu­tion précé­dente à l’in­fini, en quelques heures. Qu’un déve­lop­peur fasse deux fois exac­te­ment la même chose est le symp­tôme d’un problème d’or­ga­ni­sa­tion.

Si je passe plus de quelques heures, c’est qu’il y a un problème nouveau ou quelque chose de nouveau dans le problème, même si de haut il ressemble à un autre. Mon travail c’est unique­ment de créer ce qui manque, ce qui est nouveau par rapport à d’éven­tuelles solu­tions précé­dentes.

Et pour ce nouveau, je vais devoir étudier le problème posé, proba­ble­ment décou­vrir des sous-problèmes qu’on n’ima­gi­nait pas. Je ne sais pas ce quelles diffi­cul­tés je vais rencon­trer, quelles solu­tions vont devoir être appliquées, comment les mettre en œuvre, si elles vont réus­sir ou échouer, et encore moins si le besoin racine va effec­ti­ve­ment être couvert à la fin de tout cela.

Il y a plein de textes qui expliquent la problé­ma­tique de l’es­ti­ma­tion mais j’ai trouvé plus d’une fois que le récit de voyage de Michael Wolfe illustre très bien les enjeux avec une analo­gie que tout le monde comprend.

vous non plus

J’ai croisé de nombreuses personnes qui annonçaient savoir esti­mer assez correc­te­ment, et quelques unes qui semblaient effec­ti­ve­ment le faire. Vous en connais­sez peut-être aussi.

En pratique à chaque fois qu’on y regarde de plus près, l’es­ti­ma­tion n’est pas plus juste qu’une autre. Au mieux on compense les mauvaises esti­ma­tions en jouant sur le contexte. L’es­ti­ma­tion est poten­tiel­le­ment respec­tée, mais elle n’en est pas plus juste. Et quand compen­ser ne suffit pas, on se rassure en consi­dé­rant que ça ne compte pas parce que c’est excep­tion­nel, qu’il y a une cause exté­rieure, ou en repor­tant la faute sur un tiers.

Même les itéra­tions de la tant aimée métho­do­lo­gie SCRUM jouent sur le même registre : Donner une cible avec un enga­ge­ment permet d’avoir un peu de pres­sion sur l’équipe. C’est de la pres­sion dite « posi­tive », pour avoir envie d’at­teindre l’objec­tif.

Au final c’est de la pres­sion tout de même, qui souvent se retrouve sur l’am­pli­tude horaire ou sur la fatigue. Quand le mana­ge­ment n’a pas une atten­tion et une culture extrê­me­ment forte sur le sujet, ça joue aussi sur une baisse de qualité ou une créa­tion de dette tech­nique. C’est humain. À défaut c’est le péri­mètre qui bouge, mais l’es­ti­ma­tion n’en est pas meilleure. Bref, on pallie la mauvaise esti­ma­tion en jouant sur le contexte.

Si vrai­ment quelqu’un estime toujours juste à plus de 90%, sans compen­ser sur le contexte, c’est qu’il est en train de passer du temps à refaire ce qu’il a déjà fait. S’il travaille pour vous : virez-le et embau­chez quelqu’un qui saura réuti­li­ser plutôt que perdre du temps.

même par petits lots

Même l’es­ti­ma­tion par petits lots itéra­tifs n’est qu’une illu­sion. On estime effec­ti­ve­ment mieux des petites tâches qu’on sait perce­voir, mais c’est unique­ment parce qu’on réflé­chit déjà à la problé­ma­tique et à sa solu­tion au moment de donner l’es­ti­ma­tion.

Par la suite on se trompe autant qu’ailleurs. On compense là aussi par l’am­pli­tude horaire, le stress de la pres­sion person­nelle, la qualité ou la dette tech­nique. C’est juste que plus la tâche est petite, plus le déca­lage probable est petit et donc moins il se voit de l’ex­té­rieur quand on regarde unitai­re­ment.

Vous avez déjà remarqué qu’on ne fait pas tenir 8 tâches d’une heure dans une jour­née ou 5 tâches d’une jour­née dans une semaine ? Des tâches d’une heure dans une jour­née, prévoyez-en 6, moins le temps pour les réunions.

Et des fois on a juste oublié un cas d’usage ou manqué une problé­ma­tique. Sur un lot impor­tant on aurait assumé et dérapé un peu. Sur une petite tâche le cas manqué peut prendre plusieurs fois l’es­ti­ma­tion de la tâche initiale. On en fait donc une nouvelle tâche, avec sa propre esti­ma­tion. Là aussi, l’ex­cuse du cas excep­tion­nel ou de la sortie de péri­mètre permet d’évi­ter de remettre en cause ses esti­ma­tions.

Alors oui, les esti­ma­tions sur des petits lots ont tendance à être plus souvent respec­tées mais elles n’en sont pas beau­coup plus justes. Tout ceci n’est qu’œillères et illu­sions.

C’est mieux – et c’est logique vu qu’on estime au fur et à mesure du projet, une fois la connais­sance acquise – mais ce n’est toujours pas bon.

la mauvaise ques­tion

On peut discu­ter de l’uti­lité des esti­ma­tions, de la capa­cité du genre humain à savoir donner des esti­ma­tions abso­lues. On peu aussi s’en­fon­cer dans un projet d’op­po­si­tion, scan­der #noes­ti­ma­te… mais qu’ap­por­te­rait-on comme valeur ?

Je suis surtout agacé qu’on se pose surtout la mauvaise ques­tion. Au jour le jour je n’ai aucu­ne­ment besoin d’es­ti­mer. J’ai besoin d’ap­por­ter de la valeur. La seule ques­tion à me poser est « qu’est-ce qui amènera à priori le plus de valeur demain si je le fais aujourd’­hui ? » et mettre mes ressources dessus.

La ques­tion n’est pas simple pour autant. J’ai besoin d’éva­luer si le niveau d’ef­fort à four­nir est rentable par rapport à la valeur ajou­tée atten­due. Ensuite j’ai besoin de prio­ri­ser les évolu­tions entre elles, en fonc­tion de la valeur et du niveau d’ef­fort.

Sauf que juste­ment, je n’ai besoin pour ces usages que d’un ordre de gran­deur : Est-ce 10, 100 ou 1000 ? Est-ce beau­coup plus ou beau­coup moins que l’autre évolu­tion à laquelle je pense ? Tout autre détail est aussi utile qu’un para­chute pour monter sur une échelle.

L’éva­lua­tion de la valeur atten­due subit de toutes façons les mêmes incer­ti­tudes que le niveau d’ef­fort à four­nir. Même s’il est fait à base d’une page pleine de formules, calcul de la valeur atten­due dépend parfois tota­le­ment de para­mètres esti­més au doigt mouillé, où même un ordre de gran­deur relève plus de la convic­tion que de l’es­ti­ma­tion.

le mauvais usage

Vous posez-vous vrai­ment la bonne ques­tion ?

En cher­chant à savoir si votre projet dérape vous êtes simple­ment en train de regar­der s’il se conforme au plan prévu, à son esti­ma­tion. Véri­fier la vali­dité d’une esti­ma­tion ne vous appor­tera aucune valeur, surtout quand on sait dès le départ qu’elle est soumise à des aléas impré­vi­sibles.

Pire, en impo­sant l’es­ti­ma­tion préa­lable comme indi­ca­teur, on freine l’ini­tia­tive (si je le fais, on prend un risque, même si je sais qu’il faut le faire), on freine la capa­cité de chan­ger (si on le fait, il faut recal­cu­ler le plan, re-esti­mer, négo­cier cette esti­ma­tion, expliquer le mauvais indi­ca­teur, ça ne vaut pas le coût ici, tant pis), et on oublie notre objec­tif (l’in­di­ca­teur est bon, tant pis si en fait on s’est rendu compte que ça ne créait pas la valeur atten­due et qu’il aurait fallu faire autre chose, ça aurait remis en cause le plan).

Vous pouvez vous dire que vous saurez déjouer tout cela, rester agile et prag­ma­tique. Vous vous mentez, du moins tant que votre ques­tion sera « où est-ce qu’on en est par rapport aux esti­ma­tions ? ».

C’est encore pire si vous utili­sez l’es­ti­ma­tion comme métrique pour appré­cier l’ef­fi­ca­cité ou la compé­tence de l’équipe de produc­tion. Là non seule­ment vous compa­rez juste des choux et des carottes, mais en plus vous inver­sez votre résul­tat : Ce sont des équipes qui respectent toutes leurs esti­ma­tions que vous devriez avoir peur. Elles masquent leurs erreurs en les compen­sant, volon­tai­re­ment ou non, et ça faus­sera toutes vos analyses sur la produc­tion passée ou future.

arrê­ter de navi­guer dans le passé

Les méthodes agiles vont dans le bon sens mais il est trop facile de s’ar­rê­ter aux arte­facts sans en comprendre l’objec­tif. Le prin­cipe n’est pas que de décou­per en petits lots plus faciles à esti­mer pour pouvoir reprendre une déci­sion entre les diffé­rents lots.

Il y a aussi une philo­so­phie derrière, celle de l’ap­port de valeur.

Seul le présent créé de la valeur. La stra­té­gie envi­sage le futur, les rétros­pec­tives tirent les leçons du passé. Si vous n’êtes ni dans un contexte de choix stra­té­gique ni en train de tirer des leçons en rétros­pec­tive, vous ne devez que vous préoc­cu­per de la meilleure façon d’ap­por­ter de la valeur là, main­te­nant, tout de suite, peu importe ce que vous aviez pu prévu ou estimé par le passé.

Que dois-je faire aujourd’­hui et main­te­nant pour appor­ter le plus de valeur ?

La perti­nence de l’es­ti­ma­tion passée ne m’est jamais d’au­cune utilité pour répondre à cette ques­tion. J’in­siste : Jamais. Je prends en compte les diffi­cul­tés et faci­li­tés dans des rétros­pec­tives pour m’amé­lio­rer. Je les prends en compte pour évaluer l’ef­fort à four­nir sur le reste à faire, et donc l’op­por­tu­nité de conti­nuer. Que ces faci­li­tés ou diffi­cul­tés aient été prévues ou non, que j’ai divisé par 2 ou multi­plié par 20 mon esti­ma­tion n’im­porte fina­le­ment aucu­ne­ment.

Esti­mez, c’est utile, impor­tant. Ensuite oubliez-les et surtout ne les réuti­li­sez pas pour autre chose.

(sur le même sujet We don’t need no stin­king esti­mates)

Photo d’en­tête sous licence CC BY-NC-SA par Mark Notari

Rejoindre la conversation

5 commentaires

  1. Petite coquille dans l’avant-dernier paragraphe : s/Je prends les prends en compte pour évaluer/ Je les prends en compte pour évaluer.
    Mis à part ça : énorme +1, et je serais à jamais envieux de la facilité que tu as à faire passer simplement une idée et à la mettre en perspective dans son contexte.

  2. Bel article.

    Cependant j’ai appris que la valeur dans développement n’est pas la même pour tout le monde, et diffère beaucoup entre l’évaluation d’un développeur et d’un commercial ou d’un client par exemple,. Là où le premier verra plus le fond le second accordera plus de valeur à la forme. La création de valeur dans le temps du developpement n’est donc pas la même pour tout le monde.
    L’estimation à mon sens permet de confirmer la valeur qu’est prêtes à investir la personne qui voit la forme, dans le fond. Charge aux développeurs de s’accorder à cette valeur.
    D’ailleurs, par définition une estimation est une évaluation approximative, elle n’a donc pas besoin d’être juste, seulement statistiquement au plus proche possible de la réalité.
    Personnellement il n’existe pas de context edans lequel je n’invisterai pas 20 fois plus que l’estimation pour créer de la valeur, mais ce ne serait pas la valeur que l’on attend de moi.

    1. La valeur, dans mes propos, est celle perçue par le client et/ou par l’actionnaire de la société (suivant l’inclinaison stratégique choisie – normalement les deux vont de pair, mais pas toujours avec les mêmes arbitrages long terme / court terme). En aucun cas je ne parle de la valeur technique (sauf à ce que l’objectif soir de créer un bijou technique à fin de revendre la société dans une meilleure valorisation).

      Après oui, l’estimation de valeur n’est pas la même pour tout le monde. Maintenant il ne sert pas à grand chose de chercher combien coûte un investissement si on ne s’est pas d’abord accordé sur la valeur qu’on en attend (fut-elle elle aussi approximative et peu fiable, il en faut une).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par Scaleway, ONLINE SAS, joignable par téléphone au +33 (0)1 84 13 00 00 et joignable par courrier à l'adresse BP 438 - 75366 Paris Cedex 08.