En mars, un ancien collègue m’a envoyé une capture d’écran. Un formulaire d’inscription complet, avec validation, base de données et e-mail de confirmation, généré en trente secondes. Sous l’image, une question : « Du coup, le projet qu’on avait chiffré à quatre-vingts jours, c’est huit jours maintenant ? »
J’ai passé les dernières années à chiffrer des projets pour de grandes entreprises. J’ai mis un moment à répondre, parce que la réponse honnête est « non », et qu’elle demande d’expliquer pourquoi.
Ce qu’on croit
Le raisonnement paraît solide. Un projet, c’est du code. Le code s’écrit dix fois plus vite. Donc le projet coûte dix fois moins. Et si l’estimation ne baisse pas, c’est que quelqu’un se protège.
C’est faux, mais pas pour la raison qu’on donne d’habitude. Ce n’est pas que « le code, ce n’est pas tout ». C’est que le code n’a jamais été ce qu’on estimait.
Ce que dix-huit ans d’estimation m’ont appris
Quand je décompose un projet, la frappe au clavier pèse une fraction du total. Ce que je chiffre, c’est autre chose : comprendre ce que le client veut vraiment, ce qui prend trois réunions et deux revirements. Attendre une réponse de la direction informatique sur un accès. Découvrir que le système avec lequel il faut s’interfacer ne fait pas ce que sa documentation dit. Reprendre un écran parce que la personne qui va l’utiliser ne l’avait pas encore vu. Vérifier que ça marche sur le poste de travail bloqué par la sécurité du groupe.
Le buzzer m’en a donné une version en miniature. Le gestionnaire d’événements a été écrit en quelques secondes. Le bug qui ne se produisait que sur un Galaxy A33 a coûté trois jours, et l’outil n’y pouvait rien : il fallait un vrai téléphone, un vrai pouce, et quelqu’un qui remarque que rien ne se passe.
Sur un forfait de quatre-vingts jours, quand je regarde les projets qui ont dérapé, aucun n’a dérapé sur la production de code. Ils ont dérapé sur un besoin compris de travers, un environnement qui n’était pas prêt, une intégration qui ne tenait pas ses promesses. Ces trois-là ne se sont pas accélérés. Ils ne dépendent pas du clavier.
Ce que ça change en pratique
Ce qui a changé, c’est la proportion. La partie certaine du projet, celle qu’on savait faire et qu’il fallait juste écrire, est devenue presque gratuite. La partie incertaine coûte exactement ce qu’elle coûtait. Le projet est donc un peu moins cher, et beaucoup plus risqué en proportion : ce qui reste, c’est le risque.
Quand on s’engage au forfait, ça impose trois choses.
Chiffrer l’incertitude, pas le volume. Compter les écrans ne veut plus rien dire. Compter les points où on ne sait pas encore, si.
Montrer plus tôt. Si l’écran coûte une heure, il n’y a plus aucune raison d’attendre trois semaines pour le faire voir à la personne qui va s’en servir. Le revirement coûte le même prix qu’avant ; autant le provoquer le premier jour.
Et réduire ce sur quoi on s’engage. Le forfait couvrait deux choses : un travail connu et un pari sur l’inconnu. Le travail connu ne vaut plus grand-chose. Rester engagé sur le pari, au même prix, c’est garder tout le risque en ayant perdu ce qui le compensait.
J’ai fini par répondre à mon collègue. Ce n’est pas huit jours. C’est peut-être soixante, dont cinquante qui ne se voient pas sur une capture d’écran.
On a accéléré la partie du projet qu’on savait estimer. Il reste celle qu’on ne savait pas.
Recevoir le journal
Une entrée par semaine environ. Ce que je construis, ce qui casse, ce que j'apprends. Pas de promotion, désinscription en un clic.
Vous pouvez aussi suivre le flux RSS.