- Un grand projet client pour une entreprise du Fortune 500 a démarré avec une dépendance à un produit d’éditeur, mais il s’agissait en réalité d’un logiciel proche d’un produit semi-fini nécessitant une lourde personnalisation
- L’intégration du produit de l’éditeur a cumulé les défauts d’un package rigide et du développement sur mesure, menant après la livraison d’août à une death march d’intégration pour tenir la mise en production d’octobre
- Une architecture qui stockait toutes les transactions client dans un unique document JSON géant a provoqué des problèmes de performance, et la limite de 16 Mo par document de MongoDB à l’époque s’est révélée être une contrainte fatale lors de la migration des données réelles
- L’entreprise a caché le problème au client et à l’éditeur, a lancé avec un mois de retard, puis a mené en environ deux mois une réécriture skunkworks pour remplacer l’intégration de l’éditeur avec une équipe interne de 3 personnes
- Quand le CTO a exigé du travail pendant les fêtes juste avant Noël, le chef d’équipe a fait croire chaque jour que des travaux déjà terminés étaient encore en cours afin de laisser les développeurs se reposer, et l’équipe a tenu le calendrier de test de janvier ainsi que la mise en production
Une mauvaise conception née d’un produit d’éditeur
- Dans une entreprise du Fortune 500, le CTO a promis la livraison d’un grand projet pour un client important avec lequel il avait des liens personnels
- La partie centrale a été externalisée à un grand prestataire de services technologiques, et l’éditeur affirmait disposer d’un produit capable d’absorber l’essentiel du travail lourd
- En réalité, le produit ne correspondait qu’approximativement aux besoins, si bien qu’une lourde personnalisation était nécessaire pour obtenir le comportement attendu
- Résultat : les inconvénients du logiciel d’éditeur et du logiciel sur mesure se sont additionnés
- C’est devenu un package rigide qu’il fallait forcer à faire quelque chose pour lequel il n’avait pas été conçu
- Comme il était forké à partir de la base de code principale de l’éditeur, les coûts de maintenance ont explosé et le risque d’une fin de support est apparu
- Les personnes impliquées dans le projet voyaient bien que cette approche était mauvaise, mais comme les rattachements hiérarchiques directs du CTO changeaient souvent, les réunions de suivi se résumaient à des « bonne idée, chef »
Retards de planning et structure de données fatale
- L’équipe de développement interne a construit elle-même d’autres parties du projet, tandis que l’éditeur promettait tout l’été que son produit serait bientôt intégrable
- Quand le produit de l’éditeur a été livré en août, une death march d’intégration a commencé pour viser une mise en production en octobre
- En septembre, des bugs suffisamment graves pour bloquer le lancement sont apparus
- Le produit de l’éditeur stockait toutes les transactions client comme des enregistrements JSON dans un seul document JSON gigantesque
- Plus les données de test s’accumulaient, plus les performances ralentissaient
- À chaque ajout d’une nouvelle transaction, l’application lisait tout le document JSON depuis la base de données puis ajoutait le nouvel enregistrement à la fin
- L’éditeur a affirmé qu’ajouter des index sur les champs de transaction réglerait le problème, et cette approche a semblé aider pendant un temps
La limite des 16 Mo de MongoDB et la réécriture cachée
- Le problème plus grave encore venait du fait que la base de données choisie par l’éditeur était MongoDB, qui imposait alors une limite de 16 Mo par document
- En octobre, quand l’équipe de migration a commencé à injecter les vraies données client, elle s’est heurtée à cette limite de 16 Mo
- L’entreprise a décidé de démarrer l’exploitation avec un mois de retard sans révéler cette limite au client
- En parallèle, elle a lancé un projet skunkworks pour remplacer l’intégration de l’éditeur
- L’éditeur n’en a pas non plus été informé
- La situation essentielle a donc été cachée à la fois au client et au partenaire technologique
- Environ 70 personnes étaient mobilisées côté éditeur à l’origine, mais le remplacement interne n’a été confié qu’à 3 personnes
- 1 pour la conception de la base de données
- 1 pour construire le back-end en interface avec la base de données
- 1 pour construire la logique métier et les services web
La décision prise juste avant la death march des fêtes
- Il a été indiqué au client qu’une nouvelle version serait fournie en janvier pour les tests et qu’elle corrigerait les défauts les plus critiques acceptés lors du démarrage initial
- En revanche, le client n’a pas été informé que l’ensemble du système central était en train d’être réécrit en environ deux mois
- Le projet initial avait demandé plus d’un an jusqu’à la mise en production, mais cette réécriture devait être menée par 3 personnes, y compris pendant la période des fêtes
- Vers la mi-décembre, les participants au projet ont appris, non pas sous forme de demande mais d’instruction, qu’ils devraient travailler pendant les fêtes
- La plupart des membres de l’équipe étaient déjà en burn-out après six mois à travailler 60 à 80 heures par semaine
- Une sortie logicielle procure une pression et une récompense comparables à celles d’un spectacle sur scène
- Le résultat de plusieurs mois ou années de préparation atteint de vrais utilisateurs le jour de la mise en production
- Les développeurs en tirent une forte sensation d’accomplissement, à la fois par le sentiment de « je l’ai fait » et par la réaction des utilisateurs
- Une sortie logicielle peut ressembler à un spectacle live pour introvertis
Une semaine à mentir au CTO pour laisser l’équipe se reposer
- À l’approche de Noël, l’équipe de 3 personnes avait quasiment terminé le logiciel de remplacement en un mois
- Il restait encore des fonctionnalités à finaliser, mais tant que l’équipe n’entrait pas en burn-out, elle pouvait tenir le calendrier de test de janvier
- Quand le CTO a ordonné l’annulation des congés, le chef d’équipe a répondu « OK » en apparence
- En réalité, il a dit aux 3 développeurs : « Prenez une semaine de repos. Je m’en occupe. »
- Chaque matin, le chef d’équipe participait à la réunion de suivi obligatoire et faisait au CTO des comptes rendus comme si des tâches terminées le mois précédent étaient encore en cours
- « L’équipe travaille d’arrache-pied. Aujourd’hui, nous avons atteint le jalon d’intégration n°73 »
- « Hier, l’équipe a bien avancé et a terminé un autre service web »
- Les développeurs sont revenus une semaine plus tard complètement requinqués
- L’équipe a tenu l’échéance de janvier, réussi une bonne mise en production et s’est sentie, pour un moment, comme des rock stars
- Ce sentiment était plus proche de Herman’s Hermits que de The Beatles, mais l’auteur se souvient que c’était quand même agréable
1 commentaires
Avis sur Hacker News
Si vous êtes du genre à annuler vos vacances et à continuer à travailler au nom de la « culture de la deadline », alors, pour l’avoir vécu moi-même, j’ai envie de vous dire arrêtez d’être idiot
Quand on est reconnu pour avoir beaucoup travaillé, il est particulièrement difficile de s’arrêter, mais on finit par regretter tout ce temps
Si votre entreprise considère comme normal de puiser dans les jours fériés et les congés des employés pour vendre son produit, elle contribue à créer le monde dysfonctionnel dans lequel nous vivons
Si beaucoup de gens font cela, alors davantage de gens devront le faire aussi ; si personne ne le fait et que tout le monde agit comme si une telle demande était absurde, l’entreprise finira par faire des estimations réalistes, même si cela fait mal à la poche du CEO
Il suffit d’annoncer ses vacances, de prévoir un remplaçant, de les inscrire dans le calendrier de l’équipe, de faire la passation, puis de partir se reposer
Les projets vont et viennent, et les plannings glissent parfois tout seuls
Si vous commencez à déplacer vos vacances pour coller au planning du projet, vous ne partirez plus jamais en vacances de votre vie
La seule exception serait un poste où les périodes chargées sont clairement connues, comme la fin d’année, la fin de trimestre ou la saison fiscale, et où il serait inapproprié de disparaître à ce moment-là
Mon cousin a travaillé presque tous les jours jusqu’à 1 h du matin, de septembre 2023 à janvier 2024, pour finir un projet atrocement mal géré, et il n’a eu que Noël de repos, encore parce que c’était un jour férié religieux et que le directeur avait peur que les employés attaquent en justice
Il a raté des choses importantes et a perdu une dizaine de kilos à cause du stress
L’entreprise avait une échéance serrée pour migrer vers un nouveau système, alors qu’elle savait depuis cinq ans qu’il fallait le faire et n’a commencé que l’année précédente
Si elle ratait la deadline, cela lui aurait coûté des millions de dollars en frais hors contrat ; au final l’équipe a tenu la date, mais la récompense a été un licenciement quelques semaines plus tard au motif que son poste n’existait plus
Il cherche maintenant du travail après la cinquantaine, au pire moment pour devoir retrouver un emploi
Ils sont accros au sentiment d’avoir de la valeur et d’être indispensables, et n’ont rien d’autre à faire une fois rentrés chez eux
Dans plusieurs cas, l’employé récompensé portait aussi une part de responsabilité dans le désastre en question
Ce n’est qu’à la quatrième histoire environ que les cadres supérieurs présents dans la salle ont réalisé que l’entreprise avait un problème structurel
Si des jeunes lisent ceci, sachez que la manière dont ce genre d’histoire se déroule dépend énormément de l’entreprise et de la chance
Dans une entreprise saine, il est fort probable que cette façon d’externaliser l’implémentation n’aurait jamais été lancée
C’est un schéma d’échec tellement évident que des personnes expérimentées peuvent en prévoir l’issue avant même le début
Plus tôt dans le processus, les gens n’auraient pas menti au CTO en disant que tout allait bien ; ils auraient dit que cela ne fonctionnait pas
S’il avait fallu une approche plus intelligente ou plus créative pour sauver le projet, cela aurait été ajusté avec le CTO, voire avec le client
On n’aurait pas non plus imposé de longues heures de travail pendant les jours fériés à une équipe déjà en burn-out
Un manager ou un lead aurait tenu tête à la hiérarchie pour la réussite du projet et la santé de l’équipe, et aurait défendu au besoin le droit de l’équipe à se reposer pendant les congés
Dans une organisation « à moitié saine », un manager peut certes entretenir délibérément du flou ou omettre certaines informations, et selon le contexte cela peut être bien ou mal
Mais si, comme dans cette histoire, un manager ou un lead ment de manière répétée et flagrante tout au long de la chaîne hiérarchique, c’est généralement perçu comme très grave, que l’entreprise soit saine ou non
Évidemment, il est beaucoup plus facile d’évaluer ce genre de situation après coup, les bras croisés
Tout le monde peut se tromper dans une position difficile ou en état de surmenage, mais il est utile d’étudier ce type de scénario pour mieux réagir si l’on se retrouve de nouveau jeté dans une situation similaire
Si vous êtes dans ce genre d’entreprise, mieux vaut commencer à chercher ailleurs
À ce niveau de pourriture au sommet, c’est irréparable, et ils ne vous feront pas CTO pour autant
En 25 ans de carrière, je n’en ai jamais vu une seule
Il a fallu un an et demi pour corriger ça, et pendant tout ce temps, on ne pouvait même pas annuler une vente au motif que des « sous-vêtements » avaient été expédiés
En réalité, l’entreprise ne vendait pas de sous-vêtements mais uniquement des services réseau, et nous ne pouvions aider le client qu’après avoir attendu que le système clôture le processus de commande
Ce membre du conseil est parti un an plus tard et devait être assez satisfait d’avoir roulé ce CEO stupide
J’ai fini par être licencié de là-bas, et je n’ai absolument aucune sympathie pour cette entreprise désordonnée
C’était une bande d’idiots qui avaient voulu externaliser la « solution » et n’avaient fait qu’ajouter de la souffrance pour tout le monde
Il existe de vrais problèmes qu’il faut résoudre, mais la moitié de ces projets ne sont que des déchets destinés à donner l’impression qu’on économise de l’argent en ne développant pas en interne
Au final, on continue quand même à payer les coûts du contrat pour maintenir des déchets qu’on n’a même pas développés au départ
Je veux dire par là : ne pas cacher les problèmes et exposer les faits tels quels, ce qui est extrêmement rare
Il suffit de regarder le mémo sécurité de Microsoft
L’idée qu’il n’y ait pas de death march pendant les jours fériés est plus ou moins vraie si vous travaillez dans une banque ou chez les FAANG
Si c’est une entreprise avec une « culture startup », autant oublier
En pratique, quand leurs propres intérêts sont en jeu, l’attitude des gens vis-à-vis du travail change assez vite, mais à mon avis il n’y a pas beaucoup d’entreprises qui vous donnent l’occasion de le constater
Il m’est souvent arrivé d’enfreindre discrètement les règles au milieu de la nuit pour faire ce qu’il fallait, et beaucoup de gens compétents ont suivi la même voie
J’ai vu cela même dans des banques
Tant qu’il ne s’agit pas de prendre des paris financiers plus gros que la valeur de l’entreprise ou de l’équipe, beaucoup de choses passent
Soit on y arrive et on obtient une promotion, soit on réduit soi-même ses chances d’être promu, et il ne reste plus qu’à chercher un nouveau poste ensuite
Le passage expliquant que « le produit du vendeur stockait toutes les transactions client comme des enregistrements JSON à l’intérieur d’un énorme document JSON, et que pour ajouter une nouvelle transaction il fallait relire tout le document JSON depuis la base de données puis y ajouter le nouvel enregistrement à la fin » est censé paraître complètement dingue.
Dans le même genre, j’ai déjà aidé à faire la due diligence technique d’une cible d’investissement potentielle pour un fonds, et la table utilisateurs de cette startup contenait aussi les données de billets/réservations.
Un billet correspondait à une colonne, donc si l’utilisateur le plus actif de tout l’historique avait 5 billets, il fallait 5 colonnes.
Au moment de l’audit, il y avait déjà plus de 500 colonnes, et ils cherchaient des financements pour « passer à l’échelle ».
C’était bien sûr un problème solvable, mais comme on peut l’imaginer, tout avait été conçu de travers de fond en comble, et c’était le moment le plus évident de type « mais qu’est-ce que c’est que ça ? ».
Ils n’ont pas obtenu l’investissement.
Toute la base clients et produits était stockée dans un unique fichier
.jspublic de plusieurs mégaoctets, avec les mots de passe en clair, et avec les débits Internet du début des années 2000, l’application devait charger tout ce fichier avant de pouvoir faire quoi que ce soit.En plus, l’application elle-même était un unique fichier géant, et le répertoire était rempli de noms comme
index.1.js,index.final.js,index.newest.js,index.45.js.J’avais assez d’expérience pour connaître les bonnes pratiques, donc je suis allé voir le CEO pour faire licencier le CTO, puis j’ai commencé à tout reconstruire avec
git,mysql, de la logique côté serveur et une vraie architecture.Ensuite, le serveur Windows sur lequel tout ça tournait s’est fait pirater et a été transformé en serveur porno ; je ne l’avais jamais vu et je n’avais aucun droit d’admin, mais d’une manière ou d’une autre c’est devenu ma faute.
Mes premiers postes ont vraiment été très instructifs.
Le système avait été conçu par un ingénieur senior qui se vantait d’être passé par Stanford.
J’ai longuement argumenté, données de production à l’appui, qu’une fois lancé le système ne passerait pas à l’échelle, mais personne n’a écouté, et il s’est effondré quelques semaines après le lancement.
Peu après, j’ai changé d’équipe ; le pire, c’est que cet ingénieur senior a fini par être promu, et que le système a été refilé à une toute nouvelle équipe qui a dû se débrouiller avec.
L’architecture globale du système était épouvantable, et on peut sans doute deviner pourquoi.
Convaincre les dirigeants avec des dîners chics et des voyages, puis leur refiler un produit bancal afin qu’ils aient encore besoin d’eux à l’avenir.
Dans le récit lui-même, le CTO n’avait manifestement aucune idée de ce qui se passait.
De son point de vue, à la fin, tout a l’air de s’être très bien terminé.
Une victoire pour tout le monde, sauf pour les développeurs qui ont bossé 80 heures par semaine.
Tout dans cette histoire est dysfonctionnel, y compris l’approche du protagoniste.
Qu’un responsable d’équipe accorde des congés à des gens puis le cache par des mensonges est totalement inacceptable, et on entre clairement dans une zone où l’entreprise pourrait licencier quelqu’un pour ça.
On dirait même quasiment un licenciement pour faute.
Cela dit, la direction semble tellement hors de sa trajectoire qu’il pourrait probablement s’en tirer, voire se faire féliciter.
Ça ressemble à un comportement adapté à l’environnement dans lequel il se trouvait.
Si je devais conseiller ce nouveau team lead, je lui dirais qu’il n’y a rien ici dont il devrait être fier, et qu’un meilleur choix aurait été de signaler bruyamment que les gens faisaient des heures sup, puis d’exiger qu’on applique au vendeur des standards normaux ou qu’on revoie la portée du projet pour qu’elle tienne dans une semaine de travail normale.
Faire en sorte que ce genre de situation tienne malgré tout ne profite à personne et peut simplement mener les gens au burn-out ou au licenciement.
À moins d’être dans une situation vraiment désespérée pour faire vivre sa famille, un team lead a la responsabilité de protéger les horaires de travail raisonnables de son équipe contre des exigences délirantes.
C’est la colline sur laquelle il faut être prêt à se faire virer, pas celle sur laquelle il faut mentir.
Donc, si cela n’a pas eu d’impact sur les résultats, il est tout à fait acceptable que le team lead accorde des congés aux gens et aille même jusqu’à mentir à ce sujet.
Si ça avait été partagé, qu’aurait fait la direction ? Elle aurait avancé le projet encore plus.
Les gens qui veulent faire bosser les autres plus dur pour leur propre gloire méritent qu’on leur rende la monnaie de leur pièce.
Au juste, qui a vu sa journée sauvée ?
Le vendeur médiocre qui a livré des déchets ?
Le CTO qui s’entoure de béni-oui-oui et n’a manifestement aucune idée de ce qui se passe dans son entreprise ?
Les développeurs qui ont trimé jusqu’à l’os, pour qu’au final on leur dise « ça va, je vous ai laissé prendre une semaine de vacances » ?
Le protagoniste, qui a menti à tout le monde pour respecter une échéance arbitraire fixée par une entreprise qui se moque de ses employés ?
Cette histoire m’a fait frissonner du début à la fin.
Je suis du genre à travailler dur, et il m’est arrivé de faire un peu d’extra pour que des mises en production côté client se passent bien, mais cette histoire relève de la folie pure.
Si l’on consacre parfois plus de temps, c’est parce qu’il existe une relation de confiance avec son manager et qu’on sait qu’on peut toujours dire la vérité.
En réalité, c’est le concept central d’une culture sans blâme, et cela n’est possible que lorsque tout le monde dit la vérité.
Mentir comme un possédé pour tenir les délais d’un CTO idiot, c’est littéralement insensé.
Si vous êtes dans ce genre de situation, il faut en sortir immédiatement et trouver un meilleur emploi.
« De la fierté et un sentiment d’accomplissement », et un burn-out ?
Quand il dit « on a tenu le planning de janvier, on a super bien lancé, on a eu un petit moment de rock stars », le « on » veut clairement dire moi.
J’ai peut-être juste eu de la chance, mais je n’ai jamais été licencié pour avoir dit la vérité, et la vérité était plus facile à faire coller aux faits
Du genre : « Il y a un bug dans une bibliothèque tierce sur le chemin critique. On peut rendre le bug plus difficile à déclencher, mais on ne peut pas le corriger avant que l’éditeur le fasse », ou bien : « Avec la hausse du nombre d’utilisateurs, des problèmes de performance sont apparus plus tôt que prévu. Pendant les deux mois nécessaires pour corriger ça, soit on triple les dépenses d’infrastructure pour atténuer le problème, soit on risque de perdre des clients à cause des performances », ou encore : « Notre plus gros client n’a compris ce qu’il voulait qu’après avoir reçu le premier prototype. C’est complètement différent de ce qu’on pensait construire. Soit on construit ça et on en tire des revenus, soit on poursuit un rêve et on meurt. »
Encore une fois, j’ai peut-être simplement eu de la chance, mais l’honnêteté a bien fonctionné pour moi
Donc, comme d’autres l’ont dit, ils répondent « je vais examiner ça », puis vous écartent lentement ou vous affectent à des tâches subalternes
La deuxième option, c’est de se taire et de les regarder peiner longtemps avant d’échouer
En général, ça prend environ un an, mais j’ai aussi vu des cas abandonnés en 2 ou 3 mois, avec un leadership de fait débarqué au trimestre suivant
Si quelqu’un demande votre avis, vous pouvez exposer vos inquiétudes avec diplomatie, mais si personne ne demande, vous pouvez aussi vous taire
La vraie question est de savoir si vous allez signaler activement les problèmes d’un plan porté par quelqu’un de plus haut placé que vous qui veut s’en attribuer le mérite
Dès que vous le faites, cette personne a l’impression que son jugement est remis en cause et le prend comme une attaque personnelle
C’est extrêmement difficile à faire sans se faire d’ennemis, et les ennemis restent longtemps ; le tort causé par un seul ennemi est difficile à compenser, même avec plusieurs amis
Donc il faut jouer le jeu
Le fait que l’auteur mente à propos de choses déjà terminées est un détail vraiment important
Chaque matin, pendant la réunion obligatoire de suivi de death march avec le CTO, il entrait en disant « l’équipe travaille dur », « aujourd’hui nous avons atteint le point d’intégration du jalon n°73 », « hier nous avons bien avancé et terminé un web service de plus », alors qu’en réalité il s’agissait de travaux déjà terminés le mois précédent
Sous un certain angle, ça ressemble à du sous-promettre et sur-livrer
S’il avait menti en disant que des choses non terminées étaient finies, ça aurait été bien plus dérangeant
Clairement plus risqué, et du point de vue de l’équipe, ce n’aurait pas été idéal non plus de revenir en disant : « Voici les tickets, j’ai déjà dit au CTO que c’était terminé, alors dépêchez-vous »
Les interactions entre développeurs et direction souffrent énormément de l’asymétrie d’information et d’un manque de confiance
En ce moment, je travaille sur un projet de mise à jour d’une base de code qui tourne sur un compilateur très ancien
Ça fait un an qu’on travaille dessus, de gros pans du système sont terminés, mais il reste encore une partie assez importante
La direction ne comprend pas le processus et n’a pas la certitude que le projet finira par réussir
Je ne leur en veux pas d’être inquiets, vu le long historique d’échecs des projets logiciels, en particulier des travaux de migration
On faisait des réunions d’avancement chaque semaine, et maintenant c’est passé à deux fois par semaine, comme s’ils pensaient que ça allait accélérer les choses
La plupart du temps, ils n’y assistent pas directement et passent par un manager intermédiaire qui joue les messagers
Du point de vue des développeurs, il est évident que ça va fonctionner, et je n’ai personnellement jamais douté du succès
C’est juste que le système est gros et ancien, donc la durée reste incertaine
Ce qu’il reste se compte en mois, pas en années, et je connais la règle des 80/20, mais on est déjà bien enfoncés dans ces 20 %
Pour la direction, tout cela n’est qu’un état binaire terminé/pas terminé, donc il leur est difficile d’évaluer l’avancement, et il n’y a pas de « confiance » dans ce qu’on dit
C’est compréhensible
Même si nous n’avions rien fait pendant un an, tant qu’on tenait les réunions, ils ne l’auraient pas su
C’est un contrat au forfait, donc nous n’avons aucune raison de faire traîner, mais tout le risque est de leur côté
Ils ont déjà dépensé beaucoup d’argent et sont nerveux
Ils ont pris de bonnes décisions techniques sur la base des conseils d’experts techniques externes, mais restent malgré tout sans vraie certitude
Au final, si le projet échoue, c’est eux qui prendront le choc, pas nous — ou en tout cas beaucoup moins
Il n’y a pas de solution simple
On ne peut pas juste exiger que les managers soient techniques, d’autant que cette technique n’est même pas au cœur de leur activité
Faire venir davantage de consultants ne les rassurera pas pour autant
Le mieux qu’on puisse faire, c’est continuer d’avancer et livrer
Même en blocs d’un mois, ça irait ; il suffit d’affiner et de tout décomposer en sous-tâches
Ce n’est pas grave si ce n’est pas parfait, ni s’il reste des zones floues
Je recommande de donner à chaque bloc un nom sympathique et amusant
Par exemple, des noms de danses classiques comme tango, cha-cha ou valse conviennent bien
Il suffit d’organiser des réunions avec les managers, d’y inclure les cadres supérieurs et de demander aux managers intermédiaires d’assister aux stand-up quotidiens
Faites en sorte que tout le monde reste debout pour que les réunions soient courtes, et suivez l’avancement par rapport aux tâches de la liste
Qu’une tâche s’ajoute ou prenne un peu de retard ne surprend pas les gens tant qu’on reste globalement sur la bonne trajectoire
Nous savons tous les deux que le vrai gros passage difficile, c’est la mise en production, mais il n’est pas nécessaire de leur en parler avant que tout soit prêt
Les retards rendent la direction nerveuse, ce que je comprends, mais multiplier les réunions ne fait pas aller les choses plus vite
Qu’un PM fasse un point de 30 minutes tous les jours en disant « je vais vous soutenir et vous fournir tout ce qu’il faut pour remettre le projet sur les rails » n’aide pas
La seule chose nécessaire, c’est moins de réunions
Le seul obstacle, c’est le temps, et si le temps est un obstacle, c’est parce qu’au départ la hiérarchie a imposé un calendrier irréaliste
Au fond, en montrant qu’ils ne font pas confiance aux développeurs, ils montrent aussi qu’ils ne font pas confiance à leur propre capacité de management à avoir choisi les bons développeurs
Ils sont très mauvais sur un aspect essentiel de leur travail
Un projet d’un an ne devrait pas se résumer à un état binaire terminé/pas terminé
Il devrait y avoir des indicateurs d’avancement exploitables
Les dirigeants n’ont pas besoin d’être techniques, mais il doit impérativement y avoir, quelque part dans la hiérarchie, quelqu’un capable de traduire l’avancement dans un format compréhensible
Il y a deux choses dont je suis sûr à propos du prestataire, et elles sont difficiles à pardonner
La première, c’est qu’il a fait en sorte que la logique centrale dépende du fait de faire grossir indéfiniment des enregistrements Mongo, et la seconde, c’est qu’avec un effort délibéré de trois personnes un peu au-dessus de la moyenne, on aurait pu le remplacer en environ trois mois
Le fait que ce prestataire soit arrivé à traiter avec des clients du Fortune 500 montre à quel point des organisations similaires à ce client peuvent se sentir impuissantes face à un travail logiciel pourtant pas si important
En réalité, la portée de ce projet semble être le genre de chose que certains ici pourraient réaliser comme projet hobby
Du coup, je comprends aussi pourquoi Retool est populaire auprès des responsables techniques, mais pas forcément auprès des ingénieurs
Je me demande quelle autre approche produit pourrait combler le même écart
Grâce aux tableurs, n’importe qui à un échelon assez bas dans l’organisation pouvait bricoler en quelques jours un prototype grossier mais presque fonctionnel, sans avoir à passer par d’autres personnes de l’entreprise
Avant les tableurs, il fallait convaincre la hiérarchie de faire prendre en charge la demande par le service IT, et rien que ce processus prenait au minimum trois mois
Ensuite, il aurait fallu attendre encore quelques trimestres pour recevoir une implémentation grossière mais presque fonctionnelle, écrite en Cobol ou en C, qui ne correspondait pas aux besoins
Quelques développeurs et quelques personnes du support sont allés rencontrer les utilisateurs, et les développeurs travaillaient depuis six mois sur un nouvel outil censé résoudre un gros problème
Sauf que ce jour-là, c’était la première fois que les utilisateurs finaux le voyaient
Peu après, nous reprenions la route en repassant la frontière de l’État, et les développeurs faisaient profil bas
À ma connaissance, plus personne n’a jamais reparlé de ce projet
Ils font faire tout le travail aux juniors et le facturent au tarif horaire d’un développeur senior
J’aimerais vraiment que les gens arrêtent d’utiliser des images d’en-tête générées par IA
Ça casse la concentration dès le départ
Le code est derrière l’écran, là ?
Et il y a aussi du code sur le dossier de la chaise au fond ? Ou alors la personne assise est un iPad géant ?
Si on va utiliser des images IA, il faut au moins faire en sorte qu’elles n’aient pas l’air totalement bizarres et délirantes
Ces images se génèrent littéralement en quelques secondes, c’était vraiment la meilleure de la sélection ?