Dans quels pièges est votre programme ?

Trop de fronts ouverts

Douze initiatives stratégiques pour une organisation qui en termine trois par an. Chacune a un sponsor, une ligne budgétaire et une présentation de lancement ; aucune n'a les personnes dont elle a besoin.

Une feuille de route de démarrages

La feuille de route montre quand les choses commencent, jamais quand elles finissent. L'avancement est rapporté comme « lancé », alors commencer donne l'impression de livrer.

Tout est priorité un

Quand chaque initiative est critique, aucune ne l'est. Les équipes fixent discrètement leurs propres priorités, et elles correspondent rarement à celles du sponsor.

Le petit oui raisonnable

Une démo pour le régulateur, une demande d'un client clé, un quick win pour le conseil d'administration. Chaque ajout est trop petit pour être refusé, et personne ne fait le total.

Le virage du nouveau sponsor

Un nouveau dirigeant arrive et veut laisser sa marque sur le programme. La direction change, les raisons non.

Deux versions en parallèle

Au lieu de choisir, le programme construit les deux : web-first et mobile-first, l'ancien processus et le nouveau, « pour un temps ». Ce temps ne finit jamais.

Les initiatives zombies

Du travail que personne n'a arrêté et que personne ne finance correctement. Il continue de tourner « au cas où », en consommant des personnes, de l'infrastructure et de l'attention.

La taxe du changement de contexte

Des personnes réparties sur quatre ou cinq engagements passent plus de temps à recharger le contexte qu'à faire le travail.

Des files pleines, un flux lent

Tout est en cours, donc tout attend autre chose. Les délais s'allongent, alors même que tout le monde est occupé.

La vitesse prise pour une direction

Les courbes de vélocité montent, les démos sont superbes, et le programme n'est pas plus proche de son résultat qu'il y a six mois.

La solution comme exigence

Le programme est lancé comme « un nouveau portail », « une plateforme de données » ou « un agent », pas comme un problème à résoudre. Une fois que la réponse est le périmètre, personne ne peut demander si une réponse plus modeste suffirait.

La liste de souhaits de chacun

Pour faire signer le business case, chaque partie prenante reçoit un élément en échange de son soutien. Le périmètre devient un traité de paix, pas une conception.

La plateforme avant le produit

Le programme construit de l'infrastructure pour des besoins que personne n'a encore : le moteur générique, le framework réutilisable, l'API que chaque équipe consommera un jour. Les utilisateurs d'aujourd'hui attendent ceux de demain.

« Tant qu'on y est. »

Les trois mots les plus chers de l'informatique. L'équipe touche déjà au système, alors le changement d'à côté semble gratuit. Il ne l'est jamais : il apporte ses propres tests, données, dépendances et parties prenantes.

S'aligner sur le rival

Un concurrent livre quelque chose, et cela entre dans la liste sans que personne ne vérifie si vos clients le veulent.

Le parapluie de la conformité

Certaines exigences sont vraiment obligatoires. Mais une fois que « réglementaire » devient un mot de passe, tout s'abrite dessous, et personne n'ose demander quel article de quel texte exige réellement cette fonctionnalité.

Des changements sans prix

Le nouveau périmètre est accepté en atelier, consigné dans un backlog, et n'apparaît jamais dans la date ni dans le budget. Le plan reste au vert. Le navire s'alourdit.

Pas de non-objectifs

Le programme dit ce qu'il fera, jamais ce qu'il ne fera pas. Tout ce qui n'est pas explicitement exclu est permis, et chaque comité de pilotage le rouvre.

Réduire le périmètre comme un échec

Retirer une fonctionnalité ressemble à rompre une promesse faite à son sponsor, alors personne ne le propose. Les programmes ajoutent du périmètre facilement et n'en retirent qu'en cas de crise, quand le retrait coûte le plus cher.

Le test qu'on explique et qu'on écarte

Le test de performance échoue, les utilisateurs pilotes peinent, la répétition de migration prend trois fois plus de temps que prévu. Chaque résultat reçoit une explication, et aucun n'a le droit de changer le plan. L'amiral arrête le test, et le navire part quand même.

« Notre programme est différent. »

Chaque programme semble unique vu de l'intérieur, donc personne ne regarde comment des programmes similaires se sont réellement déroulés. Daniel Kahneman appelait cela la vision de l'intérieur : on planifie à partir de sa propre histoire, pas à partir des faits observés chez tous les autres.

L'estimation comme négociation

Le premier chiffre honnête est « trop élevé », alors on le retravaille jusqu'à ce qu'il rentre dans l'enveloppe budgétaire. Puis la négociation s'inverse : les équipes blâmées pour des « points manqués » apprennent à se garder de la marge, et les estimations gonflent discrètement. Dans les deux cas, le chiffre cesse d'être une prévision et devient une défense.

Aucune place pour l'inconnu

Le plan couvre chaque tâche connue, et rien d'autre. La provision pour aléas est soit absente, soit discrètement dépensée dès le premier trimestre pour des choses connues depuis le début.

Périmètre, date et budget, tous figés

Verrouiller les trois laisse la qualité comme seule variable. Elle cède en silence, et la facture arrive après la mise en production.

La date est venue en premier

L'échéance a été annoncée avant que quiconque ne planifie le travail, et le plan a ensuite été construit à rebours pour s'y ajuster. Tout paraît faisable, parce que c'est ainsi qu'il a été conçu.

Construire avant de concevoir

Comme pour le podium de l'Opéra, le travail démarre avant que les inconnues clés ne soient résolues, pour montrer des progrès ou pour sécuriser un financement. La vitesse du début devient le retravail de la fin.

La longue fenêtre

Des années de construction avant le premier vrai utilisateur. Plus la fenêtre est longue, plus le monde a le temps de changer sous le plan : nouvelles réglementations, nouveaux dirigeants, nouvelles technologies.

La fausse précision

Un diagramme de Gantt détaillé au jour près pour le dix-huitième mois. La précision suggère une certitude que personne n'a, et fait passer chaque écart pour un échec.

Des plans par équipe, pas par programme

Chaque équipe a un plan crédible. L'intégration entre elles, là où se trouve l'essentiel du risque, n'appartient au plan de personne.

Le coût irrécupérable

« On a trop dépensé pour s'arrêter maintenant. » L'argent déjà dépensé devient la raison de continuer à dépenser, bien après que le business case a cessé d'avoir du sens.

Neuf femmes, un mois

Des personnes ajoutées tard, quand le programme est déjà en retard. Chaque nouvel arrivant ralentit les experts avant d'accélérer quoi que ce soit.

Staffer selon les disponibilités

L'équipe est composée de ceux qui étaient libres, pas de ceux dont on avait besoin. Le programme récupère les personnes que personne d'autre n'a demandées, puis s'étonne des résultats.

Recruter dans l'urgence

Le plan de montée en charge exige trente personnes d'ici juin. Les entretiens raccourcissent, la barre baisse discrètement, et l'onboarding devient « lis le wiki ». Un mauvais recrutement fait en une semaine prend un an à défaire.

La réflexion externalisée

L'intégrateur conçoit, construit et comprend le système. L'équipe interne gère le contrat. Quand le contrat se termine, le savoir part avec lui, et l'entreprise possède un système qu'elle ne sait pas expliquer.

Conway ignoré

Melvin Conway a observé en 1968 que les systèmes reflètent la structure de communication des équipes qui les construisent. Dessinez les équipes d'une façon et l'architecture d'une autre, et l'organigramme gagne à chaque fois.

Le héros

Une personne sait comment le système critique fonctionne vraiment, répond à chaque escalade et travaille chaque week-end. Tout le monde l'admire. Personne ne remarque que le programme dépend désormais de la santé et de la bonne volonté d'une seule personne.

Des personnes découpées en pourcentages

Trente pour cent sur ce programme, quarante sur celui-là, le reste sur le run. Deux managers, trois stand-ups, pas de vraie équipe. Chaque tranche paie le coût complet du changement de contexte.

Le changement culturel par note de service

Une transformation agile est annoncée, les valeurs s'affichent sur des posters, de nouveaux intitulés de poste apparaissent. Le processus budgétaire, la chaîne d'approbation et le comportement des dirigeants restent exactement les mêmes. Les gens croient ce que font les dirigeants, pas ce qu'ils disent.

Le meilleur ingénieur devient manager

Le programme perd son ingénieur le plus solide et gagne un manager sans formation, sans soutien et sans temps. Les deux métiers en souffrent, et la personne aussi.

Le management par la pression

Les échéances sont imposées d'en haut, les erreurs sont punies, et les questions sont vues comme de la résistance. Les gens arrêtent de remonter les problèmes, arrêtent de proposer des idées, et finissent par ne plus s'en soucier.

Pas de propriétaire

Tout le monde est consulté, personne ne décide. La question circule de comité en comité jusqu'à ce que l'échéance décide pour tout le monde.

Le HiPPO

L'avis de la personne la mieux payée tranche la question, quelles que soient les preuves. Les équipes apprennent à deviner ce que pense le chef plutôt qu'à découvrir ce qui est vrai.

Le voyage à Abilene

Tout le monde est d'accord à voix haute et en désaccord en privé. La décision est unanime, et personne n'y croit.

Trop de portes

Comité d'architecture, revue de sécurité, comité budgétaire, comité de pilotage, chacun se réunissant une fois par mois. Chaque porte ajoute des semaines d'attente pour quelques minutes de décision.

Le bikeshedding

C. Northcote Parkinson a décrit un comité qui approuve une centrale nucléaire en quelques minutes puis débat une heure de l'abri à vélos, parce que tout le monde comprend un abri à vélos. Les programmes passent des heures sur les couleurs du logo et des minutes sur le modèle de données.

Chaque décision est une porte à sens unique

Les choix réversibles, comme une bibliothèque, une mise en page d'écran ou une approche de test, reçoivent le même examen que les choix irréversibles, comme un fournisseur central, un modèle de données ou un contrat. Alors les petits sont lents, et les gros sont bâclés pour rattraper le retard.

Attendre la certitude

Une étude de plus, un benchmark de plus, un avis de plus. L'information continue d'arriver, la certitude jamais.

Le boomerang

Une décision prise en mars revient en avril parce que quelqu'un a manqué la réunion, ou simplement ne l'aimait pas. Rien n'est jamais vraiment décidé.

L'amnésie de réunion

La décision a été prise, mais personne ne l'a écrite. Six semaines plus tard, trois personnes se souviennent de trois versions différentes.

Le veto silencieux

Tout le monde est d'accord dans la salle, puis rien ne se passe. La décision est respectée sur le papier et ignorée dans le backlog.

Too abstracted

A generic engine to handle every future case. Rules stored in metadata, configuration on top of configuration. It promises flexibility. In practice, the simplest change now needs the one person who understands the framework.

Over-engineered

Event sourcing for a back-office form. Twenty microservices for a product with three hundred users. A service mesh before the first customer. Each choice is defensible on its own; together they multiply the moving parts the team must master.

Built for the dream scale

Architecture sized for a hundred million users when the business plan targets one hundred thousand. Sharding, multi-region and caching layers that cost months now, for a load that may never come.

Gold-plated everywhere

Five nines, zero downtime and the strictest security profile demanded for every component, including the internal reporting tool. The bar is set by the most critical system, never by the actual risk.

Not invented here

An in-house framework, a homemade workflow engine, a custom identity server. Building it is exciting. Maintaining it for ten years, with the people who built it long gone, is not.

Unknown or fashionable stacks

The new language or framework is exciting, often fresh from a conference, and nobody on the team has ever run it in production. Learning happens on the critical path, with the deadline watching.

The grand rewrite

The legacy system works, but it is ugly, so the program will replace it with the perfect one, all at once. Fred Brooks named this the second-system effect: the successor carries every idea the first one had to leave out. Meanwhile, the old system keeps changing, and the target keeps moving.

Never good enough to ship

The architecture phase is extended once, then twice. Nothing reaches production until everything is right, so nothing is learned from real users until it is far too late to change course.

Blind to production

Designs validated on a laptop and in slides, never under real load, real data volumes, real network failures or a real 3 a.m. incident. Production behavior is discovered at go-live, when it is most expensive to learn.

Misunderstood and misused

A powerful tool used against its grain: a cache treated as a database, a message broker used as a workflow engine, an ORM fighting the data model. The technology isn't wrong. The way it is used is.

Attendre les outils

Un ticket pour obtenir un environnement de test, un autre pour un accès à la base de données, un troisième pour une règle de pare-feu. Chacun prend des jours, et chacun bloque un développeur qui était prêt à commencer.

Attendre une signature

Le travail est fait, et il attend le prochain comité d'architecture, la prochaine revue de sécurité ou le prochain comité des changements. Quelques minutes de revue, des semaines de file d'attente.

Attendre une autre équipe

Vous avez besoin d'un petit changement dans un service partagé. Il entre dans leur backlog, derrière leurs propres priorités. Votre sprint se termine avant que le leur ne commence.

La course de relais

L'analyste écrit, l'architecte conçoit, le développeur construit, le testeur teste, l'équipe d'exploitation déploie. À chaque passage de témoin, du contexte se perd et les questions s'accumulent. Cinq passations, cinq traductions du même besoin.

Le ping-pong de tickets

« Peux-tu préciser ? » « Voir commentaire ci-dessus. » « Ce n'est pas ce qu'on voulait dire. » Une question qui prendrait deux minutes en face à face prend deux semaines dans un outil de ticketing.

Le document que personne ne lit

Quarante pages de spécifications qui ont pris un mois à écrire et que personne ne lit en entier. Les vraies décisions se prennent plus tard, dans un couloir, et ne reviennent jamais dans le document.

La surcharge de réunions

Des réunions récurrentes qui ont survécu à leur raison d'être, des points d'avancement où les gens lisent à voix haute ce qu'ils auraient pu écrire, et des invitations envoyées à douze personnes « juste pour les tenir informées ». Les agendas se remplissent, et le travail se fait dans les interstices.

La taxe du reporting

Le même statut réécrit quatre fois, pour quatre comités, dans quatre modèles. On consacre plus d'efforts à expliquer l'avancement qu'à le produire.

Le faire deux fois

Des exigences mal comprises, des défauts trouvés tard, des fonctionnalités reconstruites après la première démo. La reprise est le gaspillage le plus coûteux, parce qu'on paie le travail deux fois, plus le retard entre les deux.

Les corvées manuelles

Des déploiements manuels, des tests de non-régression manuels, des données copiées à la main entre systèmes. Chaque répétition est lente, source d'erreurs et discrètement épuisante.

Le statut est une opinion

La couleur est choisie par la personne qui en est responsable, selon ce qu'elle ressent pour le mois prochain. Personne ne demande quelles preuves se trouvent derrière.

Une nuance plus claire à chaque niveau

Le développeur dit rouge, le chef d'équipe rapporte orange, le programme rapporte vert avec points de vigilance. Chaque étape adoucit un peu la vérité, avec de bonnes intentions, jusqu'à ce que le sommet de la chaîne voie un autre programme que la base.

Le plan de rattrapage qui ne peut pas rattraper

Chaque glissement s'accompagne d'un plan de rattrapage, et chaque plan de rattrapage suppose que l'équipe va soudain aller plus vite : moins de bugs, des décisions plus rapides, aucun arrêt maladie. Le statut reste vert sur la foi d'une vélocité que personne n'a jamais vue.

La replanification silencieuse

Quand un jalon glisse, le plan est discrètement redessiné. Le programme est toujours « conforme au plan ». Ce n'est simplement plus le même plan qu'au trimestre dernier.

L'activité au lieu des résultats

Pourcentage de tâches terminées, points de story consommés, documents livrés, heures passées. Tout cela peut être vert alors que rien ne fonctionne de bout en bout.

Le syndrome des 90 %

Chaque chantier est terminé à 90 %, et ce depuis trois mois. Les derniers 10 %, l'intégration, les données, la performance, les vrais utilisateurs, sont là où se cache le vrai travail.

La loi de Goodhart

Quand une mesure devient un objectif, elle cesse d'être une bonne mesure. Dès que ce sont les dates des jalons qui sont jugées, les jalons commencent à être déclarés « atteints avec réserves ».

Le rouge est puni

Un statut rouge déclenche des audits, du reporting supplémentaire et des visites de dirigeants. L'équipe apprend que le rouge coûte plus cher que le problème lui-même, alors le rouge est évité jusqu'à ce qu'il ne puisse plus l'être.

Le comité de pilotage comme théâtre

Soixante diapositives, un ordre du jour chargé, aucune décision. La réunion est conçue pour rassurer, pas pour décider.

Le vert du fournisseur

L'intégrateur rapporte du vert sur son périmètre contractuel. Chaque fournisseur est vert sur sa propre partie, et personne ne possède la couleur de l'ensemble.

Chaque équipe sur sa rive

Le programme est découpé par équipe, fournisseur ou système, et chaque partie a son propre plan. L'intégration entre elles appartient au plan de tout le monde, c'est-à-dire de personne.

Pas de squelette ambulant

Après des mois de programme, il n'existe toujours aucun flux qui fonctionne de bout en bout, de l'écran de l'utilisateur jusqu'au dernier système back-end et retour. Chaque composant existe ; le parcours, non.

L'intégration big bang

Toutes les parties sont connectées en même temps, dans une seule « phase d'intégration » vers la fin. Quand quelque chose casse, personne ne peut dire laquelle des vingt nouvelles connexions en est la cause.

Des contrats seulement sur le papier

Les interfaces sont décrites dans un document de spécification, signé il y a des mois. Personne ne les teste automatiquement, donc chaque côté implémente sa propre lecture de la même page.

Même mot, sens différent

Pour un système, un « client » est une personne ; pour un autre, un contrat ; pour un troisième, un foyer. « Date » signifie date de réservation ici et date de valeur là. Chaque équipe a raison dans son propre contexte.

Des environnements qui ne correspondent pas

L'intégration est testée dans un environnement avec des versions différentes, une configuration différente et un dixième des données. Ça marche là-bas. La production est un autre pays.

La migration en un week-end

Déplacer des années de données est prévu comme une bascule unique, répétée une fois, si tant est qu'elle le soit. Elle prend trois fois plus de temps que la fenêtre ne le permet.

Des données sales, découvertes tard

Des doublons, des champs manquants, des valeurs que personne ne sait expliquer. Les vraies données ne rencontrent le nouveau système qu'à la première répétition complète, et chaque règle écrite sur des données de test propres casse.

La performance après la recette

Les tests fonctionnels passent, le métier valide, puis le test de charge est lancé pour la première fois. Les décisions d'architecture qu'il aurait changées ont été prises il y a un an.

La sécurité à la fin

Le test d'intrusion est planifié deux semaines avant la mise en production. Ce qu'il trouve ne peut être corrigé qu'en retardant le lancement ou en acceptant le risque.

La mise en production comme ligne d'arrivée

La définition de « terminé » du programme, son budget et ses critères de succès s'arrêtent tous à la mise en production. Tout ce qui vient après appartient au « métier » ou au « run », c'est-à-dire à personne en particulier.

Les utilisateurs le découvrent en semaine de formation

Les vrais utilisateurs voient le système pour la première fois quelques semaines avant la mise en production, dans une salle de cours, avec des données de démonstration. Leurs retours arrivent quand plus rien ne peut changer. La conduite du changement se réduit à un plan de communication.

L'exploitation, pas invitée

L'équipe de run découvre le système à la passation : pas de runbooks, une supervision ajoutée à la dernière minute, un planning d'astreinte monté en un week-end. Ils en seront responsables pendant dix ans ; ils l'ont rencontré vendredi.

La bascule big bang

Tous les utilisateurs, toutes les fonctionnalités, toutes les données, le même week-end. Le pari est que tout fonctionne d'un coup, parce que le plan n'a laissé de place à rien d'autre.

Pas de retour possible

Il y a un plan pour basculer, et aucun plan répété pour revenir en arrière. Quand le premier problème sérieux apparaît le lundi matin, la seule option est de corriger en avançant, sous pression, en production.

L'équipe part avec les invités

L'équipe programme est dissoute, réaffectée ou en fin de contrat la semaine qui suit la mise en production. Les personnes qui comprennent pourquoi le système fonctionne comme il fonctionne sont parties juste au moment où les questions commencent.

Des bénéfices que personne ne mesure

Le business case a été écrit pour obtenir le financement, puis classé. Personne n'a pris de mesure de référence avant le démarrage, donc personne ne peut dire ce qui a changé après.

L'ancien système zombie

L'ancien système devait être éteint « trois mois après la mise en production ». Des années plus tard, il tourne encore pour un rapport, une équipe, un cas particulier, et l'organisation paie pour les deux.

Les contournements deviennent le processus

Les utilisateurs contournent ce qui ne leur convient pas : un export vers un tableur, une boîte mail partagée, une étape manuelle. Bientôt, le vrai processus vit en dehors du système, et personne ne l'a conçu.

La DSI possède le programme, personne ne possède le résultat

L'attention du sponsor est passée à autre chose le lendemain de la fête. Le système a un propriétaire ; le résultat pour lequel il a été construit n'en a pas.