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

[Neuromancien2]

A vous lire on croirait qu'il n'existe que des projets désastreux, gérés par des chefs de projets incompétents.
Je travaillais pourtant récemment sur un projet sur lequel :

• Il existait une documentation détaillée (spécifications fonctionnelles et techniques, spécifications d'interface, etc.) mise à jour avant chaque évolution;
• Il existait des normes précises pour la réduction des documents et l'écriture de code, en général bien respectées;
• Les développements étaient correctement chiffrés et les délais étaient respectés.
• Les équipes intégraient des débutants et des développeurs plus expérimentés fonctionnellement et techniquement, et connaissant bien le client.

Nous avions un chef de projet expérimenté, qui ne laissait rien au hasard.
Bien sûr, il arrivait souvent que le client change d'avis, ou qu'il soit incapable d'exprimer son besoin. Mais les développeurs avaient des connaissances fonctionnelles et pouvaient parler avec le client pour comprendre son besoin et lui faire des propositions.

Ce n'était pas parfait et les relations avec le client n'étaient pas toujours faciles. Nous avions chez le client des interlocuteurs incompétents et parfois de mauvaise foi. Mais le projet s'est plutôt bien passé...

Je pense que tout se décide très tôt, lors de l'avant-vente, de la définition du périmètre fonctionnel et des clauses du contrat avec le client. Par exemple, il doit être clairement prévu que les évolutions du besoin doivent donner lieu à un nouveau chiffrage.

[pseudocode]

Envoyé par Neuromancien2

A vous lire on croirait qu'il n'existe que des projets désastreux, gérés par des chefs de projets incompétents.

D'un autre coté, le titre de la discussion invite plutôt à parler des échecs cuisants que des réussites dithyrambiques.

[B.AF]

[QUOTE=Neuromancien2;4509244]
Nous avions un chef de projet expérimenté, qui ne laissait rien au hasard.
Bien sûr, il arrivait souvent que le client change d'avis, ou qu'il soit incapable d'exprimer son besoin. Mais les développeurs avaient des connaissances fonctionnelles et pouvaient parler avec le client pour comprendre son besoin et lui faire des propositions.
[QUOTE]

Bah oui, mais ça ça coute cher et beaucoup de boites dans l'IT qui est perçu comme un centre de coût font dans l'économie et donc crée des usines à process en faisant des armées mexicaines.

En quelques lignes tu as résumé : tout se passe bien quand le circuit de la connaissance est fluide et les gens compêtents.

Moi je n'ai jamais d'ailleurs compris pourquoi tant de DSI se plaignent des échecs de l'offshoring, des plateformes et autres basecamps : je ne comprendrai jamais comment des gens non formés juste avec une norme et un processus et une approche technique peuvent designer une application métier à forte valeur ajoutée, et comment d'autres peuvent croire que c'est possible. C'est souvent la cause principale d'échec : plus il y a de couches, plus les itérations coûtent, plus les itérations coutent plus les tests coutent, plus les tests coutent plus la livraison est longue, plus la livraison est longue plus la marge réduit.

[atc666]

je pense qu'il ne faut pas perdre de vue que si on crée une société ou si on travaille tout court ce n'est pas trop pour le plaisir de travailler ... donc c'est pour l'argent qu'on bosse tous non ?
donc l'argent premier point important de tout projet , cela me semble assez logique.
le client n'est pas toujours conscient de ce que vaut vraiment ce qu'il désire , et souvent a un budget qu'il ne veut pas dépasser ...
le boss de la société qui va tenter d'écrire le soft lui il veut payer son personnel et faire du benef ... logique aussi
le programmeur lui veut ne pas travailler 60 heures et être payer 35 ... normal aussi
que faire ?

Je dirai choisir un programmeur comme commercial ou du moins un commercial qui a "tâté" de la programmation (ou au moins lui imposer de passer un moment avec les programmeurs pour se familiariser a notre monde)
cela devrai déjà permettre de mieux situer le projet dans sa difficulté.
pour le patron éviter peut-être de travailler pour un patron pour qui un pc sert a lire son courrier point barre...( la je suis gentil , j'aurai pu dire sert a donner l'impression qu'il sais s'en servir ... riez pas j'en ai déjà vu)
et si le boss est dans cette situation , ben à lui de prendre la décision d'engager un adjoint qui lui aura des compétences minimales en informatique
ET SURTOUT DE L'ÉCOUTER

[wiztricks]

Envoyé par atc666

je pense qu'il ne faut pas perdre de vue que si on crée une société ou si on travaille tout court ce n'est pas trop pour le plaisir de travailler ... donc c'est pour l'argent qu'on bosse tous non ?
donc l'argent premier point important de tout projet

oui et non: je travaille en échange d'un salaire qui me permette d'avoir une vie décente et dont le montant soit comparables à celui d'autres employés/cadres/... à qui on donne le même type de responsabilité.

L'entreprise qui m'emploie transforme des produits ou effectue des services dans lequel je suis un des 'acteurs'. L'entreprise n'est viable qu'à partir du moment ou elle est capable de produire et dégager suffisamment de bénéfices pour investir, évoluer,...

Derrière un projet informatique, il y a une entreprise qui investit pour produire plus, moins cher,... ou qui remet à jour son outil de production - comme on refait la peinture de temps en temps.
Si on investit, c'est dans l'espoir fondé pour que çà rapporte le plus rapidement possible. Si un investissement de estimé à 100 ne rapporte que dans 12 mois, il est tentant de trouver la SSII qui prétendra faire le boulot pour 50 sans oublier d'évaluer le risque qu'au bout du compte la facture pourrait être de 150.

Si dans chaque cas, nous parlons d'argent, de monnaie... le contexte "temps" qui lui est associé change profondément sa nature.
-W

[wiztricks]

Envoyé par pseudocode

Dans l'entreprise, l'esprit d'équipe est souvent ce qui permet de sauver un projet, permettant aux dirigeants d'être félicités avec une prime et aux développeurs d'être félicités avec un petit mot gentil.

C'est vrai.
Mais je peux t'assurer que dans la plupart des projets en crise ou il m'est donné d'intervenir, et lorsque c'est justifié, je fais en sorte que l'équipe soit remerciée de façon significative et que les responsables aient à revoir leur plan de carrière.
-W

[wiztricks]

Envoyé par B.AF

Moi je n'ai jamais d'ailleurs compris pourquoi tant de DSI se plaignent des échecs de l'offshoring, des plateformes et autres basecamps : je ne comprendrai jamais comment des gens non formés juste avec une norme et un processus et une approche technique peuvent designer une application métier à forte valeur ajoutée, et comment d'autres peuvent croire que c'est possible. C'est souvent la cause principale d'échec : plus il y a de couches, plus les itérations coûtent, plus les itérations coutent plus les tests coutent, plus les tests coutent plus la livraison est longue, plus la livraison est longue plus la marge réduit.

Ces deux dernières semaines, j'ai eu à traiter un problème grave.

Dans le diagramme des "causes" :

• "culture opérationnelle du DSI insuffisante pour lui permettre d'identifier risques et palliatifs appropriés".
• "forte autorité n'aimant entendre que ce qu'elle a envie d'entendre"
• "interventionnisme contre-productif"
• "préférence à s'entourer de flatteurs et à placardiser chefs de projets et architectes expérimentés".

Le projet avait pour but de réduire la quantité de rebus produits par une chaîne de production. Qui dit "rebus", dit "refaire" + délais plus charge sur le système technique.

La solution avait été pensée sur un coin de table par des religieux: techniquement indéboulonnable mais délicate a mettre en place sous la forme d'une évolution des applications existantes(*).
(*) dans le contexte, il aurait été plus sage de ré-écrire l'appli mais bon.

Indéboulonnable signifie aussi qu'il va falloir que la bête se fatigue avant que vous puissiez présenter un plan B. Un plan B est une solution acceptable que vous pourrez mettre en place en quelques heures. Le plan A est la solution qui a été vendue au client mais tellement mal pensée que vous êtes certain de ne pas l'avoir terminée avant plusieurs semaines.

Mais comme cela fait quatre semaines qu'ils se croient à une semaine du but, ils pensent encore que c'est une question de nombre de personnes alors que c'est un vrai pb de conception.

Il va falloir être habile, trouver des arguments "simples" pour convaincre sans s'enterrer dans des explications techniques que personne ne comprendra.
Note: Si personne comprend, c'est pas vendu ;-(
Que faire?

• Soyez patient, favoriser l'installation du doute...
• Restez modeste. Vous y croyez au mec qui arrive avec une solution qui marche du premier coup alors que vous vous échinez depuis des semaines à çà? J'aime bien mes idées mais je ne suis pas Dieu. Si vous voulez remettre en route l'esprit critique des bonshommes pour qu'ils 'testent' l'inconcevable que vous allez leur proposer, il faut qu'ils reprennent de la hauteur... qu'ils lèvent le nez de leur guidon: ils connaissent mieux les pièges que vous.
• Choisir l'heure pour lancer votre tomahawk. Personnellement, j'aime bien faire çà le soir. L'heure à laquelle l'équipe est désabusée... ils sont réceptifs et surtout les neurones çà bosse à plein tube quand on dort.
• A l'aube vous avez du boulot: est ce une bonne idée? Ou sont les pièges?

Bingo.

Comment cela traite le problème DSI? dommages collatéraux!

Plutôt que de la jouer 'zorro', j'ai opté pourrissement en immobilisant de façon indéterminée nombre de ses ressources critiques. Tous les autres projets attendent et prennent du retard. Son équipe projets étant dirigée par une brêle, ils vont mettre du temps avant de réaliser l'ampleur des dégats.


Notre brave monsieur va donc devoir:

• quelques explications aux métiers - il a l'habitude mais à force çà lasse -
• tancer les flatteurs qui lui ont chanté les qualités du sous traitant à qui le projet a été confié

Rien de mortel, juste agaçant. En espérant qu'il lui reste l'intelligence de remettre en cause nombre d'options.

Dans les deux cas, vous l'avez sorti de la mouise: vous êtes un héros.

-W

[B.AF]

Envoyé par wiztricks

Ces deux dernières semaines, j'ai eu à traiter un problème grave.

Dans le diagramme des "causes" :

• "culture opérationnelle du DSI insuffisante pour lui permettre d'identifier risques et palliatifs appropriés".
• "forte autorité n'aimant entendre que ce qu'elle a envie d'entendre"
• "interventionnisme contre-productif"
• "préférence à s'entourer de flatteurs et à placardiser chefs de projets et architectes expérimentés".

Tu as juste rencontré un cadre sup dans une entreprise française. Nous sommes la démonstration, voir une réserve naturelle dy syndrôme de petter.

Le pb en france, c'est qu'on ne différencie pas entrepreneur et cadre supérieur.

[souviron34]

Envoyé par B.AF

Le pb en france, c'est qu'on ne différencie pas entrepreneur et cadre supérieur.

si c'était le seul

• Il y a aussi que un "cadre" (notion typiquement française) ne s'abaisserait pas à mettre les mains dans le cambouis
  
  
• Il y a aussi qu'un poste est un titre, en France, et non pas un grade
  
  
• Il y a aussi qu'un titre est un titre, pas une position dans la pyramide, faisant que l'on doit gérer ce qui est en dessous.
  
  
• Il y a aussi que , vu dans cette optique, un "supérieur" n'est jamais jugé pas ses "inférieurs", ce qui est courant en Amérique du Nord..

Et j'en passe pas mal

[B.AF]

Envoyé par souviron34

si c'était le seul

• Il y a aussi que un "cadre" (notion typiquement française) ne s'abaisserait pas à mettre les mains dans le cambouis
  
  
• Il y a aussi qu'un poste est un titre, en France, et non pas un grade
  
  
• Il y a aussi qu'un titre est un titre, pas une position dans la pyramide, faisant que l'on doit gérer ce qui est en dessous.
  
  
• Il y a aussi que , vu dans cette optique, un "supérieur" n'est jamais jugé pas ses "inférieurs", ce qui est courant en Amérique du Nord..

Et j'en passe pas mal

Ah oui....Je me rappelle la tronche d'un gars à qui j'ai du expliquer un jour que la légitimité d'un manager était la crédibilité que lui accordait son équipe.....

[souviron34]

Envoyé par B.AF

Ah oui....Je me rappelle la tronche d'un gars à qui j'ai du expliquer un jour que la légitimité d'un manager était la crédibilité que lui accordait son équipe.....

yes

Les fameuses "évaluations annuelles", que j'ai eues lorsque je travaillais au Canada, n'étaient pas seulement la mise sur la papier des points forts ou faibles ou à améliorer de moi (par exemple) avec mon (son) supérieur, mais également il y avait un paragraphe entier pour mon jugement de son activité ou attitude.

Ces évaluations, rassemblées par le supérieur de mon supérieur, ou la DRH, sont prises en compte à leur tour pour l'évaluation annuelle de mon supérieur..



Le dernier rang d'en haut, le PDG, est quant à lui évalué par le CA..

[B.AF]

Pour ça je reconnais qu'on sent que l'époque de la noblesse, du clergé et de la bourgeoisie, c'est encore très présent dans notre culture....

Le clergé, ce sont les organismes de formation
La bourgeoisie, la légion de cadres qui veulent être nobles
La noblesse, nos bonnes vieilles "élites" où les bandes de potes hauts fonctionnaires, franc macs et inspecteurs des finances...

Bah oui, ça bouge pas vite la France...C'est pire que le chiendent : tu les décapites, ça repousse pareil 250 ans plus tard et maintenant, tu peux plus rien faire...

[yorukaze]

Envoyé par pseudocode

Pour rappel : Le projet "Cauchemar"

On a pas bossé dans la meme boite? Ha nan en fait mon "patron" était incapable de faire autant de chose(c'est pour dire), on avait un consultant a chaque fois différent sur la période de conception/Cdc/dev, un turn over énorme, donc au final toi petit dev avec 3moi dans la boite tu te retrouves a etre chef de projet et tenter d'expliquer un projet que tu ne comprends pas totalement à des stagiaire (oui parce que les employés coutent cher, donc tu prends 2employés et 8stagiaires ...)
Bon vent ma fois

[yoyo88]

un turn over énorme, donc au final toi petit dev avec 3moi dans la boite tu te retrouves a etre chef de projet

Qui a dit que l'évolution dans l'entreprise est longue?


Perso je pense que c'est dans les Projet cauchemar qu'on voit qui a les reins solide pour mener a bien a projet. (d'ailleurs c'est valable dans tous les domaines pas seulement l'informatique)

[chaplin]

Envoyé par yoyo88

Perso je pense que c'est dans les Projet cauchemar qu'on voit qui a les reins solide pour mener a bien a projet. (d'ailleurs c'est valable dans tous les domaines pas seulement l'informatique)

Curieusement, ce sont ceux qui ont la plus grande conscience professionnelle qui se cassent la gueule en premier. Ensuite, il y a ce don que certains ont pour pouvoir mentir et ceux là s'en sortent très bien, à parfois devenir une qualité pour ne pas dire une vertue dans certains métiers, plus précisement certains postes.

[lam7a]

Envoyé par yoyo88

Qui a dit que l'évolution dans l'entreprise est longue?


Perso je pense que c'est dans les Projet cauchemar qu'on voit qui a les reins solide pour mener a bien a projet. (d'ailleurs c'est valable dans tous les domaines pas seulement l'informatique)

Oui mais le problème est double, tout d'abord t'attends pas à ce qu'on reconnaisse la solidité de tes reins et ensuite tu peux être sûr que tous les projets Cauchemar par la suite seront pour ta pomme...

Pour en revenir au sujet, tout est une question de mentalité. Je sais pas pour vous mais dans ma SSII, à chaque fois qu'on m'a envoyé sur un projet c'était avec une tape dans le dos et vas-y mon gars on compte tous* sur toi. T'as beau dire: ouais mais moi je connais pas cet techno, ce framework, cet outil... La réponse est toujours la même: Tu vas monter en compétence... Ok, mais c'est prévu dans le planning ça??? non... ok!

Ensuite, pour répondre à ceux qui compare notre métier à celui du bâtiment, je dirais juste une chose. Quand on construit un immeuble, on fait appel à à des maçons, des électriciens, des plombiers, des couvreurs, etc... Vous voyez où je veux en venir? Sur nos projets info pour des raisons purement financière, on préfère envoyer de jeunes stagiaires au casse-pipe. Je regrette on peut pas être un pro partout, design, méthode, orm, bdd, sécurité, cuisine, football, etc...
Si l'un de vous a déjà réussi à faire intervenir un expert Hibernate/Spring/Websphere/skevouvoulé, ou obtenir une formation pour son équipe en début de projet qu'il me donne la recette... moi j'ai jamais réussi... et on n'a compris ma demande qu'au moment où le projet a commencé à tourner de l'oeil et à sombrer dans un coma très profond...


*Le dirlo, le com' et la compta...

[yoyo88]

Curieusement, ce sont ceux qui ont la plus grande conscience professionnelle qui se cassent la gueule en premier. Ensuite, il y a ce don que certains ont pour pouvoir mentir et ceux là s'en sortent très bien, à parfois devenir une qualité pour ne pas dire une vertue dans certains métiers, plus précisement certains postes.

Oui c'est sur que les "grandes gueules" s'en sorte souvent très bien alors qu'il ne sont pas forcement les meilleurs. C'est d'ailleurs souvent pour caché leurs incompétence qu'il se mette en avant. (exemple de l'utilisateur de mauvaise fois)
Cependant les supérieurs ne sont pas dupe, loin de la. Quelqu'un qui a de bonne idée et qui sait les exposer un forcement un élément qu'il faut gardé. (enfin en principe... puisqu'en pratique c'est plus la personne qui sais imposés ses idée qui monte)

En réalité je pense que sa dépend plus de la boite ou l'on bosse, si c'est une boite où le developpement de logiciel n'es pas une des activité principal, alors oui ceux qui monte ne sont pas forcement les meilleurs.

(enfin c'est mon avis de jeune informaticien qui decouvre le monde merveilleux du travail... d'ici quelque années j'aurrai sans doute perdu mes illusions )

[rakakabe]

J'ajoute a la liste mon propre experience (il s'agit d'un projet en interne):

- Lorsqu'on prefere le jeu individuel au sport d'equipe (fais ton boulot et fous moi la paix ..., et surtout pas touche a mon job);
- Lorsque le projet est developpe en secret sans que l'utilisateur final n'est au courant de rien.

Les consequences :
1 - les tests sont en retard car le decideur n'a pas le temps
2 - l'utilisateur lambda va refuser le soft car on n'a pas demande son avis ! et plouf

[pseudocode]

Envoyé par rakakabe

- Lorsque le projet est developpe en secret sans que l'utilisateur final n'est au courant de rien.

??

Faut vraiment avoir du temps/argent à perdre pour développer un soft sans demande du client (ou etude marketing).

[benwit]

Envoyé par pseudocode

??

Faut vraiment avoir du temps/argent à perdre pour développer un soft sans demande du client (ou etude marketing).

J'ai déjà vu également ...
disons que celui qui commande l'appli n'est pas l'utilisateur final ... c'était un chef qui veut tel et tel fonctionnalité pour se vanter d'avoir une application qui fait tel ou tel truc mais l'outil est imposé à des utilisateurs (du coup, les gens qui connaissent le métier ne veulent pas l'utiliser ... et on embauche des jeunes fonctionnels en cdd qui ne connaissent pas le métier pour utiliser le truc ... mais comme au bout d'un moment, ça les gave, il y a un turn over important)