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

Mais au fait, qu'entend-on par échec d'un d'un projet informatique ?? :koi: Dépassement des budgets ? Dépassement des délais ? Insatisfaction des utilisateurs ? Rejet par les utilisateurs ? Abandon du projet en cours de réalisation ? Abandon uniquement de certaines fonctionnalités ? Coûts de maintenance plus élevés que prévu ? ...

On voit, en effet, qu'un projet peut rencontrer des difficultés plus ou moins graves. Il y a celles qui font que le projet va moins bien se dérouler que prévu et celles qui vont carrément faire mourir le projet.

Est-ce que koopajah qui a ouvert la discussion pourrait nous apporter des précisions ce qu'il entend par échec d'un projet de développement logiciel ?

Pour ma part, tous les projets auxquels j'ai participé ont connu diverses difficultés en cours de route mais tous sont parvenus en Prod un jour. Certains faits rencontrés m'ont particulièrement choqué mais jusqu'à présent j'ai eu la chance (:?) d'avoir travaillé avec des responsables capables de "redresser" (de manière pas toujours orthodoxe :aie:) les situations de "crise".

Citation:

---

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.

---

Pourquoi devrait-on laisser son estimation de la charge de travail bafouée sous prétexte que nous sommes en temps de crise?
A t-on le droit de voir son travail renié alors que l'on nous a pas laissé le temps nécessaire.
Je pense que ton collègue est assez malin pour choisir les personnes à dénigrer et que tu devrais changer d'attitude faire à l'estimation de tes compétences et ne pas de laisser marcher sur les pieds.

Tu n'aimes pas lire ces lignes mais rappel toi tes ressentiments lors que tu as vécu ce que tu nous as écrit.


Amicalement

Un classique qui en rajoute très souvent une bonne couche supplémentaire et qu'on découvre lors de la première livraison :
les utilisateurs du produit final ont été complètement oubliés par les spec : leurs besoins et leur mode d'utilisation du logiciel (pourtant relié à la performance globale du logiciel) seront à considérer dans une version future (voire futuriste) ...:)

Dire que quand j'etais a l'ecole on nous mettait en garde contre les mauvaises conceptions, les conceptions inexistantes, que dans un bon programme le developpement ne representait qu'une partie infime (il me semble que la conception est pour plus de moitie)...

Aujourd'hui on a largement simplifie le truc: pas de conceptions, pas de tests, on code en live, les utilisateurs viennent nous voir pour des changements, la direction pour d'autres (bien sur tout le monde en meme temps et en s'etonnant que cela puisse prendre plus de cinq minutes)... Les demandes sont faites individuellement, la main gauche ne doit SURTOUT pas savoir ce que fait la main droite, sous peine de donner un semblant de cohesion au developpement.

Bien sur il n'existe aucune specification en matiere de developpement (ce serait trop facile), et chacun code un peu comme il a appris, avec ses propres specifications.

Cela fait plusieurs entreprises ou je constate le meme chaos dans le domaine du developpement. Alors des petits genies ont decide, pour credibiliser le machin de lui donner un nom. L'extreme programming etait ne...

Citation:

---

Pourquoi devrait-on laisser son estimation de la charge de travail bafouée sous prétexte que nous sommes en temps de crise?
A t-on le droit de voir son travail renié alors que l'on nous a pas laissé le temps nécessaire.
Je pense que ton collègue est assez malin pour choisir les personnes à dénigrer et que tu devrais changer d'attitude faire à l'estimation de tes compétences et ne pas de laisser marcher sur les pieds.

---

En temps de crise ou non généralement les gens se taisent a tort ou a raison.
Sauf quand c'est pas la crise on change rapidement de boite/projet

Citation:

---

Tu n'aimes pas lire ces lignes mais rappel toi tes ressentiments lors que tu as vécu ce que tu nous as écrit

---

je me le dis tous les matin ce que tu vient d'écrire
Par expériences je trouve que c'est un peu partout pareil , c'est les noms de personnes/projet/entreprise qui changent.

Citation:

---

Cela fait plusieurs entreprises ou je constate le même chaos dans le domaine du développement. Alors des petits génies ont décidé, pour crédibiliser le machin de lui donner un nom. L'extreme programming etait ne..

---

j'ai apprécié cette réflexion parce que généralement une boite pour ce donner une bonne conscience utilise ce genre de termes :D

Un autre signe :
quand le chef de projet, qui n'a plus codé depuis 20 ans et ne codera jamais plus, est la seule personne suivant une formation sur la nouvelle technologie que personne dans l'équipe ne maîtrise et que l'on va utiliser sur notre projet hi-tech.

Citation:

---

Envoyé par nlegriel

[b]Pour ma part, tous les projets auxquels j'ai participé ont connu diverses difficultés en cours de route mais tous sont parvenus en Prod un jour. Certains faits rencontrés m'ont particulièrement choqué mais jusqu'à présent j'ai eu la chance (:?) d'avoir travaillé avec des responsables capables de "redresser" (de manière pas toujours orthodoxe :aie:) les situations de "crise".

---

Je ne pense pas que "c'est en prod" soit le seul critère excluant l'échec.

Citation:

---

Envoyé par mister3957

Je ne pense pas que "c'est en prod" soit le seul critère excluant l'échec.

---

Bien sûr ! J'ai déjà vu un projet déclencher la colère des clients et des dirigeants une fois mis en prod (alors que nous étions régulièrement félicités et encouragés durant les premières étapes de développement).

Cependant, comme le projet consistait en du "service internet", nous avons pu rectifier les applicatifs après coup :aie: et faire survivre le projet. Ce ne fut pas sans douleurs.

Citation:

---

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

---

Pas partout, mais presque. Dans la boite où je suis actuellement, ça ne se passe pas non plus de maière parfaite (je ne pense pas que ça existe), mais ça ne se passe pas trop mal. On édite un site de partage photo. En tant que responsable de la partie serveur (en JavaEE, sur laquelle vient se connecter un client Flex), je peux librement faire mes choix technologiques, analyser et concevoir les fonctionnalités. Parfois, les exigences du marketing font que les priorités changent, ou que les fonctionnalités évoluent, mais dans l'ensemble, on arrive à garder ce type de changement sous contrôle, et surtout, tout le monde est bien conscient de l'impact sur les délais qu'ils ont. En 2 ans et demi, on ne m'a jamais reproché de prendre trop de temps pour un projet. Et ça marche ! Je suis plutôt fier de ce qu'on a fait, franchement. Et c'est pas loin d'être la première fois depuis que je suis dans le métier...

La boite où j'étais avant, j'étais chef de projet. Un projet de site de partage de vidéos. Epouvantable. En fait de chef de projet, je me suis surtout retrouvé en train de faire du développement 15 heures par jour, parce que le cahier des charges évoluait toutes les heures à peu près, et qu'on ne pouvait rien y faire, puisque le directeur marketing qui croyait faire sa liste au père Noël était un pote de promo HEC du patron, qui bien entendu n'écoutait absolument ce qu'on lui disait, même sur le plan technique. Pas moyen de "gérer" quoi que ce soit quand une bonne partie du travail d'aujourd'hui consiste à défaire le travail de hier et à le refaire différemment. Le tout dans une ambiance délétère. Pas le pire souvenir de ma vie professionnel, mais presque. 6 mois en enfer. Et un résultat dont je suis très loin d'être fier, là, par contre. Et je passe sur la partie où j'étais supposé faire trimer 50 heures par semaine des stagiaires payés 600 euros par mois (bac +5, hein), les délais impossibles à tenir qu'on rallonge au dernier moment, ce qui empêche toute planification correcte et tout travail un peu soigné...

Citation:

---

Envoyé par william44290

il me semble que par définition tous les projets sont voués à une forme plus ou moins prononcée d'échec.

---

Pas mal. La logique floue appliquée à l'évaluation d'un projet, c'est une idée intéressante ! :D

Un truc issu de mon expérience, en tout cas : ne pas approuver sous la contrainte ce qu'on désapprouve en fait. Quand votre supérieur hiérarchique, le client ou le service marketing vous impose un délai trop court, on ne peut pas vous empêcher de le dire. Ensuite, il faut ajouter un truc du style " puisque on n'a que 1 mois, on essaiera de tenir de délai, mais selon moi, c'est trop court, il en faudrait 3". Faute de quoi, on vous balancera FORCEMENT à la gueule que vous étiez d'accord avec le délai quand ça va commencer à merder. D'une manière générale, il ne faut pas se solidariser avec les décisions qu'on désapprouve. Les "managers" (bureaucrates, en fait) cherchent souvent à susciter ce type de comportement, histoire d'avoir quelqu'un à qui faire porter le chapeau pour se couvrir, et il n'est pas facile de résister à la pression, mais ça se terminera toujours à votre désavantage si vous cédez !

Tout à fait, il faut donner votre avis, voir même le noter par écrit...
Si vous présentez la chose calmement, poliment, et de façon argumentée logiquement personne ne pourra vous en vouloir, ou alors votre management est gravement malade.

Parce que si vous ne le faites pas il y aura toujours une espèce de manager politicien qui trouvera le moyen de se blanchir et de mettre la totalité du poids de l'échec du projet sur votre dos :aie:

Après vous faites ce qu'on vous dit de faire mais au moins vous aurez prévenu officiellement avant...

Citation:

---

Envoyé par mister3957

J'ai remarqué également un autre "fléau", celui ci interne. C'est cette peur qu'un employé apporte quelque chose afin que l'entreprise devienne dépendant de ses travaux et que par conséquent celui-ci devienne indispensable et garantisse sa sécurité d'emploi. De ce fait, l'entreprise n'est ouverte à aucune proposition des "ouvriers", créative ou non, évolutives ou non, rentable ou non, et en reste à ses méthodes soit disant "fiables". Vous avez déjà rencontré ce genre de problème ?

---

:ccool:

Citation:

---

La COMMUNICATION

---

On a beau invente les telephones, internet, mail, chat, reseau social, ... mais on ne sait toujours pas comment se communiquer :aie:.

Citation:

---

Envoyé par rakakabe

On a beau invente les telephones, internet, mail, chat, reseau social, ... mais on ne sait toujours pas comment se communiquer :aie:.

---

:ccool:

je dirais même de moins en moins...

Entre le "politiquement correct", la "modernité", la "vitesse", et le fait de n'être plus face à face, et de ne guère plus avoir le droit de ne pas être d'accord avec la "tendance générale", ça va de plus en plus mal, à mon avis, de ce côté-là...

Des signes qui ne trompent pas
Véridique :

Demande utilisateur : Se transférer des fichiers entre eux ( du genre Skype ou MSN :P )
Version de l'architecte technique : Faire un gestionnaire de version compatible WebDAV. (8O)
Mise en oeuvre : La stagiaire commerciale chargé du marché Chinois développe (conçoit et code) ce projet (avec Eclipse pour J2EE pour info) . :calim2:

Je vous laisse deviner le résultat et à quelle niveau il y a eu un blocage (Attention pas facile de trouver :mrgreen:).

Citation:

---

Envoyé par Pierre Louis Chevalier

Tout à fait, il faut donner votre avis, voir même le noter par écrit...
Si vous présentez la chose calmement, poliment, et de façon argumentée logiquement personne ne pourra vous en vouloir, ou alors votre management est gravement malade.

Parce que si vous ne le faites pas il y aura toujours une espèce de manager politicien qui trouvera le moyen de se blanchir et de mettre la totalité du poids de l'échec du projet sur votre dos :aie:

Après vous faites ce qu'on vous dit de faire mais au moins vous aurez prévenu officiellement avant...

---

Vécu, à partir de là on sait que personne n'écoute donc on s'exprime puisqu'on sait qu'on ne changera pas le monde.

En dix ans, j'ai travaillé sur des projets de toutes sortes comme développeur et pseudo chef de projet. Les projets sur lesquels j'ai bossé diffèrent au niveau des technologies, des ressources, du budget et de la taille du projet (6 mois à trois, 12 mois tous seul, 2 ans à 15, etc ...) J'ai connu pratiquement toutes les situations décrites précédemment. Pas de besoins, pas de specs, pas de temps, des bras cassés, de gros problèmes principalement politique et rarement techniques.

Je penses qu'un projet peut vraiment démarrer et arriver à termes dans les délais impartis/négociés quand le périmètre global du projet est clairement défini et validé à la fois par le client, la moa et la moe (s'il la taille du projet en impose). Il faut dans les grandes lignes dire ce que le projet fera, et surtout, ce qu'il ne fera pas, fonctionnellement et techniquement. Des spécifications faites à la volée peuvent remettre en cause les choix techniques et/ou d’infrastructures qui ont été faites au départ.

En tant que développeur, il faut bien faire la distinction entre les évolutions, la maintenance et les corrections de bug. Cela peut permettre d’éviter de se faire exploité par sa hiérarchie. La communication est primordiale, mais il faut limiter au maximum les interlocuteurs. Cela peut être le client final, le commercial, la moa ou le chef de projet. En cas de specs, il faut les réécrirent et les faire valider, sinon faire des propositions si le besoin existe.

Je peux confirmer que l'apparence de l'IHM est très importante. Dans ce monde ou tout est une question de marketing, il est souvent plus facile de rassurer le client sur les délais si l'interface en met plein les yeux (Malheureusement c’est comme ça, mieux veut une belle boite vide qu’une moche avec un truc utile dedans).

Pour terminer je dirais également que la simplicité doit être la stratégie globale quelques soit les besoins. Un bon projet si complexe soit-il fonctionnellement doit s'appuyer sur un ensemble de modules/bibliothèques/fonctions qui doivent être courtes, simples et efficaces et quand on aime travailler en équipe, c'est un devoir de s'adapter aux compétences, à la rapidité et à la personnalité des différents intervenants.

Bonjour,


Je suis content que de nouvelles personnes comprennent que lorsque l'on fait partie d'une équipe on ne peut pas se mettre hors du cercle pour mieux le critiquer.
Aujourd'hui je sortais du parking en voiture et fait inhabituel il y avaient deux utilitaires de chaque côté qui m'empêchait de voir la rue. Je n'avais pas de visibilité à droite et à ma gauche à l'arrière de l'utilitaire se trouvait une personne qui se collait à l'utilitaire pour me laisser passer.
J'ai décidé de passer en me concentrant sur la personne de gauche pour ne pas la toucher lorsque j'étais passé j'ai tourné la tête pour m'apercevoir qu'une voiture était juste devant moi et que je m'étais suffisamment avancé pour la touchée.
Cette situation n'aurait jamais dû avoir lieu car j'aurai dû attendre que la personne derrière le camion se soit dégagé avant de m'engager ce qui m'aurait permis de me concentrer sur ma droite alors j'aurais parfaitement vu la voiture arrivée.

Lorsqu'une situation arrive alors qu'elle aurait pu être évitée il faut essayer de savoir où l'on a fait une erreur afin que cela ne se reproduise pas on ne peut pas être acteur d'une action même si l'on est pas seul et en faire porter la responsabilité aux autres intervenants. Un supérieur hiérarchique est une personne humaine qui peux mal juger une situation et si l'on s'en aperçoit on se doit de lui faire savoir (pas forcement devant tout le monde à définir suivant l'urgence) et s'il n'ai pas capable de s'en apercevoir on se doit de trouver une solution quitte à trouver une autre personne en dehors du groupe.

Amicalement

Toujours plus haut.

2617

Pour ma part, j'ai surtout eu l'impression qu'émettre des idées qui pouvaient provoquer des bouleversements irréversibles (comme la création d'un cahier des charges, AVANT la conception (elle-même inexistante) et le développement, puis faire des tests et créer une phase de déploiement, ou même créer des spécifications techniques, voire appliquer la norme AFNOR (encore un gros mot)) posaient des problèmes aux utilisateurs finaux et a une partie de l'équipe qui ne comprennent pas que développer a l'arrache (surtout dans le domaine du web, qui a été malmené par les déclarations fumeuses des éditeurs comme Microsoft), c'est l'échec assuré.

Et encore... Il faut voir notre programme après 5 ans de non-analyse, de non-conception et de changements dans tous les sens (on a bien tenté d'y apporter des améliorations, mais c'est peine perdu.)!!!

La dessus, cerise sur le gâteau, convocation du Directeur : "on arrête tout, les utilisateurs ne sont pas contents, on va optimiser le truc pour rendre ca plus rapide. Par contre, tout doit rester comme c'est aujourd'hui et les utilisateurs ne veulent pas fractionner les pages". Comprenne qui pourra...

Citation:

---

Envoyé par Excellion

La dessus, cerise sur le gâteau, convocation du Directeur : "on arrête tout, les utilisateurs ne sont pas contents, on va optimiser le truc pour rendre ca plus rapide. Par contre, tout doit rester comme c'est aujourd'hui et les utilisateurs ne veulent pas fractionner les pages". Comprenne qui pourra...

---

C'est un directeur qui écoute et qui veut une solution.
C'est un poste qui n'a pas forcément un beau rôle et s'il convoque, c'est qu'il y a un gros problème de communication dont tu n'es pas le responsable vu les idées que tu as proposé et les utilisateurs ont aussi leur part de responsabilité.