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 :

Pourquoi les projets IT échouent si souvent ?

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Étudiant
    Inscrit en
    Août 2011
    Messages
    283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Août 2011
    Messages : 283
    Points : 18 071
    Points
    18 071
    Par défaut Pourquoi les projets IT échouent si souvent ?
    Pourquoi les projets IT échouent si souvent ?
    Selon une nouvelle étude, pour 74% des sondés le manque de ressources est la cause principale

    Innotas, en bonne entreprise américaine de conseils en gestion de projet IT et Cloud, a dévoilé les résultats de son étude sur l'échec des projets IT en entreprise.
    Chose étonnante, lors de la dernière année plus 50% des professionnels questionnés avouent l'échec d'un projet IT, mais alors qu'elle est la principale cause? Pour 74% d'entre eux, le manque de ressource serait la cause principale.

    Vrai ou faux ? Y a-t-il véritablement manque de ressource ? Manque de chefs de projet IT ? La question a été posée au président de l'entreprise spécialisée dans la recherche d'emploi Dice.com, à savoir Shravan Goli, il révèle alors que le nombre de postes de « chef de projet » qui reste à pourvoir reste à un seuil stable de l'ordre de 3.200 postes libres.

    Est-ce que c'est le véritable problème ? Pas tout à fait, ce métier connaît une croissance stable et attire pas mal de monde vu le salaire annuel moyen plus conséquent que pour les autres métiers IT (106.000$ contre seulement 85.000$, aux États-Unis), toutefois avec la croissance rapide et la diversification des domaines d'application de l'IT et l'introduction des méthodes de développement agiles, le rôle d'un chef de projet a évolué et demande par conséquent plus de compétences, allant du management du projet en sa globalité, la motivation des équipes, le maintien d'une bonne communication entre les groupes à la supervision des développeurs et des cycles de développement.

    En revanche, pour le président de Innotas Kevin Kern, le manque de ressource ne constitue pas l'unique cause de cet échec, pour lui les entreprises ont tendance à considérer les départements IT comme un fardeau financier et seraient les départements les plus en proie aux coupes budgétaires, or ces derniers devraient être considérés comme une des clés de la réussite d'une entreprise moderne.

    De plus la difficulté de mise en œuvre des projets n'est pas prise en valeur lors de la soumission du projet par les cercles de décision, ces derniers préférant se focaliser sur sa valeur ajoutée, ce qui conduit inéluctablement à un échec.

    Enfin, autres faits notables qui ressortent à travers cette étude :
    • 64% des professionnels interrogés affirment l'existence d'un bureau de gestion de projet, ce qui n’empêche pas l'existence de carence en terme de gestion des ressources
    • Bénéfices de la réalisation du projet (17%), Établissement des priorités (14%), Budget (13%) et Alignement avec la concurrence (5%) sont les principaux challenges auxquels il faut faire face pour le succès du projet.
    • 94 % des sondés estiment que le succès du projet est d'une importance cruciale pour la réussite de leur entreprise.

    Source : Talkincloud.com

    Et vous ?

    Qu’en pensez-vous ?

  2. #2
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Bonjour,

    Je suis d'accord avec les deux analyses : d'un cote, on manque de vrais chefs de projets competents, et de l'autre, avec ou sans chef de projet, un projet informatique n'est qu'un centre de cout, bien trop eleve, dans lequel on peut sabrer a loisir.

    Combien de projets a-t-on chiffre a X, reellement, et la reponse est apres "bon, a vendu X/3, avec pleins de fonctionalites en plus, debrouillez-vous" ?

    Apres, les entreprises ne savent pas chercher un chef de projet : soit elles prennent un bon developpeur pour le recompenser, et ne le forment surtout pas a son nouveau poste, soit elles cherchent un mouton noir et jaune a 6 pattes agiles, et trouvent que tous les candidats ont vraiment de pietres profils.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  3. #3
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Voici les quelques causes que j'ai identifié sur les échecs des projets IT :
    * des projets sous vendu (chiffré X et vendu X/3 comme dit par gangsoleil)
    * Réduction des coûts au max avec une équipe réduite, 1 ou 0 développeur expérimenté et x stagiaires (sinon, ce n'est pas drôle)
    * Un mauvais cadrage métier (c'est dingue le nombre de fois où j'ai pu constater qu'il a été vendu une usine à gaz d'une rare complexité alors que le besoin métier réel était ridicule et minime )

    Le 3ième point est souvent la cause qui revient le plus souvent.
    Souvent, les clients et/ou les équipes métiers ne sont pas assez investis dans le développement des CDC.
    L'informatique est souvent considéré, à tort, comme une "boîte noire" obscure auquel ils ne comprennent rien (et ne veulent pas faire l'effort de comprendre) et nous donne le minimum d'info pour qu'on se débrouille "comme on pense que ça devrait"
    Au final, on obtient un programme qui ne convient pas et qui du coup, n'est pas utilisé

    Les choses changent pas mal avec le développement des méthodologies agiles mais ça prend du temps

  4. #4
    Membre extrêmement actif
    Avatar de benjani13
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    Février 2010
    Messages
    615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant en sécurité

    Informations forums :
    Inscription : Février 2010
    Messages : 615
    Points : 2 824
    Points
    2 824
    Par défaut
    Citation Envoyé par Saverok Voir le message
    * Réduction des coûts au max avec une équipe réduite, 1 ou 0 développeur expérimenté et x stagiaires (sinon, ce n'est pas drôle)
    J'ai connu ça l'année dernière, nous étions uniquement 5 apprentis sur un projet (dev SAP). En plus c'était notre tout premier projet après notre embauche, et nous n'avions pas été formé à SAP.
    C'était google toute la journée

    Je rajoute que quelque mois après un des apprentis a été envoyé chez un client en tant que formateur SAP

  5. #5
    Membre extrêmement actif
    Avatar de Aurelien Plazzotta
    Homme Profil pro
    .
    Inscrit en
    Juillet 2006
    Messages
    312
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : Juillet 2006
    Messages : 312
    Points : 934
    Points
    934
    Par défaut
    L'article est très révélateur d'un cercle vicieux qui se maintient, et pour longtemps.

    94% des sondés se font mousser en assurant que le département IT est d'une importance cruciale, mais seulement 14% font preuve de sens commun en établissant des priorités (résultat: l'expression de besoins fait office de cahier des charges et 45% des fonctionnalités développées ne sont jamais utilisées, source Choisir l'agilité de M.BOISVERT et S.TRUDEL).
    La situation n'est pas près de changer.

    D'ailleurs, dans les projets agiles, il n'y a pas de chef de projet, il n'y a que des facilitateurs.

    Depuis l'ère post-Google, la Recherche et Développement est devenu l'un des rares départements au sein d'une entreprise à produire encore de la valeur ajoutée. Il est donc logique (connaissant la nature intrinsèque de l'Homme), que les autres départements (qui eux ont des décideurs siégeant au conseil d'administration), justifient leur contrat de travail en empêchant le service IT de sortir de l'ombre.

    Je reconnais néanmoins que mon jugement est biaisé car je n'ai jamais travaillé dans une petite entreprise.
    Je porte l'épée brisée, et sépare les vrais rois des tyrans. Qui suis-je ?

  6. #6
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    Juin 2003
    Messages
    452
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : Afghanistan

    Informations forums :
    Inscription : Juin 2003
    Messages : 452
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut c simple
    Les echecs viennent je suis sûre du fait que le métier de base dans l'informatique qui celui de concepteur développeur est telement peux valorisé qu'il implique forcément des echecs par manque de motivation et d'intéret.

  7. #7
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Janvier 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2014
    Messages : 18
    Points : 23
    Points
    23
    Par défaut
    Il y a le manque de ressources, mais le point à noter c’est que le marché des IT est presque saturé et que les projets qui sortent du lot se font rares…, ce qui fait que le besoin n’est pas déclenché chez le consommateur ….

  8. #8
    Membre actif
    Inscrit en
    Février 2006
    Messages
    311
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 311
    Points : 253
    Points
    253
    Par défaut
    Les echecs viennent je suis sûre du fait que le métier de base dans l'informatique qui celui de concepteur développeur est telement peux valorisé qu'il implique forcément des echecs par manque de motivation et d'intéret.
    Entre autre mais je crois aussi que tous les projets ne sont pas destinés à réussir faut voir au cas par cas , à partir du moment où un projet est lancé c'est une expérience jamais tentée donc un risque.

    Je pense plutôt que les projets qui réussissent le mieux ce sont ceux qui sont réalistes tant sur le plan technique que fonctionnel ce qui n'est pas toujours le cas trop souvent le code devient complexe , le développeur/programmeur est prit pour un magicien ou son avis ne compte tout compte fait pas lors des choix voir rarement.

    Ce qui est sûre c'est qu'un développeur n'a presque aucun pouvoir sur un projet même si tu fonces sur quelque chose où tu sais que (techniquement) ça va pas fonctionner mais que ton chef lui est illuminé qu'il faut faire ainsi.

  9. #9
    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
    Gangsoleil a toujours raison, et Saverok a bien complété : tant qu'on aura des décideurs qui
    (1) baseront tant les objectifs que les moyens sur des fantasmes
    (2) refuseront d'impliquer des sachants métier dans le projet

    mais aussi de développeurs qui

    (3) partiront bille en tête en sachant qu'ils vont se planter, mais en espérant quand même s'en sortir.

    on aura beaucoup de casse.

    Le point (1) est lié à la jeunesse de nôtre discipline, et devrait se réduire avec les siècles. Le point (2) devrait être plus facile à corriger, mais à condition de faire passer l'information au bon endroit : les sources d'information des décideurs, pas celles des informaticiens de métier. Le point (3) me parait incorrigible : c'est la nature humaine.
    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.

  10. #10
    Membre émérite
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    Juin 2012
    Messages
    851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juin 2012
    Messages : 851
    Points : 2 424
    Points
    2 424
    Par défaut
    Rien de bien nouveau, le Standish Group via son Chaos report obtient des chiffes similaires.

    De nombreuse méthodlogie et bonne pratique existe: PRINCE2, PMI, ITIL, Six Sigma...
    Elles ont déjà fait leur preuve, de nombreux ouvrages sortent à chaque année.

    Un bon livre par exemple
    INFORMATION TECHNOLOGY PROJECT MANAGEMENT

    Le chef de projet doit gérer une panoplie de domaine dont les risques, communication, échéancier, plan d'affaire, budget...
    Ce n'est pas tous le monde qui a les compétences.

    Il y a beaucoup trop de décideur pressé qui prenne des décisions critiques après avoir lu un titre d'un magasin.
    Des mauvaises décisions, ce n'est pas ça qui manque en informatique. J'en ai vu énormément qui rejetait la faute
    d'échec sur les autres alors qu'au final, c'est lui le chef.

    Une bonne communication, implication des utilisateurs font partie des critères pour réussir un projet.
    La technologie est rarement l'écher d'un projet.

  11. #11
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par Johnny P. Voir le message
    Je pense plutôt que les projets qui réussissent le mieux ce sont ceux qui sont réalistes tant sur le plan technique que fonctionnel ce qui n'est pas toujours le cas trop souvent le code devient complexe , le développeur/programmeur est prit pour un magicien ou son avis ne compte tout compte fait pas lors des choix voir rarement.
    Je ne partage pas ton avis.
    Les clients n'ont pas assez d'argent pour investir dans des trucs au hasard.
    Et puis, la nouveauté n'est pas forcément au rdv.
    J'ai connu des projets qui n'avaient rien d'innovant (et même plutôt archaïque dans le concept) se vautrer lamentablement.

    Je pense que c'est souvent une mauvaise préparation qui est la cause de l'échec du projet.
    C'est un peu comme si une fois que le projet a été approuvé en CA, il fallait tout de suite le mettre en route et avoir le plus rapidement quelque chose à montrer.
    Du coup, on a juste une expression de besoin mais rien qui ne ressemble à un CDC et encore moins à un SFG mais les dev eux, débutent...
    Et là, les développeurs composent presque à l'aveugle et les multiples ajustement entraînent de la complexité (et avec des développeurs débutant, c'est encore mieux...).
    Au final, on obtient quelque chose d'ultra bugué qui ne répond pas aux besoins

  12. #12
    Membre émérite
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    Juin 2012
    Messages
    851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juin 2012
    Messages : 851
    Points : 2 424
    Points
    2 424
    Par défaut
    Citation Envoyé par Johnny P. Voir le message
    Entre autre mais je crois aussi que tous les projets ne sont pas destinés à réussir faut voir au cas par cas , à partir du moment où un projet est lancé c'est une expérience jamais tentée donc un risque
    On appelle ça la gestion de risque.

    Il faut
    les identifier
    estimer leurs impacts
    Avoir un plan s'ils surviennent
    les surveiller

  13. #13
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 352
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 352
    Points : 20 359
    Points
    20 359
    Par défaut
    Citation Envoyé par Arsene Newman Voir le message
    Pourquoi les projets IT échouent si souvent ?
    Pour 74% d'entre eux, le manque de ressource serait la cause principale.
    bonsoir cet argument me semble faux..
    Quelques exemples : Louvois développé par Steria ça a coûté plus de 200millions d'euros ( au frais du contribuable bien sûr) ; d'après Le Monde Informatique il n'y avait même pas une personne capable de gérer tout cela, chacun avait son mot à dire.

    *l'Obamacare développé par CGI, une ruine totale qui a coûté plus de 400millions de dollars le truc ça ne marche même pas. Forcément avec plus de 300millions d'Américains faut peut-être prévoir la bonne architecture...Fox News en a fait largement écho ainsi que tous les médias..
    Le groupe de services informatiques s'était déjà illustré avec un système identique pour la gestion des patients de Hawaii..

    Des gros projets pour les administrations j'en ai encore d'autres comme le Dossier Médical informatisé...
    donc qu'on ne vienne pas affirmer qu'il y a un manque de ressources avec les millions engloutis...
    comme le mentionne parfaitement bien "Saverok" c'est que pour monter un chantier logiciel ça débouche inévitablement sur une usine-à-gaz

  14. #14
    Membre extrêmement actif
    Avatar de Aurelien Plazzotta
    Homme Profil pro
    .
    Inscrit en
    Juillet 2006
    Messages
    312
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : Juillet 2006
    Messages : 312
    Points : 934
    Points
    934
    Par défaut
    Peut-être aussi le système de rémunération des chefs de projet les poussent-t-il à prendre et maintenir des décisions absurdes.

    J'ai travaillé pour différents chefs de projets qui basaient leur niveau de vie en tablant sur le fait que les primes annuelles et le salaire ne faisaient qu'un.
    Ils ne pouvaient donc tolérer l'absence de primes pour l'année suivante. Ils en venaient donc à accepter des échéanciers fantasmagoriques (comprendre irréalisable ), des technologies non maîtrisées ainsi qu'une dette technique à faire pâlir celle du Traité de Maastricht.

    Sans oublier le transfert indû des responsabilités qui met à mal la motivation des opérationnels :
    "Quand ça marche, jme félicite, quand ça merde, tu t'excuses."

    Allez j'imagine que tout le monde a connu ça :
    Images attachées Images attachées  
    Je porte l'épée brisée, et sépare les vrais rois des tyrans. Qui suis-je ?

  15. #15
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Je pense que c'est souvent une mauvaise préparation qui est la cause de l'échec du projet.
    avec des développeurs débutant, c'est encore mieux...
    Je pense que le point centrale est là.

    Bien souvent les besoins utilisateurs ne sont pas toutes comprises et on ne cherche pas toujours à les comprendre.
    Si en plus, le projet est géré par une SSII au forfais, une fois le cahier des charges validé, on va tout faire pour le respecté, même s'il ne correspond plus aux besoins actuels.
    Je pense que l'agilité à toute ca place là: avoir du feed-back utilisateur en livrant un version régulièrement.
    Cette petite règle toute simple, implique une réelle implication des développeurs pour répondre aux besoins (réels) du client.
    Et cela sort justement de ce cycle infernal CDC, Etude, développement, tests, recette, production, ...
    Mais travail plutot sur le partenariat developpeur/client qui doivent travailler ensemble dans un même but: la réussite

    Ensuite, le secteur informatique pêche de jeunisme.
    On aime pas les séniors dans notre secteur.
    Avez vous beaucoup vu d'annonce de développeur pour les plus de 40 ans?
    A 25 ans, tu es confirmé; à 28 ans, expert.
    Et si à 35 ans tu n'es pas devenu "chef de projet", tu as raté ta vie (professionnelle).

    Où est la passion de notre métier?
    Est ce qu'un "ancien" developpeur n'apporte rien au projet?
    Pourtant, il les connait tout les pièges à éviter et les bon algorithmes optimisés.
    Mais non, on préfere engager un petit jeune qui connait le dernier framework J2EE et que l'on ne payera que 32K€/an
    Tant pis si on plante le projet...

  16. #16
    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
    Pour ma part, dans les échecs de projets j'ai vu :
    - manque de ressource, argent ou temps. Je veux une application de VOD au 31 juin. On est le 6 et il n y a qu'un seul dev de prévu...
    - besoin mal défini : ceux qui ne savent pas ce qu'ils veulent, ou qui définisse le besoin sans poser de question autour d'eux(utilisateurs, etc...)
    - besoin complexe pour rien. Ici, c'est 90% de ma cause d’échec dans une grosse boite. On laisse des gens définir un projet idéal, ils ajoutent un millions de merde dedans et après 6 mois de dev, il devient in maintenable parce que la logique métier est trop grosse dedans. Par exemple on automatise des millions de choses, sans se poser la question de l'utilité. Au final, on créé une usine a gaz pour ne surtout pas faire confiance a l'humain devant son pc, alors que pour 254%M du prix on pouvait répondre au besoin en donnant plus de latitude aux utilisateurs. (un exemple, dans un formulaire, au lieu de lancer des actions en javascript qui mette a jour des champs en fonction d'autres valeurs, on fait une vérification en pré submit, et ca coute bien moins cher.)

  17. #17
    Membre averti
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    192
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 192
    Points : 395
    Points
    395
    Par défaut
    Premièrement, c'est intéressant de voir que tout le monde jusqu'à présent partage ce constat.

    Je pense qu'il y aurait beacoup moins d'échecs s'il y avait une phase préparatoire d'expression des besoins avec quelqu'un pour tenir un rôle particulier entre le client et le chef de projet.

    Un vrai boulot qui fait tampon et cette personne (moitié métier, moitié technique) recueillerait les besoins, les traduirait au moins en cahier des charge un peu détaillé.

    En tout cas quelque chose qui permettrait d'éviter un gros point noir des projets informatiques selon moi : plus on approche de l'échéance, plus on nous demande de faire des changements dans ce qui a déjà été réalisé car ça ne correspond pas ou peu au besoin.

    Il en découle des grosses verrus dans le code par manque de temps donc des bugs... et aussi des dépassement de temps/budget.

    En ayant une idée très précise de ce qu'il faut réaliser dès le début, le chef de projet a toutes les cartes en main.

    Dans l'idéal, ce serait à ce poste de mettre le HOLA entre des demandes trop fournies et des ressources trop limitées.

    La concertation entre client/jobDeLaMortQuiManque/chef de projet permettrait de partir sur des bases saines, réalistes, et de livrer quelque chose de fini et qui correspond aux besoins.

  18. #18
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Albinre Voir le message
    Il y a le manque de ressources, mais le point à noter c’est que le marché des IT est presque saturé et que les projets qui sortent du lot se font rares…, ce qui fait que le besoin n’est pas déclenché chez le consommateur ….
    C'est vrai mais le consommateur n'est pas le plus qualifié pour connaitre l'évolution de ses besoins, ce sont les dirigeants, chefs, ... qui doivent faire évoluer les logiciels dans un but de meilleurs performances, interopérabilités, sécurités, anticipations de l'évolution du métier, ...

    Citation Envoyé par temoanatini Voir le message
    Un vrai boulot qui fait tampon et cette personne (moitié métier, moitié technique) recueillerait les besoins, les traduirait au moins en cahier des charge un peu détaillé.

    En tout cas quelque chose qui permettrait d'éviter un gros point noir des projets informatiques selon moi : plus on approche de l'échéance, plus on nous demande de faire des changements dans ce qui a déjà été réalisé car ça ne correspond pas ou peu au besoin.
    ...
    En ayant une idée très précise de ce qu'il faut réaliser dès le début, le chef de projet a toutes les cartes en main.
    C'est le but de Scrum, mais en france on n'utilise que le nom et on n'applique pas la méthode et c'est le chef de projet qui s'y colle généralement sans succès.

  19. #19
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    222
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Isère (Rhône Alpes)

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

    Informations forums :
    Inscription : Mars 2011
    Messages : 222
    Points : 766
    Points
    766
    Par défaut
    Pour moi une bonne source d'échec c'est la disparation du modèle de développement V. Plus précisément le fait que le développement se fasse officiellement avec un modèle en V alors qu'en pratique ce n'est pas du tout le cas: début des développements avant même qu'une spec ne soit faite, la spec qui arrive en plein milieu du développement et qui ne correspond évidemment pas à ce que les développeurs avait compris, prévu et commencé à développer, les specs qui changent quotidiennement parce que les gens qui font les specs "se rendent mieux compte en voyant le résultat", les tests faits à la va vite parce que "y'a pas de modfs très compliquées, pas de risque, on vérifie juste l’affichage"... Tout ça prend arrive à son paroxysme le jour où la "spec finale" arrive enfin... le jour de mise en prod (quand ce n'est pas le lendemain).

  20. #20
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Citation Envoyé par olreak Voir le message
    Plus précisément le fait que le développement se fasse officiellement avec un modèle en V alors qu'en pratique ce n'est pas du tout le cas
    Le modele en V n'est qu'un modele parmi tant d'autres, mais je vois ce que tu veux dire.

    D'ailleurs, si des modeles de developpement avec des cycles courts et une forte interaction entre le demandeur et l'executant sont apparus, ce n'est pas pour rien. Mais le probleme, c'est que la plupart des gens n'ont absolument pas compris les bases et les concepts de ces methodes, et disent les appliquer en n'appliquant qu'une partie sous des noms vendeurs type agile ou scrum.

    Un mode de developpement, que ce soit en V, iteratif, agile, ou n'importe quoi, serait souvent bien plus benefique que le n'importe quoi qui est mal applique.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

Discussions similaires

  1. Réponses: 0
    Dernier message: 08/07/2015, 12h47
  2. Pourquoi les builds échouent si souvent ?
    Par Arsene Newman dans le forum Actualités
    Réponses: 17
    Dernier message: 03/07/2014, 17h18
  3. [Processeur] Pourquoi les moteurs 3d sont souvent limité par le cpu
    Par Fifou625 dans le forum Composants
    Réponses: 1
    Dernier message: 04/08/2011, 19h10
  4. Pourquoi les projets ERP prennent beaucoup de temps?
    Par kisitomomotene dans le forum Forum général ERP
    Réponses: 2
    Dernier message: 29/01/2008, 17h33
  5. [WSAD] pas les projets RAD ???
    Par jaoued dans le forum Eclipse Java
    Réponses: 3
    Dernier message: 17/01/2005, 10h46

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