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

**caalors** · 11/07/2009, 14h20

"Projet" réel (portail comptable), vécu en SSII :

0/ Projet lancé à l'initiative d'une commission qui elle même ne croit pas au projet
1/ Pas de cahier des charges
2/ Pas de chef de projet
3/ Un chef produit qui ne connait ni le métier ni le domaine
4/ Pas de réunions entre développeurs
5/ Des développeurs qui ne connaissent pas le développement web
6/ Chaque développeur est son propre chef de projet
7/ Pas de convention d'écriture (ni de bonnes pratiques d'une manière générale)
8/ Langage non adapté au web
9/ Une charte graphique qui est définie après le début des développements
10/ Des développeurs qui refusent d'adopter la charte graphique (ben oui, chacun a fait la sienne)

Résultat, démission du chef produit et abandon du projet qui a été repoussé d'un an.

Le seul changement apporté, c'est qu'on est passé d'un langage à un autre, lui aussi inadapté, tant qu'à faire ;-)

C'est là qu'on comprend tout le sens de "ça pue" et qu'on se dit qu'il est préférable d'y aller...

Ps : petit oubli, un patron qui aime dire, à tour de bras, "nous on aime bosser dans l'urgence" et qui rajoute "les cahiers des charges, c'est quand on est à l'école, ici on n'a pas le temps"

@Patriarch24,

Tu as tout à fait raison.
A te lire je retrouve ce que j'ai lu dans ce livre :
http://www.eyrolles.com/Informatique...-9782212115611
C'est suite à cette expérience et à cette lecture que je me suis mis à ces méthodes.

**xasmxasm** · 11/07/2009, 15h33

Bonjour,

Il faut croire qu'être informaticien demande plus de connaissances que seul celles de l'informatique. Il est clair qu'aujourd'hui on est tellement formaté par le travail que l'on se concentre uniquement sur des connaissances techniques. On n'est pas forcement à l'écoute de ce que l'on nous dit la seule chose que l'on peut lire ici est "agile" et deux ou trois commentaire le reste n'est que... (vous mettrez ce qui vous plaira)
Pourquoi commencer quelque chose qui est voué à l'echec puis en rejeter la faute à qui voudra bien l'endosser? Ce qui ce concoit clairement s'exprime clairement alors pourquoi ne pas exposer un à un les tenant et les aboutissant avant que cela n'arrive. Je pense que l'exposer de ce projet aussi bon soit-il arrive bien trop tard pour ce projet mais peut-être utile pour de nouveau projet et il est dommage que ce soit des developpeurs qui le commente peut-être faudrait-il le soumettre à d'autres personnes.

Je ne suis pas la pour juger mais j'en ai assez de lire sur la toile des suites commentaires qui font penser que rien ne peut évoluer ou bien les innombrables conflits entre ms et linux.

Il est vrai que le monde est loin d'être parfait mais le fait de le dire n'y changera rien. N'oublions pas que l'informatique associée à d'autre technologie permet à l'humanité d'avancée plus vite avec moins de tracasserie et de communiquer plus facilement.

Amicalement

**MetalGeek** · 11/07/2009, 16h58

J'ai déjà eu à créer un logiciel dont les fonctionnalités n'étaient pas encore fixées - aucun cahier des charges ... mais qui était déjà vendu ! Les commerciaux n'étaient même pas d'accord sur que le "produit" devait faire dans les détails... Je ne sais pas comment ils ont réussi à le vendre, en tout cas ça prouve qu'ils étaient meilleurs que les chefs de projet...

**MetalGeek** · 11/07/2009, 17h03

Ah oui, j'en oubliais un...
Que pensez-vous d'un projet que l'on vous confie (à vous tout seul, hein, au moins on vous fait confiance), qui est basé sur du COM entre Excel, une base base SQL Server locale + une base Oracle distante, et qu'une fois le projet arrivé à la phase de récéption (tant bien que mal), on vous dit que le client veut que l'interface du logiciel soit accessible à distance et multi-utilisateur (oui oui, vous avez bien lu "Excel"), mais qu'il ne veut pas d'une application web ? Le client est un professionnel, mais bon il a peut-être bu un truc périmé ce jour-là, mais que dire du patron qui opine et vous confie ça ?

**wiztricks** · 11/07/2009, 17h33

Envoyé par ypicot

...
En fait ma question est celle-ci : je pense qu'il y a un rapport direct entre la taille du projet et les problèmes générés. Ce n'est pas visible à mon niveau, mais est-ce que certains pourraient confirmer / infirmer ce point ?

Yvan

Tout à fait!
Gros projets = plus ressources = plus personnes qui se pré-occupent de leur bonnes gestion (coûts délais) mais pas nécessairement plus douées dans la gestion des risques ou le management.

Les petits projets passent en général "sous le radar"...
Ils ne sont pas assez gros pour inquiéter qui que ce soit. On peut prendre beaucoup plus de risques sans que ce soit un drame. C'est la taille optimale pour les prototypes géniaux.
- W

**millie** · 11/07/2009, 19h56

Envoyé par 10_GOTO_10

La "maquette" présentée aux clients, qui était en fait un fichier PPS, avec des screenshots bricolés avec paint shop pro. Et fait pas une ligne de code n'avait encore été écrite.

D'où le nom de maquette

EDIT : Ah moins que la maquette était présentée par les commerciaux en tant que produit presque fini et non en tant que maquette ?

**xasmxasm** · 12/07/2009, 09h10

Bonjour,

A je comprends mieux maintenant en fait vos chefs on deux oreilles pour les clients et une bouche pour vous. Vraiment essayer de communiquer dans ce cas avant que votre chef rencontre le client ou bien accompagné le se sera plus simple.

Amicalement

**millie** · 12/07/2009, 09h31

J'espère ne rien apprendre à personne, mais l'intérêt d'une maquette (dans tous les domaines), c'est justement pour avoir une idée visuelle du résultat sans avoir à réaliser le projet.
C'est une technique classique qui peut intervenir assez tôt dans la conception pour donner une idée de l'IHM au client sans avoir à coder (c'est le but), ce qui peut se faire conjointement ou non avec des designers (ça permet donc de définir plus clairement tous les écrans). S'ils ne connaissent pas la technologie, ils donnent souvent des fichiers photoshop.

**10_GOTO_10** · 12/07/2009, 12h18

Envoyé par millie

J'espère ne rien apprendre à personne, mais l'intérêt d'une maquette (dans tous les domaines), c'est justement pour avoir une idée visuelle du résultat sans avoir à réaliser le projet.

Pardon, je me suis mal exprimé. J'aurais dû dire "prototype". En l'occurrence, le projet en question était présenté aux clients comme étant en cours de réalisation, limite au stade de béta-version.

**millie** · 12/07/2009, 12h30

Envoyé par 10_GOTO_10

Pardon, je me suis mal exprimé. J'aurais dû dire "prototype". En l'occurrence, le projet en question était présenté aux clients comme étant en cours de réalisation, limite au stade de béta-version.

D'accord, c'est plus clair maintenant

**xasmxasm** · 12/07/2009, 12h38

Re,

Metalgeek allons que dis tu donc il ne serai ni necessaire de savoir ce que logiciel doit faire ni comment et pourtant il serai réalisable cela fait deux pages que des personnes s'en plaignent et toi tu demontre que cela ne sert à rien.
En ce qui concerne ton appli qui est basé sur un COM entre excel et des bases de données il me semble que c'est le nouveau logiciel qui doit être multi utilisateurs et accesible à distance.

Pourquoi n'essayez vous pas de créer de nouvelles façon de voir les choses plutôt que de passer votre temps à montrer les disfonctionnements?

Seul la peur et le doute empeche d'avancer dans la joie et la bonne humeur.

Amicalement

**millie** · 12/07/2009, 14h54

Je n'ai jamais dit que ça suffisait ?

J'ai juste dit que les maquettes pouvaient intervenir (pouvaient = non systématique et ça dépend du projet) dans la phase de conception pour donner rapidement un aperçu de l'IHM au client, j'ai carrément pas dit que c'était suffisant (ni que ça avait un sens suivant la nature du projet).

**souviron34** · 12/07/2009, 16h14

Envoyé par mister3957

Moi je voudrai seulement être rassuré que ce n'est pas comme ça partout quand même ?

ben pas tout à fait partout !!!

Mais très très très très très très très souvent

Envoyé par wiztricks

Tout à fait!
Gros projets = plus ressources = plus personnes qui se pré-occupent de leur bonnes gestion (coûts délais) mais pas nécessairement plus douées dans la gestion des risques ou le management.

Les petits projets passent en général "sous le radar"...
Ils ne sont pas assez gros pour inquiéter qui que ce soit. On peut prendre beaucoup plus de risques sans que ce soit un drame. C'est la taille optimale pour les prototypes géniaux.
- W

Absolument..

J'ajouterais donc à la liste du premier post :

Un budget de 25 millions d'entrée de jeu
Un délai prévu de 2 ans
Une équipe de 30 personnes ou plus
Une méthodologie complexe, en affirmant vouloir suivre des normes de qualité
Une "fausse" méthodologie agile, où le "Chef" est en fait le commercial
L'usage de concepts "du moment", les derniers "buzz-word" à la mode
La mise aux postes de responsabilité de gens purement administratifs
La mise aux postes de responsabilité de gens purement techniques
La mise aux postes de responsabilité / le choix des technologies / architectures aux "jeunes spécialistes" (le gars qui vient de finir son stage ou son Mastère spécialisé..)
La mise aux postes de responsabilité / le choix des technologies / architectures aux "vieux croûtons" (le gars qui a 25 ans de boîte, toujours dans la même, sur le même soft)

J'en oublie certainement

**benwit** · 12/07/2009, 21h15

Une petite image qui résume ce qui a été dit ...

**souviron34** · 13/07/2009, 00h17

je l'ai en français...

Et ça date...

Mais visiblement, malgré toutes les grandes révolutions que l'on entend à gauche et à droite, rien de bien neuf sous le soleil..

**bartoumi** · 13/07/2009, 15h29

Salut tout le monde

Jusque la, tout le monde parlait de relation entre Client, Commerciaux , Managers et développeur et les incompréhensions entre ses personnes la

Je vous ajoute un petit point :
Votre responsable vous demande d'estimer une charge ou faire une petite étude sur une fonctionnalité a ajoutée (comprenez "Fait moi ça pour Hier").
Ok, vous jouer le jeu. Vous allez faire de votre mieux (surtout en temps de crise)
Vous donnez la réponse suivante : (par exemple) ça prend 10 jours à faire en faisant comme ça.
Le responsable vous répond : 10 jours !!! non vous allez le faire en deux jours (tests y compris).
Que faites vous ?
Vous allez le faire a l'arrache en cinq jour (donc trois jours de retard et de remontrance - et c'est pas facile-)

Et voila le pire : Y'en auras tirs un collègue à vous pour dire (quand vous n'êtes pas la bien sur) qu'il pouvait le faire en une demis journée (c'est du vécu) .
Il passera trois jours à chercher des irrégularité dans votre code pour les montrer aux responsable. Du coup le chef vous demande un compte-rendu avec argumentaire pourquoi vous avez passez cinq jour dessus.
le compte rendu me prendra 1/2 journée a faire + une réunion de deux heure.

Votre collègue ne l'a pas fait contre vous , il veut juste se faire recruter chez le client final (du coup il est prêt a tout)

si on fait le compte j'ai mis 6 jours a le faire (dev+ test + compte rendu et réunion) je reconnais un peu a l'arrache avec des horaire pas possible.

après cela, une ambiance de "lourdeur" vas s'installer dans l'équipe et un nouveau système de management vas s'installer que j'appellerai: MRMF
Management par la Recherche du Meilleur Fayot

Sachant que ce que je viens de décrire se produit a tout les échelons d'une hiérarchie dans une entreprise, je vous laisse imaginer une des grande cause intrinsèque a l'échec de nos projet en gle.

Pour finir, j'ai vu quand même des projet réussir , c'était des projet de moins de trois mois à deux personne Max.

**cherkaoui.j.e** · 13/07/2009, 16h52

Envoyé par koopajah

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

Quel est le problème avec la méthode Agile?

gl · 13/07/2009, 17h45

Envoyé par cherkaoui.j.e

Quel est le problème avec la méthode Agile?

Personnellement je n'ai pas de problème particulier avec les méthodes agiles en tant que telle. Bien au contraire.

Par contre avec le discours qui consiste à dire "utilisons les méthodes agiles pour gagner du temps", j'aurais plusieurs reproches à formuler.

Tout d'abord, même utilisée correctement, les méthodes agiles ne représente pas toujours un gain de temps de développement (généralement, c'est plutôt un gain de réactivité et un gain lors des phases de maintenance et d'évolution) et rarement (pour ne pas dire jamais) un gain de temps à court terme s'il faut tout mettre en place.
Généralement ce type de discours est tenu par des gens qui ont vaguement entendu parler des méthodes agiles et surtout qui n'ont pas pesé toutes les conséquences de leur mise en place. Utiliser une méthode aussi bonne soit elle là où elle n'est pas adaptée n'est clairement pas une bonne idée.

Pour résumer, les méthodes agiles ne sont pas des "silver bullet". Elles ne vont pas résoudre tous les problèmes possibles et imaginables, elles ne sont pas applicables dans tous les contextes et elles ne se mettent pas en place du jour au lendemain en un claquement de doigt.
En particulier, dans un environnement particulièrement "bordélique" et sans qualité, elles ne seront probablement que peu efficaces (et généralement mal appliquées) et ont pour effet pervers de donner bonne conscience aux personnes qui continuent pourtant à aller droit dans le mur.

**souviron34** · 14/07/2009, 10h44

Envoyé par gl

Pour résumer, les méthodes agiles ne sont pas des "silver bullet". Elles ne vont pas résoudre tous les problèmes possibles et imaginables, elles ne sont pas applicables dans tous les contextes et elles ne se mettent pas en place du jour au lendemain en un claquement de doigt.
En particulier, dans un environnement particulièrement "bordélique" et sans qualité, elles ne seront probablement que peu efficaces (et généralement mal appliquées) et ont pour effet pervers de donner bonne conscience aux personnes qui continuent pourtant à aller droit dans le mur.

et de plus elle nécessite au moins en tant que Chef de projet quelqu'un qui a une expérience "large" et si possible très nettement plus large que technique, en particulier d'une longue collaboration avec des utilisateurs..