La mort au bout du planning

Il était une fois et une fois il n’était pas un projet informatique. D’une durée prévue de 12 mois, ce projet occupait à temps plein un chef de projet et un développeur. La communication entre le chef de projet et le développeur se faisait sans heurt :

- bonjour, ça va ? demandait chaque matin le chef de projet
- bonjour, ça va, répondait chaque matin le développeur.
- à demain, disait chaque soir le développeur.
- à demain, répondait chaque soir le chef de projet.

La seule entorse à cette routine somme toute assez joyeuse avait lieu tout les vendredis soirs, où le développeur disait :

- bon week end,
- merci, répondait le chef de projet, bon week end.

Le projet était sans risque, car il suivait un plan. Et pour éviter toute espèce de confusion, le plan était affiché au mur :

- du 1er janvier au 30 novembre : développement
- du 1er décembre au 21 décembre : recette
- du 22 décembre au 30 décembre : correction
- 31 décembre : mise en production.

Le développeur développait. Le chef de projet allait en réunion, avec son ordinateur portable. Il rédigeait des comptes-rendus dans Word, qu’il envoyait par email avec Outlook. Le soir, il faisait des suivis de projets, avec des fichiers Excel colorés. De temps en temps, il préparait des présentations, avec PowerPoint. Chacun vivait sa vie de son côté, tranquillement, sans embrouilles. Un projet de rêve.

En janvier, le développeur avait découvert qu’il pouvait jouer avec Pinball sur son ordinateur. Il ne mettait pas le son, pour ne pas déranger le chef de projet. De temps en temps, il regardait le plan affiché au mur. Il était rassuré.

En février, le développeur s’aperçut qu’il existait un logiciel sur son ordinateur qui s’appelait Internet Explorer et qui lui permettait de lire des informations très intéressantes sur l’avenir des abeilles, un sujet qui le préoccupait au plus au point. Le plan sur le mur n’avait pas bougé. Il savait où il allait. Le chef de projet était satisfait, lui aussi, car le développeur remplissait bien ses suivis. Le projet avançait donc comme prévu, sur des roulettes.

En mars, le développeur parti au ski. En avril, le chef de projet parti au ski. Mais le projet avançait bien, car le chef de projet avait bien pris garde d’envoyer par email le tableau de suivi au développeur, afin de bien anticiper toute cette période de congés.

En mai, le développeur pris connaissance du cahier des charges du projet. Un pavé de 682 pages. Ce fut une belle affaire, ce cahier des charges en .pdf, car le développeur n’avait pas le lecteur Acrobat. Il lui fallu un certain temps, à lui et au chef de projet, pour comprendre pourquoi, malgré tous les clics, le fichier ne s’ouvrait pas. Heureusement, on trouva la solution et une demande d’installation d’Acrobat fut transmise par voie hiérarchique au Service Informatique. Il y eu quelques dissension entre le Service Informatique et le chef de projet, car le responsable informatique reprochait au chef de projet de n’avoir pas anticipé cette demande qui allait occuper une partie de son équipe. Quand le développeur put enfin ouvrir le fichier du cahier des charges, le problème fut de pouvoir l’imprimer. Cela ne fonctionnait pas, une histoire de driver a priori. Le développeur n’osa pas, cette fois, déranger le chef de projet, après tous les problèmes causés par l’histoire du lecteur Acrobat. De toute façon, il pouvait le lire sur l’écran, cela fonctionnait aussi bien. Le développeur regarda le pla affiché au mur, et calcula assez facilement, grâce à la calculatrice intégrée à Windows qu’il devait développer l’équivalent de 682 pages divisé par 6 mois restant à faire soit l’équivalent de 113,6 pages par mois, c’est-à-dire environ 5,68 pages par jours. Après avoir lu les 10 pages de table des matières, il fut assez rassuré par ce calcul. Il remercia le chef de projet de ce plan affiché au mur.

En juin, le développeur commença à développer. Il avait lu sur Internet que Visual Studio Team System était un outil intéressant.  Mais comme le coût de la licence n’avait pas été prévu dans le projet, ce n’était pas bien grave, il utiliserait Notepad, qui est aussi un outil très intéressant, et surtout qui ne demande pas d’installation, donc évite les embrouilles avec le Service Informatique. La lecture de ses 5,68 pages par jour procurait une grande satisfaction au développeur, car il comprenait tout. D’ailleurs, il n’y avait rien à développer. Les 113 premières pages rappelaient l’importance du projet, les acteurs principaux, les attendus, l’existant, et bla bla bla...

En juillet, le chef de projet partit en vacances à la mer. En août, le développeur partit en vacances à son tour. Mais comme pour les vacances d’hiver, le suivi fut assuré. Avant de partir, le développeur s’aperçut qu’il prendrait du retard sur sa lecture quotidienne du cahier des charges, alors il mit les bouchées doubles. Heureusement, le plan affiché sur le mur lui rappelait l’objectif à tenir.

En septembre, le développeur s’inquiétait quand même un peu, car la lecture du cahier des charges devenait plus compliquée. Afin d’anticiper, et pour suivre le plan accroché au mur, il décida de manière unilatéral à venir tous les samedis.

En octobre, le développeur s’aperçut que plus il avançait dans sa lecture du cahier des charges, plus leur mise en œuvre en terme de développement s’avérait complexe. Il décida, toujours de manière unilatérale, de venir aussi tous les dimanches. Le chef de projet finit par s’en apercevoir car, le vendredi soir, le développeur oubliait de lui souhaiter un bon week-end et faisait comme les autres soirs. Le chef de projet décida alors de venir aussi travailler tous les week-ends.

En novembre, le développeur commença à se sentir un peu fatigué. Le chef de projet se mit aussi à coder dans Notepad. Le 11 novembre, le développeur dut s’absenter, car il était malade. Mais ce n’était pas grave, ils allaient rattraper leur retard. L’objectif clair affiché au mur les tenait motivé. Ils se mirent à développer aussi la nuit. Enfin, une nuit sur deux, car le développeur était de plus en plus malade. Le chef de projet, à force de développer, attrapa une tendinite, car il n’avait pas l’habitude de ce genre de tâches. Il se mit à le plus faire ses suivis. Ni à participer aux réunions. Le 21 novembre, le développeur envoya à la DRH un arrêt maladie d’une semaine. Il vient pourtant le 23 novembre, pour rattraper le retard. Le 24 novembre, il envoya à la DRH un arrêt maladie de 6 mois. Le 25 novembre, le chef de projet s’aperçut qu’il n’y arriverait pas tout seul. Le 26 novembre, son Directeur lui accorda une rallonge budgétaire, et une équipe de 10 développeurs arrivèrent. Le 27 novembre, le chef de projet s’aperçut qu’ils n’y arriveraient toujours pas, son Directeur lui accorda une nouvelle rallonge budgétaire et 20 nouveaux développeurs arrivèrent. Du 28 novembre au 30 novembre, pendant deux jours et deux nuits, tous les bureaux, les salles de réunion, les caves, les greniers, furent réquisitionné pour le projet. Malgré tout, ce n’était pas fini.

Le projet fut jeté à la poubelle. Le chef de projet fut mis dans un placard. Le directeur fut mis à la porte. 

On appela un scrum master, qui battit une équipe transverse, obtint un product owner digne de ce nom, arracha le vieux planning du mur et le remplaça par des grandes affiches de Will Smith et de Charlize Theron.

Comments

[Rédigé par : Lamine]

Salut à tous,

Une histoire qui me donne le sourire mais en réalité on a tous connus ou vécu une situation pareille.

Heureusement l'agilité (Scrum en particulier) est là pour faire face : un suivi sur le très court, court et moyen terme nous permet d'avoir une idée claire sur l'avancée du projet et ressouder l'équipe pour donner le max de chacun.

A+

[Rédigé par : Denis]

C'est tellement vrai !
On a tous connu un projet similaire ... c'est la mémoire collective des chefs de projets.

C'est pour ça que Scrum nous parle si bien.

[Rédigé par : Alex]

Jolie histoire qui m'a fait sourire, merci pour ce moment de détente

[Rédigé par : gaspard]

Si je comprends bien, l'image n'a d'autre but que d'appâter le lecteur ;)

[Rédigé par : Frédéric Doillon]

Pour les livres, il s'agit d'un plugin intégré automatiquement dans TypePad. Il suffit juste de saisir le code ISBN du livre, et il est automatiquement récupéré, avec un lien vers Amazon...il faut bien vivre.

[Rédigé par : Eric Reboisson]

Une histoire très amusante hé hé.

En passant, petite question, les livres affichés dans le menu de droite le sont ils via un plugin wordpress ? si oui lequel ?

Bonne soirée.