- La modernisation des logiciels legacy rend difficile la définition de l’ensemble du périmètre à partir des seules informations visibles avant le début des travaux ; les estimations initiales doivent donc être traitées comme une base ajustable, et non comme une date butoir
- Comme pour une réparation automobile, on peut au départ établir un devis de 18 000 $ sur 30 jours, mais une fois le démontage et l’inspection effectués, des dommages cachés peuvent apparaître, nécessitant un devis complémentaire et une nouvelle approbation
- Les projets de modernisation révèlent eux aussi une complexité cachée, comme des échecs d’intégration ou des comportements imprévus ; forcer le travail à rentrer dans l’estimation d’origine entre alors en conflit avec la réalité
- Un leadership sain demande non pas « pourquoi ne l’avons-nous pas vu ? », mais quelle est la complexité, quelles sont les solutions, quels sont les trade-offs, quelles sont les alternatives, puis décide de poursuivre ou d’arrêter
- Dans un contexte complexe, il faut répéter les cycles d’essai, d’expérimentation et de découverte plutôt que suivre un manuel figé ; le rôle du leader est de créer un environnement où les patterns peuvent émerger, plutôt que d’exercer un contrôle excessif
Une estimation n’est pas une date limite, mais un repère de progression
- Dans une modernisation logicielle complexe, traiter une estimation comme une date limite ferme entre en conflit avec la réalité révélée par le travail lui-même
- Une estimation initiale est construite à partir des informations visibles de l’extérieur et de l’expérience, mais de nouvelles complexités peuvent apparaître une fois le travail lancé
- Une « estimation » est une approximation de la valeur réelle, et dans une modernisation complexe, il est difficile de prédire parfaitement tous les résultats avant de commencer
L’analogie avec la réparation automobile : dommages invisibles et devis complémentaire
- Dans la réparation automobile, l’expert en assurance soumet d’abord son estimation des dommages à l’atelier, et l’atelier transmet lui aussi son propre devis à l’assureur
- Par exemple, l’expert estime les dommages à 15 000 $
- L’atelier estime les dommages à 18 000 $ et la durée des réparations à 30 jours
- L’expert et les spécialistes de l’atelier évaluent ensemble les dégâts, puis les réparations commencent une fois le nouveau devis approuvé par l’assureur
- Pendant la réparation, des dommages invisibles au départ peuvent être découverts
- Le démontage des pièces peut révéler des dégâts supplémentaires
- Une machine de redressage peut être utilisée pour inspecter les dommages du unibody frame
- Il faut vérifier si l’impact ne s’est pas propagé vers l’arrière du châssis, et pas seulement au point de collision
- Si ces dommages supplémentaires exigent 20 000 $ de plus, l’atelier envoie une demande de réparation complémentaire à l’assureur, qui décide alors de poursuivre les réparations ou de déclarer le véhicule en perte totale (total loss)
- Refuser ces 20 000 $ supplémentaires au seul motif que le devis initial était de 18 000 $ ne correspond pas à une procédure de réparation réaliste
La modernisation legacy révèle elle aussi une complexité cachée
- La modernisation de logiciels legacy relève du domaine des logiciels complexes
- On peut établir une estimation initiale à partir de problèmes apparemment clairs vus de l’extérieur, mais davantage de complexité apparaît au cours du travail réel
- Comme dans la réparation automobile où l’on découvre des dommages cachés ou des dégâts sur le châssis, la modernisation peut faire apparaître des problèmes absents de l’estimation initiale
- Dans ce type de situation, il faut définir l’étape suivante via une nouvelle approbation et une réévaluation, plutôt que de rester enfermé dans l’estimation d’origine
Les questions que posent les bons leaders
- Dans un environnement de développement logiciel sain, lorsque des problèmes apparaissent, on pose des questions utiles à la décision plutôt que de chercher un coupable
- Quel est le niveau de complexité de ce problème ?
- Quelles solutions sont possibles ?
- Quels sont les trade-offs de chaque approche ?
- Existe-t-il des contournements ou des solutions alternatives ?
- À l’inverse, si la discussion glisse vers « pourquoi cette complexité n’a-t-elle pas été vue ? », « pourquoi cela prend-il autant de temps ? » ou « pourquoi la date estimée initiale n’a-t-elle pas été tenue ? », l’équipe se retrouve prisonnière de l’estimation d’origine
- Dans les projets de modernisation, certains vont jusqu’au bout et d’autres sont arrêtés
- Si le coût complémentaire est approuvé, on passe à l’étape suivante et le processus se répète jusqu’à se rapprocher de l’achèvement
- Si le coût dépasse la valeur attendue, le projet peut être arrêté
- La décision entre poursuivre et arrêter n’est pas simple, et des frameworks ainsi que des ateliers d’aide à la décision peuvent être utilisés pour donner une direction
Différence entre contexte compliqué et contexte complexe
- Dans le Cynefin framework de A Leader’s Framework for Decision Making, la réparation automobile ou l’entretien d’une moto peuvent relever d’un contexte compliqué (complicated context)
- Dans la réparation automobile, un expert écoute le récit de l’accident, puis analyse et teste plusieurs éléments — dommages invisibles, dégâts sur le châssis, etc. — afin de déterminer la meilleure action
- Dans un contexte complexe (complex context), on ne peut juger du bon ou du mauvais qu’après avoir essayé
- Une intégration censée fonctionner peut échouer
- On peut découvrir un comportement inédit qu’il faut ensuite prendre en compte
- Il n’existe pas de trajectoire fixe ni de manuel à suivre pour moderniser un système legacy complexe
- La modernisation consiste à répéter un processus d’essai, d’expérimentation, de découverte, de résolution, puis de passage au morceau suivant
Les balles courbes ne sont pas l’exception, mais la réalité
- Si la modernisation applicative se situe entre le complexe et le compliqué, il faut alors un tableau de bord adapté pour évaluer l’avancement et la réussite
- Appliquer un simple processus d’estimation à un contexte complexe revient à vouloir résoudre toutes les vis et tous les écrous au marteau
- Les balles courbes imprévues d’un projet de modernisation sont une réalité
- Il est impossible de prédire tous les résultats à l’avance
- Même avec beaucoup d’analyse préalable, on n’aboutit pas à un modèle de données parfait
- De nouveaux apprentissages surviennent à presque chaque étape
- Le modèle de données doit évoluer selon la complexité découverte
- Lorsque les estimations changent, il faut chercher comment avancer au lieu de se mettre en colère, de blâmer quelqu’un ou de s’enfermer dans une analyse visant à forcer le respect du calendrier initial
La façon dont la culture organisationnelle traite les balles courbes
- Le modèle de culture organisationnelle de Ron Westrum distingue la manière dont les organisations traitent les personnes qui signalent les balles courbes et la façon dont elles gèrent l’échec
- Les organisations Power-Oriented tirent sur le messager qui annonce la balle courbe, et l’échec débouche sur la recherche d’un bouc émissaire
- Les organisations Rule-Oriented ignorent le messager qui signale la balle courbe, et traitent l’échec comme un problème d’application de la définition
- Les organisations Performance-Oriented forment le messager qui signale la balle courbe, et font de l’échec un point de départ pour l’exploration
- Si le problème à résoudre reste pertinent et répond toujours aux besoins métier, il faut avancer une étape à la fois
- La cible finale du logiciel à moderniser reste l’utilisateur
Les domaines complexes exigent une gestion expérimentale
- Un leader qui ne reconnaît pas un domaine complexe peut s’impatienter lorsque les résultats attendus n’arrivent pas rapidement
- Dans un domaine complexe, la capacité à tolérer l’échec est essentielle, car l’échec est un élément indispensable de la compréhension expérimentale
- Un contrôle excessif de l’organisation empêche l’émergence de patterns utiles
- Les leaders qui tentent d’imposer de force de l’ordre à un contexte complexe échouent
- Les leaders qui préparent la scène, prennent du recul, laissent les patterns émerger et jugent quels patterns sont souhaitables peuvent réussir
1 commentaires
Avis sur Hacker News
J’ai connu une période où la direction traitait les estimations comme des échéances, tout en continuant à changer les spécifications, sans vouloir entendre pourquoi elles pouvaient évoluer
Dans ces cas-là, pour chaque tâche un tant soit peu significative, j’adoptais la réaction du « cerf pris dans les phares ». Je disais : « Ça pourrait être assez important. Il faudrait que quelqu’un de l’équipe passe environ une heure à regarder ce qui est réellement nécessaire. » Le manager demandait alors, comme toujours, « même à la louche ». Je donnais alors un chiffre assez élevé pour le faire bondir de sa chaise, et ce chiffre lui restait en tête. Ensuite, après une heure de due diligence, j’évitais autant que possible de donner un autre chiffre que cette estimation approximative, puis je finissais par livrer « en avance sur le planning », ce qui me faisait bien paraître
Avec un bon manager, cette stratégie n’était absolument pas nécessaire, et c’était vraiment appréciable, mais face à des gens qui n’avaient aucune intention d’apprendre les compétences de leur propre métier, je finissais par répondre comme ça. Les réunions sont aussi devenues bien plus amusantes
L’équipe design, l’équipe frontend, l’équipe backend et l’équipe QA gonflaient chacune leurs estimations de cette façon, puis le chef de projet augmentait encore le total de 150 à 200 %, et les account managers ainsi que l’équipe commerciale ajoutaient encore 150 à 200 % avant le chiffrage
Au final, la maintenance d’un site web qui aurait raisonnablement pu être assurée par une équipe dédiée de 8 à 10 développeurs web/full-stack corrects coûtait près de 1 million de dollars par mois. En dehors du support 24 h/24, j’ai l’impression que quelques bons développeurs Rails ou Django, voire un seul avec un graphiste à temps partiel, auraient suffi
Quelques années plus tard, le client s’est rendu compte de la situation, et la direction de l’entreprise a complètement gâché les choses : environ 100 personnes ont perdu leur emploi et des droits impayés. Ce jour-là, j’ai moi-même perdu environ 26 000 dollars
La capacité totale est par exemple de 40 points, et elle varie un peu quand des membres de l’équipe partent ou arrivent. La Velocity correspond au débit moyen en points par personne-jour
La Volatility, c’est à quel point le sprint change. Retirer un ticket à 5 points et le remplacer par deux tickets à 3 et 2 points peut être acceptable, mais si cela arrive 12 fois dans un sprint de deux semaines, même avec un total inférieur ou égal à 40 points, on ne termine pas le sprint
Nous prenions chaque jour un instantané du sprint pour regarder les ajouts et suppressions de tickets, et nous pouvions montrer aux managers que lorsque la volatilité était faible, nous terminions presque toujours, alors que lorsqu’elle était élevée, nous échouions, que la Velocity soit dépassée ou non. La raison est qu’il n’y a pas le temps de planifier correctement et de clarifier les exigences. Faire en sorte que l’équipe produit regarde plus loin que deux semaines aidait dans une certaine mesure
Les ingénieurs qui donnent des estimations exagérément gonflées pour des tâches simples ont aussi souvent tendance à être peu performants. Cela peut marcher avec quelqu’un qui ne juge pas les livraisons lentes, ou avec un manager qui ne connaît pas le contexte, mais un manager informé s’en rend vite compte
Au lieu d’une valeur fixe unique, il faut donner une marge d’erreur, par exemple « 3 mois, ±4 semaines ». La plupart des ingénieurs savent que leurs estimations comportent une marge d’erreur, mais, d’une façon ou d’une autre, ils ont été conditionnés à oublier de le dire
Côté management aussi, la taille de la marge d’erreur montre immédiatement le niveau de confiance dans l’estimation et permet de discuter des risques. On peut alors avoir des conversations du type : « Nous avons actuellement 30 % d’incertitude dans les deux sens ; quelle en est la principale cause, et peut-on passer quelques jours à enquêter pour la réduire point par point ? »
Je ne comprends pas qu’un métier d’ingénierie n’arrive pas à parler correctement de risque, de probabilité et d’intervalles de confiance. Ce n’est pas seulement la faute des managers
On peut comprendre qu’un manager inexpérimenté, ou quelqu’un qui remplace provisoirement une autre personne, ne soit pas à l’aise avec l’incertitude, mais dans les autres situations, il n’y a pas d’excuse
Cet article porte sur des projets de modernisation, et ce type de projet a des échéances souples, car le logiciel existant continue de tourner pendant le développement de son remplaçant
Il peut y avoir une pression budgétaire, des engagements et des attentes utilisateurs pour de nouvelles fonctionnalités, mais si le remplaçant a un jour de retard, ce n’est pas catastrophique
À l’inverse, si vous lancez une sonde spatiale et que la position des planètes ne permet plus l’assistance gravitationnelle, le vaisseau n’atteindra pas sa destination. Si un petit fabricant d’outillage réalisant 100 millions de dollars de chiffre d’affaires annuel signe avec Ford un contrat pour livrer d’ici mars des moules destinés à la ligne de production du F150 2026, avec une pénalité de 20 000 dollars par minute de retard, il ne peut pas dire en février : « On a eu une surprise, ça ne va pas être possible. » Il ne doit signer que s’il est sûr de pouvoir le faire
Ford ou la NASA ne seront pas surpris si l’établissement d’un devis coûte des dizaines de milliers de dollars. Si vous leur donnez un ECO et que vous dites qu’une pièce qui semble réalisable à la main en 30 minutes nécessite 3 semaines et 8 000 dollars, ils savent que cela inclut le risque sur l’échéance, les étapes d’acceptation, les étapes d’inspection, les plans de secours, etc.
Mais si, dans le groupe de modernisation de l’OP, vous dites : « Comme les informations sont incomplètes, une tâche de 30 minutes consistant à changer le libellé d’un bouton peut prendre jusqu’à 3 semaines et 8 000 dollars », vous vous ferez jeter dehors. Les estimations optimistes sont récompensées, les estimations pessimistes sont découragées, et les estimations exactes cessent d’avoir de l’importance. Au final, on est toujours en retard, et personne n’est vraiment surpris
Cela peut inclure des changements matériels, des mises à niveau du système d’exploitation ou la prise en charge de nouvelles fonctionnalités. J’ai vu des projets fonctionner ainsi en parallèle pendant plus de dix ans
En 1505, Michelangelo a estimé qu’il faudrait 5 ans pour achever le tombeau du pape Julius II
En réalité, cela a pris environ 40 ans, à cause de petits à-côtés comme le plafond de la chapelle Sixtine
Comme l’échéance fondée sur l’estimation n’a pas été tenue, la portée du projet a été fortement réduite. Le pape Julius II est mort avant son achèvement, et il y a eu des demandes de changement de la part du client, Julius, et de ses héritiers, des problèmes de chaîne d’approvisionnement, des renégociations de contrat, des conflits sociaux, une pénurie de travailleurs qualifiés et un épuisement des financements dû à la durée très longue
Donc ce genre de chose existe au moins depuis 1505. Le plus drôle, c’est que le pape n’est même pas enterré dans ce tombeau
J’ai appris quelque chose d’important au début de ma carrière. Le premier chiffre annoncé reste dans les mémoires
Malheureusement, c’est souvent vrai en pratique, et les gens continuent de dire : « vous n’aviez pas dit X au départ ? ». « Oui, mais nous avons obtenu de nouvelles informations » ne marche pas toujours
Effet pervers : les personnes qui le savent finissent aussi par éviter de donner des chiffres
Scotty : « Bien sûr, capitaine. C’est comme ça qu’on garde sa réputation de faiseur de miracles »
Par exemple, jour→semaine, semaine→mois, mois→trimestre. Si quelque chose doit prendre une journée, j’annonce 3 semaines. Ça paraît beaucoup, mais au final, avec la bureaucratie, les procédures et la dette technique, on termine généralement dans ces eaux-là
Il y a un passage qui dit : « Imagine-t-on un assureur contester auprès d’un réparateur que, puisque l’estimation initiale était de 18 000 dollars, il ne paiera pas les 20 000 dollars supplémentaires ? C’est absurde, non ? Moi aussi. Heureusement, le monde réel ne fonctionne pas comme ça ». Or, dans l’assurance, ce genre de chose arrive tout le temps
Ce n’est pas vrai seulement pour l’assurance auto ou habitation, mais aussi pour l’assurance santé. Souvent, cela se négocie jusqu’à un point raisonnable, mais pas toujours ; le ton très assuré de « le monde réel ne fonctionne pas comme ça » est donc surprenant
Même si déclarer une perte totale peut coûter plus cher, le plafond est clair et le dossier peut être clôturé. Les assureurs n’aiment pas les dossiers ouverts
Le second, aussi appelé « tarif préférentiel » dans l’assurance auto, est un contrat-cadre selon lequel certains types de travaux sont facturés à un tarif négocié fixe
C’est très différent d’un devis ferme. Un devis ferme est généralement une estimation ponctuelle pour un travail précis, dans laquelle l’estimateur prend le risque et s’engage à terminer à ce tarif même si c’est beaucoup plus complexe que prévu
Une astuce, quand c’est possible, consiste à n’estimer que pour un périmètre fixe, en excluant les inconnues que l’on ne peut pas connaître
Il ne faut pas estimer « implémenter la fonctionnalité X », mais « le moteur de la fonctionnalité X ». Si l’on découvre du travail supplémentaire, il faut l’ajouter sous forme de jalons découverts, comme « refactorisation du code existant » ou « intégration des fonctionnalités X+Y »
Mais cette nomenclature et cette compréhension doivent remonter dans la hiérarchie pour que cela fonctionne. Si quelqu’un transforme le jalon « moteur de la fonctionnalité X » en « fonctionnalité X terminée » avec la même estimation, c’est fichu
J’ai aussi vu un problème lié : le leadership qui considère les deadlines comme de la « motivation ». C’est comme les gens qui veulent chauffer une maison à 72F et règlent le thermostat sur 80F « pour que ça aille plus vite »
Une fois, les autres participants à une réunion de direction ont oublié que moi, simple ingénieur subalterne, j’avais été invité. Quelqu’un a reconnu qu’il serait très difficile de tenir la deadline X et a demandé s’il fallait la remplacer par une date plus réaliste ; un PM senior a répondu : « Nous ne déplaçons jamais les deadlines ! L’ingénierie utilise tout le temps qu’on lui donne ! »
Dans ce cas précis, l’ingénierie a rendu du temps quand j’ai quitté l’équipe
Il est également vrai que beaucoup d’équipes d’ingénierie utilisent tout le temps qui leur est donné
Mais les managers devraient préparer l’organisation aux dépassements, plutôt que de transformer estimations et plans en deadlines rigides devant les ingénieurs. Si, à l’approche de la date de fin prévue, les développeurs peuvent expliquer quelles parties ont pris plus longtemps et pourquoi, cela devrait être raisonnablement compris
Les managers doivent aussi faire en sorte que les clients, les commerciaux et les dirigeants au-dessus d’eux ne traitent pas la date de fin planifiée comme une deadline. S’il faut prendre un engagement, la deadline côté client doit être nettement postérieure à la date de fin estimée
Les radiateurs électriques peuvent aussi avoir cet effet en pratique, car ils ne s’éteindront pas immédiatement simplement parce que l’air près du radiateur s’est réchauffé
Après avoir vu trop d’« estimations au doigt mouillé » se transformer en deadlines dures, je pousse auprès des parties prenantes une approche No Estimates
Au début, il y a évidemment de la résistance. Pour lever les inquiétudes, il est utile d’expliquer que des estimations assez précises pour être légitimement utilisées dans la planification ne sont en réalité possibles que dans deux cas
A) Lorsque le travail restant ressemble fortement à une copie du travail passé. Par exemple, provisionner un second datacenter pour le même système
B) Lorsque l’équipe juge que le nouveau travail fonctionnel restant est entré dans le dernier quartile et qu’il est bien défini, y compris les risques restants qui pourraient empêcher le succès
Les micro-estimations rendent possible le micro-management. Une équipe saine identifie les tâches les plus prioritaires en fonction des risques pesant sur la réussite du projet, puis les exécute dans cet ordre
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
Une formule amusante que j’avais vue autrefois sur HN m’a marqué. Elle est tape-à-l’œil et a l’air élégante, mais comme les autres méthodes d’estimation, elle n’a aucune validité formelle et n’est qu’une formule arbitraire fondée sur une expérience personnelle
https://news.ycombinator.com/item?id=37965582
Mes maths d’estimation : R = t × [1.1^ln(n+p) + 1.3^X]
R est le temps réellement nécessaire, t le temps minimal possible lorsqu’aucune communication n’est nécessaire, n le nombre de personnes impliquées dans le processus, y compris côté client et organisation de développement, p la plus longue distance de communication dans le projet, et X le nombre de nouveaux outils, bibliothèques ou techniques utilisés dans le processus
Par exemple, si un projet où un seul développeur écrit le code prend 2 semaines (t=2), implique 5 personnes au total (n=5), utilise 1 nouvel outil (X=1) et a une plus longue distance de communication de 4, alors 2×(1.1^ln(5+4) + 1.3^1) = 4,5 semaines
Il faut ajouter à X non seulement les inconnues connues, mais aussi les inconnues inconnues
Malheureusement, une estimation est une négociation. Celui qui donne le chiffre en premier perd généralement à cause de la « grimace ».
« Quelle est l’estimation ? » « Je ne sais pas vraiment. » « Même approximativement. »
« Alors, vous voudriez que ce soit fait pour quand ? »
C’est le piège dans lequel les nouveaux managers tombent à chaque fois. Si vous donnez une réponse, bingo. C’est là qu’ils affichent la « grimace ». Ils inspirent entre leurs dents, font la moue et disent : « Ah, c’est totalement irréaliste. D’où sort ce chiffre, au juste ? », puis avancent un chiffre plusieurs fois plus élevé ou proposent de réduire le périmètre. Du genre : « Ouh là, dans ce délai, avec de la chance, on pourrait seulement livrer la fonctionnalité X, à condition de couper la fonctionnalité Y de l’autre projet. »
Quoi que vous fassiez, l’important est de ne pas donner le premier chiffre. Comme au poker ou lors de l’achat d’une voiture, il faut un peu de temps pour prendre le coup de main. Le temps, même dans les grandes entreprises, c’est de l’argent, et il faut le traiter comme tel. C’est un jeu à somme nulle.
Là où je travaille, au nom de l’efficacité, les estimations sont sans cesse revues à la baisse, et le travail reporté n’est pas autorisé non plus.
On a vécu pendant plus d’un an dans un état proche du crunch, sans temps de récupération. J’ai continué à espérer que ça s’améliore, mais j’ai l’impression que ça empire au contraire. En plus, tout le monde est constamment réaffecté à d’autres zones du produit, sans avoir le choix. Je tiens encore debout, mais mentalement je me sens complètement vidé.