IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Actualités Discussion :

Étude : 50 % des projets de développement d'applications se soldent par un échec

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 875
    Points : 86 930
    Points
    86 930
    Billets dans le blog
    2
    Par défaut Étude : 50 % des projets de développement d'applications se soldent par un échec
    Étude : 50 % des projets de développement d'applications se soldent par un échec
    cela est-il dû à la lenteur des codeurs et la dette technique ?

    Si une entreprise peut se permettre de démarrer de nouveaux projets informatiques chaque année, garantir leur succès est une chose qui est bien moins évidente. Pour réussir, un projet doit en effet respecter des contraintes de coût, de délai et de qualité (respect des exigences définies par le cahier de charges). Mais dans la pratique, il est difficile de voir un projet respecter ces 3 critères, et les meilleurs projets sont ceux qui arrivent à terme avec un écart relativement faible par rapport à ces critères.

    Plusieurs études ont été menées sur la réussite des projets informatiques, et la plupart s'accordent sur le fait qu'une bonne partie (parfois la majorité) des projets informatiques se soldent par un échec. Précisons que la notion d'échec ici signifie que soit le projet n'est jamais lancé ; soit il est lancé, mais n'est jamais terminé ; soit il est terminé, mais ne répond pas aux besoins exprimés par les utilisateurs. C'est cette définition d'échec qui a été utilisée dans une étude menée par IDG (International Data Group) pour la plateforme de développement low-code Appian.

    Pour cette étude, plus de 500 décideurs et responsables IT issus d'entreprises de plus de 1000 employés ont été interrogés. Précisons que plus de la moitié des répondants étaient des employés dits de niveau C (CIO, CTO, CSO). L'étude montre que les grandes entreprises aux États-Unis et en Europe (Allemagne, Espagne, France, Royaume-Uni) adressent chaque année à l'IT en moyenne 180 demandes de nouveaux projets (développement d'applications, améliorations ou autres). Ce qui, selon IDG, indique que ce type de demande monte en flèche au niveau mondial. Par région, les entreprises européennes font beaucoup plus de demandes que leurs homologues US. Le nombre de demandes de nouvelles applications ou améliorations chaque année s'élève à 150 en moyenne pour une entreprise US, contre 230 pour une entreprise de la zone EMEA (Europe uniquement).


    Toutefois, le résultat le plus frappant de l'étude est que 50 % de toutes les nouvelles demandes de développement d'applications se soldent par un échec. Dans les détails, l'étude révèle que 15 % de ces projets ne sont jamais lancés, 15 % ne sont jamais terminés et 20 % sont livrés, mais ne répondent pas aux besoins de l'entreprise.


    Aux États-Unis, le département Marketing est plus susceptible que les autres départements de demander de nouvelles applications, tandis que dans la zone EMEA, c'est le département Ventes qui est le plus gros demandeur d'applications.

    Quelles sont les causes d'un tel taux d'échec ? Dans ce qui ressemble à une tentative de désigner des responsables, le rapport indique que « les services informatiques ont du mal, ou n'arrivent pas, à répondre aux besoins évolutifs de l'entreprise, principalement en raison de la lenteur du codage et des problèmes liés à la dette technique. » La dette technique, définie comme le coût implicite du travail supplémentaire lié au choix d’une solution facile immédiate au lieu de la solution appropriée de long terme, « représente une partie majeure du problème », peut-on lire dans le même rapport.

    D'après l'étude, si les équipes IT passent 50 % de leur temps à coder de nouvelles applications et améliorations, elles prennent environ 40 % du temps consacré au développement pour gérer la dette technique. La dette technique a donc un impact considérable sur les entreprises. En effet, pour 55 % d'entre elles, la dette technique augmente les coûts opérationnels. 52 % des répondants estiment aussi que la dette technique fait que le développement d'une fonctionnalité simple prend plus de temps que prévu. Jusqu'à 47 % estiment encore que la dette technique réduit les performances et l'évolutivité des applications, alors que pour 37 % des personnes interrogées, cela rend plus long le temps nécessaire pour mettre une application sur le marché. Enfin, 17 % des répondants estiment que la dette technique empêche les améliorations de l'expérience client. Seuls 5 % des entreprises disent ne pas avoir expérimenté de dette technique.


    Pour ce qui est des sources de la dette technique, aux États-Unis, ce sont les décisions IT (47 %) et la pression de livrer les applications (43 %) qui sont le plus souvent pointées du doigt. En Europe, c'est plutôt la mauvaise documentation des exigences des projets (42 %).


    Sources : Appian, Infographie de l'étude, Détails de l'étude

    Et vous ?

    Que pensez-vous des résultats de l'étude ?
    Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?
    En tant que développeur, gérer la dette technique fait-il partie de votre quotidien ? Combien de temps y accordez-vous en moyenne dans la semaine ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 553
    Points : 18 448
    Points
    18 448
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Pour réussir, un projet doit en effet respecter des contraintes de coût, de délai et de qualité (respect des exigences définies par le cahier de charges).
    Je suis contre le concept de "cahier des charges" pour les projets informatique.
    Il faut trouver d'autres solutions.
    Le client n'exprime pas correctement son besoin, les développeurs comprennent mal le besoin du client, le besoin du client évolue, etc.
    Il faut faire du développement agile, il faut avoir des réunions régulière avec le client pour qu'il puisse guider la direction à prendre.

    Citation Envoyé par Michael Guilloux Voir le message
    Dans les détails, l'étude révèle que 15 % de ces projets ne sont jamais lancés, 15 % ne sont jamais terminés et 20 % sont livrés, mais ne répondent pas aux besoins de l'entreprise.
    Ça il faudra s'en rappeler : 20% des projets livrés ne répondent pas aux besoins de l'entreprise.
    Ça veut dire que c'est hyper commun qu'une entreprise paie des développeurs pendant longtemps pour rien du tout.

    Il y a des développeurs qui ont travaillé pendant des années, pour rien.
    Keith Flint 1969 - 2019

  3. #3
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Février 2004
    Messages : 758
    Points : 2 086
    Points
    2 086
    Par défaut
    Personnellement, au niveau des grandes entreprises, ce qui est le plus impactant pour les nouvelles ou les modifications d'applications existantes, ce sont les délais demandés par les métiers.

    Très souvent ces délais sont ridiculement faibles comparé aux temps de développement. Dernièrement, dans une grande entreprise, le métier m'a expliqué que 90 jours de charges de développement d'un nouveau projet informatique c'était beaucoup trop, ils le voulait fini en moins d'un 1 mois. Leur solution (véridique) : mettre 9 développeurs et c'est fini en 10 jours...

  4. #4
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 553
    Points : 18 448
    Points
    18 448
    Par défaut
    Citation Envoyé par blbird Voir le message
    mettre 9 développeurs et c'est fini en 10 jours...
    C'est comme la blague du chef de projet qui pense qu'en mettant 9 femmes il peut avoir un bébé en 1 mois.
    Keith Flint 1969 - 2019

  5. #5
    Membre extrêmement actif
    Profil pro
    Inscrit en
    Juin 2010
    Messages
    794
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2010
    Messages : 794
    Points : 987
    Points
    987
    Par défaut
    Avec des délais qui ne correspondent à rien, une organisation des entreprise datant du 19ème siècle, des décideurs qui ne savent rien etc. oui le taux d'échec est nécessairement faramineux.

  6. #6
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    Pour moi la principale cause est la course au moins cher / au plus rapide, sinon c'est le concurrent qui choppe le projet.

    Alors pour rentrer dans les exigences clientes, dans les bons chiffres qui vont bien lors d'une réponse à appel à projet, les commerciaux sortent des trucs de leurs chapeaux, enquillent leurs primes et ensuite les pilotes / techs se débrouillent avec ce qu'ils ont.

    Du coup on met moins de bonhommes, et on en met des pas chers, on limite fortement la préparation au projet et donc son pilotage dans l'ensemble et puis il n'y a plus qu'à presser les devs comme des citrons avec objectif "le bouton il faut qu'il marche". Et si ça foire, c'est à cause d'eux.

    Par ailleurs il y a encore beaucoup trop cette mentalité "le client est roi" qui fait qu'on lui laisse trop de pouvoir dans le pilotage (alors que l'on est sensé lui vendre ça aussi, ainsi que l'accompagnement et de la conduite du changement).

    Parfois lorsque ça ne correspond pas au besoin, ça peut venir également du client, ils ont des gugusses aussi de leur côté qui sont bien éloignés des utilisateurs finaux. Donc la maîtrise d'ouvrage comme la maîtrise d'oeuvre sont bâclées, d'ailleurs les frontières ne sont pas claires dès le départ.

    Pour des projets internes, c'est pareil, sauf que le client ce sont ces fameux "mecs du conseil".

    L'agilité c'est bien mais peu comprennent ses rouages et très très peu y sont formés, c'est souvent pour faire effet de mode c'est tout mais dans le fond les roadmaps sur des années sont bien là, et à respecter car déjà vendues. Ça arrange bien les "chefs", on a posé le déterminisme du cycle en V sans se casser la tête à écrire ces specs barbantes.

    Mais du coup c'est pire, les devs doivent avancer à l'aveugle, bouton après bouton, et au moindre sujet de fond qui tombe, ça fait parfois mal, souvent trop mal, et flop ! En général les gens se barrent, et puis on reprend les mêmes "chefs", les mêmes commerciaux, et on revend des trucs, on trouve d'autres petits jeunes et on recommence.

    J'ai déjà entendu dire "ce qui nous fait gagner de l'argent, c'est pas le projet mais sa TMA". Et j'ai taffé dans une boite où la stratégie était de berner le clients jusqu'à ce qu'il atteigne un point de non retour financier, donc obligé de continuer avec eux, ça fait de la tréso régulière, de la visibilité financière, un monde parfait, c'est génial... jusqu'à ce que le juridique du client s'en mêle, un autre avantage de l'agilité, on ne s'engage pas, c'est parfait.
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  7. #7
    Membre extrêmement actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2015
    Messages
    1 104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2015
    Messages : 1 104
    Points : 2 573
    Points
    2 573
    Par défaut
    Citation Envoyé par redcurve Voir le message
    Avec des délais qui ne correspondent à rien, une organisation des entreprise datant du 19ème siècle, des décideurs qui ne savent rien etc. oui le taux d'échec est nécessairement faramineux.
    Et des subordonnés (cadres intermédiaires, chefs de service, product owners) qui n'osent remonter aucune alerte aux décideurs, aucune information discordante, de peur que la tête qui dépasse se prenne le coup de marteau.
    "If the revolution ain't gon' be televised
    Then fuck, I'll probably miss it" - Aesop Rock

  8. #8
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    Citation Envoyé par Grogro Voir le message
    Et des subordonnés (cadres intermédiaires, chefs de service, product owners) qui n'osent remonter aucune alerte aux décideurs, aucune information discordante, de peur que la tête qui dépasse se prenne le coup de marteau.
    L'ingérence.. ça ressemble à un art de vivre dans notre métier.

    99% de ce que l'on fait se trouve sous un capot avec 10.000 verrous, donc l'ingérence est ultra propice.

    Il n'y a qu'à voir dans l'univers automobile, on peut ouvrir le machin, le décortiquer, l'analyser, ça donne lieu à des études, des magazines papier / émissions de TV, tout est transparent.. sauf lorsque ça touche au numérique, boites noires, donc on en profite pour y mettre des saloperies dedans, on s'en fou y'a personne qui voit.
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  9. #9
    Expert confirmé Avatar de sergio_is_back
    Homme Profil pro
    Responsable informatique, développeur tout-terrain
    Inscrit en
    Juin 2004
    Messages
    1 076
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique, développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 076
    Points : 5 542
    Points
    5 542
    Par défaut
    Citation Envoyé par Ryu2000 Voir le message
    Je suis contre le concept de "cahier des charges" pour les projets informatique.
    Il faut trouver d'autres solutions.
    Ça a au moins le mérite de poser les bases. Mais comme beaucoup je reçois des CDC qui tiennent sur deux pages rédigés à la vite

    Citation Envoyé par Ryu2000 Voir le message
    Le client n'exprime pas correctement son besoin, les développeurs comprennent mal le besoin du client, le besoin du client évolue, etc.
    Oui tout ça c'est vrai... Il faut souvent passer beaucoup temps que ce soit au téléphone, sur site avec le client pour bien préciser les limites et tous les aspects...
    Cet aspect là n'est pas pris en compte dans un chiffrage souvent et c'est pourtant primordial, plus un CDC est flou et plus il faut chiffrer et vendre de l'analyse et de la gestion de projet
    Alors comme souvent ça n'a été chiffré et vendu on évite de perdre du temps avec ça et le projet part en sucette...

    Citation Envoyé par Ryu2000 Voir le message
    Il faut faire du développement agile, il faut avoir des réunions régulière avec le client pour qu'il puisse guider la direction à prendre.
    Attention avec le développement Agile j'ai vu certaines boîtes faire tester le soft directement par le client et livrer 10 ou 12 versions dans la semaine avec des bugs d'affichage et même des plantages pur et simples en production dans ces cas c'est du détournement de ressources pur et simple et des pertes d'exploitation pour le client et ça nui à la relation avec celui-ci

  10. #10
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 553
    Points : 18 448
    Points
    18 448
    Par défaut
    Citation Envoyé par sergio_is_back Voir le message
    Ça a au moins le mérite de poser les bases. Mais comme beaucoup je reçois des CDC qui tiennent sur deux pages rédigés à la vite
    D'un côté c'est parfois mieux.
    Il faut juste bien comprendre les fonctions principales et commencer par concevoir ça.
    Avoir un cahier des charges qui contient trop de petits détails qui ne servent à rien, ça fait perdre du temps... C'est un coup à développer plein de fonctions qui ne servent à rien.

    C'est quasi impossible de savoir à l'avance ce qui serait le mieux pour le client dans des années.

    Exemple de bon cahier des charges (Citroën 2 chevaux) :
    « Faites étudier par vos services une voiture pouvant transporter deux cultivateurs en sabots, cinquante kilos de pommes de terre ou un tonnelet à une vitesse maximum de 60 km/h pour une consommation de tois litres d’essence aux cent. En outre, ce véhicule doit pouvoir passer dans les plus mauvais chemins, il doit être suffisamment léger pour être manié sans problèmes par une conductrice débutante. Son confort doit être irréprochable car les paniers d’oeufs transportés à l’arrière doivent arriver intacts. Son prix devra être bien inférieur à celui de notre Traction Avant »
    Citation Envoyé par sergio_is_back Voir le message
    Oui tout ça c'est vrai... Il faut souvent passer beaucoup temps que ce soit au téléphone, sur site avec le client pour bien préciser les limites et tous les aspects...
    Il faut être en contact avec ceux qui utilisent réellement l'outil.
    Avoir une réunion 2 fois par mois pourrait être utile.

    Citation Envoyé par sergio_is_back Voir le message
    j'ai vu certaines boîtes faire tester le soft directement par le client et livrer 10 ou 12 versions dans la semaine
    D'un côté ça fait gagner du temps sur le test, vu que c'est le client qu'il les fait ^^
    Par contre si c'est en production ça craint...
    Keith Flint 1969 - 2019

  11. #11
    Expert confirmé
    Avatar de Doksuri
    Profil pro
    Développeur Web
    Inscrit en
    Juin 2006
    Messages
    2 450
    Détails du profil
    Informations personnelles :
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juin 2006
    Messages : 2 450
    Points : 4 600
    Points
    4 600
    Par défaut
    Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?
    les delais trop cours et le manque de reflextion avant le lancement du projet (surtout par les non-dev).
    on ne vous consulte pas et un jour : "bon, on va faire le projet X, on a 3 mois" .... au bout d'un moment, on se trouve confronte a un probleme : "mais vous avez pense a X ? et Y ? et pourquoi vous n'avez pas pense a Z ?"
    du coup, comme les devs sont deja engages, on trouve des solutions a l'arrache. ce qui amene a la reponse suivante ....
    En tant que développeur, gérer la dette technique fait-il partie de votre quotidien ? Combien de temps y accordez-vous en moyenne dans la semaine ?
    gerer la dette tecnique est le quotidien... si on prend du debut du codage a la resolution du dernier bug remonte par le client : 50% du temps
    exemple : si le dev dure 3mois, on va debugger pendant 3mois (pas a 100% de debug, on va faire d'autres projets en meme temps) mais pendant 3mois, on aura une petite liste de bugs a traiter
    La forme des pyramides prouve que l'Homme a toujours tendance a en faire de moins en moins.

    Venez discuter sur le Chat de Développez !

  12. #12
    Membre expérimenté
    Homme Profil pro
    Développeur Web
    Inscrit en
    Septembre 2016
    Messages
    373
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Septembre 2016
    Messages : 373
    Points : 1 335
    Points
    1 335
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Que pensez-vous des résultats de l'étude ?
    Déjà les 15% qui ne commence jamais son probablement du aux clients qui font une demande mais qui ce rendent compte qu'elle ne rentre pas dans leur budget et la remette donc à plus tard. (dans la boite ou je bosse on à trois projet en attente comme ça depuis le début de l'année.).

    Pour le reste, c'est plutôt inquiétant... Mais bon quand je vois que l'un de nos clients à voulut faire appel à une entreprise multi nationale qui avais les moyens de mettre une équipe de 15/20 personnes pour refaire entièrement leur outil principal et que cette entreprise n'a rien été capable de sortir d'autre que des maquettes en presque 2 ans. Sa ne m'étonne guère...

    Citation Envoyé par Michael Guilloux Voir le message
    Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?
    Si je reprend l'exemple cité plus haut, une très très très mauvaise approche du projet. Je ne vais pas entrer dans les détails, mais quant à la première réunion ils ont annoncer qu'ils allaient tout mettre sur un seul écran qui sera modulable, j'ai eu du mal à ne pas exploser de rire. Résultat 2 ans après ils ont décider que finalement ils allais garder une structure plus proche de ce qui existe aujourd'hui, parce qu'il y à énormément de problématique qu'ils n'avais pas pris en compte.

    Et oui quand il y à une trentaine de calculateur différent qui ont tous leur particularité et qu'ils peuvent tous évoluer de manière différente c'est une vrais folie que de vouloir tout généralisé...

    Après y'a le client aussi, qui ne sais jamais exactement ce qu'il souhaite, et qui oublie toujours ses petits détails qui font qu'un développement simple devient super compliquer et qui double le temps de dev et de recette. Details bien sur qui sont ressortie au premier jours de recettage par le client. Pas avant.

    En bref, le travail de chef de projet c'est pas donner à tout le monde, j'ai de la chance de bosser avec des personnes qui préfèrent dire non à un projet qu'ils estime non viable plutôt qu'avec des personnes qui promettent mont et merveille et qui nous foutent dans la merde par la suite. Cette gestion réfléchie fait que nos clients sont content et que nous n'avons jamais eu à livrer avec plus d'un jour de retard. (En même temps en moyenne nos projets sont sur trois mois maximum).

    C'est ça là le problème je pense, les décideurs qui aguiche le client en leur promettant un truc parfait en trois semaines alors qu'il faudrait un mois de dev.

    Citation Envoyé par Michael Guilloux Voir le message
    En tant que développeur, gérer la dette technique fait-il partie de votre quotidien ? Combien de temps y accordez-vous en moyenne dans la semaine ?
    Je répondrais oui sur la maintenance de vieux logiciel. Dans un premier ça représenter 80% des demandes clients, corriger les bugs existants. Avec le temps ça à heureusement diminuer, mais y'a toujours des partie de l'application ou personne ne va et qui remonte de temps en temps un problème "L'autre jour en allant ici j'ai vue un message d'erreur bizarre apparaitre, vous pouvez regardez ça ?" ^^'

    Après sur la maintenance des logiciels que j'ai produit, il y à très peut de dette techno, souvent c'est le client qui revient nous dire "Ca bug, il faudrait que dans le ce cas précis ça fasse comme ça !" sauf que ce cas particulier n'avais jamais été évoquer au cours de nos discutions et recettage. De ce fait je ne vois pas ça comme un bug mais plus comme une demande d'évolution.
    Après comme je l'ai dit plus haut, je suis dans une boite ou on préfère ne pas avoir un contrat trop borderline plutôt que d'accepter un truc que l'on sera obliger de bâcler pour le livrer à temps.

  13. #13
    Membre éclairé Avatar de Matthieu76
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Mars 2013
    Messages
    568
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2013
    Messages : 568
    Points : 890
    Points
    890
    Par défaut
    En tout cas j'ai l'impression que le problème viens très rarement des développeurs. C'est plus un problème incompréhension entre le business et les responsables IT.

  14. #14
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Il arrive que les développeurs ne soient pas au niveau. Ca s'est vu. Mais les contraintes idiotes sont quand même une source d'échec importante. Avec aussi la taille du projet. Plus il est gros, plus il risque de se bananer(d'ou le découpage en lot chez les gens sérieux, qui peut même être poussé jusqu'à l'agile, dans certains cas).

    J'ai vu beaucoup de projets se vautrer, mais les seuls auquel j'ai participé était et de loin les deux plus gros de tous ceux sur lesquels j'ai bossé, et dans les deux cas, des décisions du grand chef sont responsables.
    1. un projet de 5000 jours, 1200 déjà consommés, un premier lot déjà prêt, un ROI estimé de 18 mois sur l'élimination de la dette technique, le le PDG coté client qui décide d'annuler ce projet(et plein d'autres) pour faire un cadeau aux actionnaires.
    2. un projet de 60 personnes sur 18 mois pour refondre un référentiel client. Les specs ont deux ans d'âge, et ne correspondent donc plus à la réalité du terrain, mais on a interdiction de les adapter : le vice-président coté client a signé avec son sang, et il refuse toute adaptation pour des motifs aussi futiles que "ça ne marchera jamais". Accessoirement, il y avait des choix techniques aberrants en termes de performances qui auraient pu planter à eux seuls le projet. 6 ans plus tard, ils n'avaient toujours pas eu l'occasion de le faire. Projet mis à la benne et recommencé avec une autre solution(dont je ne sais rien de plus).


    50% de projets plantés, ça me parait énorme, mais si ils ont fait un filtre préliminaire sur la taille et ignoré tous les projets de 100/200 jours que j'ai toujours vu finir à peu près correctement, soudain, ça devient réaliste, à mon sens.

    Le meilleur chiffre de l'étude, c'est quand même 40% des couts générés par la dette technique. Genre de chiffre qu'il faudra que je ressorte. Parce-que souvent on m'a demandé de faire "vite et mal, on s'en fout", de la part de gens qui passent leur temps à beugler contre les couts de maintenance. Il est arrivé que je prenne, hélas, des raccourcis, mais j'essaye d'éviter autant que je peux. Et pas seulement au niveau du code. La doc et essentielle aussi. Je n'oublierais jamais ce jour de 2012 ou j'ai sauvé mes fesses grâce à une personne qui en 1995 avait pris la peine d'imprimer tous ses mails avant de partir à la retraite. Au milieu de ces 300 pages, j'ai trouvé la réponse à ma question(et je me suis arrangé pour que le code devienne auto-documenté, comme ça, si on perd la relique, yaka lire le code).

    J'entends souvent "mais pourquoi tu te fais chier à mettre tout ça dans des fonctions alors qu'un bête copier-coller marche aussi bien". J'ai une réponse, maintenant : "pour ne pas perdre 40% de mon temps en dette technique".
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  15. #15
    Membre éprouvé
    Homme Profil pro
    Intégrateur Web
    Inscrit en
    Août 2012
    Messages
    263
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Intégrateur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2012
    Messages : 263
    Points : 1 040
    Points
    1 040
    Par défaut le cahier des charges protège les parties contractantes...
    Citation Envoyé par Ryu2000 Voir le message
    Je suis contre le concept de "cahier des charges" pour les projets informatique.
    Ne pas oublier que le cahier des charges offre une certaine protection juridique aux parties contractantes, je suppose d’autant plus importante qu’il est détaillé. En cas de suppression de celui-ci, il faudrait trouver autre chose pour le remplacer.

    Citation Envoyé par Ryu2000 Voir le message
    Le client n'exprime pas correctement son besoin, les développeurs comprennent mal le besoin du client, le besoin du client évolue, etc.
    Il faut faire du développement agile, il faut avoir des réunions régulière avec le client pour qu'il puisse guider la direction à prendre.
    Je dois avouer qu'en matière de conception web, je suis tombé sur des clients, au moins des clients néophytes ne sachant pas exprimer leur besoin voire attendant de leur prestataire qu’il leur révèle leur besoin, genre : “Vous savez très bien ce qu’il me faut”, “Tous nos documents sont à votre disposition” (des rapports d’activité annuels !), etc. Alors, des fois, faut pas trop compter sur le client. Souvent, aussi, il faut lui faire comprendre que son désir ne correspond pas nécessairement à son besoin, et lui démonter quel est ce besoin.

    Allez, un lien :
    La solitude de l’architecte d’information

  16. #16
    Membre averti
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    106
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 106
    Points : 311
    Points
    311
    Par défaut
    Chez nous, nous avons tout ce qu'il faut pour réussir un projet :

    - Un directeur qui ne parle que de délocaliser la production parce que c'est trop cher
    - Un "manager" qui donne l'impression d’être un technicien que l'on a catapulté manager et qui n'a aucune espèce d'idée de ce qu'il fout là (et qui passe plus de temps à faire de la veille techno que des trucs de manager)
    - Un "architecte" arrogant et incompétent qui ne manquera pas de te rabaisser à la moindre occasion ("mais tu sais pas ça ? mais t'es un gros nul ! ")
    - Un commercial. Tout est dans ce mot.
    - Un chef de projet interne. Bon, ok, rien à dire sur celui là, il tient la route et il est compétent.
    - Une "responsable projet" hystérique et intrusive qui n'a que les mots "marge", "estimation", "reste à faire" et "points de fonction" à la bouche.
    - Des développeurs juniors découvrant ce monde merveilleux, jetés comme des Hobbits en Mordor.
    - Des développeurs séniors qui se cassent parce qu'ils en ont assez ce cette merde
    - Et moi, entre deux eaux, assez blasé de la vie pour m'en frangipaner de tout ça, et qui ne regarde que la somme inscrite en bas de son bulletin de paie en fin de mois et qui se dit qu'il devrait changer de métier.


  17. #17
    Expert éminent
    Avatar de pmithrandir
    Homme Profil pro
    Responsable d'équipe développement
    Inscrit en
    Mai 2004
    Messages
    2 418
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable d'équipe développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 418
    Points : 7 295
    Points
    7 295
    Par défaut
    Je pense que les résultats de cette étude sont logique, et que paradoxalement, ils explore une solution assez hazardeuse.(temps de codage et dette technique)

    la différence USA / Europe s'explique pour ma part par l'avance considérable sur 2 pooints qu'ont les USA :
    - l'agilité d'entreprise, l'écoute de toutes les idées, la hierarchie plus accessible, etc...
    - la possibilité d'embaucher et de se passer de prestataire. (donc d'etre vraiment agile)

    Quand on peut mettre toutes les personnes du projet autour de la table, parce qu'ils sont tous salariés de la boite ca va plus vite que si on doit faire un cahier des charges, un appel d'offre, un engagement forfaitaire, etc...

  18. #18
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par pmithrandir Voir le message
    (.../...)la hiérarchie plus accessible, etc...(.../...)
    ça, c'est un sujet énorme en soi. Je suis au CHSCT, alors j'entends parfois des histoires assez édifiantes. Entendu juste hier, un exemple; deux programmeurs se sont fait refourguer un projet merdique, non documenté, avec forte pression pour livrer. A la mi Juillet, la chef va les voir :

    _Bon, ben on en a besoin pour fin Juillet. Donc vous aurez fini.
    _Hein? Quoi? mais même fin Septembre, c'est impossible, vu tout ce qu'il reste à faire, et toute la dette technique à travers laquelle nous nageons!!!(notons que la chef comprend le terme de dette technique).
    _Je m'en fous que ça soit impossible. Pensez que c'est possible, et vous allez y arriver. Allez, juste un dernier effort!!!

    Résultat, fin septembre, le projet a été classé "non prioritaire". Toujours pas fini. Parmi les deux programmeurs, la dame multiplie désormais les arrêts maladie, et le monsieur a frôle le burnout. Je le soupçonne de préparer son départ pour ne pas finir comme la dame. Cela surprendra-t-il quelqu'un?

    (et on est une bonne boite; j'ai vu tellement pire ailleurs...)
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  19. #19
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 553
    Points : 18 448
    Points
    18 448
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Je m'en fous que ça soit impossible. Pensez que c'est possible, et vous allez y arriver.
    Les chefs, les commerciaux et les managers n'ont aucune idée de ce qui est réalisable et peuvent promettre n'importe quoi...
    Parfois la paroles des développeurs n'est pas pris en compte.
    Keith Flint 1969 - 2019

  20. #20
    Expert éminent
    Avatar de pmithrandir
    Homme Profil pro
    Responsable d'équipe développement
    Inscrit en
    Mai 2004
    Messages
    2 418
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable d'équipe développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 418
    Points : 7 295
    Points
    7 295
    Par défaut
    C'est toute la différence entre être agile... et faire de l'agile.

    On commence en général par le second... mais si on évolue pas rapidement vers le premier, on a pas obtenu 90% des bénéfices.

Discussions similaires

  1. Réponses: 24
    Dernier message: 03/11/2013, 14h20
  2. Réponses: 3
    Dernier message: 16/09/2008, 21h56
  3. Gestion des projets informatiques
    Par fadex dans le forum Gestion de projet
    Réponses: 8
    Dernier message: 22/08/2007, 12h55
  4. [D7] Développer une application avec des paquets
    Par aityahia dans le forum Delphi
    Réponses: 3
    Dernier message: 17/04/2007, 11h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo