+ Répondre à la discussion Actualité déjà publiée
Page 6 sur 9 PremièrePremière ... 23456789 DernièreDernière
Affichage des résultats 101 à 120 sur 175
  1. #101
    Membre régulier
    Inscrit en
    janvier 2011
    Messages
    51
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 51
    Points : 70
    Points
    70

    Par défaut

    Mais enfin que voudrais tu que fasse les gens incompétents sinon???
    Il faut les intégrer quand même, c'est de la discrimination sinon !
    Au mur et une balle dans la tête

    Sinon, je ne connaissais pas ce Dilbert. Je vais de ce pas checker qui c'est ...

  2. #102
    Membre émérite

    Inscrit en
    janvier 2006
    Messages
    967
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 967
    Points : 890
    Points
    890

    Par défaut

    Citation Envoyé par el_slapper Voir le message

    Parfois, même des professionels se font surprendre par la vraie difficulté de créer une appli complète, et pas seulement son code(qui lui-même n'est pas forcément trivial).

    Alors que le maçon, on le voit poser ses briques.
    On peut ajouter que même entre pros, on a beaucoup de mal à estimer le temps de travail des uns et des autres sur des technos différentes.
    Pour prendre l'exemple d'un gars qui code un peu, mais dont ce n'est pas l'activité principale (moi), je n'ai pas vraiment d'idée du nombre de jours/homme qu'il faut pour développer un projet "fini". Concevoir / développer, ok, j'ai une petite idée, mais documenter, tester, mettre en intégration... tout ça, à moins d'être un "vrai" développeur, c'est très difficile d'en avoir une idée précise.

    Je pense qu'on manque beaucoup en France de "bricoleurs", pas informaticiens de formation, qui savent faire leurs propres outils avec un peu de VBA, de C++ ou de PHP à partir de briques bien conçues.

  3. #103
    Membre habitué
    Inscrit en
    mars 2007
    Messages
    64
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 64
    Points : 148
    Points
    148

    Par défaut

    Citation Envoyé par Carhiboux Voir le message

    L'ignorance des décideurs

    Comme cité par d'autres avant moi. L'absence de connaissance dans le domaine informatique semble même être devenu une norme ou un prérequis pour accéder à des postes à hautes responsabilités. Tous les hauts postes dans les sociétés d'informatiques un peu conséquentes sont tous occupés par des personnes de formation commerciale.
    Effectivement, de plus en plus de DSI sont d'origine HEC ou autres écoles de commerce. Tout simplement parce que l'informatique n'est qu'un centre de coût et n'est pas vue comme un facteur d'innovation pour la boîte.

    Bien que simple développeur, j'avais lu il y a quelque temps le livre d'Yves Cazeau Performance du système d'information : Analyse de la valeur, organisation et management, Neuf scènes de la vie quotidienne d'un DSI. L'auteur y mettait bien en évidence ce problème et donnait des pistes pour rendre visible les gains dus à l'informatique.

  4. #104
    Nouveau Membre du Club
    Homme Profil pro Jean-Christophe Blanchard
    Inscrit en
    janvier 2010
    Messages
    17
    Détails du profil
    Informations personnelles :
    Nom : Homme Jean-Christophe Blanchard

    Informations forums :
    Inscription : janvier 2010
    Messages : 17
    Points : 35
    Points
    35

    Par défaut

    Ce qui m'a le plus surpris c'est le manque de procédure standardisée, chaque projet dans chaque entreprise est traité différemment, on est pas dans un process standard tel qu'enseigné en théorie.
    Egalement surprenant c'est le mélange de compétents et d'incompétents dans une entreprise (les plus compétents étant souvent moins bien payé : syndrome de Peter ?, les incompétents et paresseux rarement virés, situation peut être typiquement française), une fois j'ai travaillé chez un gros client, projet de 20 personnes et aucune stratégie de test rééllle (5 ans plus tard appli toujours instable m'a ton dit ;-) )...

  5. #105
    Membre Expert
    Avatar de Pelote2012
    Homme Profil pro Yannick Leborgne
    Développeur informatique
    Inscrit en
    mars 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Nom : Homme Yannick Leborgne
    Âge : 33
    Localisation : France, Haute Vienne (Limousin)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2008
    Messages : 832
    Points : 1 625
    Points
    1 625

    Par défaut

    Ayant commencé dans une SSII, ce qui m'a frappé c'est 2 ou 3 gars hyper balaise sur lesquels l'agence s'appuyé beaucoup dessus (pas de bol pour eux ils sont partis chez des concurrents pour être mieux payés).
    Le reste pas très ordonnés, ne surtout rien dire sur la qualité du boulot des gars qui sont là depuis 20 ans (on se demande pourquoi il s sont toujours là)
    Et dès qu'une personne quitte un projet, tous les malheurs sont de sa faute ...
    J'ai aussi vu des gars partir et revenir (salaire + 50% = 30% par le concurrent + 20% car l'agence ne pouvait pas se passer de lui sur un gros projet , vive le turn over) comme quoi, il n'y a pas que les patrons qui se font avoir (d'un autre côté, il paieraient correctement ...)

    Bref je me suis barré de là (en plus je n'avais plus de vie de famille), j'ai trouvé un boulot sympa dans une petit boîte sympa, je revie
    Si débugger est l'art d'enlever les bugs ... alors programmer est l'art de les créer

  6. #106
    Expert Confirmé Sénior
    Avatar de shenron666
    Homme Profil pro Tony BAYART
    Ingénieur développement logiciels
    Inscrit en
    avril 2005
    Messages
    2 319
    Détails du profil
    Informations personnelles :
    Nom : Homme Tony BAYART
    Âge : 38
    Localisation : France, Val de Marne (Île de France)

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

    Informations forums :
    Inscription : avril 2005
    Messages : 2 319
    Points : 4 865
    Points
    4 865

    Par défaut

    5 - L’interaction avec les personnes

    À force de passer du temps devant son ordinateur à coder, on pense que la programmation est un travail solitaire. Pourtant, c’est étonnant le nombre d’interactions avec d’autres personnes en entreprise (réunion, conversation avec des bêta-testeurs, discussion avec des collègues, etc.).
    ça me fait halluciner d'imaginer que le gars n'ai pas eu un projet à plusieurs à concrétiser pour obtenir son diplôme
    et quand on réalise un projet à plusieurs, bah on reste pas dans son coin

    4 - Le problème de l’écriture

    Cela aide beaucoup d’être capable d’écrire clairement afin de passer un message. Dans une certaine mesure, la rédaction du code et l’écriture sont tout à fait semblables. Dans les deux cas, vous devez exprimer vos idées clairement et sans ambigüité, d’une manière structurée.
    idem que le point précédent quand on doit rédiger une doc, ou une thèse, ou commenter son code pour un jury...
    comment est-ce possible de ne découvrir cela qu'une fois en entreprise

    3 - Un logiciel n’est jamais terminé

    « Avant mon premier travail, je pensais que lorsque vous avez développé une fonctionnalité, vous en avez fini » écrit Warne « Cependant, en réalité, très souvent vous revenez dessus. Peut-être parce que ce n’était pas exactement ce que le client voulait, il faut fixer un bug ou ajouter quelque chose de nouveau ».
    en fait, durant ses études, il n'a jamais développé de programme complexe
    juste des fonctionnalités

    Warne ajoute qu’il ne comprenait pas pourquoi les nouvelles fonctionnalités étaient presque toujours introduites dans un code existant. Ceci à cause du fait de toujours développer des programmes à partir de zéro à l’université, ce qui n’est presque jamais le cas en entreprise.
    euh, une nouvelle fonctionnalité c'est... nouveau, en plus, donc forcément dans un code existant
    et ça rejoint mon commentaire précédent...

    2 - Quelques algorithmes intelligents

    Pendant le cycle universitaire, sont enseignés des structures de données et algorithmes intelligents, dont on s’attend à trouver dans les systèmes en entreprise. Cependant, ce sont des structures de données et des algorithmes assez basiques qui sont utilisés dans le monde du travail, d’après Warne.
    j'utilise les algorithmes les plus adaptés à la situation, pas forcément les plus basiques, et souvent je dois tester pour trouver le plus efficace voire "tuner", ajuster un algorithme pour un cas avec des particularités
    il devrait peut être changer de boulot...

    1 - La complexité de l’agrégation

    Au vu des algorithmes et structures basiques utilisés dans les programmes, Warne pensait qu’il n’y aurait pas de nombreux défis à travailler sur le système. Ce qui était faux, car le système était extrêmement compliqué à cause du nombre important de fonctionnalités simples qui étaient regroupées ensemble. « La complexité d’un système provient de l'agrégation d'un grand nombre de pièces simples, pas de toutes les pièces complexes » conclut Warne.
    ça dépend du programme
    c'est vraiment un senior ? ou c'est juste un gars qui a des années d'expériences dans un seul job de dev ?
    quand on a fait plusieurs boites et plusieurs domaines fonctionnels divers et variés, on ne peut pas avoir ce genre de réflexion, ou alors on a pas eu de boulot intéressant
    ou du moins, c'est ce que je ressent quand je lis ça

    au final, j'ai l'impression que le gars a eu des études basiques baclées incomplètes
    et a décroché un boulot inintéressant
    il ne tient qu'à lui de changer et rendre sa VDM plus intéressante
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  7. #107
    Membre du Club
    Homme Profil pro Bayrone Laurd
    Recherche et développement en décolletage
    Inscrit en
    janvier 2010
    Messages
    20
    Détails du profil
    Informations personnelles :
    Nom : Homme Bayrone Laurd
    Localisation : France

    Informations professionnelles :
    Activité : Recherche et développement en décolletage
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2010
    Messages : 20
    Points : 44
    Points
    44

    Par défaut Idem

    Amis développeurs, (cela ne vous rassurera pas), mais sachez que dans l'industrie métallurgique, cest exactement la même chose.

  8. #108
    Membre émérite
    Homme Profil pro Jean Paul
    Ingénieur développement logiciels
    Inscrit en
    novembre 2008
    Messages
    201
    Détails du profil
    Informations personnelles :
    Nom : Homme Jean Paul
    Localisation : France

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

    Informations forums :
    Inscription : novembre 2008
    Messages : 201
    Points : 816
    Points
    816

    Par défaut

    Citation Envoyé par laurdbayrone Voir le message
    Amis développeurs, (cela ne vous rassurera pas), mais sachez que dans l'industrie métallurgique, cest exactement la même chose.
    Cela ne me rassure pas du tout

  9. #109
    Expert Confirmé Sénior
    Avatar de shenron666
    Homme Profil pro Tony BAYART
    Ingénieur développement logiciels
    Inscrit en
    avril 2005
    Messages
    2 319
    Détails du profil
    Informations personnelles :
    Nom : Homme Tony BAYART
    Âge : 38
    Localisation : France, Val de Marne (Île de France)

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

    Informations forums :
    Inscription : avril 2005
    Messages : 2 319
    Points : 4 865
    Points
    4 865

    Par défaut

    Citation Envoyé par laurdbayrone Voir le message
    Amis développeurs, (cela ne vous rassurera pas), mais sachez que dans l'industrie métallurgique, cest exactement la même chose.
    bah c'est la même chose partout... ou pas
    ça dépend du point de vue de la personne, de son parcours, tant éducatif que professionnel, de l'environnement professionnel, de la persistance de l'existant, etc...

    et aussi de la volonté de la personne à ne pas rentrer dans un moule qui ne lui convient pas
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  10. #110
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 2 003
    Points
    2 003

    Par défaut

    Citation Envoyé par laurdbayrone Voir le message
    Amis développeurs, (cela ne vous rassurera pas), mais sachez que dans l'industrie métallurgique, cest exactement la même chose.
    Dans la métallurgie, le PDG sait que l'acier existe.

  11. #111
    Membre Expert Avatar de Squisqui
    Inscrit en
    décembre 2010
    Messages
    367
    Détails du profil
    Informations forums :
    Inscription : décembre 2010
    Messages : 367
    Points : 1 042
    Points
    1 042

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    Dans la métallurgie, le PDG sait que l'acier existe.
    Preuve que la métallurgie possède les mêmes soucis.
    Résumer l'acier à la métallurgie, c'est comme résumer le développement logiciel à pisser du code.
    Les alliages sont magiques au même titre que le développement logiciel pour le monsieur en haut.
    Je pense que les métallurgistes doivent faire la gueule lorsqu'on leur annonce qu'ils doivent produire un métal aux propriétés fantaisistes en un temps irraisonnable.

  12. #112
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 2 003
    Points
    2 003

    Par défaut

    Bon, j'y connais rien en métalurgie, donc la métaphore va se stopper rapidement.

    Cependant, je suis à peu près sur que le chef est capable de comprendre qu'un alliage est plus solide d'un autre, plus souple ou je ne sais quoi.

    En d'autres termes, le PDG ne connais rien au détail, mais soyons sérieux, ce n'est pas son métier. Cependant, il ne crois pas que le métal sort d'une boita magique (le fait qu'il paye des fournisseurs pour cela doit grandement aider).

  13. #113
    Expert Confirmé Avatar de ManusDei
    Homme Profil pro
    esclave du Grand Capital
    Inscrit en
    février 2010
    Messages
    1 279
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : esclave du Grand Capital

    Informations forums :
    Inscription : février 2010
    Messages : 1 279
    Points : 2 921
    Points
    2 921

    Par défaut

    Ce qui m'a le plus surpris lors des premiers pas en enterprise.

    Le bordel ambiant.
    Les tâches sont plus ou moins distribuées, mais y a toujours des moments où on va se retrouver à bosser sur autre chose, de non prévu (qui aurait dû être fait par quelqu'un d'autre qui n'a pas le temps, par exemple). On râle aussi pas mal sur l'administration, mais j'ai l'impression que c'est pareil en entreprise.

    L'expertise
    Ou plutôt le manque de, parfois. Pas le temps semble être le mot d'ordre, donc pas mal de choses sont bidouillées. Et ensuite faut savoir où ranger les bidouilles pour qu'elles soient retrouvables pour la fois suivante. Je suis dans une SSII, bien sûr on range la bidouille en interne, donc si une autre boîte prend le relais, ils recoderont les bidouilles.

    La réinvention de la roue
    J'ai à mon actif 3 stages de 6 mois, dans 3 entreprises différentes (dont celle qui m'a embauché). J'ai revu les projets de mes deux premiers stages, sous d'autres noms et d'autres formes dans les entreprises suivantes (codés en interne), et apparemment d'autres entreprises les ont refaits aussi.
    Je commence presque à comprendre le pourquoi du libre, même si c'est probablement autant le bordel.
    http://www.traducteur-sms.com/ On ne sait jamais quand il va servir, donc il faut toujours le garder sous la main

  14. #114
    Membre émérite
    Homme Profil pro Jean Paul
    Ingénieur développement logiciels
    Inscrit en
    novembre 2008
    Messages
    201
    Détails du profil
    Informations personnelles :
    Nom : Homme Jean Paul
    Localisation : France

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

    Informations forums :
    Inscription : novembre 2008
    Messages : 201
    Points : 816
    Points
    816

    Par défaut

    Pour résumer.

    Ce qu'on apprend a l'école et que l'on imagine être (en mieux et plus Pro) en entreprise:
    http://fr.wikipedia.org/wiki/Unified_Modeling_Language
    http://fr.wikipedia.org/wiki/Cycle_en_V
    http://fr.wikipedia.org/wiki/M%C3%A9thode_agile
    http://fr.wikipedia.org/wiki/Unified_Process
    etc.

    Ce que l'on découvre réellement en entreprise:
    http://www.risacher.com/la-rache/index.php?z=2

    Quand on connait la méthode LaRache et que l'on découvre que c'est la méthode réellement utilisé dans la plupart des SSII. On a tout comprit

  15. #115
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 2 003
    Points
    2 003

    Par défaut

    Citation Envoyé par ElJipi Voir le message
    Quand on connait la méthode LaRache et que l'on découvre que c'est la méthode réellement utilisé dans la plupart des SSII. On a tout comprit
    80% des projets informatiques sont des échecs (pa rentables car trop cher, ne répondant pas aux besoins, jamais fini, etc ...). Ça a peut-être un lien.

  16. #116
    Expert Confirmé Avatar de jabbounet
    Homme Profil pro frederic frances
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 911
    Détails du profil
    Informations personnelles :
    Nom : Homme frederic frances
    Âge : 39

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 911
    Points : 2 968
    Points
    2 968

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    80% des projets informatiques sont des échecs (pa rentables car trop cher, ne répondant pas aux besoins, jamais fini, etc ...). Ça a peut-être un lien.
    Ceci dit l'expression et la compréhension du besoin est en lui même un domaine sous-estimé..... En dix ans de boulot j'ai eu assez rarement de cahier des charges suffisamment clair pour commencer à travailler dans de bonnes conditions. Les rares fois ou c’était le cas cela venait de gens qui avait à la fois la connaissance métier (ou en tout cas le comprenait) et la connaissance technique associé (évite les besoin délirant et non réalisable ou trop couteux)....

    Lors du déroulement du projet il faut aussi apprendre à être ni trop perfectionniste (explose les délais), ni trop peu (réduit la qualité donc augmente les retours et les cout de maintenance).
    ....

    Bref tout un tas de chose compliqué à équilibrer dans un projet avec plein d'inconnues et des humains pour travailler dessus.

    Autrement pour ce qui m'as surpris, pas grand chose si ce n'est que parfois les gens ne travaillent pas tous dans la même direction (faire que les projets marchent et créent de l'activité) et se tirent dans les pattes parfois au point de planter une activité.
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  17. #117
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro Pierre Caboche
    Inscrit en
    octobre 2005
    Messages
    2 673
    Détails du profil
    Informations personnelles :
    Nom : Homme Pierre Caboche
    Âge : 34
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 673
    Points : 8 981
    Points
    8 981

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    80% des projets informatiques sont des échecs (pa rentables car trop cher, ne répondant pas aux besoins, jamais fini, etc ...). Ça a peut-être un lien.
    Pas du tout.

    Ici, il y a confusion entre la cause et la conséquence (et vous allez vite comprendre pourquoi la méthode La Rache est si répandue...).


    Recette pour un projet (informatique ou autre) qui échoue :

    Ingrédients:

    - un commercial payé a la com'

    - un système de mesure des performances du commercial complètement biaisé (ex: basé uniquement sur la valeur des contrats qu'il décroche)

    Notez que l'ingénieur n'apparait pas du tout dans la liste des ingrédients. C'est normal....

    Étapes:

    1. Laisser le commercial discuter avec le client (il est important que le commercial soit motivé uniquement par sa com' et que la réussite ou l'echec du projet n'ait aucune incidence sur celle-ci. Si ça plante, on dira que c'est la faute de l'ingénieur)

    2. Attendre que le commercial revienne, tout fier de lui, en disant: "hé les mecs, j'ai décroché le contrat du siècle ! Le client avait l'air super emballé par l'idée ! Maintenant que j'ai fait le plus dur (convaincre le client) tout ce qu'il vous reste à faire, c'est développer un "warp drive engine" en 3 mois. Je ne sais pas ce que c'est, mais rien que le nom ça a l'air super cool ! "

    3. Réaction de l'ingénieur :

    Évidemment, ceci est une caricature... (tout le monde sait bien qu'il faut au minimum 4 mois pour développer un warp drive engine... )



    L'idée de base, c'est que même avec les meilleurs ingénieurs du monde, si on a des projets irréalistes ou à produire dans des délais fantaisistes ou avec des ressources insuffisantes, on court inévitablement à la catastrophe. Dans ce cas, dépités, il arrive que même les meilleurs ingénieurs se tournent vers la "méthodologie" La Rache (vu que le projet est condamné d'avance, autant se tourner vers une méthodologie qui demandera moins d'efforts et qui est plus facile à mettre en place... )


    Le pire, c'est que certaines personnes jugées "importantes" dans la hierarchie d'une société sont en fait incroyablement remplaçables. Par exemple, en ce moment, j'ai un "chef de projet"/commercial en France, si on demain on me le remplaçait par un perroquet dénué d'intelligence, qui ne comprend rien à ce qu'on lui dit, et ne ferait que répéter "bon, quand est-ce que tu peux nous livrer ?", je ne suis pas sur de pouvoir faire la différence (surtout que je ne communique avec lui que par e-mail ou par téléphone).

    Bref si on me le remplaçait par un perroquet, ça ressemblerait un peu à ça:
    http://dilbert.com/strips/comic/1995-04-23/
    ou plus généralement à ça:
    http://search.dilbert.com/search?w=turing+test

    Bref, je sens que je vais être content de le quitter celui-là...

  18. #118
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 189
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 189
    Points : 10 584
    Points
    10 584

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    80% des projets informatiques sont des échecs (pa rentables car trop cher, ne répondant pas aux besoins, jamais fini, etc ...). Ça a peut-être un lien.
    Outre l'excellente réponse de pcaboche, j'aimerais pointer le fait que le mot "echec" a pas mal de définitions différentes.

    Si on compte tous les projets qui n'ont pas donné dans le temps prévu l'ensemble des fonctionnalités prévues, effectivement, on ne doit pas être loin de 80%. Mais on a aussi des projets qui livrent dans les délais un ensemble incomplet mais utilisable, des projets qui livrent en retard la totalité des composants, etc.....

    Et si pcaboche a raison de taper sur les commerciaux, nous les techniciens ne sommes pas forcément parfaits non plus. Nous avons tendance à nous faire plaisir, et ça donne des monstres à 500 milliards que des gens sensés abandonnent dès que possible.
    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. #119
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 2 003
    Points
    2 003

    Par défaut

    Citation Envoyé par pcaboche Voir le message
    Pas du tout.

    Ici, il y a confusion entre la cause et la conséquence (et vous allez vite comprendre pourquoi la méthode La Rache est si répandue...).

    Recette pour un projet (informatique ou autre) qui échoue :

    Ingrédients:

    - un commercial payé a la com'

    - un système de mesure des performances du commercial complètement biaisé (ex: basé uniquement sur la valeur des contrats qu'il décroche)

    Notez que l'ingénieur n'apparait pas du tout dans la liste des ingrédients. C'est normal....

    Étapes:

    1. Laisser le commercial discuter avec le client (il est important que le commercial soit motivé uniquement par sa com' et que la réussite ou l'echec du projet n'ait aucune incidence sur celle-ci. Si ça plante, on dira que c'est la faute de l'ingénieur)

    2. Attendre que le commercial revienne, tout fier de lui, en disant: "hé les mecs, j'ai décroché le contrat du siècle ! Le client avait l'air super emballé par l'idée ! Maintenant que j'ai fait le plus dur (convaincre le client) tout ce qu'il vous reste à faire, c'est développer un "warp drive engine" en 3 mois. Je ne sais pas ce que c'est, mais rien que le nom ça a l'air super cool ! "

    3. Réaction de l'ingénieur :

    Évidemment, ceci est une caricature... (tout le monde sait bien qu'il faut au minimum 4 mois pour développer un warp drive engine... )



    L'idée de base, c'est que même avec les meilleurs ingénieurs du monde, si on a des projets irréalistes ou à produire dans des délais fantaisistes ou avec des ressources insuffisantes, on court inévitablement à la catastrophe. Dans ce cas, dépités, il arrive que même les meilleurs ingénieurs se tournent vers la "méthodologie" La Rache (vu que le projet est condamné d'avance, autant se tourner vers une méthodologie qui demandera moins d'efforts et qui est plus facile à mettre en place... )
    On remarque ici que tout le monde à un comportement rationnel. Le blâme reviens donc à ceux qui fixent les règles du jeu.

    S'il est clair que ce schema est répandu, tu as aussi celui du projet qui échoue car on a toujours fait selon LaRache. J'ai pu constater le phénomène récemment. C'est plus pernicieux : au début ça marche, et on dev vite. Puis, le soft se révèle avoir quelques défaut pratiquement incorrigibles, dont l'origine elle même est relativement inconnue. Bien sur, il s'est écoulé quelques années dans le process. C'est l'effet soufflet au fromage : ça gonfle bien au début, mais ça se dégonfle aussi vite.

  20. #120
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro Pierre Caboche
    Inscrit en
    octobre 2005
    Messages
    2 673
    Détails du profil
    Informations personnelles :
    Nom : Homme Pierre Caboche
    Âge : 34
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 673
    Points : 8 981
    Points
    8 981

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    On remarque ici que tout le monde à un comportement rationnel. Le blâme reviens donc à ceux qui fixent les règles du jeu.
    Excellente remarque.

    Généralement, ceux qui fixent ces règles absurdes, ce sont les dirigeants, donc des commerciaux (ou anciens commerciaux). Donc finalement, c'est toujours le même problème...

    Citation Envoyé par deadalnix Voir le message
    S'il est clair que ce schema est répandu, tu as aussi celui du projet qui échoue car on a toujours fait selon LaRache. J'ai pu constater le phénomène récemment. C'est plus pernicieux : au début ça marche, et on dev vite. Puis, le soft se révèle avoir quelques défaut pratiquement incorrigibles, dont l'origine elle même est relativement inconnue. Bien sur, il s'est écoulé quelques années dans le process. C'est l'effet soufflet au fromage : ça gonfle bien au début, mais ça se dégonfle aussi vite.
    Juste une question : est-ce que vous vous trouvez dans ce j'appelle "le cycle en 2 temps" ? (voir citation ci-dessous)

    Citation Envoyé par pcaboche Voir le message
    Ce qui m'a toujours amusé dans l'acronyme "RAD", c'est que cela ne veut pas dire "Développement d'Applications Rapides (comme on pourrait le penser de prime abord), mais "Développement Rapide d'Applications". Et dans les faits, c'est surtout: "Développement Rapide d'Applications (souvent très lentes et pas forcément faciles à maintenir)".

    Et dans certains cas, ça se traduit par l'émergence d'un nouveau cycle de développement, que j'appelle "le cycle en 2 temps", malheureusement de plus en plus en vogue:

    1er temps:
    - l'entreprise exprime un besoin, elle fait un appel d'offres
    - un consultant arrive et propose sa solution
    - le consultant fait du RAD et respecte les délais
    - le client est content, le consultant touche son gros chèque
    - on met la solution en prod

    2ème temps:
    - au bout d'un certain temps d'exploitation, les problèmes de volumétrie/charge apparaissent
    - on fait appel à un "spécialiste" pour corriger les défauts de "cette grosse m**** d'application" (dixit les utilisateurs)
    - au bout d'un moment (3 ou 4 entreprises où on retrouve le même genre de problème), le "spécialiste" en a ras le c*l de devoir essuyer les m***** de ces consultants à la c*n

    J'ai volontairement mis le terme "spécialiste" entre guillemets. En fait, ce qui en fait "spécialiste", c'est qu'il sait se retrousser les manches plutôt que d'utiliser des outils pour gamins censés lui mâcher le travail...

    Il existe une variante, qui est le cycle en 3 temps. C'est la même chose que le cycle en 2 temps, mais avec une extension:

    3ème temps:
    - on sous-traite les évolutions du système dans un pays du tiers-monde où les gens s'en fichent parce qu'ils sont payés au lance-pierre pour travailler sur des applications où tout le monde a jeté l'éponge depuis longtemps
    - on demande au dernier spécialiste en place de faire un "transfert de connaissances"
    - si ce n'est pas déjà fait dans le 2ème temps (des raisons personnelles qui l'ont contraint à rester), le spécialiste se casse en disant à tout le monde d' "aller se faire ***** avec un ***** pendant qu'un ****** vous ***** le *****... " (utilisez votre générateur d'insultes préféré pour remplir les blancs)

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •