25 signes et expériences réelles qui montrent qu'un projet de développement logiciel est destiné à l'échec

[koopajah]

25 signes et expériences réelles qui montrent qu'un projet de développement logiciel est destiné à l'échec

Malgré tous nos efforts pour faire de chaque développement logiciel en entreprise un succès, certains projets restent maudits depuis leur commencement. Voici 25 signes et expériences réelles qui montrent qu'un projet de développement logiciel est destiné à l'échec.

- Le projet change de nom pour la troisième fois en autant de mois.

- Le chef de projet décide qu'il vaut mieux écrire une version séparée du logiciel pour les Etats-Unis plutôt que d'internationaliser une version unique.

- Les spécifications ont commencé quatre mois après le début du développement.

- Le nouveau directeur de R&D informe fièrement les dirigeants que le projet sera fini à 99% en avance sur le planning et leur assure que le logiciel peut-être livré directement aux clients sans avoir besoin de phases de tests.

- Vous êtes un développeur web. Vous ouvrez l'archive ZIP qui contient les fichiers HTML produits par votre client pour le site que vous intégrez à votre application web. Vous découvrez que les documents HTML du client sont simplement des fichiers Microsoft Word sauvegardés au format HTML.

- Le mémo dit que vous allez développer une application 64 bits sur une plateforme 16 bits.

- Le développeur ne comprend pas le document de spécifications et continue de coder malgré tout. Et l'équipe de validation ne sait pas comment réaliser ses tests mais "teste" malgré tout.

- Quand vous voyez le budget du projet, vous réalisez que plus de la moitié a été dépensée pour demander à un infographiste de créer une maquette de la page d'accueil du site, sans même s'assurer que le design était réalisable. Ou sans aucune considération pour les milliers de pages de contenus qui existeront en plus de cette page d'accueil.

- L'utilisateur ou le client demandent de nouvelles fonctionnalités au lieu de se focaliser sur la résolution de bugs et l'amélioration des performances.

- Vous trouvez une liste de 16 bonnes pratiques de développement et réalisez qu'aucune d'entre elles n'est suivie.

- Les rapports d'avancement sont vus comme une insubordination.

- Le nouveau dirigeant remplace toutes les personnes ayant une connaissance profonde de l'organisation par des externes de son ancienne société.

- C'est un gros projet et son nom est Projet Iceberg. Ou alors c'est la troisième fois que la société essaye de l'arrêter et le projet porte le nom de code Phoénix. Etrangement, vous ne croyez pas que celui ci renaîtra de ses cendres.

- Même les clients qui ont eu la version gratuite sont énervés.

- Le manager de votre projet critique (rapportant 80% des revenus de votre société) a appris la technologie choisie depuis moins de trois mois et il forme 4 nouveaux développeurs en même temps. Le manager a eu droit a une durée de trois mois pour réaliser le projet.

- Ils ont changé le chef de projet et relocalisé le projet entier dans une autre ville. (Vous vous considérez comme chanceux que les deux villes soient sur le même continent.)

- Le chef de projet décide d'appliquer la méthode Agile pour "gagner du temps".

- L'équipe de management décide de dépenser un million d'euros sur un projet en valant 20 000. Ensuite les managers décident en accord avec l'équipe achat de la société que le logiciel d'un million d'euros demande un matériel valant 2 millions d'euros. Pendant ce temps, une secrétaire achète un PC d'occasion et un CD-Rom contenant de nouveaux logiciels d'automatisation. Elle code le projet pendant sa pause déjeuner. (On pourrait en fait considérer celui-ci comme un succès).

- Le chef de projet vous informe que maintenir un historique complet de toutes les bases de données est une fonctionnalité obligatoire de l'application, mais il n'a pas eu le temps de (lire : ne sait pas) réaliser un modèle de données pour ça. Alors il a décidé de prendre de l'avance en commençant l'interface web et de s'en inquiéter plus tard. Et c'est le Le chef de projet !

- Le chef de projet dit : "soyez créatifs". Cela se produit après que l'équipe de management ait diminué l'effectif sur le projet de 20%. Et après que l'équipe informatique ait récupéré du matériel prévu pour le recyclage, indiquant que c'était votre environnement de développement.

- Quand vous êtes embauché comme l'architecte principal et qu'après 4 semaines dans le projet vous ne comprenez toujours pas ce qu'ils veulent que vous fassiez. Finalement vous découvrez qu'ils ne savent pas non plus.

- Quand les spécifications indiquent que la nouvelle application doit fonctionner exactement comme celle qui existe déjà.

- L'équipe dirigeante demande une date de livraison de l'application avant même que vous ayez reçu une seule information concernant les fonctionnalités demandées.

- Quand le tout nouveau chef de projet crée un planning sans consulter personne de l'équipe technique et alloue pour chaque élément 2 semaines dans le planning (y compris les éléments comme "architecturer la base de données" et "écrire le code").

- On vous donne de nouvelles fonctionnalités à développer le jour de la livraison. Souvent.



C'est une liste basée sur des témoignages de nombreux professionnels de l'informatique. Mais, au final, c'est peut être encore incomplet ? Avez-vous des anecdotes à partager avec nous ?

[Aka Guymelef]

Le projet change de nom pour la troisième fois en autant de mois

Vécu

[pseudocode]

Les spécifications ont commencé quatre mois après le début du développement

Petits joueurs. Chez nous, en ce moment même, le code a 6 mois d'avance sur la spec.

[ram-0000]

Envoyé par pseudocode

le code a 6 mois d'avance sur la spec.

Ah ? Vous avez une spec quand même (vieux motard que jamais)

[al1_24]

Les specs, c'est pas ce qu'on fait après la recette, une fois qu'on est bien d'accord sur le produit terminé ?

[pseudocode]

Envoyé par al1_24

Les specs, c'est pas ce qu'on fait après la recette, une fois qu'on est bien d'accord sur le produit terminé ?

Ca c'était notre ancien processus. Maintenant c'est : on code, puis on fait la spec, puis on modifie le code. Bien sur, lors de la modification, on doit essayer de ne pas trop changer de chose pour ne pas perdre de temps.

[pcaboche]

Envoyé par ram-0000

Ah ? Vous avez une spec quand même (vieux motard que jamais)

C'est quoi une spec. ?

[Deallyra]

Envoyé par pcaboche

C'est quoi une spec. ?

Un truc hyper chiant qu'on laisse aux stagiaires xD

[pseudocode]

Pour rappel : Le projet "Cauchemar"

Tout commence le 2 janvier, et votre tête souffre encore de vos derniers excès.

Vous êtes assis dans une salle de conférence avec plusieurs managers et quelques uns de vos collègues. Vous êtes un chef d'équipe. Votre patron (Chef de Projet) est là et il a amené avec lui tous ses chefs d'équipe. Son patron (un chef de service ou de département) a décidé de cette réunion.

« Nous avons un nouveau projet à développer! », dit le patron de votre patron. Appelons-le BB (pour BigBoss). BB décrit l'essentiel du nouveau marché identifié et du produit à développer pour l'exploiter.

« Nous devons avoir ce produit sur le marché pour le 4ème trimestre : le 1er octobre! », exige BB. « Comment cela vous prendre-t-il de temps pour faire l'analyse ? ».

Vous levez votre main. Votre patron essaie de vous arrêter, mais vous n'êtes pas conscient de ses efforts.

« Monsieur, nous ne pouvons pas vous dire combien de temps prendra l'analyse tant que nous n'avons pas un cahier des charges

« Le cahier des charges ne sera pas prêt avant 3 ou 4 semaines », dit BB. « Alors, imaginez que vous avez déjà le cahier des charges devant vous maintenant. Combien de temps avez-vous besoin pour l'analyser ? »

Personne ne respire. Tout le monde se regarde pour voir si quelqu'un a une idée.

« Si l'analyse dépasse le 1er avril, alors on a un problème. Pouvez-vous finir l'analyse d'ici-là ? »

Votre patron rassemble son courage et déclare : « On trouvera un moyen, Monsieur! ». Votre mal de tête augmente de 2 aspirines.

« Bien. ». BB sourit. « Maintenant, combien de temps pour la conception ? »

« Monsieur, » dites-vous. Votre patron pâlit visiblement. Il est clairement inquiet quant à sa prime annuelle. « Sans une analyse, il n'est pas possible de vous dire combien de temps prendra la conception. »

L'expression de BB se durcit. « IMAGINEZ que vous avez déjà l'analyse! », dit-il, tout en vous fixant de ses petits yeux ronds. « Combien de temps cela vous prendra pour la phase de conception ? »

2 aspirines ne suffiront pas... Votre patron, dans une tentative désespérée de sauver sa future prime : « Hé bien, Monsieur, dans la mesure où il ne reste plus que 6 mois pour finir le projet, la conception ne devrait pas dépasser 3 mois. »

« Je suis heureux que vous approuviez ce choix », affirme BB, rayonnant. Votre patron se détend. Il sait que sa prime est assurée.

BB poursuit : « Donc, l'analyse sera prête pour le 1er avril, la conception pour le 1er juillet, et cela vous donne 3 mois pour coder le projet. Cette réunion est un excellent exemple du bon fonctionnement de notre nouvelle politique d'accords et de délégation ("consensus and empowerment"). Maintenant, dégagez et commencez à bosser. Je veux les plans-qualité et le plan projet sur mon bureau pour la semaine prochaine. Oh, et n'oubliez pas votre réunion d'équipe multi-projets et les rapports qui seront nécessaires pour les audits-qualité des mois à venir. »

« Oublions l’aspirine », pensez-vous alors que vous vous en retournez vers votre open-space. « J'ai besoin de bourbon ».

Visiblement excité, votre patron vient vers vous et dit : « Quelle fantastique réunion! Je pense que l'on va vraiment faire quelque chose de révolutionnaire avec ce projet! ».
Vous approuvez d'un hochement de tête, trop dégoutté pour faire quoique ce soit d'autre...

« Au fait, » continue votre patron, « j'ai failli oublier. » il vous tend un document d'une trentaine de pages. « Vous vous souvenez que l’ISO vient faire une évaluation la semaine prochaine. Voici le guide d'évaluation. Vous devez le lire entièrement, le mémoriser puis le détruire. Il vous indique comment répondre à n'importe quelle question que l’ISO pourrait vous poser, il vous indique également quels endroits du bâtiment vous pouvez leur montrer et ceux que vous devez éviter. Nous devons obtenir l’accréditation pour juin! »

Vous et vos collègues commencez à travailler sur l'analyse du nouveau projet. C'est difficile dans la mesure où vous ne possédez aucun cahier des charges. Mais, avec les 10 minutes d'introductions données par BB en ce matin fatal, vous avez quelques idées de ce que le logiciel est supposé faire.

Le cahier des charges arrive le 15 février, soit 1 mois et demi après le démarrage du projet.

Puis une nouvelle révision arrive le 20, le 25 et toutes les semaines suivantes. Chaque nouvelle révision contredit la précédente. Visiblement, les gars du marketing qui l'écrivent, bien qu'ils aient toute la délégation de pouvoir nécessaire, ne trouvent pas d'accord.

En dépit de tout cela, vous et vos collègues poursuivez votre travail d'analyse.

Et un miracle se produit!!!

Le 1er avril, vous avez fini l'analyse!! Vous allez trouver votre patron et gémissez :
« Comment avez-vous pu dire à BB que nous avions fini l'analyse ??? »
« Avez-vous regardé un calendrier dernièrement ? c'est le 1er avril! »
L'ironie de la date ne vous échappe pas.
« Mais nous avons encore tant de points à éclaircir et analyser! »
« Qu'est-ce qui vous prouve que vous n'avez pas fini ? » demande impatiemment votre patron.
« Quuuooiiii ???? ...»
Mais il vous coupe par un : « L'analyse ne peut pas continuer indéfiniment, elle doit s'arrêter à un moment donné. Et puisque c'est la date à laquelle elle devait s'arrêter, elle est donc finie. Maintenant, retournez à votre bureau et commencez la conception. »

Alors que vous vous traîner vers votre bureau, vous commencez à considérer les avantages de garder une bouteille de bourbon dans le tiroir à dossier de votre bureau.

Ils ont organisé un pot pour célébrer la fin dans les temps de l'analyse. BB a prononcé un interminable discourt sur la délégation. Et votre patron a félicité sa troupe pour sa cohésion et son exceptionnel esprit d'équipe. Finalement, le grand directeur du département monte sur l'estrade et annonce que l'audit ISO s'est très bien passé et a remercié tout le monde pour avoir bien étudié puis détruit le guide d'évaluation.

Alors que les semaines s'écoulent, vous et votre équipe commencez la conception du logiciel.
Bien sûr, vous découvrez que l'analyse sur laquelle la conception est censée se baser n'est pas sans défauts. Mais lorsque vous annoncez à votre patron que vous avez besoin de renforcer l'analyse sur ses points faibles, il déclare simplement : « La phase d'analyse est terminée. La seule activité autorisée est la conception. Maintenant, retournez-y ! »

Alors, vous et votre équipe dégrossissez la conception du mieux que vous le pouvez, sans vraiment savoir si le cahier des charges a été correctement analysé ou non. Bien sûr, cela n'a pas grande importance dans la mesure où de nouvelles versions du cahier des charges continuent de s'amonceler semaine après semaine.

A mi-chemin en plein dans la phase de conception, le département marketing annonce qu'il a repensé le cœur du système. Leur nouveau cahier des charges est complètement restructuré. Ils ont éliminé quelques domaines fonctionnels majeurs, et les ont remplacés par des fonctionnalités que des études de marchés auprès de clients potentiels ont montrées plus en adéquation avec les attentes de ces-dits clients.

Vous annoncez à votre patron que ces changements signifient que vous devez re-analyser et re-concevoir la plus grande partie du logiciel. Mais il vous répète : « La phase d'analyse est terminée. La seule activité autorisée est la conception. Maintenant, retournez-y ! » Et vous y retournez...

Dégrossir, hacher, trancher, couper... vous essayez de créer une sorte de document de conception qui reflète vaguement le nouveau cahier des charges. Toutefois, les évolutions de ce document ont simplement augmenté en fréquence et amplitude.

Vous tracez votre chemin avec obstination au travers de ce cahier des charges.

Et le 1er Juillet, un nouveau miracle fut!

Vous avez fini la phase de conception! Plutôt que d'aller trouver votre patron pour vous plaindre, vous commencer à stocker dans le tiroir-dossier de votre bureau des bouteilles de vodka.

Ils ont organisé un pot pour célébrer la fin dans les temps de la conception, et leur accréditation ISO. Cette fois, le discourt de BB est si interminable que vous devez aller plusieurs fois aux toilettes.

Il y a des nouvelles bannières et de nouvelles affiches sur les murs de tous les bureaux. Ils montrent des aigles et des alpinistes, et ils parlent d'esprit d'équipe et de délégation. Elles se regardent mieux après quelques scotches. Cela vous rappelle que vous devez faire de la place dans votre bureau pour le brandy.

Vous et votre équipe commencez à coder. Mais vous découvrez rapidement que la conception est inexistante dans plusieurs domaines importants. Vous convoquez une session de conception dans une des salles de conférence afin de résoudre les points les plus critiques. Mais votre patron vous surprend et disperse la réunion par un : « La phase de conception est terminée. La seule activité autorisée est le codage. Maintenant, retournez-y ! »

Votre patron engage un consultant afin de construire des outils permettant de calculer le pourcentage d’avancement du projet en se basant sur les tâches du planning prévisionnel. Il affiche sur le mur un graphique en forme de thermomètre géant, avec le nombre 100% au sommet. Chaque jour, il allonge la ligne rouge en fonction des tâches terminées.

Trois jours après l'apparition du graphique, votre patron vous arrête dans le couloir : « Le graphique ne progresse pas suffisamment vite. Nous devons atteindre les 100% pour le 1er octobre. »

« M... Mais nous n'sommes mêm'pas sûr k... kk... ke'le planning pr..présivio…prévisionnel soit complet » prononcez-vous péniblement.
« Nous devons atteindre les 100% pour le 1er octobre. », répète votre patron. « Êtes-vous sûr que vos rapports d’activités sont à jour ? »
Puis, dans un flash de génie du management, il déclare : « Ca y est, je sais! Je veux que vous instituiez une nouvelle politique de reporting dans votre équipe d'ingénieurs. Vos rapports d’activités devront indiquer le pourcentage d’avancement de chaque tâche. Voilà qui devrait augmenter le pourcentage d’avancement global ! »

Vous décidez de ne pas lui dire que cela va requérir deux mois/homme non planifiés. Vous décidez de ne rien lui dire du tout. Vous décidez que des injections sous-cutanées d'éthanol pure représentent la seule solution. Vous faites les arrangements nécessaires.

Dégrossir, hacher, trancher, couper... vous et votre équipe codez comme des fous. Au 1er août, votre patron, regardant d'un air soucieux son graphique, impose une semaine obligatoire de 50 heures.

Dégrossir, hacher, trancher, couper... au 1er septembre, le thermomètre géant indique 112% et votre patron vous demande d'écrire un rapport expliquant pourquoi vous avez dépassé le nombre de tâches prévues initialement. Il impose les samedi obligatoires.

Dégrossir, hacher, trancher, couper... Les esprits s'échauffent, les gens démissionnent, le département qualité fait pleuvoir les rapports d'anomalies chez vous, les clients demandent des guides d'installation et d'utilisation, les vendeurs demandent des previews pour des clients particuliers, le cahier des charges continue d'évoluer et le magasin d'alcools n'accepte plus votre carte de crédit. Quelque chose doit se passer.

Le 15 septembre, BB convoque tout le monde.

Alors qu'il entre dans la salle, ses yeux sont injectés de sang. Lorsqu'il parle, les tons graves de sa voix soigneusement posée vous causent des problèmes gastriques immédiats. « Le directeur qualité m'a informé que ce projet implémente moins de 50% des fonctionnalités requises! Il m'a également informé que le système se plante tout le temps, affiche des résultats erronés et se traîne lamentablement. Il s'est également plain de ne pouvoir suivre le rythme avec toutes ces livraisons quotidiennes que vous lui faites. »

Il s'arrête quelques secondes, visiblement en train de se calmer : « Le directeur qualité estime qu'à ce taux de développement, nous ne seront pas capable de sortir un produit avant décembre! ». En fait, vous pensez plutôt "mars", mais vous n'en dites rien.

« Décembre!!! », hurle BB. Les personnes baissent leur tête comme s'il leur pointait un fusil d'assaut vers eux. « Décembre est absolument hors de question. Chefs d'équipe, je veux de nouvelles estimations sur mon bureau pour demain matin. Je déclare dorénavant les semaines de 65 heures obligatoires tant que ce projet n'est pas fini. Et il a intérêt à finir pour le 1er novembre! »

En quittant la réunion, on peut l'entendre murmurer : « accords... délégations, ... pfff, à ch...! »

Votre patron est tout blanc. Sa prime annuelle vient de s’envoler. « Avez-vous quelque chose à boire ? » Ayant tout juste fini votre dernière bouteille de Bone's Farm, vous extrayez une bouteille de Thunderbird de votre étagère et en versez dans son reste de café. « combien cela va prendre pour finir le projet ? »
« On a b'soin de figer l'cahier des charges, de l'analyser, de concevoir et de l'implémenter. », dites-vous d'une voix plus que pâteuse.
« Pour le 1er novembre ??? », dit votre patron, « Impossible! Retournez juste coder ce p... de logiciel! », hurle-t-il.

Quelques jours plus tard, vous apprenez que votre patron à été transféré au département de Test. Le taux de turn-over a atteint des sommets. Les clients, informés à la dernière minute que leurs commandes ne pourront être honorées, ont commencé à les annuler. Le Marketing réévalue si, oui ou non, ce logiciel doit faire parti des objectifs généraux de la société, etc., etc.. Les mémos volent, les têtes tombent, les politiques changent, et le cours des choses est, en général, bien sombre...

Finalement, en mars, après bien trop de semaines à 65 heures, une version très instable du logiciel est prête. Sur le terrain, le taux de découverte des bugs est élevé, et les équipes de support technique voient leur volonté poussée à l'extrême pour traiter les plaintes et demandes diverses de clients en colère.

[Deallyra]

Pas mal ^^

j'ai l'impression de lire une de mes journees au taff.

[zeavan]

Voila ce que m'as dit mon CTO il y a quelque temps, moi je suis a 80000 pieds, cela exlique mes decisions un point c'est tout, en pleine reunion devant tout le monde apres le n'ieme desaccord de ma part sur ces choix.
Je lui reponds et bien moi je suis peut-etre a 60000 pieds mais j'y suis du 1er au dernier.

Le mec s'est fait virer quelque temps apres pour avoir pratiquement fait couler la boite par ces depenses inutiles, une boite de 35 personnes dirigees comme une boite de 1000.

Pour un projet qui prend une mauvaise tournure c'est quand vous dit pas ce qu'on attend de vous mais comment il faut le faire.

[Altess]

Envoyé par mon_nom_est_personne

j'ai l'impression de lire une de mes journees au taff.

On bosse dans la même boite ?

Envoyé par Altess

On bosse dans la même boite ?

j'aurais aimer car ca me dit que la desorganisation est partout

[ctiti60]

C'est vraiment excellent pseudocode et tellement réaliste !

Je me souviens encore d'un entretien dans une société :
"Nous ici, on fait la conception autour de la machine à café, car c'est plus conviviale. On la note ensuite sur des post-it".

Bizarrement, cette société a eu des difficultés financières...

[keskispas]

J'en ai vécu une pas mal : l'application à développer a été vendue comme un produit existant qui ne serait que "configuré".

[mister3957]

J'ai les mêmes à la maison ! Une boîte de 50 personnes dont 10 informaticiens.

Mais rassurez moi, c'est quand même pas partout comme ça si ? Vous auriez des noms ? ^^

[ferrero]

y a aussi un signe coté client final.

Quand le client n'a pas de culture de projet ça veut dire quand tu lui envoie les specs pour validation, il t'appelle et te dis bah moi je valide pas ça, ce que je veux c'est voir une 1ere version dans laquelle je peux valider le fonctionnelement de l'appli.

le risque à prendre c'est developpé une 1ere version qu'on peut jeter par la suite et vous pouvez imaginer ce que cela peut engendrer

[ruscov]

On vous donne de nouvelles fonctionnalités à développer le jour de la livraison. Souvent.

Ca m'arrive presque tout le temps.
Tiens hier par exemple....

[mister3957]

Ha oui il y a également le fait de construire une maquette pourrie juste pour avoir de l'IHM à mettre dans les spec, et une fois validée commencer à développer à partir de ça en se disant "bah on a déjà ça... on va récupérer le travail ça nous fera gagner du temps"

Plus généralement pour mon cas, l'avancement du projet est restreint à l'apparence, comme si nous construisons une voiture et que son état d'avancement se basait uniquement sur la carrosserie. Le client demandant une version toute les semaines, il faut alors lui montrer de la taule au détriment des aspects moteur, freinage, intérieur, sécurité, confort etc. Le seul objectif fixé étant "faut que ça roule".