ben moi je suis plutôt devenu "Désensableur des projets échoués"
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
ben moi je suis plutôt devenu "Désensableur des projets échoués"
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'abstractionEnvoyé par Deallyra
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.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.
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.
IT Comedy club
Y a du vécu mais j'ai bien rigoler lolll25 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 ?
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!).
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).
Vécu pendant un stage en licence info, le logiciel n'est jamais entré en production, la nouvelle directrice commerciale n'en voulait pas- 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.
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.
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
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
Le cas des projets envoûtés
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
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
Résultat :
" Le coût du projet Géode
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(source Wikipedia , à "Géode")
A bon entendeur, et jamais 2 sans 3 !!
Ecris-la toi-même, petit chef !- 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.
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.- Les spécifications ont commencé quatre mois après le début du développement.
Naturellement. Et comme il faudra tout recommencer from scratch, on fera croire que c'est à cause du 1% qui restait.- 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.
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.- 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.
Ouais, pourquoi pas, parce que, quand même, seize bits, ça fait pas moins de trente-deux couilles.Le mémo dit que vous allez développer une application 64 bits sur une plateforme 16 bits.
Ils sont payés de toute manière, alors faire ça ou peigner la girafe...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.
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.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.
Il a tort d'attendre quoi que ce soit de quelqu'un qui lui a livré une application pourrie.- 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.
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.- Vous trouvez une liste de 16 bonnes pratiques de développement et réalisez qu'aucune d'entre elles n'est suivie.
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.Le nouveau dirigeant remplace toutes les personnes ayant une connaissance profonde de l'organisation par des externes de son ancienne société.
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.- 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).
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.- 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 !
Non je plaisante : piquez la place de ce bouffon !
Rappellez-vous que, quand vous aviez candidaté sur ce poste, l'offre d'emploi précisait : "vous serez force de proposition"...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.
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.- Quand les spécifications indiquent que la nouvelle application doit fonctionner exactement comme celle qui existe déjà.
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.- 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.
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.- 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").
Kestata ? Tutfoudmagueule ? (Re-zut, c'est l'auteur des bédés de Nabuchodinosaure qui va me demander des droits!)- On vous donne de nouvelles fonctionnalités à développer le jour de la livraison.
Ah ouais quand même.Souvent.
En effet, je crois que seule une intervention divine peut sauver certains projets.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager