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

[souviron34]

ben moi je suis plutôt devenu "Désensableur des projets échoués"

[lepinekong]

Envoyé par Deallyra

Un truc hyper chiant qu'on laisse aux stagiaires xD

Ca c'est pour les p'tits joueurs. Pour les gros, ils le confient à des cabinets de conseil hyper cheros et le prix grimpe avec le niveau de l'abstraction
L'avantage d'avoir une coquille vide c'est qu'on peut faire ce qu'on veut au moins.

[jabbounet]

Envoyé par lepinekong

Ca c'est pour les p'tits joueurs. Pour les gros, ils le confient à des cabinets de conseil hyper cheros et le prix grimpe avec le niveau de l'abstraction
L'avantage d'avoir une coquille vide c'est qu'on peut faire ce qu'on veut au moins.

j'ai souvenir d'un "on dit" d'un ancien collègue a propos de certaines personnes.

Si c'est simple tu dit que c'est compliqué et tu le fait
Si c'est compliqué tu dit que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

[goosy]

Envoyé par 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 ?

Y a du vécu mais j'ai bien rigoler lolll

[professeur shadoko]

j'ai pas tout lu ... mais je voudrais vous raconter un expérience vécue (au début des années 90).

Domaine : finances
Objectif: pas clair, vague idée de ce qu'il fallait faire et , apparemment personne ne l'avait fait avant.

On a tatonné à gauche à droite, puis fait des protos ... pendant un an!
Le chef de projet a pété un cable mais la direction nous a soutenu (mais oui!)

Une fois que les idées ont été claires on a commencé à coder en Juillet, la version Beta était prête en septembre et le produit final livrable en janvier.

On a donc travaillé sans specs et au radar.

Non seulement ça s'est vendu comme des petits pains, mais , comme on n'était pas sûr de nous, chaque partie avait été testée à mort et le produit s'est révélé robuste (j'ai rencontré plus tard un client qui l'avait fait tourner 7 ans sans un problème).

Comme Monsieur Jourdain on avait fait de "l'agile" sans le savoir. Mais les point principaux du succès étaient:

- un petite équipe technique soudée travaillant "en commando" (des spécialistes très bien payés)
- une communication permanente et confiante avec la direction (oui il existe d'excellents managers et d'excellents commerciaux!)
- une grande rigueur dans le contrôle des résultats, dans la documentation de ce que l'on faisait (d'autres on pris le relai).

Donc oui le projet heureux existe!
(sans doute avec des modalités chaque fois différentes: le point critique est la relation entre donneurs d'ordres et équipe de réalisation. La programmation est une aventure humaine avant tout!).

[professeur shadoko]

Un petit mot supplémentaire car je suis revenu sur quelques pages en arrière...
A propos de "l'industrialisation": voilà un joli mot magique censé résoudre les problèmes de notre "industrie".
Pourquoi personne ne parle de "l'industrialisation de la stratégie miliaire"?
Voilà une comparaison qui va choquer et pourtant je dis tout le temps que le premier bouquin d'informatique a été écrit vers 1830! C'est "De la guerre" de Clausewitz (ne prenez pas les choses au premier degré: j'ai des raisons puissantes et graves pour détester la chose militaire: mais les aspects méthodologiques de Clausewitz sont fondamentaux).

[Kistrof]

- 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.

Vécu pendant un stage en licence info, le logiciel n'est jamais entré en production, la nouvelle directrice commerciale n'en voulait pas

[SuperBidi]

On peut pas comparer le dév à l'architecture ou à l'automobile pour une raison simple :
Quand une maison tient debout, tu peux pas l'installer chez un autre utilisateur.

Si tu devais développer chaque fois le même logiciel pendant 20 ans, je peux t'assurer une chose, à la fin, tu approcherais du zéro bug.
Et si tu faisais construire un pont par l'équipe qui a construit ta maison... je te laisserai le traverser en premier.

[bankai_khn]

Y a un cas qui me fatigue particulierement

• c'est quand le DG te dit en 5 min ce qu'il veux dans l'application.
  
• et te donne un delais de 1 mois, sachant que meme toi informaticien tu ne peu donner un delais car tu n'as aucune idee sur les specifications et qu'il te faudras faire une etude au moins prealable pour donner une fourchette de temp approximatif,
  
• de plus tu est le seule developpeur et tu doit t'occuper de l'analyse des besoins, rapport, du code, du design ...etc
  
• et les services concerner par cette app' ne te facilite pas la tache vue qu'ils te donne enfin un RDV pour t'expliquer leurs process de fonctionnement 3 semaine apres le RDV avec le DG
  
• Des regles de gestions qui sort de la logique que tu as le devoir de corriger car c'est pas logique tu ne peux pas developper une application en se basant sur leurs regeles preetablie qui ne sont pas optimiser ou parfois redicule :S ,
  
• De plus personne ne sais ce qu'il veux et tu enttends fait comme tu le veux mais le jour de la livraison tout le monde te tombe dessus en clamant haut et fort NON CA NE DOIS PAS ETRE AINSI alors que toi tu as fait un effort inuhumain pour entrer dans leurs tete et essayer d'entirer au max
  

C'est Un projet toujours en cours je suis optimiste mdr je me dit que je vais m'en sortir, j'ai bien fait comprendre au DG que 1 mois vaux mieu qu'il oublie ! c'est deja pas mal

Concernant le dernier point de ma liste je ne suis pas encors la mais j'espere minimiser au maximum les " Ha non il manque ceci " ou " Et bien ca ne sert a rien" ...etc ... Ca m'es deja arriver dans d'autre projets et croyez moi c'est penible les modifications et les ajout de module a la fin quand tu te dit enfin c'est fini

[okaparka]

Si un projet d'informatisation contient le mot "GEODE" (quelque part dans les documents contractuels) alors ce projet est maudit et va au fiasco.
En Voici 2 preuves Incontournables.

1°) Hopitaux de marseille

Voici un extrait du rapport de la cour des comptes (Rapport public annuel 2012 – février 2012) , je cite le rapport page 910 : " L’AP-HM avait donc, dans un premier temps, fait l’acquisition après un appel d’offres, lancé en 2005, du progiciel Géode de la société Sage, dans le cadre du projet Appropharm. Ce progiciel devait permettre la gestion des stocks physiques des médicaments en facilitant la gestion comptable de ces stocks en temps réel."

Résultat :
"L’échec de ce projet, et les mesures palliatives mises en place, ont entraîné pour l’AP-HM au moins 14 M€ de dépenses largement, voire totalement, inutiles." (ref: même rapport de la Cour de Comptes page 900)


2°) Informatisation de L'ANPE /Pôle Emploi

Je cite Le Monde Informatique du 22 déc 2005 : "Le nouveau directeur général de l'ANPE a décidé de "geler" le déploiement du nouveau système d'information qui était censé optimiser le travail des conseillers. Lancé en 1997, ce projet Géode devait être opérationnel en 2001.". Fin de la citation


Résultat :
" Le coût du projet Géode , estimé à 22,8 millions d’euros en 1996, s’est élevé à 135,5 millions d’euros sans qu’il y ait le moindre début d’application."
Source : Note de bas de Page N° 1 , page 6 du rapport d'information du Sénat présenté à la commission et annexé au procès-verbal de la séance du 19 juin 2008 -Session ordinaire 2007/2008 N°409.

Note : Les Smileys n'apparaissent pas dans le texte original des citations ci dessus référencées.

Et pour conclure
"La géode n'a quasiment pas d'usage en elle-même sauf à titre de collection, en exposition pour générer du tourisme ou en occultisme mais, là, nous quittons le domaine scientifique" (source Wikipedia , à "Géode")

A bon entendeur, et jamais 2 sans 3 !!

[I_believe_in_code]

Envoyé par koopajah

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

- 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.

Ecris-la toi-même, petit chef !

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

Pas de problème, le développement sera quand même terminé quatre mois avant que les spécifications commencent à ressembler à quelque chose. En revanche j'exige d'être payé d'avance, hein, parce que faudrait pas me prendre pour un idiot. Non ? On ne peut pas me payer maintenant parce qu'on n'aura le budget pour me payer que quatre ans après la livraison du logiciel ? C'est pas grave ! En bon visionnaire, j'avais déjà décidé de ne jamais bosser avec "on" cinquante ans avant la naissance de son père.

- 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.

Naturellement. Et comme il faudra tout recommencer from scratch, on fera croire que c'est à cause du 1% qui restait.

- 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.

Un client c'est comme un gamin ou comme un supérieur hiérarchique : faut mettre des limites à sa bêtise. Sinon on finit par se faire virer pour notre incompétence supposée par des gens qui ont déjà prouvé la peur.

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

Ouais, pourquoi pas, parce que, quand même, seize bits, ça fait pas moins de trente-deux couilles.

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.

Ils sont payés de toute manière, alors faire ça ou peigner la girafe...

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.

Aucun problème, je prends l'autre moitié du budget pour vous expliquer comment vous sortir de cette situation. Non, ne soyons pas méchant, je vous donne un tuyau gratuitement : virez tout le monde dans votre boîte, sauf la femme de ménage qui n'a rien fait de mal, elle, et demandez à cette dernière de recruter du nouveau personnel et de diriger l'entreprise. Si cette dame a un coeur, elle n'hésitera pas à proposer le poste de passeur de serpillière en priorité à son ancien patron.

- 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.

Il a tort d'attendre quoi que ce soit de quelqu'un qui lui a livré une application pourrie.

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

Et si avec cela vous gardez encore le moral, on vous mettra sous les yeux la liste des quatre-vingt sept bonnes pratiques dont quatre-vingt six ne sont pas suivies par vous. Heureusement, vous suivez scrupuleusement la dernière qui affirme que si vous aimez l'objet et les design materne, vous ne pouvez pas vous planter.

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

Les personnes remplacées s'associent pour créer une nouvelle boîte pendant que celle du nouveau dirigeant commence à décliner. Si la nouvelle boîte a besoin d'un patron viril et clairvoyant, je connais une ex-femme de ménage qui fait l'affaire.

- 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).

La secrétaire devrait s'associer avec l'ex femme de ménage... à elles deux elles feront du meilleur boulot que deux équipes entières d'experts j2ee encravatés et surpayé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 chef de projet !

Comme vous êtes sous ses ordres, c'est à vous de vous assurer que tout fonctionnera quand même comme il faut, en temps et en heure.

Non je plaisante : piquez la place de ce bouffon !

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.

Rappellez-vous que, quand vous aviez candidaté sur ce poste, l'offre d'emploi précisait : "vous serez force de proposition"...

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

Oui, oui, parfait, j'accepte de faire le même boulot deux fois. Mais tu me paies aussi deux fois, et d'avance, parce que ça sent l'entourloupe tout ça.

- 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.

Ce n'est pas grave : vous ne comptez ni respecter la date de livraison ni programmer toutes les fonctionnalités demandées. Si ? Alors allez travailler ailleurs.

- 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").

L'écriture du code est une phase tout à fait secondaire, nous sommes bien d'accord. D'ailleurs il est inconcevable, en 2012, que les ordinateurs ne soient toujours pas capables de lire dans nos pensées et de se programmer tout seuls. Dans un avenir proche, je crois en la génération spontanée d'applications parfaites. Le chef de projet sera un magicien moderne. Il marmonera des conjurations incompréhensibles (zut, FTL va me demander des droits pour les avoir paraphrasés), des incantations à côté desquelles un diagramme UML passera pour du code écrit en assembleur. La main de Dieu terminera le travail.

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

Kestata ? Tutfoudmagueule ? (Re-zut, c'est l'auteur des bédés de Nabuchodinosaure qui va me demander des droits!)

Souvent.

Ah ouais quand même.

En effet, je crois que seule une intervention divine peut sauver certains projets.