Tu penses que ça va te prendre combien de temps ? Cette question à la con me file un frisson à chaque fois qu’on me la pose. Le problème c’est qu’il n’y a pas de bonne réponse à cette question. Ton estimation de temps sera forcément une blague et aujourd’hui on va voir pourquoi.
Théorie du chaos
Imagine, tu décroches un nouveau travail. Pour le trajet du premier jour, tu vas faire comme tout le monde. Tu vas demander une estimation de temps à Google Map. Et le premier jour, tu te mets bien, tu vas arriver à l’heure.
Le lendemain, pas de chance, il y a toute la terre sur l’autoroute avec toi. Tu débarques avec 20 minutes de retard. OK, dans le futur tu partiras 20 minutes plus tôt histoire d’être peinard. Le surlendemain, chaos total, carambolage, autoroute fermée, tu te tapes toutes les départementales de la terre et t’arrives avec deux heures de retard. Ton boss il fait la gueule et ton estimation de 20 minutes, c’est une grosse blague. Tu commences à faire rire tous tes collègues.
Du coup, tu fais comment ? Tu pars 1 heure en avance ? 2 heures en avance ? Mais comment tu fais si tu tombes en panne ? Et tu fais comment s’il tombe 20 cm de neige ? Tu arrives au cœur du problème. Ça fait longtemps que tu parles plus de ton trajet en fait. Tu n’estimes plus ton trajet. Tu estimes le chaos potentiel durant ton trajet. Ton estimation de temps est une blague car tu estimes le chaos. Le chaos est par définition imprévisible. Et ceux qui disent le contraire ne font qu’amplifier ce chaos.
Caisse de résonance
Si je te parle de ça aujourd’hui c’est parce que tu es particulièrement concerné dans le milieu de la tech. Plus un système est complexe, plus il est sujet au chaos. Et dans la tech côté chaos on est à peu près au niveau Carnaval. Y’en a de partout et c’est le bordel !
Des systèmes complexes ? Tu fais ça tous les jours. Pire, tu as un milliard de dépendances qui sont des systèmes complexes et qui ont eux-mêmes des dépendances. Ton estimation de temps est une blague car le chaos potentiel autour de toi est incalculable.
Et au milieu de tout ce chaos, t’as un chef de projet qui vient te voir. Sereinement, il te met des specs qui tiennent sur un post-it devant ta face et il te dit : combien d’heures de travail pour ça ? Et toi du coup tu regardes le post-it et tu trouves ça super drôle !
Tout de suite après il rajoute « tu peux faire ça vite vite ? ». Bah oui, il faut que ça aille vite. C’est ça ton domaine. Les technologies évoluent et les façons de faire aussi. T’apprends en permanence pour une seule raison : aller plus vite. Savoir plus de choses, être capable de tenir la cadence d’un secteur connu pour son rythme infernal. Pour la plupart des gens qui gèrent des projets informatiques, un bon développeur est un développeur rapide. Rien à foutre de la qualité. Rien à foutre de la maintenabilité. Rien à foutre des bonnes pratiques. Rien à foutre de la stabilité.
On patchera plus tard. Tu as tenu les délais ? C’est bien, toi, t’es un bon développeur. Ton estimation de temps est une blague car on te pousse à faire toujours plus vite. Et comme on te pousse à faire vite il faut en plus que tu estimes vite.
Ton estimation est ta deadline
Alors je vais pas parler du cas où c’est le chef de projet qui fait l’estimation de temps pour toi. Si c’est même pas toi qui estimes le temps nécessaire pour faire ton propre travail, tu es actuellement dans les sous-sols de l’enfer. C’est chaud. Barre-toi très loin. Vite.
Quand c’est toi qui l’as fait, tu as généralement très peu de temps pour la faire. Et en très peu de temps, il se passe plein de choses. D’abord tu sais que peu importe ce que tu vas dire ça va être utilisé tel quel. Ton estimation de temps est une blague car tu sais très bien que ça va devenir ta deadline. Sachant ça, tu estimes large. Logique.
On va te dire que c’est trop long ton estimation là. C’est trop cher pour le client tu comprends ? D’ailleurs on a vu quelqu’un faire la même chose en moitié moins de temps. C’est simple ! T’es nul ou quoi ?
Et avec cette technique non seulement on refuse ton estimation, mais en plus on titille ton énorme égo. Tu finis par craquer. Tu raccourcis ton estimation. J’ai souvent fait exactement la même chose. « En effet ça c’est facile, je l’ai fait plein de fois ». Évidemment sans rien vérifier. Ton estimation de temps est une blague car c’est souvent ton égo qui fait l’estimation. La plupart du temps le chaos ne s’invite pas et tout se passe comme prévu. Mais quand le chaos s’invite, ça peut vite devenir spectaculaire.
Ta deadline est une blague
Dans l’une des agences où je suis passé un collègue a été victime exactement du même scénario. Post-it, estimation puis chaos. Il s’était engagé le lundi matin pour finir une tâche le lundi même. Il a ship vendredi 15 h. Le vendredi de la semaine d’après.
Ce vendredi-là, avec toute l’équipe de dev, on lui a fait une clef de bras et on l’a forcé à venir dans un bar. On voulait savoir tous les détails. Son histoire chaotique nous a fait rire toute la soirée. On l’a écouté toute la nuit et c’était incroyable.
Son histoire, c’était le schéma habituel d’une tâche piège. À chaque fois qu’il s’approchait de la fin de la tâche soit on lui en rajoutait soit on lui changeait carrément le scope. La plus grosse blague étant le changement de scope sans le changement de délais. Ton estimation de temps est une blague car tu donnes un temps strictement fixe sur un problème qui peut évoluer. Quand plus personne prend les choses au sérieux, c’est au développeur de payer le prix.
Ta blague ne te fait plus rire
Bon ceci dit le scope peut très bien rester le même et les délais être non tenus. Ça arrive fréquemment et là tout d’un coup ça te fait plus rire.
Faire du dev c’est comme monter un meuble Ikea. T’es bon pour monter des meubles. Tu fais ça depuis des années. En plus, tu as une documentation pour t’aider. Souvent tu le fais avec d’autres personnes. Tu assembles plein de pièces ensemble pour former un beau résultat utilisable. La plupart du temps ça se passe bien. Et puis des fois t’es au milieu de l’assemblage et tu te rends compte qu’il te manque une pièce. C’étais pas du tout prévu ça. Tu te retrouves à refaire cette pièce. Il faut qu’elle soit parfaite et surtout compatible avec le reste.
Le problème c’est que cette pièce est très compliquée à faire. Ça demande autant de temps que tout le meuble. Tu te retrouves bien dans la merde. Le chaos s’installe. Et avec ton meuble bancal, tu sais plus comment t’en sortir. Ton estimation de temps ne te fait plus rire quand les enjeux sont sérieux. Et c’est vraiment pas marrant quand ça atteint des cas extrêmes.
La tentative de la méthode agile
La méthode agile fait tous les efforts possibles pour contrôler le chaos. Dans les efforts remarquables, tu trouves l’itération de sprint pour trouver la cadence (ou vélocité) idéale d’une équipe. Et tu trouves surtout le fameux planning poker qui permet mine de rien de discuter et de réfléchir longuement, avec plein d’acteurs différents, avant de faire une estimation.
La méthode agile se base sur un système de point. Ce système de point n’est pas censé être une estimation de temps, mais une estimation de complexité de la tâche. Et on donne à chaque sprint un nombre de points.
Mais voilà, la méthode agile n’est jamais vraiment appliquée complètement. Et malgré tous les tours de pass-pass le projet a toujours une hard deadline. Dans 100% des entreprises où je suis passé, tout le monde traduisait l’estimation de points en estimation de temps. Ni vu ni connu l’estimation de temps était faite comme ça et l’illusion agile était parfaite.
C’est quoi la solution ?
J’ai pas de solution ! Ça fait cinq minutes que je t’explique que c’est le chaos. Bon par contre, tu me connais, j’ai toujours deux / trois conseils pour toi. Il faut apprendre à vivre avec le chaos au lieu de le défier.
Mon premier conseil est de ne jamais laisser ton égo prendre des décisions pour toi. Ne tombe jamais dans le « non, mais ça je connais, déjà fait, facile ». Tôt ou tard ça va se retourner contre toi. Demande toujours un temps de réflexion, prends ton temps pour faire des recherches, pose des questions, demande des clarifications et vérifie tout ce que tu peux vérifier. Investis-toi dans cette estimation. Ne te laisse pas aller à donner un délai ridicule par facilité et excès de confiance.
Second conseil : ne donne jamais un temps absolu. Donne toujours une fourchette de temps. Si tu estimes que ça va te prendre 2 jours, tu peux dire que ça va te prendre entre 2 et 4 jours selon tels critères et sous certaines conditions. Au-delà même du fait que tu te protèges, tu permets surtout à ton entreprise d’avoir des détails sur ta réflexion. D’avoir une vue sur les risques de ta tâche. Et si elle estime que les risques sont trop élevés elle pourrait ajuster les plannings en conséquence.
Enfin mon dernier conseil est de toujours donner une mise à jour en temps réel sur ton estimation. Si au bout d’un jour c’est le chaos total alors, dis-le tout de suite. Transparence totale. Va voir ton chef de projet et dis-lui qu’on est plus parti sur quatre jours de travail. Cette façon de faire à deux avantages. La première c’est que ton entreprise peut s’adapter en temps réel, voir même trouver des solutions en réduisant le scope. La seconde c’est que le fait d’être transparent va moins te stresser et du coup te rendre plus efficace.
Épilogue
Le Graal c’est d’être dans une entreprise qui ne fait pas d’estimation. Il parait que ça existe. Ces entreprises livrent des projets quand ils sont parfaits et du coup sans date particulière. Personnellement, j’ai jamais vu ça nulle part où je suis passé. Si toi non plus alors il est temps que tu acceptes la variable chaos dans ton travail de tous les jours. Elle sera toujours là.
clearfix