Estimation de développement logiciel : comment lire le chiffre
Votre prestataire a renvoyé un chiffre. Voici les quatre questions qui le retransforment en la fourchette qu’il est réellement.
Le mail faisait quatre lignes. Une salutation, un merci pour l’appel, puis le chiffre : 12 semaines, 180 000 dollars. Le fondateur nous l’a transféré avec une question posée dessus. “C’est bien, ça ?”
L’estimation de développement logiciel est la pratique qui consiste à prédire combien de temps et combien d’argent coûtera la construction d’un logiciel. Sauf que ce qui atterrit dans votre boîte mail n’est pas une prédiction. C’est une fourchette que quelqu’un a écrasée en un chiffre unique, parce qu’un chiffre unique est ce que vous avez demandé. Tout ce qui compte vit dans la fourchette qu’on a jetée.
Le fondateur en question, ancien directeur des opérations d’un hôpital en train de construire un produit de prise de rendez-vous pour cliniques privées, ne savait pas lire ce chiffre. La plupart des gens avec qui nous travaillons non plus, et ce n’est pas un défaut d’intelligence. C’est que tous les guides jamais écrits sur l’estimation de développement logiciel sont écrits pour celui qui produit l’estimation. Cherchez le terme et vous trouverez neuf articles qui apprennent à des ingénieurs à dimensionner une tâche, et aucun qui apprenne à un dirigeant quelles questions rendent le chiffre honnête.
Ceci est l’autre type d’article.
Ce qu’est réellement une estimation logicielle
Trois objets différents portent le nom d'”estimation”, et les confondre est l’endroit où meurt l’essentiel de l’argent.
Il y a l’ordre de grandeur, lâché au téléphone par quelqu’un qui connaît votre problème depuis quarante minutes. Il y a le budget, produit après qu’une équipe a lu vos exigences et s’est disputée à leur sujet. Et il y a la promesse, le chiffre sur lequel un prestataire sera tenu et qu’il défendra donc dans chaque conversation que vous aurez pendant les six prochains mois.
Ils arrivent dans la même police. Ils veulent dire des choses radicalement différentes.
Sous les trois tourne la même mécanique : quelqu’un découpe le travail en morceaux, dimensionne chaque morceau, et additionne. Le dimensionnement peut se faire en jours, en story points, en tailles de t-shirt. L’unité vous importe peu. Ce qui importe, c’est que chacun de ces morceaux a été dimensionné sous incertitude, et que l’incertitude n’a pas survécu à l’addition.
Pourquoi l’estimation de développement logiciel produit toujours une fourchette, et pourquoi la fourchette reste cachée
Steve McConnell a passé une carrière à mesurer à quel point les estimations logicielles se trompent, et le résultat porte un nom : le Cône d’Incertitude. Au début d’un projet, au moment où le concept est acté mais où rien n’est décidé dans le détail, les estimations produites par des estimateurs chevronnés peuvent se tromper d’un facteur quatre vers le haut et d’un facteur quatre vers le bas. Soit un écart de seize entre l’extrémité pessimiste et l’extrémité optimiste. Non pas parce que l’estimateur est mauvais. Parce que le projet n’est pas encore décidé.
Le cône se resserre au fil du projet, et l’essentiel de ce resserrement se produit sur les 20 à 30 premiers pour cent du calendrier. Mais voici ce que les fondateurs se trompent avec une régularité remarquable : il ne se resserre pas parce que l’équipe force davantage. Il se resserre parce que des décisions sont prises. La variabilité de l’estimation est le reflet direct de la variabilité du projet. Comme le formule McConnell, “il n’est pas possible d’être plus précis ; il est seulement possible d’avoir plus de chance.”
Ce qui produit la phrase la plus utile de ce texte :
On ne négocie pas une estimation à la baisse. On peut seulement décider moins de choses à propos desquelles elle sera incertaine.
Tout fondateur ayant un jour poussé sur un devis a senti le prestataire “affûter son crayon” et revenir 15% moins cher. Rien n’a été appris entre-temps. Aucune décision n’a été prise. L’incertitude n’est allée nulle part. Elle a simplement été réaffectée, en silence, de la marge du prestataire vers votre date de lancement.
Quels sont les quatre types d’estimation ?
La plupart des articles classent les estimations par technique : analogique, paramétrique, à trois points, ascendante. Cette taxonomie sert celui qui estime. Voici la vôtre, classée par ce à quoi le chiffre vous engage réellement.
L’ordre de grandeur. Une forme, pas un chiffre. Livré d’expérience avant que quiconque ait lu quoi que ce soit. Sa seule fonction honnête est de répondre à “cette conversation a-t-elle seulement un sens ?”. Portant l’écart complet de seize, il est inutilisable pour planifier et dangereux dans un board deck.
Le budget. Produit après une vraie phase de discovery, où quelqu’un a interrogé vos exigences et trouvé les parties auxquelles vous n’aviez pas pensé. C’est contre celui-là que vous planifiez. Il devrait arriver sous forme de fourchette. S’il arrive sous forme de point, quelqu’un a arrondi à votre place.
L’engagement. Ce sur quoi l’équipe sera réellement tenue. Il n’est honnête qu’une fois qu’assez de choses ont été décidées pour resserrer le cône, ce qui en pratique signifie après qu’une partie du travail a commencé.
Le prix contractuel. Un chiffre à conséquences juridiques. Il contient une prime de risque, et vous payez cette prime que le risque se matérialise ou non. C’est là que l’estimation cesse d’être de l’arithmétique et devient une position de négociation, et c’est pourquoi le chiffre inscrit dans un énoncé des travaux n’est jamais celui du premier appel.
Ce ne sont pas quatre techniques. Ce sont quatre niveaux de promesse. Et le geste fatal, que nous voyons des fondateurs commettre en permanence, consiste à traiter un ordre de grandeur comme s’il s’agissait d’un prix contractuel, puis à se sentir trahi quand le réel se présente.
Les quatre questions qui font ressortir la fourchette
Quand un chiffre arrive, vous disposez d’une fenêtre courte pendant laquelle poser des questions dures reste normal et n’est pas encore devenu hostile. Servez-vous-en. Ces quatre questions travaillent plus que n’importe quel marchandage.
1. “Quel est le pire cas, et que faut-il pour y arriver ?”
Les bons estimateurs en tiennent déjà le compte. Jacob Kaplan-Moss, co-créateur de Django et auteur du guide pratique le plus clair sur la capture de l’incertitude en même temps que du temps, soutient que toute estimation qui vaut quelque chose porte les deux. “Dix à quinze jours” vous apprend une chose que “dix jours” dissimule activement.
Si votre prestataire ne sait pas produire un pire cas, c’est qu’il n’y a pas réfléchi, et vous venez d’apprendre gratuitement quelque chose de cher.
2. “Quelle ligne vous inspire le moins de confiance ?”
La variance ne se répartit presque jamais uniformément sur un projet. Elle se concentre. Une tâche, en général celle que personne n’a jamais faite, explique l’essentiel de la dispersion du plan tout entier. Trouvez cette tâche et vous aurez trouvé votre vrai risque, ainsi que le seul endroit où dépenser de l’argent tôt rapporte vraiment.
Pour l’outil de prise de rendez-vous, cela n’a jamais été le calendrier. C’était la vérification des droits auprès de la caisse d’assurance, une intégration avec un système dont la documentation était un PDF de 2016.
3. “Qu’avez-vous supposé que j’aurais prêt, et pour quand ?”
Enfoui dans chaque estimation se trouve un jeu d’hypothèses sur vous. Que vous validerez les maquettes en deux jours et non en deux semaines. Que vous obtiendrez les accès auprès de votre prestataire de paiement. Que vous trancherez le modèle tarifaire avant que les écrans de facturation soient construits. Que vous trouverez une vraie clinique prête à tester avec de vrais patients.
D’expérience, la cause la plus fréquente d’une date manquée n’est pas l’ingénierie. C’est un fondateur qui gère aussi la vente, la levée de fonds et le recrutement, et qui est devenu le goulot d’étranglement de onze décisions dont personne ne lui avait dit qu’elles lui appartenaient.
4. “Qu’est-ce qui n’est pas dans ce chiffre ?”
Posez la question franchement. La migration des données depuis le tableur que tout le monde utilise encore. L’outillage d’administration pour l’équipe opérationnelle. La deuxième série de retouches de design. Les tests de charge. La validation sur l’app store. Les deux semaines de correction de bugs après le lancement, qui ne sont pas optionnelles et n’apparaissent jamais dans l’estimation.
Tout ce qui n’est pas dit devient plus tard une demande de changement, à un prix que personne n’a négocié sous pression concurrentielle.
Qu’est-ce que la règle des 80/20 en développement logiciel ?
Les gens cherchent cette formule, alors répondons, puis corrigeons-la.
La version que les ingénieurs se racontent entre eux est celle de Tom Cargill, des Bell Labs, et elle est plus drôle et plus juste : les premiers 90% du code prennent 90% du temps, et les 10% de code restants prennent les autres 90% du temps.
C’est une blague sur un phénomène réel. Un logiciel a l’air fini bien avant de l’être. La démo de la sixième semaine est superbe. Elle bouge, elle clique, elle fait se pencher votre board en avant. Ce qu’elle ne fait pas, c’est gérer deux secrétaires qui partagent un même identifiant et posent deux patients sur le même créneau de 15h. Ni un paiement refusé. Ni un patient qui annule deux fois et se fait facturer quand même. Ni les trente états fastidieux qui séparent le “chemin heureux” de la production.
Cet écart entre la démo et le fini, c’est là que les estimations vont mourir, et c’est pourquoi un prestataire qui vous montre quelque chose d’impressionnant en semaine six puis se tait n’est pas nécessairement en retard. Il se peut simplement qu’il ait atteint le vrai travail.
Comment estimer le coût d’un logiciel quand c’est vous qui payez
Vous ne le prévoyez pas. Vous le bornez. Trois gestes, par ordre de valeur.
Achetez une décision, pas une remise. Si une ligne concentre l’essentiel de l’incertitude, payez pour une investigation courte et bornée dans le temps portant exactement sur cette chose-là, avant de vous engager sur l’ensemble du chantier. Deux semaines payées sur l’intégration de l’assurance coûtent radicalement moins cher que la prime de risque que vous paieriez sur un prix forfaitaire de douze semaines, et moins cher encore que de découvrir le problème en semaine neuf.
Budgétez le pire cas, pilotez sur le cas attendu. Prenez la fourchette au sérieux dans les deux sens. Mettez le chiffre pessimiste dans le modèle que vous montrez à votre board. Faites tourner l’entreprise sur le chiffre attendu. Un fondateur qui a déjà annoncé le chiffre optimiste à ses investisseurs s’est retiré à lui-même la capacité de bien décider plus tard.
Comprenez ce que le modèle de facturation fait à la relation. Le forfait vous achète de la certitude et vous la payez deux fois : une fois dans la prime de risque intégrée au chiffre, une fois dans un partenaire qui gagne désormais de l’argent chaque fois qu’il vous dit non. La régie coûte généralement moins cher au total et exige que vous soyez réellement présent. Aucun des deux n’a raison dans l’abstrait. Nous avons écrit séparément sur ce qui fait vraiment le prix d’une application, et la version courte est que la grosse variable n’a jamais été le taux horaire.
Quand le chiffre dépasse le budget
Le premier réflexe de presque tous les fondateurs est de pousser sur le chiffre. C’est le mauvais levier, et c’est celui qui a le plus de chances de produire un prestataire qui dit oui et un projet qui pourrit en silence.
Poussez sur les décisions. Chaque heure d’incertitude dans l’estimation est accrochée à quelque chose que personne n’a encore tranché, et vous avez le droit de trancher. Coupez ce que vous ne pouvez pas défendre. Repoussez l’intégration qui sert 8% des utilisateurs. Livrez la version qui marche pour une clinique plutôt que celle qui marche pour toutes. Resserrer le périmètre de projet est le seul geste qui réduit le chiffre sans déplacer la douleur vers un endroit invisible.
L’outil de prise de rendez-vous est passé de douze semaines à sept. Non pas parce que quelqu’un a affûté un crayon, mais parce que l’intégration de facturation avec l’assurance, la plus grosse source d’incertitude du plan, a été sortie de la v1 et remplacée par un export CSV qu’une personne lançait le vendredi. C’était laid. C’est sorti à temps pour le client de référence. L’intégration a été construite quatre mois plus tard, proprement, par une équipe qui savait alors à quoi les données ressemblaient vraiment.
La question à poser à la place
“C’est bien, ça ?” est sans réponse, et les fondateurs qui la posent espèrent généralement que quelqu’un les absoudra d’une décision qui leur revient pleinement.
La version qui admet une réponse est celle-ci : qu’est-ce que vous ne savez pas encore, et combien va me coûter le fait de le découvrir ? Une estimation incapable de répondre à cela n’est pas une estimation. C’est un vœu avec des décimales.
Questions fréquentes sur l’estimation de développement logiciel
Qu’est-ce que l’estimation en développement logiciel ?
C’est la pratique consistant à prédire l’effort, le temps et le coût nécessaires à la construction d’un logiciel. Le résultat est véritablement une fourchette, parce que le travail n’a pas encore été entièrement décidé. Quand vous recevez un chiffre unique au lieu d’une fourchette, quelqu’un a tranché à votre place sur l’extrémité de cette fourchette qu’il allait vous montrer.
Quelle est la précision des estimations logicielles ?
Les premières se trompent énormément, et c’est mesuré, pas anecdotique. Au stade du concept, les estimations produites par des estimateurs chevronnés portent une erreur d’environ un facteur quatre dans chaque direction. La précision s’améliore à mesure que les décisions sont prises et que le périmètre cesse de bouger, pas à mesure que l’estimateur se concentre davantage.
Comment estimer le coût d’un logiciel en tant que fondateur non technique ?
Vous ne l’estimez pas. Vous le bornez. Demandez un cas attendu et un pire cas, budgétez sur le pire cas, identifiez la seule ligne qui concentre le plus d’incertitude, et payez pour une investigation courte et bornée dans le temps portant uniquement sur celle-là avant de vous engager sur l’ensemble.
Que dois-je demander quand je reçois une estimation logicielle ?
Quatre choses : quel est le pire cas et ce qui le déclenche, quelle ligne inspire le moins de confiance à l’équipe, ce que l’estimation suppose que vous allez livrer et pour quand, et ce qui a été délibérément exclu du chiffre.
Pourquoi les projets logiciels dépassent-ils toujours les délais ?
En général pas parce que l’ingénierie a été lente. Parce que le périmètre a continué de bouger, parce que des décisions qui revenaient au fondateur sont arrivées tard, ou parce que du travail que tout le monde supposait inclus (migration de données, outillage d’administration, correction de bugs après lancement) n’a jamais été dans le chiffre.