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

[wiztricks]

Envoyé par pseudocode

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

Les cas ou cela peut faire sens sont par exemple dans les activités d'évaluation.

On sait que dans X mois la boite aura besoin de... et on cherche les moins mauvaises technos qui pourraient être utilisables.

Il ne fait pas y jeter beaucoup d'argent mais bien construite ce genre de démarche permet (parfois) de mieux formuler ses besoins: définir ce qu'on veut ou pas en se mettant en situation... quitte à tout jeter plus tard.
C'est souvent préliminaire à un POC (proof of concept).

Ça craint lorsque les objectifs ne sont pas communiqués aux bonshommes qui grattent: ils y croient, ils font de leur mieux mais les objectifs fluctuent en fonction des retours sans qu'ils sachent vraiment quel rôle ils jouent.

Ceci dit, pour un projet dont la réalisation prend 6 à 12 mois - moment ou les prestataires d'une SSII réalisent - vous pouvez avoir 1 à 3 fois ce temps passé en phase d'avant-projet...

Et le nombre de 'projets' qui meurent dans cette étape est monstrueusement supérieur à ceux qui passent en réalisation.
(et c'est normal)

-W

PS: j'insiste mais... tant qu'on ne saura pas mieux délimiter les contours d'un projet informatique, il sera difficile voire illusoire de parler de réussite ou d'échec. Et je reste convaincu que, dans la majorité des cas, ces contours ne peuvent qu'être "flous" car ils sont relégués à n'être que les instruments de dessins qui leurs sont étrangers.

Derrière, bien caché, il y a peut être matière à débat sur la maturité des technologies et des savoirs faire pour réaliser de façon sûre.
Et la réponse est non, nous ne savons pas encore... et nous sommes loin d'avoir acquis la maturité atteinte dans d'autres industrie pour que cela change rapidement.

Note: Un avion s'écrase et toute l'industrie aéronautique profite des découvertes faites pour améliorer la qualité et les procédés de fabrication.
=> existence d'agence gouvernementales qui collectent et transforment les informations pour qu'elles puissent être utilisables.

Si on doit échanger 200000 simulateurs cardiaques parce que 'bug' dans le soft, on fera cela en catimini histoire de ne pas affoler les foules mais globalement la collectivité en profitera peu.

[souviron34]

Envoyé par wiztricks

PS: j'insiste mais... tant qu'on ne saura pas mieux délimiter les contours d'un projet informatique, il sera difficile voire illusoire de parler de réussite ou d'échec. Et je reste convaincu que, dans la majorité des cas, ces contours ne peuvent qu'être "flous" car ils sont relégués à n'être que les instruments de dessins qui leurs sont étrangers.

C'est d'ailleurs en gros ce qu'on avait dit dans le thread "Les bonnes pratiques"...

• Le vrai succès d'un projet est quand les utilisateurs finaux l'utilisent et en sont contents..
  
  
• Le vrai échec est quand ils ne s'en servent pas, ou, si ils y sont obligés, n'arrêtent pas de râler contre...

[benwit]

Envoyé par souviron34

Le vrai échec est quand ils ne s'en servent pas, ou, si ils y sont obligés, n'arrêtent pas de râler contre...

Quand un développeur râle après un framework et traîne des pieds pour l'utiliser, c'est ?
A) qu'il est incompétent et devrait suivre une formation à l'utilisation de ce framework.
B) qu'il est utilisateur de cette boite noire non intuitive et donc que ce framework est un échec ?

[william44290]

un informaticien n'est pas un utilisateur. (il n'est même pas normal )

[jabbounet]

Envoyé par pseudocode

??

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

ou alors anticiper l'avenir.
il faut savoir par exemple que certaines entreprise/personnes reflechissent déjà la téléphonie de dans 5/10 ans....

que certaines technos qui sont "hype" aujourd'hui ont vu les premiers bout de specs les concernants il y'a plus de dix ans.

[mister3957]

Envoyé par souviron34

• Le vrai succès d'un projet est quand les utilisateurs finaux l'utilisent et en sont contents..
  
• Le vrai échec est quand ils ne s'en servent pas, ou, si ils y sont obligés, n'arrêtent pas de râler contre...

Mouais... j'ai un collègue qui dit ça aussi, mais je suis pas d'accord...

Lorsque le projet est en production et qu'il a évolué, sous pression constante, de la part du producteur comme du client, se faisant sans cesse la guerre des mails parapluies (avec toujours 10 milles copies), c'est un succès juste car il est en prod ?
Je sais pas, si tu mets 2 ans avec autant de déboire (procédures juridiques, la moitié des employés du constructeur qui se barre, ta femme qu'en peut plus à force de t'entendre ruminer etc...) pour acheter une voiture car la transaction se passe au plus mal, même si le prix est bon, les performances au rendez-vous, pour toi, ce sera une bonne vente ? Un bon coup ?

Qui plus est, nous sommes chez un éditeur de logiciel, et non une SSII au forfait, ce qui impose comme objectif supplémentaire de pérenniser nos production "à l'extérieur" pour les réintégrer "à l'intérieur", un objectif supplémentaire qui n'est pas rempli si l'on se contente de "faut que le client soit content"...

A ce compte là, on a perdu 600 000€ et on a aggravé notre réputation sur le marché, tout en augmentant le turn over, mais bon, le client il est content, donc on est des boss, objectif(s) atteint(s).

Bref, on a tout à y gagner à faire les choses correctement, arrêtons de s'aveugler avec des trucs piochés à droite à gauche pour se convaincre qu'on est bon, que ce qu'on a fait était irréprochable, ça nuit à la remise en question qui, dans l'informatique, et surtout dans les boîtes en difficultés, est un outils indispensable, voire décisif.

[souviron34]

Envoyé par mister3957

Lorsque le projet est en production et qu'il a évolué, sous pression constante, de la part du producteur comme du client, se faisant sans cesse la guerre des mails parapluies (avec toujours 10 milles copies), c'est un succès juste car il est en prod ?

....
si l'on se contente de "faut que le client soit content"...

A ce compte là, on a perdu 600 000€ et on a aggravé notre réputation sur le marché, tout en augmentant le turn over, mais bon, le client il est content, donc on est des boss, objectif(s) atteint(s).

Je n'ai pas parlé de clients


J'ai parlé d'utilisateurs


Ne pas confondre....

J'ai rarement été dans des SSII, une ou 2 fois chez des éditeurs (certains avec clientèle captive (leurs employés ou les employés du client) , d'autres non), et la plupart du temps chez des industriels, et en général dont les machines contiennent et sont basées sur des logiciels pour plus de 50%... (machines d'imageries médicales (IRM, radio, scanners, etc), ou machines d'entraînement de pilotes, de controleurs aériens, etc)

Et la raison du succès (ou de l'échec) d'entreprises industriellles vendant du matériel avec un logiciel qui est au moins 50% du produit, ou d'éditeurs de logiciels dont la clientèle n'est pas captive (et a une voix), c'est que les utilisateurs soient contents (ou non)..

Tu peux faire la meilleure machine du monde, si le mec qui la manipule fait des erreurs et peste en permanence contre "ce foutu logiciel", tu ne dépasseras guère le stade de la démo... ou du premier exemplaire vendu...

Envoyé par mister3957

Bref, on a tout à y gagner à faire les choses correctement, arrêtons de s'aveugler avec des trucs piochés à droite à gauche pour se convaincre qu'on est bon, que ce qu'on a fait était irréprochable, ça nuit à la remise en question qui, dans l'informatique, et surtout dans les boîtes en difficultés, est un outils indispensable, voire décisif.

Remise en question que visiblement tu ne sembles pas prêt à faire...

Je ne sais pas qu'est-ce que tu penses qui "aveugle" ??

Les méthodologies agiles et l'ergonomie des logiciels sont les pièces centrales pour arriver à la prise en compte de l'utilisateur (bien que certains projets menés avec d'autres choses réussissent aussi).

Mais au vu de ton âge, je te pardonne je ne sas pas si dans ta boîte vous avez des test d'utlisabilité, des labos et des études d'utilisabilité et d'ergonomie avant de démarrer l'édition d'un logiciel..

Mais aussi le fait que , que ce soit les dernières technos ou non, tout n'est pas bon à prendre.. Et la remise en question doit se faire dans ce sens-là AUSSI....


Mais ces démarches sont bien basées sur le fait que le plus important est que l'utilisateur final soit content..

Le client n'est que le maillon financier..

Il est nécessaire, mais il n'achétera QUE si les utilisateurs sont contents (ou alors ils sont captifs).

[souviron34]

Envoyé par benwit

Quand un développeur râle après un framework et traîne des pieds pour l'utiliser, c'est ?
A) qu'il est incompétent et devrait suivre une formation à l'utilisation de ce framework.
B) qu'il est utilisateur de cette boite noire non intuitive et donc que ce framework est un échec ?

Je dirais un peu comme l'a dit william44290

Disons que normalement la conclusion est B, mais qu'il est possible que cela puisse être A

Car notre métier est d'utiliser ces outils.

Cependant, quand on fait des logiciels pour d'autres métiers, ce n'est pas nous qui devons dicter la formation métier..

Je l'ai déjà dit ailleurs, mais pour moi un logiciel correct doit être intuitif et demander zéro formation.


Dans la pratique, surtout de logiciels complexes avec des retombées critiques (vies en jeu), il est bon d'avoir un minimum de formation.. Mais pour la plupart, de l'ordre d'une 1/2 heure à 1/2 journée devrait suffire... (pour des gens qui n'ont jamais touché ce genre de logiciels, par exemple, mais qui connaissent leur métier)

Mais de toutes façons , la base est que cela soit intuitif...


Dans le cas que tu présentes, je dirais que dans 90% des cas, ce sera B....

[pseudocode]

Envoyé par jabbounet

ou alors anticiper l'avenir.
il faut savoir par exemple que certaines entreprise/personnes reflechissent déjà la téléphonie de dans 5/10 ans....

que certaines technos qui sont "hype" aujourd'hui ont vu les premiers bout de specs les concernants il y'a plus de dix ans.

Oui mais là tu as une étude marketing (ou l'équivalent), donc tu as un "client" a qui tu peux demander des choses pendant le développement (confirmations, détails, ... )

C'est différent de faire un CDCF à l'aveugle, partir en développement et livrer le logiciel a quelqu'un qui n'a rien demandé.

[ceinoxe]

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

Vécu

[B.AF]

La principale cause d'échec est la suivante :
- L'utilisateur est une b*t* en informatique. Bien qu'il ne puisse rien faire au quotiden sans utiliser l'informatique (d'un virement bancaire à ses mail pros) et qu'il passe son temps à vouloir un plus petit portable et un blackberry, il ne veut surtout pas assumer sa technophilie.
- La moa est un fourre tout mélangeant les placardisés hargneux avec les jeunes diplomés qui forment les experts fonctionnels. Le hargneux explique que de toutes façons, les utilisateurs sont mauvais et que c'est à cause de ça qu'il fait de la moa. Le jeune diplomé voit le monde en UML et en Java.
Le patron de l'ensemble est un illusioniste de première qui passe son temps à alimenter un stock de 'spécification fonctionnelles' inutiles, est à rejeter toute responsabilité des retards sytèmatiques.
- Quelques génies qui à force de se faire ch*** tous les jours à utiliser un SI qui ne fonctionne pas et qui ont développé aux mêmes des applis non documentées, dans des technos toujours obscures, et qu'il préservent jalousement de la MOA. D'ailleurs, ça les fait beaucoup rire de voir la MOA ramer pour comprendre.
- La moe est une équipe de bons développeurs mais traités comme des être sous intelligents, qui ne comprennent jamais rien, mais assuments les responsabilités de tous les échecs. Ils finissent toujours par faire du reverse engineering chrono des applis des génies après que les specs de la moa soit considérées inutilisables.(mais ça ira ieux après avoir explosé le budget formation)
- La direction business, elle veut pas entendre parler d'IT sauf pour justifier son incapacité à produire de chiffres. Elle a des besoins, mais en fait, elle compte sur la moa pour comprendre à sa place. Elle préfére toujours acheter un logiciel pour 'bénéficier' des connaissances des autres.Entre 3 poncifs dignes d'un manager américain, elle se dérobe des comités stratégiques (pour pas dire informatique, hein, c'est sale) pour aller jouer au golf.

Tous les projets sont toujours à la base un échec, qui est celui d'obtenir de la qualité unitaire au niveau du business. C'est à dire que le motif d'échec principal aujourd'hui, c'est d'industrialiser des processus inconnus.

[souviron34]

Envoyé par B.AF

La principale cause d'échec est la suivante :
- L'utilisateur est une b*t* en informatique. Bien qu'il ne puisse rien faire au quotiden sans utiliser l'informatique (d'un virement bancaire à ses mail pros) et qu'il passe son temps à vouloir un plus petit portable et un blackberry, il ne veut surtout pas assumer sa technophilie.
- La moa est un fourre tout mélangeant les placardisés hargneux avec les jeunes diplomés qui forment les experts fonctionnels. Le hargneux explique que de toutes façons, les utilisateurs sont mauvais et que c'est à cause de ça qu'il fait de la moa. Le jeune diplomé voit le monde en UML et en Java.
Le patron de l'ensemble est un illusioniste de première qui passe son temps à alimenter un stock de 'spécification fonctionnelles' inutiles, est à rejeter toute responsabilité des retards sytèmatiques.
- Quelques génies qui à force de se faire ch*** tous les jours à utiliser un SI qui ne fonctionne pas et qui ont développé aux mêmes des applis non documentées, dans des technos toujours obscures, et qu'il préservent jalousement de la MOA. D'ailleurs, ça les fait beaucoup rire de voir la MOA ramer pour comprendre.
- La moe est une équipe de bons développeurs mais traités comme des être sous intelligents, qui ne comprennent jamais rien, mais assuments les responsabilités de tous les échecs. Ils finissent toujours par faire du reverse engineering chrono des applis des génies après que les specs de la moa soit considérées inutilisables.(mais ça ira ieux après avoir explosé le budget formation)
- La direction business, elle veut pas entendre parler d'IT sauf pour justifier son incapacité à produire de chiffres. Elle a des besoins, mais en fait, elle compte sur la moa pour comprendre à sa place. Elle préfére toujours acheter un logiciel pour 'bénéficier' des connaissances des autres.Entre 3 poncifs dignes d'un manager américain, elle se dérobe des comités stratégiques (pour pas dire informatique, hein, c'est sale) pour aller jouer au golf.

Excellent

à garder sous le coude...

Et tellement vrai...

Envoyé par B.AF

Tous les projets sont toujours à la base un échec, qui est celui d'obtenir de la qualité unitaire au niveau du business. C'est à dire que le motif d'échec principal aujourd'hui, c'est d'industrialiser des processus inconnus.

je rajouterais "avec des techniques dont on n'a pas la moindre idée de savoir si c'est utile"...

[Caravane]

c est vécu par tout le monde, c est certaint, mais l'essentiel c est d'essayer de nettoyer un peut ce bordel quand on a les moyens.

[yukon_42]

Envoyé par B.AF

Le jeune diplomé voit le monde en UML et en Java.

Tellement vrai.... tu as travaillé avec moi y'a 2-3 ans ? .

J'ajouterais:
Quand le patron vient voir le développement tout les jours et demande d'ajouter une fonctionnalité mineure qui change radicalement le prog (mon projet actuel )

Quand ton stagiaire te dit que dans sa fac,école d'ing etcetc on fais comme ça et pas autrement et que ça marche pas : le programme est planté et aucune copie de sauvegarde à était faite pas ce génie qui ne se souvient pas de ce qu'il a changé
Et que çà fais au moins 10 fois qu'il te fais çà
(Vécu hier )

[jabbounet]

Envoyé par yukon_42

Quand ton stagiaire te dit que dans sa fac,école d'ing etcetc on fais comme ça et pas autrement et que ça marche pas : le programme est planté et aucune copie de sauvegarde à était faite pas ce génie qui ne se souvient pas de ce qu'il a changé
Et que çà fais au moins 10 fois qu'il te fais çà
(Vécu hier )

normalement il y'a une gestion de conf, si c'est bien utilisé ça évite les problèmes.

si y'en a pas tu es quasiment certain de te planter.

[pseudocode]

Envoyé par B.AF

Le patron de l'ensemble est un illusionniste de première qui passe son temps à alimenter un stock de 'spécifications fonctionnelles' inutiles, et à rejeter toute responsabilité des retards systématiques.

Tiens, moi c'est l'opposé. Le demandeur ne donne spécification fonctionnelle et repousse la date de sortie du produit.

[yukon_42]

Envoyé par jabbounet

normalement il y'a une gestion de conf, si c'est bien utilisé ça évite les problèmes.

si y'en a pas tu es quasiment certain de te planter.

Si si y'en a une... le problème c'est qu'il ne l'utilise pas ( son ecole d'ing lui as pas appris )

Et quand le stagiaire est le fils du patron, bah tu peux rien dire
Ça aussi c'est un signe d'échec

[B.AF]

Envoyé par pseudocode

Tiens, moi c'est l'opposé. Le demandeur ne donne spécification fonctionnelle et repousse la date de sortie du produit.

C'est kif kif. Soit les mauvais ou les ingérables invirables finissent invariablement MOA. Juste là à la place d'être auvais à la MOA, il est toujours au business.

C'est qu'une question de temps !!!

[lifty]

Anecdote vécu :

Petite PME qui gère un SI au niveau régional (nous l'appellerons GR), cette institution n'a pas été centralisée à la capitale.
Le client lui est le groupe National (nous l'appellerons GN) qui souhaiterais intégré dans son SI un outil de gestion développé dans ce centre regional.
Premier obstacle le national peine à définir un cahier de charges global qui satisferait toutes les parties, mais soit un CdC est quand même pondu.
Second obstacle qui dit centralisation dit bcp de points de vues. Du coup sur le projet il y a une vingtaine d'interlocuteurs qui pour une simple réunion technique d'une demi-journée nous arrivons à 11 jours hommes/réunion (en comptant les 2 interlocuteurs coté MOE) le budget fond à vu d'œil alors que rien n'est encore fixé. Mais soit un premier cadre de dev est pondu et une première maquette est réalisée, les délais de livraison sont fixés ...
Troisième obstacle, le GN se découvre des besoins, untel veut ci untel veut ça pour finalement ne plus le vouloir quelques semaines après ...
Résultat l'analyse commence à partir d'un CdC qui change à chaque réunion, la MOE essaie de fixer des interlocuteurs mais ce sont les grandes gueules qui se proposent ...
L'analyse n'est pas encore fini, le CdC change encore mais les délais étant courts le dev commence ... manque de temps manque de personnel la MOE a besoin de main d'œuvre pas cher, ils prennent le pari de prendre un stagiaire pour palier a leurs besoin en esperant qu'il soit pas trop mauvais ... le budget lui fond comme neige au soleil à chaque réunion de la MOA.
Il reste un mois avant la fin du projet, la phase de recette devrait être en cours mais seulement 50% du dev est fait ... cause ? pleine période de vacances les devs techniques sont partis .. reste le stagiaire et un ou 2 prestataire. Les SFD elles bougent encore, même les SFD IHM ne sont pas encore fixée.

Viens alors la date du rendu, le dev n'est pas encore fini, les tests passé sur le code révèle de grosses anomalies fonctionnelles. La MOA qui n'est toujours pas fixé sur ses besoins exigent des têtes. Les chefs de projet ont fait ce qu'ils ont pu avec le budget qu'il avait. L'enveloppe attribué a la MOA pour ce projet est partit a 70% en réunion pour finalement ne rien donné. Le stagiaire s'en va sucé jusqu'a la moëlle en ne souhaitant plus jamais bossé dans l'informatique. Les chefs de projet/equipe en ont eu mort, l'un à demandé sa mutation, un autre a démissionné pendant le projet et enfin le dernier cadre qui a tout pris dans la tronche à la fin lui est partit en dépression.
Au final, le client national songe à incorporer directement ce dernier centre régional pour faire sa tambouille en interne, l'équipe de dev est détruites et la MOE dégouté. De son côté la MOA s'en est mis plein les poches pour finalement ne rien donné de concret et en reportant la faute sur la MOE qui est incapable de comprendre ses besoins (ce qui est vrai cela dit tellement ils ne savent pas eux non plus ce qu'ils veulent).

et c'est comme ça depuis 2 ans dans ce centre informatique, perso je songe à donner ma démission avant qu'un projet comme ça me tombe dessus ...

[Altess]

Je croyais que jetais le seul dév. à subir ce genre de chose.
A vous lire, je crois que finalement, c'est pour tout le monde pareil. Ça me rassure un peu dans le fond ...