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

Solutions d'entreprise Discussion :

Pourquoi les projets de développement échouent-ils ? les développeurs accusent la complexité et le coût élevé


Sujet :

Solutions d'entreprise

  1. #1
    Communiqués de presse

    Femme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2018
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mai 2018
    Messages : 1 503
    Points : 47 888
    Points
    47 888
    Par défaut Pourquoi les projets de développement échouent-ils ? les développeurs accusent la complexité et le coût élevé
    Pourquoi les projets de développement échouent-ils ? 92 % des développeurs et architectes de logiciels accusent la complexité, le coût et les risques élevés associés à ces projets, selon vFunction

    Pourquoi les projets de développement échouent-ils ? Et peut-être plus important encore, qu'est-ce que les cadres supérieurs doivent comprendre sur les raisons de ces échecs ? Ce sont les questions auxquelles une nouvelle étude de la plateforme d'IA vFunction se propose de répondre.

    Basée sur une enquête menée par Wakefield Research auprès de 250 développeurs et architectes de logiciels américains, à un niveau supérieur dans des entreprises de 5 000 employés ou plus, elle examine les différences d'objectifs, de défis et de raisons d'échec entre les chefs d'entreprise et les architectes.

    Alors que 92 % des répondants prévoient de moderniser leurs applications ou sont en train de le faire, l'étude révèle que les projets de modernisation se sont avérés complexes, coûteux et risqués. Quatre responsables des logiciels et de l'architecture sur cinq déclarent qu'un projet de modernisation des applications a échoué en cours de route, et 74 % des personnes interrogées affirment que le projet type de modernisation des applications coûte plus d'un million de dollars, avec une moyenne de près de 1,5 million de dollars.

    Au-delà du coût financier élevé, le temps est un facteur important. 58 % des responsables des logiciels et de l'architecture affirment que l'effort type de modernisation des applications prend plus d'un an, avec une moyenne de 16 mois par projet, et plus d'un quart (27 %) disent que cela prend deux ans ou plus.

    L'un des principaux problèmes est que les luttes organisationnelles internes et le manque d'harmonisation entre les équipes commerciales et technologiques mettent en péril les efforts de modernisation des applications avant même qu'ils ne soient lancés, au point que 97 % d'entre eux prévoient que quelqu'un dans leur organisation repoussera un projet proposé. 43 % des personnes ayant connu des échecs dans le domaine de la modernisation des applications attribuent ces échecs au fait que les attentes n'ont pas été correctement définies, tandis que 37 % d'entre elles les attribuent aux changements de structure organisationnelle nécessaires.

    Nom : vFunction Color Logo on White med.png
Affichages : 16570
Taille : 188,3 Ko

    Les architectes logiciels, quant à eux, citent le "manque d'outils intelligents" comme la première cause d'échec. La lutte contre les outils inefficaces et les compétences et la formation nécessaires pour moderniser est un thème commun aux architectes interrogés, car "trop complexe", "compétences ou formation inadéquates" et "incapacité à définir correctement les attentes" sont tous trois à égalité pour la deuxième raison la plus fréquente d'échec.

    "Étant donné le coût et la durée de ces projets, il est essentiel de comprendre pourquoi ils sont réussis et pourquoi ils échouent ; l'enjeu est important. L'étude révèle que le coût, le risque et la complexité sont tous des obstacles reconnus aux projets de modernisation et que "lever et déplacer" n'est plus considéré comme un résultat de modernisation réussi", dit Moti Rafalin, PDG de vFunction. "Les architectes sont parfaitement conscients des avantages commerciaux de ces projets pour l'entreprise et ont besoin que la direction comprenne pourquoi les projets de modernisation des applications échouent. Ils ont besoin de la C-suite pour aligner et former l'équipe au succès et aider à construire l'analyse de rentabilité nécessaire pour obtenir le budget et les ressources nécessaires. Plus important encore, les architectes ont besoin d'outils intelligents pour leur travail."

    Source : vFunction

    Et vous ?

    Trouvez-vous ce rapport pertinent ?
    Quelles sont, selon vous, les principales causes de l'échec d'un projet ?

    Voir aussi :

    F5 révèle les avantages liés à l'accélération de la transformation numérique : les entreprises abordent la complexité avec des solutions d'IA et de SRE, et concilient modernisation et sécurité

    AWS Mainframe Modernization, le service de migration des charges de travail mainframe vers le cloud, est disponible, des analystes redoutent que la dette technique finisse par vous rattraper

    Pour une entreprise sur quatre, la moitié des projets d'IA échouent, d'après les résultats d'une enquête d'IDC
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre chevronné
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    756
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : août 2003
    Messages : 756
    Points : 2 041
    Points
    2 041
    Par défaut
    Quelles sont, selon vous, les principales causes de l'échec d'un projet ?
    - trop d'ambition de livrer tout d'un coup plutôt que de livrer les fonctionnalités au fur et à mesure
    - délais trop courts, budget trop serré, client radin qui a sous-estimé le coût du logiciel
    - la complexité et ça se voit avec les offres d'emploi, les sociétés cherchent des développeurs qui maîtrisent tout la partie DevOps et ne veulent pas dédier la partie CI/CD à une personne tierce qui ne ferait que ça (les CDD et les freelances spécialisés ça existe !). Je vois régulièrement des missions avec la stack suivante : Python, Django/Flask/FastAPI, PostgreSQL/MongoDB/..., React/Vue.js, Jenkins, Docker, Kubernetes, AWS/GCP/Azure/..., RabbitMQ, GraphQL, échanger avec le client pour les besoins, anglais courant (et pas que technique)
    ... pour des salaires pas extraordinaires non plus

  3. #3
    lvr
    lvr est déconnecté
    Membre extrêmement actif Avatar de lvr
    Profil pro
    Responsable de projet fonctionnel
    Inscrit en
    avril 2006
    Messages
    889
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Arts - Culture

    Informations forums :
    Inscription : avril 2006
    Messages : 889
    Points : 1 288
    Points
    1 288
    Par défaut
    Ce qui manque souvent, à mon avis, c'est
    1) Impliquer le client (et qu'il participe) à une véritable réflexion autour de cette modernisation. Répliquer les processus-métiers d'il y a 10 ans avec une nouvelle technologie n'a aucun sens.
    Une modernisation exige aussi une mise à plat, voire une mise à jour des procédures-métier. Un travail aussi de projection sur où veulent-ils aller dans 2, 4, 10 ans. De manière à ne pas créer une application qui sera obsolète dans son démarrage.
    2) (comme dit smarties) un phasage des fonctionnalités.
    3) une bonne gestion des risques faites en amont, que ce soit les risques techniques, légaux, métiers, humains, ...
    4) accepter de que cela prend du temps, avec des étapes qui ne semblent pas toujours utile : enterprise architecture, solution architecture, ciso, ...

    En gros, cela requiert
    * un client suffisamment mature, avec une réelle compréhension voir connaissance de ce qu'est une modernisation informatique,
    * IT qui écoute ses équipes techniques sur le temps/difficultés/enjeux et pas uniquement ses commerciaux.
    * un travail en transparence dans les 2 sens, où les mauvaises nouvelles sont dites tôt et pas les cachées en espérant les rattraper en catimi plus tard.

    Et pour conclure, le problème me semble moins au niveau des outils que des processus.

  4. #4
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    1 213
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 1 213
    Points : 4 296
    Points
    4 296
    Par défaut
    Quelles sont, selon vous, les principales causes de l'échec d'un projet ?


    Ben, cela dépend de qui répond à la question...

    Pour le client ou le manager, c'est le développeur qui est nul...

    Pour le développeur, c'est le client qui ne sait pas ce qu'il veut et le manager qui ne sait pas gérer un projet...

  5. #5
    lvr
    lvr est déconnecté
    Membre extrêmement actif Avatar de lvr
    Profil pro
    Responsable de projet fonctionnel
    Inscrit en
    avril 2006
    Messages
    889
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Arts - Culture

    Informations forums :
    Inscription : avril 2006
    Messages : 889
    Points : 1 288
    Points
    1 288
    Par défaut
    Ah Anselme45, je suis toujours heureux de te voir débarquer sur une discussion où je suis actif. T'es toujours là pour faire avancer le débat dans un sens constructif et réfléchi.

  6. #6
    Membre éprouvé
    Homme Profil pro
    retraité
    Inscrit en
    septembre 2014
    Messages
    470
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : septembre 2014
    Messages : 470
    Points : 1 159
    Points
    1 159
    Par défaut
    Pour voir ce rapport il faut donner des informations personnelles. Donc je ne lirai pas ce rapport, faut pas pousser.
    C'est quoi une "C-suite" ???

  7. #7
    Membre expérimenté
    Homme Profil pro
    Ingénieur avant-vente
    Inscrit en
    septembre 2020
    Messages
    383
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur avant-vente

    Informations forums :
    Inscription : septembre 2020
    Messages : 383
    Points : 1 637
    Points
    1 637
    Par défaut
    Les projets de développement échouent parce que trop de personnes différentes ont voix au chapitre, entre les commerciaux, les chefs de projet, le référent technique chez le client, son chef, le corporate IT manager, etc...

  8. #8
    Expert confirmé Avatar de kain_tn
    Homme Profil pro
    Inscrit en
    mars 2005
    Messages
    1 305
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : mars 2005
    Messages : 1 305
    Points : 5 604
    Points
    5 604
    Par défaut
    Citation Envoyé par Jeff_67 Voir le message
    Les projets de développement échouent parce que trop de personnes différentes ont voix au chapitre, entre les commerciaux, les chefs de projet, le référent technique chez le client, son chef, le corporate IT manager, etc...
    J'ajouterais:
    • Les équipes de ventes qui vendent des délais/coûts intenables sans même avoir une idée de la complexité d'un sujet. Quand ça commence par un "rétroplanning", on sait en général que le projet a de grandes chances de faire un four.
    • La direction qui ne sait pas faire de stratégie et qui change d'avis tous les quatre matins
    • Le management qui fait du micromanagement et qui se mêle des choix techniques (architecture, sécurité, stack technologique, etc)


    On a là toute la recette pour un beau gâchis quand toutes ces conditions sont réunies! Et d'ailleurs, ça ne se limite pas aux projets de développement, mais à un petit peu toutes les industries...
    Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include <stdio.h>
     
    int main(int argc, char **argv) {
     
        printf("So long, and thanks for the fish, Dennis...\n");
        return 0;
    }

  9. #9
    Membre averti
    Profil pro
    Inscrit en
    février 2008
    Messages
    161
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : février 2008
    Messages : 161
    Points : 448
    Points
    448
    Par défaut
    Heuuuuuu, les spec...

    J'ai bon ?

  10. #10
    Membre éclairé
    Homme Profil pro
    ingénieur qualité
    Inscrit en
    mars 2015
    Messages
    240
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : ingénieur qualité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : mars 2015
    Messages : 240
    Points : 899
    Points
    899
    Par défaut
    Etant plutôt coté client je pense qu'il y a aussi des gros problème avant le projet:
    Les clients ne savent pas écrire le cahier des charges de ce genre de projet.
    Certains managers "accompagnent" les clients pour l'améliorer mais le gonflent pour donner (et facturer) plus au client avec des besoins "faciles à mettre en place".
    Comme il n'y a pas forcément de gens techniques coté client, on se rend compte plus tard que ces besoins n'existent pas.
    Comme il n'y a pas forcément de gens techniques coté dév, on se rend compte plus tard qu'ils ne sont pas du tout si faciles à mettre en place.

    A la fin on se retrouve avec un client qui se plaint d'une solution qui ne sort pas à cause d'une chose inutile, et de fournisseurs qui se plaignent qu'on ne veut pas leur payer ce qu'il ne nous ont pas encore livré.
    Et on ne sait pas ce qu'il se passe entre le manager et les dev mais ça ne doit pas être reluisant.

  11. #11
    Membre confirmé
    Profil pro
    Account Manager
    Inscrit en
    mars 2006
    Messages
    148
    Détails du profil
    Informations personnelles :
    Localisation : France, Dordogne (Aquitaine)

    Informations professionnelles :
    Activité : Account Manager

    Informations forums :
    Inscription : mars 2006
    Messages : 148
    Points : 617
    Points
    617
    Par défaut
    Désolé, un peu vieux mais toujours d'actualité à ce que je vois.

    Nom : metaphore_gestion_projet_balancoire_arbre.jpg
Affichages : 2834
Taille : 116,6 Ko

  12. #12
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2019
    Messages
    116
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2019
    Messages : 116
    Points : 571
    Points
    571
    Par défaut
    Vu le management toxique en place dans beaucoup d'entreprises, et le principe de Peter qui fait que plein d'incompétents se retrouvent dans des postes de décision, ça ne m'étonne pas que les projets échouent.

  13. #13
    Membre émérite
    Inscrit en
    janvier 2006
    Messages
    671
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 671
    Points : 2 470
    Points
    2 470
    Par défaut specifiez.com
    Citation Envoyé par smarties Voir le message
    - la complexité et ça se voit avec les offres d'emploi, les sociétés cherchent des développeurs qui maîtrisent tout la partie DevOps et ne veulent pas dédier la partie CI/CD à une personne tierce qui ne ferait que ça (les CDD et les freelances spécialisés ça existe !). Je vois régulièrement des missions avec la stack suivante : Python, Django/Flask/FastAPI, PostgreSQL/MongoDB/..., React/Vue.js, Jenkins, Docker, Kubernetes, AWS/GCP/Azure/..., RabbitMQ, GraphQL, échanger avec le client pour les besoins, anglais courant (et pas que technique)
    Eh oui, les managers considèrent que plus un projet est complexe meilleur il est. Résultat, tu veux démarrer une appli Angular, t'as à peine tapé "ng new" que ton projet a déjà 150 dépendances d'un bon méga chacune. Pareil en Java, avant même la première servlet t'as déjà une vingtaine de jars (et en plus dans le git, beurk) plus une couche DAO, une couche services, une couche client, une couche business et j'en oublie probablement encore trois ou quatre. Ensuite on fait un copier-coller de tout ça une trentaine de fois et on appelle ça un micro-service...

    Citation Envoyé par lvr Voir le message
    1) Impliquer le client (et qu'il participe) à une véritable réflexion autour de cette modernisation.
    Impliquer le développeur aussi, pas seulement les "analystes" qui te pondent des specs immondes à prendre au pied de la lettre.

    Citation Envoyé par lvr Voir le message
    Répliquer les processus-métiers d'il y a 10 ans avec une nouvelle technologie n'a aucun sens.
    Ah si seulement mon client pouvait lire ça... Parce qu'actuellement la politique c'est: on achète le plus gros produit du marché et ensuite les développeurs ne font que de l'intégration coûte que coûte, en multipliant au maximum le nombre de couches d'abstraction inutiles juste pour que l'ancien workflow ait encore une chance de fonctionner...

    Citation Envoyé par Jeff_67 Voir le message
    entre les commerciaux, les chefs de projet, le référent technique chez le client, son chef, le corporate IT manager, etc...
    Donc, pour la plupart, des gens qui n'ont jamais codé plus qu'un hello world dans leur vie (je note l'absence des développeurs dans ta liste). Les devs, ils sont juste là pour suivre les specs et servir de bouc émissaire si elles étaient mauvaises dès le départ.

  14. #14
    Expert confirmé Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    mars 2014
    Messages
    1 487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : mars 2014
    Messages : 1 487
    Points : 5 772
    Points
    5 772
    Par défaut
    A tous vous lire, je ne m'étonne plus qu'il y ait des failles énormes dans les softs... voir log4shell
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  15. #15
    Membre chevronné
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    756
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : août 2003
    Messages : 756
    Points : 2 041
    Points
    2 041
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Donc, pour la plupart, des gens qui n'ont jamais codé plus qu'un hello world dans leur vie (je note l'absence des développeurs dans ta liste). Les devs, ils sont juste là pour suivre les specs et servir de bouc émissaire si elles étaient mauvaises dès le départ.
    Je me suis fait avoir une fois car la spec mise à disposition n'était plus bonne, maintenant, je fais toujours un point avec le chef de projet avant de coder une spec

    Après au niveau complexité, je suis partagé entre les applications de type monolithe et les micro-services. Je pense quand même préférer un monolithe avec des modules bien séparés car ça mutualise les ressources et on peut faire de l'asynchrone aussi.

  16. #16
    Expert confirmé
    Avatar de GLDavid
    Homme Profil pro
    Team & Project Manager
    Inscrit en
    janvier 2003
    Messages
    2 810
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Team & Project Manager
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : janvier 2003
    Messages : 2 810
    Points : 4 461
    Points
    4 461
    Par défaut
    Bonjour

    Une chose qui fait aussi échouer un projet: la motivation des équipes.
    De mon point de vue, quand on tombe sur des partenaires qui ne sont pas motivés pour un changement ("Ca marche très bien comme ça", "j'ai pas le temps pour le changement"...), le projet est voué à l'échec d'entrée de jeu.
    Le pire, quand vous êtes sous traitant, c'est que vous n'avez aucun pouvoir pour motiver les dits-partenaires. Vous rapportez à des PMOs de votre client qui vous diront: c'est à vous de les motiver, vous êtes là pour ça.

    Mouais, sauf que c'est vous tous qui avez le bâton...
    De la responsabilité des gens et une bonne assignation des tâches, signés par tous les stakeholders

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  17. #17
    Membre chevronné
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    juin 2012
    Messages
    704
    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 : 704
    Points : 1 937
    Points
    1 937
    Par défaut
    Citation Envoyé par smarties Voir le message
    Je me suis fait avoir une fois car la spec mise à disposition n'était plus bonne, maintenant, je fais toujours un point avec le chef de projet avant de coder une spec

    Après au niveau complexité, je suis partagé entre les applications de type monolithe et les micro-services. Je pense quand même préférer un monolithe avec des modules bien séparés car ça mutualise les ressources et on peut faire de l'asynchrone aussi.
    je rajouterais que c'est pas tous les entreprises qui ont besoin de supporter 5000 requêtes simultanés... et qui doivent pousser des fonctionnalités en prod à tous les jours...

    malgré tout, la mode est au microservice même si les besoins y sont souvent pas là

  18. #18
    Membre émérite
    Inscrit en
    janvier 2006
    Messages
    671
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 671
    Points : 2 470
    Points
    2 470
    Par défaut complexe IT
    Citation Envoyé par smarties Voir le message
    Après au niveau complexité, je suis partagé entre les applications de type monolithe et les micro-services. Je pense quand même préférer un monolithe avec des modules bien séparés car ça mutualise les ressources et on peut faire de l'asynchrone aussi.
    Pour ma part je suis tout à fait pour la séparation des fonctionnalités sous forme de modules (jar ou l'équivalent dans d'autres langages) placés dans des git séparés, avec des jeux de test spécifiques.
    En revanche si l'architecture micro-services c'est systématiquement passer par HTTPS + REST + quinze couches de sécurité, beurk.
    C'est bizarre, les programmeurs sont habitués à se connecter à un dépôt Maven (pour Java), CPAN (pour Perl), NPM (pour Javascript) et à y télécharger 200 dépendances avant même d'avoir pondu la moindre ligne de code, en revanche on dirait que personne n'est au courant qu'on peut avoir un dépôt Maven privé (pour ses propres librairies ou pour faire un miroir d'un autre dépôt). Du coup l'idée de créer des librairies qu'on mettrait sur un dépôt corporate partagé ensuite avec toute la boîte... non, faut absolument du web-service avec toute la lourdeur du réseau et ce même si au final on déploie tout sur le même serveur. Et après on nous parle de complexité...
    Autrefois la mode c'était les EJB, ben au moins quand tu contactais un EJB le serveur était assez intelligent pour choisir un protocole local si l'EJB était sur le même serveur que la couche web, tout en étant capable de choisir un protocole réseau si l'EJB était ensuite déplacé. Aujourd'hui faut absolument du HTTPS partout pour tout et surtout pour n'importe quoi. Et après on te parle de complexité, elle est forcément du côté applicatif, surement pas dans les protocoles de communication...

  19. #19
    Membre régulier
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2013
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : octobre 2013
    Messages : 44
    Points : 103
    Points
    103
    Par défaut
    c'est souvent un problème de communication :

    L'utilisateur final remonte le problème à son responsable (qui ne manipule pas lui), qui communique au commercial de la société de service, qui en discute avec le responsable des dev, qui voit avec le chef de projet attribué, qui demande à l'analyste, qui voit avec architecte, qui donne au développeur....

    Au final, on obtient la classique balançoire dans l'arbre ! Il suffirait qu'une fois tout ce petit monde de responsable soit d'accord entre eux dans les grandes lignes, que l'architecte + le développeur puissent discuter avec l'utilisateur final pour obtenir un résultat simple et efficace !

  20. #20
    Membre régulier
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    avril 2022
    Messages
    34
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Industrie

    Informations forums :
    Inscription : avril 2022
    Messages : 34
    Points : 71
    Points
    71
    Par défaut
    Citation Envoyé par marsupial Voir le message
    A tous vous lire, je ne m'étonne plus qu'il y ait des failles énormes dans les softs... voir log4shell
    Ceci n'a pas grand chose à avoir avec le sujet abordé dans les précédents messages... On est sur une faille sur une technologie opensource, maintenue certes par un acteur central(Apache), mais faisant intervenir pléthore d'acteurs ne répondant pas au modèle d'un projet "commercial" comme stipulé ci-haut.

Discussions similaires

  1. Réponses: 106
    Dernier message: 04/08/2022, 20h36
  2. Réponses: 10
    Dernier message: 04/10/2019, 07h25
  3. Réponses: 1
    Dernier message: 08/08/2018, 01h21
  4. Pourquoi les développeurs entrent-ils dans une guerre des tranchées ?
    Par Stéphane le calme dans le forum Débats sur le développement - Le Best Of
    Réponses: 104
    Dernier message: 23/07/2015, 13h54
  5. Pourquoi les développeurs travaillent-ils la nuit ?
    Par Gordon Fowler dans le forum Humour Informatique
    Réponses: 122
    Dernier message: 06/10/2013, 01h30

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