Comment réanimer un projet de développement logiciel laissé pour mort - Retour d'expérience - Partie 1

Plutôt que de lire, écoutez cet article avec ASTREAD

Chaque jour dans le monde, des milliers de personnes se jettent dans un nouveau projet de développement logiciel : Que ce soit une startup qui veut lancer un concept avec son site web, une entreprise qui veut développer un logiciel de gestion ou un étudiant qui désire créer une application mobile, tous voient en la technologie un moyen simple et rapide de réaliser leurs ambitions.

Mais savez-vous que selon « l’observatoire des projets » qui a réalisé une étude sur le taux d’échec dans le domaine de l’informatique en 2012, 55% des responsables sondés estiment qu’entre 16% et 50% de leurs projets stratégiques sont purement et simplement abandonnés ! 

L’histoire que je vais vous raconter parle de l’un de ces millions de projets qui a bien failli finir dans les oubliettes de l’informatique, tout en entrainant avec lui l’avenir d’une société et des salariés qui la composent.

Loin d’être un cas isolé, nous allons voir comment ce projet hautement stratégique a lentement dérivé, pour arriver à une situation tellement catastrophique que tous ceux qui y ont participé de près ou de loin s’en sont retrouvés profondément affectés.

Comme la fin du projet signifiait la fin de la société, il n‘était pas question pour la direction de l’abandonner. 

C’est dans ces conditions difficiles que j’ai été désigné pour en reprendre les rênes.

Or, l’équipe était tellement accablée par cet échec qu’elle ne pouvait accepter de recommencer.

Seule une profonde remise en question des méthodes de travail tant sur le plan technique que humain pouvait les convaincre de remettre le couvert.

J’ai donc été obligé de revoir ma façon de penser et d’aller à contre-courant de tout ce qui se faisait jusqu’alors, allant parfois à l’encontre d’un certain bon sens et des directives données par les dirigeants même de la société ! 

Et figurez-vous que ça a marché.  

Je vous propose donc de vous faire revivre cette expérience qui a changée à jamais notre façon de gérer des projets de développement…

Prologue

L’histoire commence en l’an de grâce 2008. Cela fait déjà 4 ans que je suis patron de ma société, voire plus exactement l’esclave de mon banquier, et mon activité consiste à mettre en place des réseaux d’entreprises et à développer des logiciels spécifiques en C++.

Un jour, un de mes contacts me présente une personne qui semble être dans la misère, car celui-ci s’est fait pirater son serveur et il ne sait pas comment s’en sortir. Étant toujours en quête de nouveaux clients, j’interviens un weekend et dépanne le type pour quelques euros.

Pendant ma prestation, il s’avère que lui aussi passionné de C++ et il en profite pour me présenter quelques un de ses travaux. Le niveau des échanges est très intéressant car le gars est un bon développeur chevronné.

Après tout cela, je lui laisse mes coordonnées et retourne à mes occupations…

Quelques mois plus tard, le gars me rappelle. La société dans laquelle il travaille a besoin d’un nouveau logiciel de gestion de contacts, et il voudrait savoir ce que je peux lui proposer. 

En bon commercial, je lui explique qu’il existe certainement de très bons produits sur le marché, mais que je ne suis pas revendeur. Par contre, s’il désire un développement spécifique : je suis son homme.

L’idée germe dans son esprit et il me demande un devis, chose que je fais sans problème. Je prévois quelque mois de travail pour une petite appli C++ avec une base de données SQLExpress. Après quelques négociations, il m’explique qu’il faudrait que le système soit en capacité d’interagir avec plusieurs outils tels qu’Exchanges, Outlook, Word ainsi que certains Webservices… (Liste non exhaustive)

Les choses se compliquent car le C++ n’est pas très cordial lorsqu’il s’agit d’interopérabilité. Il existe bien des librairies et autres composants COM, mais les quelques essais que je fais montrent que les choses vont rapidement devenir très pénibles.

Le C# semble tout indiqué pour ce type de besoin. J’étudie la question et je découvre un langage élégant et productif qui respecte parfaitement tous les principes de la POO. Je recontacte le gars et lui vend du rêve vis-à-vis de C#. 

Il est d’accord pour signer un nouveau devis mais il impose des conditions :

• Il veut être le chef de projet sur ce dossier 
•  Il veut participer activement au développement du produit avec moi

Ayant toujours été habitué à travailler seul et en mode cowboy, je me dis que ça me fera une très bonne expérience : alors BANCO !

Le projet débute et nous découvrons tous les deux le C#. Ayant pas mal d’expérience en C/C++ (7 ans pour ma part et 15 ans pour la sienne) nous avançons très rapidement. Lorsque l’on vient des langages de programmation bas niveaux, faire du C# est un vrai bonheur, et nous étions tous les jours émerveillés par la richesse du .NET Framework.

Une fois que nous avions fait le tour de la question vis-à-vis de nos besoins, en bon petit cowboy je crée un nouveau projet et commence à vouloir taper du code. Lorsque le gars voit ça, il m’arrête tout de suite : Mais qu’est-ce que tu fais ? N’a tu donc jamais fais de la vraie gestion de projet ?

Il m’explique les principes du cycle en V et l’importance de la conception en amont. Il en profite pour me présenter son document de conception : une véritable bible de plusieurs centaines de pages qui détaille tous les rouages de notre future application.

En lisant ce document, je découvre que nous sommes très loin de la simple application de gestion que j’avais imaginée : Le projet va en fait consister à créer une espèce de RAD (Rapid Application Development) qui intègre en natif des concepts de verrouillages pessimistes, de gestion de droits modulaire, de push et de grilles intelligentes. Bref, le mec est tellement un fondu de code qu’il a réussi à se faire financer par sa boite un de ses vieux délires sous couvert d’un projet banal. 

Bien sûr, à la découverte de toutes ces choses, j’ai évidemment demandé à ce que le budget soit rallongé : ça n’a visiblement pas posé de problème. Donc tout allait pour le mieux.

Le projet débute et le gars me prend sous son aile, il devient pour moi une sorte de mentor qui m’apprend les choses qu’un vrai codeur professionnel doit savoir : L’importance de faire des documents de conceptions et de spécifications, de l’architecture, de l’optimisation, les design patterns. C’est une époque où je suis encore jeune sans femme ni enfant, je m’investis donc à 200% en faisant des horaires de dingue et en lisant énormément de livres.

Après une bonne année de travail, le logiciel de gestion de contact est devenu un véritable monstre qui fait papa maman avec une pure architecture de barré ! Le démarrage de l’application met plusieurs minutes tellement il y a de modules génériques à charger, et de gros points faibles sont à déplorer sur les performances de SQLExpress 2005 (qui à l’époque possède des limitations de 1 CPU / 1 thread, 1 Go de RAM et 4 Go par base).

Mais bon, le Framework est sur le plan technique une vraie tuerie. Tellement convaincant que le gars en fait une présentation à l’un de ses amis qui est le co-fondateur et directeur R&D d’une société d’édition de logiciel. La présentation n’est pas désintéressée car cette société à une véritable problématique de vieillissement de son produit phare, et elle doit faire un choix stratégique majeur pour changer de technologie !

Je n’étais pas présent à cette démonstration, mais j’imagine que le CTO a dû en prendre plein les yeux : Tu glisses une grille dans ton designer, tu mets dans les propriétés les colonnes que tu veux afficher, et pouf, tout se génère tout seul ! Pour l’accès concurrentiel ? Pas de problème c’est géré en natif ! Pour le rafraichissement des données ? Le système envoie des notifications push pour que les formulaires soient toujours à jour ! Gestion de droits ? no problem, les modules et menus sont affichés en fonctions des rôles SQL paramétrés (donc couplables avec un AD) ! En termes de productivité ? Avec ça un stagiaire payé 10K te refait ton application en un temps record ! Pour la pérennité ? Tout est en .NET, ça ne risque pas de bouger ! Pour le déploiement ? C’est basé sur « ClickOnce », en un clic ton application est disponible all over the world ! Etc.

Bref, comme je l’ai déjà dit, je n’étais pas présent, donc j’imagine que les choses se sont passées ainsi. Mais une chose est sûre : l’ancien logiciel de cette société était fait avec un RAD, donc les arguments d’un système en .NET qui permet de créer des applications de gestion en un minimum de temps et de codes ont forcément touché l’âme et le cœur de son auditoire.

Après quelques temps, le gars m’explique qu’il a fait une démonstration de notre Framework, et que la société serait intéressée pour l’embaucher en tant que chef de projet pour mener à bien son virage technologique, et il me demande si je suis intéressé pour quitter ma boite et le rejoindre dans l’aventure.

Comme évoqué au début, j’étais l’esclave de mon banquier. J’ai donc vu en cette proposition une véritable aubaine pour briser mes chaines !

Les choses étant entendues, je suis mis dans la boucle des conversations emails qui se portent sur ce nouveau projet.  

Du côté de l’éditeur, ils veulent disposer d’un RAD propriétaire pour ne plus être dépendent de leur solution actuelle, car non seulement celle-ci leur pose plusieurs problèmes de cout, d’évolutivité et de maintenabilité, mais en plus ils sont pieds et poings liés avec la société qui édite ce RAD.

Du côté du chef de projet, il explique comment les choses vont s’articuler autour de plusieurs axes :

• Axe organisationnel : le projet sera géré selon les bonnes pratiques en vigueur, à savoir un cycle en V. Il faudra donc que l’éditeur puisse fournir un cahier des charges exhaustif ainsi que des spécifications très détaillées de leurs besoins.
• Axe technique : le Framework qu’il a présenté possède quelques lacunes à cause du moteur de base de données qui n’est pas adapté à tous les concepts qu’il a présentés. Il est en train d’imaginer un nouveau concept pour lever cette barrière.
• Axe économique : Le but du chef de projet n’est pas de faire de vieux os chez l’éditeur. Il désire donc avoir la possibilité d’avoir des droits d’exploitations sur le système qui va être développé pour créer plus tard une société qui aura vocation à créer d’autres logiciels de gestion.

Après quelques négociations un peu âpres entre le chef de projet et la société, cette dernière demande à avoir une estimation pour savoir quand le nouveau logiciel pourra être disponible à la vente.

Cette question peut paraitre saugrenue du fait que nous ne savons absolument pas ce que le logiciel doit faire, mais le chef de projet ne se dégonfle pas : ça sera prêt dans 2 ans maximum !

Ce « détail » étant bouclé, nous intégrons cette société après quelques mois…

La naissance d'un projet stratégique

Nous arrivons dans cette nouvelle société où le chef de projet est attendu comme le messie pour sauver la boite de son produit vieillissant. Les dirigeants le connaissent déjà très bien pour avoir partagé avec lui des locaux pendant plusieurs années, et l’avoir vu mener avec brio certains projets de développement dans le domaine du jeu vidéo.

Une équipe de trois développeurs est déjà en place : Le directeur R&D qui code sur un L4G depuis plus de 15 ans, un développeur venant de la boite qui édite le L4G en question, et un développeur VB6.

Quelqu’un nous présente le progiciel actuel qui semble très compliqué : c’est un logiciel métier qui doit gérer un certain nombre de workflow, de règles monstrueuses soumises à des agréments ainsi que beaucoup d’interopérabilité avec des tiers.

Ce logiciel étant installé chez plus de 250 clients, je suis tout d’abord mobilisé pour régler certaines problématiques sur ce dernier, le temps que le chef de projet puisse concevoir toute la stratégie de l’entreprise…

Au bout de quelques mois de travail acharné dans son bureau, voici le plan de bataille qu’il nous présente :

• En premier lieu, l’équipe de développeurs actuelle va-t-être formée au langage C#
• En parallèle, le chef de projet et moi-même redévelopperons le Framework RAD en .NET
• Le Framework devrait être terminé lorsque les équipes aurons fini d’être formées. A ce moment-là les développeurs pourront redévelopper le logiciel métier à l’aide du Framework, ce qui permettra de l’éprouver. 
• Pour que l’étape précédente puisse se dérouler dans de bonnes conditions, le directeur R&D devra fournir un cahier des charges exhaustif de tout ce qu’il voudra voir dans le nouveau logiciel.

-          Une fois que le logiciel métier sera opérationnel, le chef de projet restera encore quelques temps, puis il démissionnera pour créer une nouvelle société afin d’exploiter le Framework. 

Le plan d’action était bien sûr beaucoup plus détaillé, avec énormément de recommandation et de cours magistraux sur comment un projet informatique doit être mené dans les règles de l’art, le tout illustré de plusieurs schémas de ce type :

Nous verrons qu’en réalité, les choses se sont plutôt déroulées de cette manière :

 

Étape 1 : Euphorie

Le chef de projet nous présente sa stratégie sur le plan technique.

L’une des fonctionnalités phare de ce Framework RAD réside dans le fait que toutes les données sont synchronisées en temps réel avec tous les clients connectés, et ceci sans aucune ligne de code de la part du développeur. 

Or, le procédé que  nous utilisons avec SQL server est inefficient pour mener à bien cette tâche.

Il dévoile alors des documents de conceptions très détaillés sur comment il compte régler le problème. 

Le concept général réside en 6 lettres : IMOODB pour « In Memory Oriented Object DataBase ». L’idée principale est la suivante : Les bases de données sont faites pour gérer des informations stockées sur disque, car le coût de la RAM est extrêmement cher. Toutefois, un accès disque est aujourd’hui de l’ordre de la milliseconde tandis qu’un accès RAM se situe autour de la nanoseconde. Un accès en RAM est donc un million de fois plus rapide qu’un accès sur disque ! 

Il nous explique qu’avec l’évolution sans cesse des composants matériels (dont la RAM), les moteurs de bases de données sont de plus en plus enclin à monter toutes les données en mémoire afin d’avoir des temps d’accès proches du temps réel ! 

C’est donc le premier point de cette nouvelle stratégie : les données seront TOUTES en RAM, ce qui permettra non seulement de gérer des objets (donc pas de contraintes d’ORM) mais aussi de pouvoir maintenir des contextes de connexions afin de gérer le push de données entre le serveur et les clients.

Second point : Le stockage des données doit tout de même se faire sur disque pour la persistance, car lorsqu’on éteint la machine, les données montées en RAM disparaissent. Pour cela, il nous suffit de développer un système de stockage basé sur le model NoSQL (système clé/valeur). Il appui ses dires sur d’autres documents de conceptions très détaillés expliquant comment mettre la chose en œuvre.

Troisième point : Pour développer ces deux systèmes rapidement et s’assurer qu’ils seront évolutifs tout en tirant pleinement parti des processeurs multi-cœurs, il nous présente une architecture en « pipeline » directement inspiré des systèmes électronique. Le concept est basé sur le développement de composants connectables entre eux à l’aide de canaux logiques. Chaque composant travaille sur un thread, et a la responsabilité de ne faire qu’un type de traitement basé sur des entrées et des sorties. Cela permet d’avoir une architecture réutilisable, contrôlable et adaptable en fonction de la puissance de la machine.

Quatrième point : Notre but est de fournir un RAD à des développeurs inexpérimentés sur les technologies .NET. Il faut donc que la mise en œuvre d’IHM soit non seulement simple, mais aussi très élégante et novatrice. Le bougre n’en est pas à son coup d’essai car c’est un spécialiste des systèmes graphiques avancés. Issu du monde du jeu vidéo, il est comme un poisson dans l’eau en ce qui concerne cette partie. Il nous présente alors un outil de sa conception permettant de créer des IHM de malades avec gestion de collision, attraction, rotation, déformation et plein d’autres animations… Son petit soft fait maison ressemble à Blend et permet de générer un fichier XML qui sera interprété par son moteur graphique. De quoi donner le tournis ! 

A la vue de ces éléments, tout le monde est très impressionné tant par le niveau technique que par les idées innovantes de cette stratégie. Il est clair que nous avons affaire à un visionnaire !

La première étape consiste donc à préparer une démonstration de quelques-uns de ces concepts pour obtenir l’adhésion de tous les membres de la société.

Pour ma part, je m’attèle à mettre en œuvre un petit logiciel censé représenter une version allégée du vrai logiciel métier, le but étant de charger en RAM cinq ans de données de production pour effectuer divers traitements et montrer à tous avec quelle vitesse les données en mémoire sont manipulées.

De son côté, le chef de projet peaufine une ébauche d’interface graphique avec son moteur tandis que le directeur R&D prépare une présentation PowerPoint pour vulgariser les choix techniques évoqués ci-dessus.

Au bout de quelques semaines de travail, une réunion interne est organisée pour présenter la stratégie à toute la société.

Après une belle présentation de la part du directeur R&D qui durera quelques heures, il est temps de montrer des « preuves de concepts ». Je lance donc mon petit logiciel dont l’IHM est remplie d’images humoristiques pour détendre l’atmosphère, ce qui ne manque pas de faire son effet, puis  j’explique à mon auditoire que ce programme a pour vocation de démontrer la puissance que pourra nous permettre un système IMOODB. J’ouvre alors un module et commence à faire quelques recherches dans une espèce de base de données locale de plus de 100 000 personnes, et le résultat apparait au fur et à mesure que je tape des caractères dans mon champ de saisi. Je lance ensuite un module de statistique (point faible de l’ancien logiciel), et tout le monde constate avec stupeur que je peux manipuler 5 années de données de production aussi facilement que si j’étais avec quelques lignes sur Excel. A ce moment, la salle reste bouche bée.

S’enchaine alors la démonstration du chef de projet qui commence par expliquer que l’interface graphique est quelque chose de très important pour la perception des utilisateurs, et qu’il est de notre devoir d’innover dans ce domaine. Dès le démarrage de son programme, un méga splash screen en jette directement plein la vue, puis une fenêtre s’ouvre. A partir de là, il se met à expliquer quelques concepts de base : « Vous voyez, par exemple, lorsque vous voulez ranger des éléments, vous utilisez une liste n’est-ce pas ? Ici nous allons utiliser un système de vortex qui simule une attraction afin de grouper ces éléments de façon intuitive ». Il prend alors quelques éléments issus d’une liste puis les glisse vers un endroit de l’écran, et lorsqu’il les lâche, les éléments sont comme attirés par cette zone pour venir se regrouper naturellement en se collisionnant entre eux. Il démontre ensuite pleins d’autres concepts du même type, amenant l’effet « wahou » à son paroxysme !

Toute la société est conquise par cette démonstration, et nous en repartons gonflés à bloc ! La direction demande à ce que le projet commence au plus vite.

Le chef de projet me met immédiatement sur le développement du système de stockage en NoSQL.

Ce premier projet nous permet notamment de mettre en œuvre le système de pipeline afin d’en éprouver le concept. Je me base sur ce système pour développer toute la partie socket, gestion de fichier, compactage et correction de données corrompues. Une fois que le système de stockage a atteint un niveau de maturité suffisant, le chef de projet me demande de mettre en place une synchronisation bidirectionnelle entre plusieurs serveurs, avec gestion de tolérance de panne et verrouillage pessimiste. Il exige de ne rien commencer sans lui avoir montré des documents de conceptions fonctionnels et techniques très détaillés.

Au bout de plusieurs mois de travail et d’échanges basés sur ces documents, je m’attaque à la partie implémentation, et là les choses vont très vite. Je constate alors pleinement l’intérêt de prendre du temps pour faire de la conception, et je suis séduit par la pertinence du cycle en V.

Comme nous avons bien avancé, une nouvelle présentation est organisée pour que toute la société reste convaincue du bien-fondé de la stratégie.

Au cours de cette démonstration, je montre avec quelle aisance un serveur « storage » peut être installé et configuré. Je fais ensuite preuve du bon fonctionnement de la synchronisation et du système de tolérance de panne, ce qui ravi toute l’assemblée.

Nous annonçons fièrement qu’il a fallu environ 8 mois pour faire le storage, et le chef de projet annonce que la partie IMOODB ne mettra pas beaucoup plus. Tout cela conforte les collaborateurs sur la pertinence de la stratégie, ce qui nous permet de continuer sereinement sur le projet.

 

Étape 2 :  Inquiétude

Les choses avancent bien, et certaines personnes commencent à s’identifier à ce succès.

Mais le chef de projet coupe court à ces élans d’appropriation : il est le seul et unique concepteur de toute cette machinerie, que ce soit sur le plan technique, organisationnel ou économique et il tient fortement à ce que tout le monde dans la société en soit bien conscient.

Après cette mise au point, je lui demande s’il peut me présenter les spécifications techniques de la partie IMOODB afin que je me mettre au travail. 

Mais il y a un Hic.

Cela fait plusieurs semaines qu’il a des débats avec le directeur R&D qui a une vision différente de celle évoquée au départ. Pour lui, le moteur doit absolument posséder tous les mécanismes présent dans le SGBD de son RAD, à savoir triggers, vues, contraintes sur clés, indexes, suppression en cascade et surtout l’isolation contextuelle qui est au centre de la polémique.

Le chef de projet m’annonce qu’il doit faire plusieurs prototypes pour tester la faisabilité des demandes du directeur R&D, et que les choses sont bien plus compliquées qu’elles n’y paraissent. De ce fait, il préfère travailler seul sur le sujet pour éviter de perdre du temps en collaboration.

De mon côté, je me mets  à travailler sur des sujets annexes pour éviter de le déranger, et je me rapproche du directeur R&D qui a de forts besoins pour l’ancien produit. 

Ma sortie du projet initial se fait petit à petit.

Plusieurs mois se sont écoulés, et toujours pas de système IMOODB qui fonctionne. La direction demande ce qui se passe et le chef de projet explique qu’il ne peut pas tout faire : entre la formation des développeurs, le développement du système IMOODB et les discutions conceptuelles interminables qui se font avec le directeur R&D, il est tout bonnement naturel que les choses n’avancent pas ! Il explique que les développeurs n’ont pas une progression suffisante car ils sont pollués par des années de programmation procédurale. Il faut donc utiliser leur DIF pour qu’ils soient pris en main par un centre de formation au plus vite.

La direction demande des estimations car un salon très important doit se tenir dans quelques mois : Pourrons nous présenter quelque chose ? Que devons-nous dire aux clients qui attendent la nouvelle version avec impatiente ?

Les réponses sont les suivantes : 

•  Non, nous ne pourrons rien montrer, il faut donc s’organiser pour faire une énième démonstration de l’ancien produit à nos clients et prospects. 
•  La nouvelle version sera présentée lors du salon de l’année prochaine, les clients qui l’attendent auront alors tout le loisir de la tester et de la commander.

Les mois passent, et le fameux salon arrive. L’équipe commerciale est présente, ainsi que quelques techniciens et le chef produit.

A leur retour, j’ai une discussion avec le chef produit qui me fait part des bruits qui ont circulé durant le salon. Visiblement, celui-ci a reçu plusieurs remarques négatives par rapport à l’avancement du projet. Les délais ne sont pas réalistes, les anciens développeurs n’ont pas leur place dans l’équipe, le directeur R&D semble perdre le contrôle de la situation et les débats entre le chef de projet et le directeurs R&D laissent à penser que ceux-ci se sont lancés dans le redéveloppement d’un système de base de données, ce qui constitue en soi une véritable folie. Personne ne comprend comment le nouveau logiciel va pouvoir sortir dans ces conditions.

Nous faisons part de ces remarques lors d’une réunion de service, et le doute commence à s’installer dans l’esprit du directeur R&D, mais le chef de projet tient à se défendre devant cette critique qu’il considère comme une attaque. Pour lui, il est normal que les gens ne voient pas les choses avancer car ils ne comprennent pas la finalité de ce qu’il est en train de faire. 

Lorsque le Framework sera opérationnel, la vitesse de développement deviendra exponentielle. Il appui ses arguments en parlant d’un projet de jeu vidéo pour lequel il n’avait que 6 mois de budget ; Il a mis les 5 premiers mois à concevoir un moteur graphique, ce qui lui a permis par la suite de développer entièrement son jeu en seulement 1 mois !

Le directeur R&D atteste de ce fait car il était présent lorsque cette histoire s’est passée. Il explique qu’effectivement, tout le monde le prenait pour un fou car au bout de 5 mois, la seule chose que l’on pouvait voir était un triangle qui tourne sur un écran, et il semblait inconcevable que le jeu puisse sortir dans les temps, et pourtant il l’a fait !

Après plusieurs heures de débat, tout le monde est plus ou moins convaincu que le projet suit un déroulement normal, et que le Framework va permettre de balayer rapidement les inquiétudes.

Les choses reprennent leur cours et un jour le directeur R&D débarque dans le bureau du chef de projet. 

Cela fait au moins 8 mois que les anciens développeurs sont en formation, et il serait peut-être temps qu’ils se mettent à produire quelque chose. De plus, cela fait bien un an qu’il rédige des spécifications mais il se rend compte que certaines fonctionnalités n’ont plus lieu d’être tant le marché est en constante évolution. Il a donc pris les devants en inscrivant l’équipe à une formation « Agile » car il semble que cette méthode soit bien plus adaptée à la création du logiciel métier.

Le chef de projet donne un avis mitigé sur la question. Il pense que le directeur R&D essaye de se soustraire à l’analyse, aux spécifications et à la conception du logiciel métier comme convenu au départ, ce qui aura une incidence sur le succès des opérations.

Après de vifs échanges entre les deux protagonistes, le chef de projet cède aux exigences du directeur R&D, et un début de malentendu commence à s’installer entre les deux personnages. Pour le directeur R&D, il ne fait qu’apporter son aide afin de faire bouger le projet qui s’enlise, tandis que le chef de projet s’imagine que le directeur R&D a pris le lead de la partie logiciel métier, ce qui l’arrange car ça lui permet de se concentrer sur le Framework.

Le directeur R&D emmène l’équipe devant travailler sur le nouveau produit à cette formation. Ils en reviennent tous assez emballés et ils m’invitent à participer à la deuxième session, chose que j’accepte avec plaisir.

La formation est de très bonne qualité, et je découvre un nouveau système de pensé à l’opposé de tout ce qu’on m’a expliqué jusqu’alors : Plutôt que de vouloir faire du prédictif avec des spécifications et de la conception imaginées des années à l’avance, il est préférable de faire de l’empirique en appliquant un système « essai / erreur » pour atteindre le but convoité. On nous explique les bases de l’agilité avec quelques « serious game » pour bien illustrer les concepts, et nous apprenons plein de nouvelles méthodes très intéressantes.

A la sortie de cette formation, le directeur R&D prend les devants. Il veut appliquer la méthode au plus vite pour que les gens puissent se mettre au travail sur le nouveau produit. Il prend donc rapidement l’ascendant ce qui conforte le chef de projet sur l’idée qu’il n’est pas responsable de la partie logiciel métier, mais bien seulement de la partie Framework.

Bien qu’il soit de bonne volonté, et que sa prise de leadership soit louable, le directeur R&D possède trois handicapes qui vont le desservir par la suite :

Premièrement : Il est l’unique développeur du logiciel historique déployé sur plus de 250 sites, il ne peut donc pas s’investir pleinement dans le nouveau projet.

Deuxièmement : Comme il ne peut pas s’investir à cause du point numéro 1, celui-ci ne s’est jamais formé à la programmation orienté objet. Mais il est persuadé de l’avoir bien comprise et que cela lui permettra de donner des directives techniques sur le sujet.

Et troisièmement : C’est un personnage de caractère très colérique, ce qui peut être gênant lorsque l’on doit mettre en œuvre une méthode qui prône les échanges et la communication orale plutôt que les processus et les outils.

Le développement du logiciel métier commence enfin, tout du moins sa préparation. Le directeur R&D élabore avec le chef produit le « product backlog » et il est demandé aux développeurs de faire quelques petits projets pour tester la faisabilité de certaines fonctionnalités.

Comme tous les débuts, mettre le pied à l’étrier est assez difficile. Les « daily stand up » durent des heures, tout le monde s’engueule pendant les « pokers planning », le « product backlog » possède des « users stories » aux granularités douteuses, les « sprints planning meeting » sont interminables et décousus, bref nous vivons les premiers « sprints » de cette nouvelle méthodologie sans être accompagné, ce qui éreinte sérieusement le moral des troupes. 

Quant aux développeurs, les petits projets sur lesquelles ils sont affectés n’avancent pas, mais alors pas du tout ! Nous sommes de l’ordre de 5 lignes de code par jours, ce qui rend totalement fou de rage le directeur R&D !

Celui-ci leur rend la vie impossible à tel point que les développeurs préfèrent démissionner plutôt que de continuer à vivre cet enfer.

Bien que ce départ est présenté comme étant bénéfique, nous nous retrouvons tout de même avec une problématique majeure : il nous faut des développeurs métiers, et vite !

Heureusement, la direction propose une solution :

Une jeune boite de la région possède un type de logiciel très intéressant qui serait complémentaire avec notre business. Or, un avenant réglementaire a fait de  leur produit un élément moins attractif sur le marché, et cela les a forcé à se rabattre sur notre type de solution, ce qui commence à devenir assez gênant. 

Un rendez-vous est organisé entre nos deux sociétés. Ceux-ci possèdent pas mal de développeurs .NET et ils sont en difficulté financière. Un rachat est proposé, et après plusieurs mois de négociation, un accord est conclu.

Ce rachat nous donne trois avantages : 

1.  On récupère un logiciel complémentaire prêt à vendre. 
2.  On récupère des développeurs .NET qui connaissent le métier, ce qui n’est pas si mal dans un contexte où il est très difficile d’en trouver. 
3.  On élimine du marché un concurrent potentiel qui aurait pu faire mal s’il était prêt avant nous.

C’est donc tout bénef !

6 nouveaux développeurs arrivent et découvrent le concept de l’IMOODB.

Le chef de projet se présente comme le développeur du Framework qui leur permettra de créer le produit, et le directeur R&D se présente comme le « Product Owner » qui leur dira quoi créer.

Le chef de projet propose de faire passer quelques tests aux nouveaux arrivants histoire de connaitre leur niveau en développement, mais le nouveau salon pour lequel la société s’est engagée à présenter le nouveau logiciel se tiendra dans 3 mois ! Donc pas question de perdre du temps en futilité !

A partir de là, tout va très vite : le salon est un jalon important, et il faut montrer quelque chose ! 

Étape 3 : panique !

Le directeur R&D prend une nouvelle fois le leadership de la situation et demande au chef de projet de trouver un moyen d’accélérer la cadence.

Ce dernier s’attèle à expliquer aux développeurs comment fonctionne le Framework : Accès aux données, système de push, liste de données auto gérées, formulaires auto générées, asynchrone, … 

Le développement commence et je suis affrété à tester ce que les développeurs produisent pour vérifier la bonne implémentation des fonctionnalités.

Les journées s’enchainent à un rythme infernal, les nouveaux développeurs découvrent peu à peu dans quoi ils se sont fourrés : D’un côté, ils doivent travailler avec une technologie totalement inconnue dont toute la connaissance se trouve dans le cerveau d’une seule personne qui diffuse son savoir au compte goute, et de l’autre, on leur demande de développer des fonctionnalités ahurissantes à coup de conseils techniques douteux et maladroitement exprimés.

Tout cela se ressent fortement sur la qualité du logiciel. Les tests dévoilent des bugs catastrophiques (perte de données, plantage intempestif, formulaire qui ne s’ouvrent pas, incohérence, problèmes d’intégrité, …) accompagnés de performances très médiocres !

Le salon est bientôt là, et l’équipe n’a pas le temps d’ajouter d’autres fonctionnalités. Le directeur R&D et le chef de projet prennent une décision commune : il faut maquiller la mariée pour avoir quelque chose qui donne un semblant de logiciel terminé, car les clients nous attendent au tournant.

Les développeurs entrent dans une phase de stabilisation, et terminent les fonctionnalités manquantes en produisant des coquilles vides. Tous les cliques faisant planter le logiciel sont soigneusement répertoriés afin de permettre aux démonstrateurs de passer entre les gouttes.

En parlant de démonstrateur, nous sommes à une semaine du salon, et personne n’a encore vu le logiciel !

Quelques machines sont installées en urgence pour permettre aux experts métier de préparer un scénario de démonstration, mais c’est l’hécatombe : un plantage tous les trois cliques, des boutons factices qui ne font rien, une ergonomie qui mélange plusieurs types d’interfaces, des messages techniques incompréhensibles et des lenteurs excessives font bondir de peur tout individu qui s’approche à moins de 2 mètres d’un poste de démonstration ! Les démonstrateurs se révoltent et refusent catégoriquement de montrer ça à qui que ce soit !

Mais le service R&D est plein de ressources…

Puisque les démonstrateurs ne veulent pas présenter le produit, ce sera la R&D qui fera les démonstrations. Sont nominés le chef produit, le directeur R&D, le chef de projet et moi-même pour accomplir cette mission.

La situation sent très mauvais, mais le défi est relevé.

Pour pallier les manques fonctionnels, des PowerPoints très riches sont mis en place. Chacun répète sans cesse un scénario qui donne illusion que le logiciel est stable grâce à un soigneux jeu de slalom entre les bugs.

Un jour avant l’envoi des machines sur le salon, une erreur aléatoire venant de nulle part compromet très sérieusement notre scénario ! L’équipe fait 24H de travail non-stop pour en trouver l’origine et s’assurer que les machines partiront avec la dernière version corrigée.

Tout le monde est épuisé, mais il faut tenir bon. Des phrases laissant à penser que travailler 24 heures non-stop est quelque chose de normal avant une démo sont prononcées, ce qui est censé maintenir le moral des troupes.

Après un repos bien mérité, direction le salon au cours duquel je me suis découvert un véritable talent de pipoteur et de joueur de flute tellement j’arrivais à faire croire que le logiciel fonctionnait parfaitement. Cette expérience m’a appris une chose : Une démonstration de logiciel n’a aucune valeur tant que vous n’avez pas vous-même manipulé la souris, car le démonstrateur peut vraiment  vous faire gober ce qu’il veut. 

Le salon se termine sur un bilan positif. Les clients et prospects sont assez séduits dans l’ensemble et les commerciaux reviennent avec quelques commandes et demandes de démonstrations

Le directeur R&D maintient la pression pour que les développeurs implémentent rapidement les coquilles vides.

De ce fait, je suis convié à participer à l’effort de guerre pour ajouter un module assez compliqué. Je m’immerge malgré moi dans ce nouveau projet, car ni le chef de projet, ni le directeur technique ne savent ce qui se passe dans le code. On m’explique que cela fait partie de la méthode agile qui stipule dans son manifeste que « les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées. »

Lorsque j’ouvre le projet, les bras m’en tombent.

La solution est composée de 60 sous projets censés représenter les différents modules, et énormément de ces projets sont vides. Le code métier est concentré dans un projet dont la DLL est partagée entre l’IMOODB et le client lourd, car le système a été conçu en couplage fort entre les deux entités.

Du coup, le code situé dans ce projet à une particularité étonnante : il est constitué d’énormément de classes statiques appelé des « Helpers », qui eux même sont architecturés pour pouvoir être chainé entre eux.

Je demande au chef de projet pourquoi une telle ignominie ? Il me répond qu’ils ont dû faire ça car le système IMOODB qu’il a mis en œuvre est incapable de gérer des objets. Ainsi nous avons d’un côté des structures avec des propriétés et de l’autre des méthodes situés dans des classes statiques qui sont capables de manipuler ces données.

A mon grand étonnement, je récapitule la situation à haute voix : la société a investi des centaines de millier d’euros pour disposer d’un système de gestion de base de données orientée objet, mais celui-ci n’est pas capable de gérer des objets. Du coup, les développeurs sont obligés de séparer les données et les traitements comme avec un langage procédural, chose que l’on veut éviter à tout prix !

Le chef de projet se défend de cette situation en m’expliquant qu’il n’a pas eu le choix, car le directeur R&D voulait absolument une isolation contextuelle, et c’est cette contrainte qui l’a forcé à devoir faire de la sorte.

Sur ce, je continue à analyser le code dans lequel je vais devoir évoluer. Au milieu des 60 projets, j’en vois un qui semble posséder pas mal de fichiers sources : le projet qui contient les IHM.

Et là, c’est la fête du slip : du code behind  fait directement référence à nos supers « Helpers », le tout formant une espèce d’énorme plat de spaghetti dans lequel il est quasi impossible de suivre le moindre chemin de code !

Je me rapproche de l’équipe de dev pour comprendre comment ils peuvent travailler dans ces conditions. Ils me répondent qu’ils sont bien conscients de la situation, mais la pression permanente exercée par le directeur R&D ne leur permet pas de travailler proprement, car il s’imagine que le Framework fourni par le chef de projet leur donne la possibilité de s’affranchir de toutes les problématiques traditionnelles.

De plus, les développeurs ne comprenant pas tout au sujet du Framework, ils doivent sans cesse aller tirer les vers du nez du chef de projet qui procède à des modifications au fur et à mesure des problèmes qu’ils rencontrent.

Nous sommes donc en présence d’une situation assez burlesque :

Le directeur R&D est persuadé que le chef de projet gère les développeurs en les formant en continu à l’utilisation du Framework, et le chef de projet pense que le directeur R&D gère « son » équipe de développement en attendant que le Framework devienne mature.

Au final, personne ne gère l’équipe de développement, et celle-ci est totalement livrée à elle-même !

Le chef de projet étant très susceptible, je m’abstiens de toute remarque et tente quand même une implémentation simple.

Au bout d’une semaine, lors du fameux "daily standup", j’explique que je n’arrive pas à mettre en œuvre la création en base d’un objet métier. Là-dessus, le directeur R&D entre dans une crise de rage ! Il ne comprend pas qu’il me faille 5 jours pour faire quelque chose d’aussi trivial. 

Lorsque je pose la question : « mais qui a déjà créé un objet métier en base ? » tout le monde baisse la tête, mais le directeur R&D explique que plein de choses ont déjà été créées en base, et que ça nous a permis d’ailleurs de faire le dernier salon.

En creusant la question, les développeurs avouent qu’en réalité, ils ont déjà créé des « structures » en base, mais le comportement associé n’a pas pu être correctement implémenté du faite de différents problèmes avec l’IMOODB.

Le directeur R&D commence à comprendre, mais une part de lui-même ne veut pas se l’avouer. Le projet doit continuer coûte que coûte et quoi qu’il en coûte !

Le développement continu et la situation s’envenime.

Les conditions de travail deviennent de plus en plus insupportables pour les développeurs : 

•  Le Framework qu’ils utilisent à de nombreux bugs et personne ne les formes correctement à son utilisation. 
• Tous les matins, ceux qui arrivent en premier téléchargent la dernière version du code source et celle-ci est corrompue. Ils passent donc leur matinée à essayer de comprendre d’où vient le dysfonctionnement qui dans 80% des cas dû à un changement dans le Framework poussé par le chef de projet à 22H. 
• La solution possède tellement de DLL avec des références circulaires que le logiciel met plus de 8 minutes à compiler sur chaque poste. 
• Le système de push crée plusieurs problèmes de race condition et de deadlock qui rendent extrêmement difficile le débogage de l’application. 
• Le couplage fort de la DLL où se trouve le code métier est assujetti à plusieurs régressions, forçant tous les développeurs à dépenser chaque jour une énergie folle pour revenir à un état stable est enfin commencer à travailler. 
• Le directeur R&D donne des indications techniques avec un vocabulaire qu’il ne maitrise pas, donc complétement incompréhensibles pour tous. Du coup, les développeurs se font régulièrement crier dessus à cause de leur incompétence supposée.
• La méthode Agile n’est pas correctement appliquée, les US sont à moitié faite, les daily standup durent des heures, le directeur R&D influence les « poker planning » et il n’y a jamais eu de démonstration interne du produit.

Certains d’entre eux commencent à s’intéresser aux solutions qui existent. Des messages sont envoyés au directeur R&D et au chef de projet pour expliquer les biens faits de l’intégration continue, des tests unitaires, du découplage total, de l’architecture SOLID, des coachs Agiles, etc.

Mais le chef de projet ne veut pas en entendre parler : pour lui tout cela s’applique aux grosses sociétés qui doivent gérer des projets à plusieurs centaines de jours / hommes. Un simple auto cliqueur (qu’il estime à 3 jours de travail) permettra de faire des tests automatiques de façon simple et efficace sans avoir à mettre en œuvre toutes ces histoires.

Le directeur R&D entre en conflit avec le chef de projet. Il lui demande de trouver des solutions car le nouveau salon arrive, et il faut absolument que le logiciel soit installé chez un premier client afin qu’il puisse faire un témoignage.

Le chef de projet passe des Weekend entier à essayer de refactoriser le projet à lui seul, mais sans succès. Il s’attèle à créer son auto cliqueur, mais la règle des 80/20 vient le frapper de plein fouet car une limitation due aux popups l’empêche de faire ce qu’il avait imaginée.

Le projet continue de sombrer techniquement et humainement, mais de nouveaux formulaires sont disponibles ce qui laisse à penser au directeur R&D que les choses ne se passent pas si mal.

Et un jour, c’est arrivé : les commerciaux ont signé un premier client, et il faut l’installer le plus rapidement possible !

Le directeur R&D se met à la tâche avec beaucoup de confiance. Il coordonne la logistique, les déployeurs, les formateurs, appelle les clients pour préparer les paramétrages…

Le service R&D observe la situation comme une maman qui regarde jouer son enfant avec un pistolet chargé. Quand le chef de projet ou les développeurs essayent de faire comprendre au directeur R&D que le logiciel n’est peut-être pas encore prêt, il rétorque qu’il faut savoir se jeter dans la piscine !

Une grosse crise de dépression s’installe dans l’équipe. Personne ne dis un mot lors des repas alors que d’habitude les blagues salaces fusent à tout va. Des discours défaitistes et cataclysmiques sont exposés à qui veulent les entendre. 

Les autres services commencent sérieusement à s’inquiéter de cet état d’esprit négatif et remontent le problème à la direction. Il est alors demandé aux pessimistes de faire bonne figure, et d’arrêter d’avoir des discours aussi exagérés, car ils plombent sérieusement le moral de toute la société !

Nous sommes un vendredi, et c’est le jour du déploiement qui doit se faire dans la soirée. Les développeurs continuent à coder sans rien dire, comme il leur a été demandé, et le directeur R&D me demande si je pourrai l’aider ce soir en tant que soutien à distance. J’accepte en proposant la chose suivante : je prends mon après-midi, puis je reviens au bureau ce soir à 21H pour l’épauler.

La chose est entendue, je rentre donc chez moi en souhaitant bon weekend à tout le monde.

Le soir arrive, et je retourne au bureau pour le déploiement. 

Lorsque j’ouvre la porte de la société, je découvre que l’alarme n’a pas été désactivée, j’imagine que le chef de projet a oublié de l’activer, mais en prêtant un peu plus attention, j’entends des bruits discrets qui viennent du fond du couloir. J’avance doucement dans le noir en direction du service R&D qui est resté allumé, imaginant que je vais tomber nez à nez avec la femme de ménage. Mais lorsque j’arrive au niveau de la pièce éclairée, je vois deux développeurs sur le banc de tests avec leur tête posée sur les claviers, montrant clairement que tout espoir les a abandonnés.

Je crie : « Mais qu’est-ce que vous foutez encore là ?! »

Les deux développeurs se relèvent d’un coup et me regarde avec des yeux tout aussi étonnées que fatigués. L’un d’eux me répond la chose suivante avec quelques sanglots dans la voix :

« Rien ne marche. Plus on fait des correctifs, et plus ça merde. C’est une catastrophe ! »

A ce moment-là, le chef de projet sort de son bureau en affichant un sourire crispé. Les développeurs se taisent instantanément.

Personne ne dit rien, mais tout le monde prend conscience que nous vivons les premiers instant d’une ère de ténèbres et de chaos qui va s’abattre sans vergogne dès lundi matin.

Je décide de prendre la parole :

« Ok, je vois. Écoutez, je pense que vous avez fait le maximum, donc rentrez tous chez vous car lundi risque d’être une journée difficile. De mon côté, je vais aider le directeur R&D pour le déploiement, et nous verrons bien ce qu’il adviendra »

Chacun acquiesce et le chef de projet demande à rester avec moi pour appliquer quelques correctifs en cas de problèmes bloquants. Les autres développeurs prennent leurs affaires et viennent me voir pour confesser ce qu’ils ont sur le cœur :

« On ne peut plus continuer comme ça, il faut vraiment trouver une solution, car tout le monde est au bord de la crise de nerf ! »

Je réponds avec une phrase laconique du genre « tout va bien se passer », mais je ressens vraiment dans leurs propos qu’une autre façon de travailler doit être mise en place au plus vite, car la situation que nous vivons est très loin d’être normale.

Après le départ des développeurs, nous appelons le directeur R&D. L’installation à distance va se faire pendant une bonne partie de la nuit, et comme attendu, beaucoup de problème se produisent sur le terrain.

Au bout de plusieurs heures à  faire en sorte que les choses fonctionnent à peu près, nous arrivons à un niveau d’impuissance qui nous oblige à attendre que l’équipe de développement soit présente pour contourner certains bugs qui nous empêche de continuer l’installation. Nous n’avons pas d’autres choix que de rentrer chez nous et attendre la fin du week-end.

Lorsque je retourne au bureau lundi matin, je m’attends à voir l’équipe de développement en pleine effervescence, mais dès mes premiers pas dans la société, je sens comme une sorte de chape de plomb.

Le chef de projet qui est visiblement très épuisé m’explique la situation :

Samedi matin, le directeur R&D lui a demandé de tout mettre en œuvre pour que le logiciel soit opérationnel lundi, car il est inenvisageable de former les utilisateurs avec un système complétement buguée. Du coup, il est venu travailler samedi et dimanche pour essayer de redresser la situation.

Comme il n’y arrivait pas tout seul, celui-ci a appelé les développeurs à la rescousse pour qu’ils viennent le rejoindre dans son calvaire. Quelques-uns ont répondu à l’appel pour le dépanner.

Dimanche soir, malgré de très grosses lenteurs, la situation semblait se stabiliser, mais tout le monde a convenu de venir très tôt le lundi pour le démarrage du client.

Lundi matin, la formation des utilisateurs étant quasiment impossible du fait des multiples dysfonctionnements, le temps de formation a été sacrifié pour encore tenter de stabiliser le logiciel.

Quelques heures plus tard, le client a ouvert ses portes obligeant le logiciel à passer en production. Les utilisateurs se sont retrouvés sans formation avec un outil présentant des problèmes graves (plantages, pertes de données, mélanges dans les informations, boutons non fonctionnels, lenteurs extrêmes …)

La tension étant à son comble, les intervenants sur place ont dû prendre une décision en urgence : basculer le client sur l’ancien logiciel pour rétablir une situation stable.

Voilà où nous en sommes. Après plus de 3 ans de développement, le logiciel n’a pas tenu une journée chez le premier client. 

Le projet est donc officiellement un échec.

Étape 4 : Recherche des coupables

Le déploiement du premier client commence à arriver aux oreilles de la direction, sonnant le début d’une véritable chasse aux sorcières !

Il est demandé à toute personne ayant travaillé sur le projet d’envoyer sa version des faits par email à la direction pour tenter de mieux comprendre la situation.

Chacun s’adonne à cet exercice, et la direction décortique soigneusement chaque récit en prenant soin de rassembler les meilleurs passages dans une présentation PowerPoint.

Après quelques semaines, une réunion est organisée entre la direction et la R&D.

Objectif : Débattre de l’expérience de chacun pour tenter de déterminer d’où à bien pu venir le dysfonctionnement. 

La réunion commence fort. La direction explique à l’ensemble du service que l’échec du projet engendre une perte de plus de 600 000 euros, et qu’à la vue de la situation, des têtes vont tomber !

S’en suit la projection du PowerPoint qui rassemble toutes les phrases « anonymisées » relatant les déboires du projet vues de l’intérieur.

Il en ressort que le projet a toujours été mené de façon vague, sans direction précise, laissant les développeurs se débrouiller seul sous couvert d’une méthode qui prône l’auto organisation.

Le directeur R&D incrimine le chef de projet qui pour lui n’a pas tenu son rôle. Il expose que celui-ci avait rédigé lui-même sa lettre de mission dans laquelle se trouvait des tâches telles que la formation continue de l’équipe, la mise en place de bonnes pratiques, le suivi de la qualité du code et la création du Framework censé accélérer la productivité générale. 

De son côté, le chef de projet se défend en expliquant que ses préconisations n’ont pas été respectées, que les développeurs n’étaient pas assez compétents et que les spécifications fonctionnelles n’ont jamais été totalement rédigées. Pour lui le directeur R&D a outrepassé son rôle en voulant s’accaparer une partie technique qu’il croyait maitriser mais sur lesquelles n’avait pas les compétences requises. Sa position hiérarchique a mené le chef de projet à devoir s’écraser.

Le conflit s‘envenime, et tout le monde se met à nourrir un débat très houleux.

Après plusieurs heures de discutions, le chef de projet reconnait qu’il a une part de responsabilité dans cet échec, et tout le monde s’attend à ce que le directeur R&D en fasse de même, mais cela ne sera pas le cas.

Étape 5 : Punition des innocents

Une réunion de crise invitant tous les collaborateurs de la société est organisée pour annoncer l’échec du projet.

La direction explique très sèchement l’état de la situation, laissant comprendre que l’ensemble de la société est menacée par cet échec majeur.

La salle entre en ébullition, et les langues se délient : Faute à l’esprit mégalo du directeur R&D et du chef de projet qui ont vu trop grand, faute aux développeurs qui sont des incompétents, faute au chef produit qui ne comprend rien au métier, faute à la direction qui n’a pas su stopper l’hémorragie à temps alors que tout le monde voyait bien que les choses ne se passaient pas correctement, …

La direction essaye de calmer les choses, et annonce que la mort du projet signifie clairement la mort de la société. Nous n’avons donc pas d’autre choix que de réitérer notre confiance en l’équipe R&D pour repartir du bon pied.

Et là, c’est l’hécatombe : toute la salle est consternée par cette déclaration. « On prend les mêmes et on recommence ? » s’écrient certains participants.

Le directeur R&D et le chef de projet essayent de tirer leur épingle du jeu en expliquant que les développeurs n’étaient pas au niveau, ce qui est la cause principale de l’échec. 

Les développeurs, qui sont des débutants pour la plupart, n’osent pas rétorquer et se laissent convaincre par l’assemblée qu’une grosse part de responsabilité leur incombe.

Une fracture se crée entre le service R&D et le reste de la société qui se sentait déjà spolié depuis plusieurs années par des développeurs un peu trop chouchouté à leur gout.

La tension est d’autant plus palpable que personne ne sait comment nous allons pouvoir nous tirer de ce mauvais pas, car ni le chef de projet, ni le directeur R&D, ni les développeurs n’ont de solution pour sortir de cette impasse.

La réunion se termine dans le chao, la confusion et un brouhaha de remarques injurieuses et blessantes vis-à-vis de tous les participants au projet. Tout porte à croire que la fin de la société est proche, et certains évoquent leur envie de quitter la boite.

Arrivé à ce stade, l’espoir a quitté une bonne majorité des collaborateurs, laissant place à un sentiment d’impuissance et d’incompréhension qui ne présage rien de bon.

Étape 6 : promotion des non participant

Comme vous pouvez vous en douter, l’ambiance était au plus bas au service R&D car tout le monde en a pris pour son grade.

J’étais dans mon bureau avec le chef de projet lorsque le directeur R&D débarque avec un air dépité

Celui-ci demande au chef de projet comment il voit les choses pour redresser la situation.

Le chef de projet explique qu’il est complétement dépassé par les évènements, et que la qualité de code du logiciel métier ne permettra pas de repartir sur de bonnes bases. A part trouver rapidement 5 ou 6 développeurs chevronnés pour reprendre le dossier, il ne voit pas comment les choses vont pouvoir s’arranger.

Je profite alors de ce moment de désespérance pour expliquer mon point de vue : A mon sens, le gros problème de ce projet n’est pas technique comme tout le monde le croit, mais managérial. Pour moi, il faut absolument que l’équipe puisse se raccrocher à une personne capable de la motiver à remonter la pente en la formant et en mettant en œuvres des méthodes qui sont conformes à notre temps.

J’explique que je suis prêt à endosser ce rôle à condition d’avoir carte blanche.

Voyant mon élan d’enthousiasme, le directeur R&D m’emmène aussi tôt voir la direction pour que j’expose mon plan. La direction ne sachant que faire me donne le feu vert, et acquiesce à toutes mes exigences pour que je reprenne les rênes du projet.

Me voilà donc promu « lead developer » d’une équipe au plus bas moralement, et dont la légitimité a été fortement remise en cause par l’ensemble des collaborateurs de la société.

Tout le monde pensait que mon action était peine perdue, mais en réalité, j’étais comme un agriculteur qui a racheté un terrain sur lequel un volcan a tout dévasté : il ne pouvait en être que plus fertile et j’y voyais une magnifique opportunité de faire de grandes choses !

Mais ceci sera l’objet d’un prochain article de blog…