Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 6 sur 8 PremièrePremière ... 2345678 DernièreDernière
Affichage des résultats 101 à 120 sur 147
  1. #101
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 819
    Points
    12 819

    Par défaut

    Citation Envoyé par javamine Voir le message
    Bon, reprenons depuis le début.
    Tu crois vraiment qu'un DSI iraient vendre une migration à son PDG et aux actionnaires en leur disant "Euh oui c'est cher parce qu'il n'y a personne de compétent..." hum...

    Intéresse toi d'un peu plus près à ce qui se passe dans les entreprises. Migrer une application coûte très cher (et surtout très risqué), mais il y a un bon ROI pour les évolutions futures. Regarde les architectures cobol, et celle J2EE et Dotnet après, tu comprendras pourquoi c'est 10 fois moins cher de faire évoluer une application qui n'est pas en cobol (en prenant le cas d'un expert cobol d'un coté, et d'un expert J2EE de l'autre).



    On voit que franchemet tu n'as pas dû beaucoup fréquenté (et subir) les décisions marketing d'importance sur des gros projets...


    Cela n'a pas grand chose à voir avec la technologie nécessaire, et/ou les évolutions en termes de besoins, ou les possibilités, ni avec la finance engagée (de toutes façons, ce sera le client qui paiera). Cela a beaucoup plus à voir avec "qu'est-ce qu'on peut "vendre" qui nous donnera un "plus" par rapport à nos concurrents ?".. Et dans ce cadre, promouvoir qu'on est "à la pointe des avancéées technologiques c'est le nec plus ultra... marketing..

    Car comme ce gars du marketing a en face de lui la plupart du temps un autre gars de marketing ou un administratif qui n'y connait rien, les 2 sont dans le même monde de "buzz"....











    Citation Envoyé par lepinekong Voir le message
    ..snip..
    J'aurai encore beaucoup de choses à dire, mais ce sera pour un autre fil peut-être
    Excellent témoignage, merci


    Mais que rien ne t'empêche d'en dire plus
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  2. #102
    Membre émérite
    Homme Profil pro
    Inscrit en
    décembre 2003
    Messages
    396
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : Conseil

    Informations forums :
    Inscription : décembre 2003
    Messages : 396
    Points : 819
    Points
    819

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    Cela n'a pas grand chose à voir avec la technologie nécessaire, et/ou les évolutions en termes de besoins, ou les possibilités, ni avec la finance engagée (de toutes façons, ce sera le client qui paiera). Cela a beaucoup plus à voir avec "qu'est-ce qu'on peut "vendre" qui nous donnera un "plus" par rapport à nos concurrents ?"..
    Il y a comme qui dirait un malentendu.
    Je parlais d'entreprises "non informatique", où chez eux, la finance passera avant tout pour leur service informatique (puisque c'est eux qui paient et non un éventuel client).

    Tu parles d'entreprises dont leurs métiers est de vendre l'informatique. Tu expliques que c'est par soucis marketing qu'ils prennent des décisions. Qu'est ce qui se cache derrière le marketing? => les retombés financières.
    Tu réduis ce que j'ai dis par "finance engagée" or je te parlais de retour sur investissement. Donc même les soit disantes considération marketing sont égale à "on dépense beaucoup plus mais c'est joli ça nous fera vendre plus"

    On revient donc sur ce que je t'ai dis => on "migre, casse tout, change de techno" (rayer la mention inutile) uniquement quand on se rend compte que même si on engage de grosses dépenses, ça nous fera gagner plus.
    C'est cosmic

  3. #103
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 819
    Points
    12 819

    Par défaut

    Citation Envoyé par javamine Voir le message
    On revient donc sur ce que je t'ai dis => on "migre, casse tout, change de techno" (rayer la mention inutile) uniquement quand on se rend compte que même si on engage de grosses dépenses, ça nous fera gagner plus.
    C'est ce que j'ai dit plus haut : cela n'a rien à voir avec la techno, et ses évolutions/pérennités, mais tout aveec l'argent..

    Ce serait donc au CP de dire : non, on va plus s'emmerder qu'autre chose...


    Citation Envoyé par javamine Voir le message
    C'est un besoin business.
    Les vieilles applications cobol fonctionnent très bien certes, mais dès qu'il s'agit de faire une évolution, de la maintenance, ... cela coûte beaucoup plus cher que si ces applications utilisait, comme tu le dis, ce qui est novateur.
    FAUX..

    C'est uniquement parce que les fomations (BTS, DUT, fax, écoles spécialisées) ne forment plus qu'aux nouvelles technos..


    C'est comme les mécanos automobile : aucun mécano "normal" ne sait s'en sorir avec les voitures de maintenant..

    Pour chaque constructeur il y a des bancs de tests électroniques spécialisés, incompatibles les uns avec les autres..

    Alors je veux bien que vous défendiiez cette pratique, mais je suis résolument et fondamentalement contre...



    Citation Envoyé par javamine Voir le message
    Parfois il faut mieux tout refaire (et dépenser énormément), pour qu'à l'avenir les évolutions soient moins coûteuses, et donc sur le long terme avoir un bon retour sur investissement.
    Tu ne vois pas comme une contradiction, là ??


    Faire le total "dépenses énormes pour refaire" + "dépenses moins coûteuses plus tard" (et je suis très dubitatif sur ce point, en particulier à cause justement du turnover des technos) à comparer à "former les jeunes générations à garder les compatibilités avec l'ancien" ???
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  4. #104
    Membre émérite
    Homme Profil pro
    Inscrit en
    décembre 2003
    Messages
    396
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : Conseil

    Informations forums :
    Inscription : décembre 2003
    Messages : 396
    Points : 819
    Points
    819

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    C'est ce que j'ai dit plus haut : cela n'a rien à voir avec la techno, et ses évolutions/pérennités, mais tout aveec l'argent..
    C'est ce que je disais aussi donc on est d'accord la dessus.

    Citation Envoyé par souviron34 Voir le message
    FAUX..

    C'est uniquement parce que les fomations (BTS, DUT, fax, écoles spécialisées) ne forment plus qu'aux nouvelles technos..
    Tu me dis que c'est faux et après tu donnes un argument qui va dans mon sens. Cherchez l'erreur?
    Mais je suis d'accord, c'est pour ça que ce je dis est vrai et tu le confirmes. On ne forme plus qu'aux nouvelles technos, donc les compétences vieux systèmes sont plus rares donc plus cher.

    Je n'ai jamais dis que je défendais cette pratique, mais les entreprises s'adapte simplement à la réalité des formations actuelles.

    Citation Envoyé par souviron34 Voir le message
    Tu ne vois pas comme une contradiction, là ??
    Non.
    Exemple bidon :
    Coût de maintenance d'une vieille appli : 50 € par an
    Refonte de l'appli : 200 €
    Coût de maintence de la nouvelle appli : 5 € par an

    Au bout de quelque temps on fini par moins dépenser que ce que l'on dépensait avant.

    Citation Envoyé par souviron34 Voir le message
    (et je suis très dubitatif sur ce point, en particulier à cause justement du turnover des technos)
    On peut l'être effectivement. Mais quand tu vois l'ancienneté des vieux systèmes, on peut penser que les nouveaux qui les remplaceront dureront également longtemps. Donc le turnover n'est peut être pas si impactant.

    Citation Envoyé par souviron34 Voir le message
    à comparer à "former les jeunes générations à garder les compatibilités avec l'ancien"
    Possible...Mais de nos jours, trouver des "jeunes" pour travailler sur ces vieux systèmes ne cours pas les rues. Les nouveaux talents sont attirés par ce qui est neuf, ce qui brille, alors ça ne doit pas être évident d'en trouver des bons à former.

    Enfin pour résumer, comme tu le dis, tout à avoir avec l'argent. Quand on fait un choix on fait celui qui semble être le plus viable économiquement. Après si les DSI se sont planté, et que former des gens sur les vieux systèmes auraient été moins cher, moi je m'en fiche, je suis sur les nouvelles technos et ça me fait du travail
    C'est cosmic

  5. #105
    Membre confirmé
    Profil pro Lépine Kong
    Inscrit en
    janvier 2010
    Messages
    207
    Détails du profil
    Informations personnelles :
    Nom : Lépine Kong
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2010
    Messages : 207
    Points : 219
    Points
    219

    Par défaut

    Citation Envoyé par B.AF Voir le message
    ...

    Et avec tout ça, il a encore le droit à une vie le chef de projet ?

    Chacun son truc, mais moi devenir un amas de tâche de couleur parce que des "wise men" l'ont décidé, très peu pour moi.


    Ca suffit un peu ce genre de classification de l'humain idéal, on a l'impression de voir une sélection de barbaque dans des caissettes de supermarché.
    Je suis d'accord

    Chef de projet c'est des fois enviables et des fois non enviables. De plus en plus il y a beaucoup de tâches administratives (reporting ils appellent ça) où des fois tu te demandes si t'as pas fait bac + 5 pour faire du boulot de niveau de secrétariat, donc si tu aimes trop le technique ça va te gonfler. Moi ça va parce que comme à l'origine je suis ingénieur généraliste je m'adapte assez bien à tout que ce soit pour faire des cocottes en papier (des fois tu te demandes vraiment pourquoi ils avaient besoin d'un chef de projet sauf pour le prestige ou pour porter le chapeau au cas où ça tournerait mal) soit pour travailler à un rythme de fou (enfin des fois t'as des envies de meurtre).

    En général, sauf pour les chanceux et planqués, c'est assez stressant parce que le client en veut toujours plus surtout quand c'est du forfait alors que c'est pas facile de motiver des développeurs quand de manière générale il y a eu dévalorisation du métier, donc il faut compter sur leur passion, heureusement il y en a encore.

  6. #106
    Membre Expert
    Inscrit en
    février 2005
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 1 243
    Points : 1 702
    Points
    1 702

    Par défaut

    Citation Envoyé par javamine Voir le message
    Non.
    Exemple bidon :
    Coût de maintenance d'une vieille appli : 50 € par an
    Refonte de l'appli : 200 €
    Coût de maintence de la nouvelle appli : 5 € par an

    Au bout de quelque temps on fini par moins dépenser que ce que l'on dépensait avant.
    Le coût de la maintenance applicative est plus sensible à la qualité de conception et d'utilisation qu'à la technologie de l'application.

    Il veut mieux une équipe de star qui fait une appli en brainfuck qu'une bande de singe qui fait du J2E.

  7. #107
    Membre confirmé
    Profil pro Lépine Kong
    Inscrit en
    janvier 2010
    Messages
    207
    Détails du profil
    Informations personnelles :
    Nom : Lépine Kong
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2010
    Messages : 207
    Points : 219
    Points
    219

    Par défaut

    Envoyé par B.AF Voir le message
    Les gens extraordinaires créent
    Les gens ordinaires maintiennent.
    C'est plus facile de créer que de maintenir le code de zigotos qui ont parfois disparu dans la nature: donc je préfère créer c'est pour ça que je fais des nouveaux projets et jamais des projets de maintenance tout au plus sur des applications existantes je peux être 1/10 du temps Responsable d'Application, car comme tout le monde sait Responsable seulement veut dire Non-Coupable

  8. #108
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 819
    Points
    12 819

    Par défaut

    Je me permet de constater qu'il semble bien il y avoir une différence de point de vue entre "vieux routards" et "jeunes lascars"
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  9. #109
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par javamine Voir le message
    Exemple bidon :
    Coût de maintenance d'une vieille appli : 50 € par an
    Refonte de l'appli : 200 €
    Coût de maintence de la nouvelle appli : 5 € par an

    Au bout de quelque temps on fini par moins dépenser que ce que l'on dépensait avant.
    Ca c'est le discours avant la refonte, celui que tient le jeunot qui n'a pas envie de se cogner du CDA (code des autres, 90% du travail en informatique), et qui croit qu'il saura bâtir en 6 mois ce qu'on n'a pas réussi à refondre en 10 ans...

    Si cette estimation était correcte, et que la refonte dure 1 an, note qu'il faudrait quand même près de 5 ans pour l'amortir au travers des économies de maintenance réalisées. Je connais pas mal de décisionnaires qui hésiteraient: ce n'est pas un bon retour sur investissement. (5 ans, c'est souvent plus que la durée de vie du DSI qui prend la décision...)

    Mais le vrai problème, c'est que les 50€ par an, ils sont connus, certains, sans risque. Les 200€, ils ont tendance à devenir 500, et puis, ils mettent 2 ou 3 fois plus de temps que prévu à arriver (donc on continue à payer les 50 pendant ce temps). Et même si on arrive à quelque chose qui marche aussi bien que l'appli d'origine (je connais pas mal de contre exemples), on découvre à ce moment que la maintenance coutera plus de 5€, parce que dans les 50, il y avait toute une maintenance évolutive qu'on n'avait pas compté dans les 5... En fin de course, on va payer 500, et réaliser une économie de 25 (vs les 200 et 45 prévus) et là, le système s'amortit sur 20 ans... La refonte n'est plus rentable !

    Et ca, bien sur, c'est quand tout va bien... Parfois, le nouveau projet n'aboutit pas, et on reste avec le vieux système, après que le jeune chef de projet qui a vendu la refonte ait décidé de larguer le projet en route, ou que la super techno de la mort sur laquelle on comptait n'a pas tenu ses promesses... Et là, il y a toujours quelqu'un pour dire que moyennant 200 euros de refonte, on pourrait...

    Sérieusement, la plupart des décideurs (DSI et financiers) connaissent ce discours, et ont une mauvaise opinion de la capacité des informaticiens à évaluer les couts et les charges de travail (et ils ont raison). La force des vieilles technologies, c'est non seulement qu'elles sont éprouvées, mais surtout que leurs couts (directs et indirects) sont connus et maîtrisés.

    Quant au fait de "créer" vs "maintenir", bien souvent, en informatique "créer" c'est assembler pêle mêle des bouts de librairies, et laisser à d'autres le soin de les maintenir et de les faire évoluer. La difficulté, ce n'est pas d'assembler les 500 (ou les 5000) premières lignes de code, c'est de les transformer en un produit utilisable, et de les faire évoluer sans avoir besoin de tout refondre tous les 3 ans...

    Je ne crois pas que les gens ordinaires maintiennent (ou plutôt, je ne crois pas qu'ils maintiennent bien)...

    Francois

  10. #110
    Membre Expert
    Inscrit en
    février 2005
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 1 243
    Points : 1 702
    Points
    1 702

    Par défaut

    Citation Envoyé par lepinekong Voir le message
    C'est plus facile de créer que de maintenir le code de zigotos qui ont parfois disparu dans la nature: donc je préfère créer c'est pour ça que je fais des nouveaux projets et jamais des projets de maintenance tout au plus sur des applications existantes je peux être 1/10 du temps Responsable d'Application, car comme tout le monde sait Responsable seulement veut dire Non-Coupable
    Facile à dire sur le papier, créer une application pro, c'est pas une histoire de technique, c'est une histoire d'expérience. Tout le monde peut assembler des technos et des processus, tout le monde ne peut pas concevoir une application avec tout ce que cela implique. Et souvent, ce sont les moins créatifs qui critiquent le plus l'existant. Pour créer du neuf, il faut aimer déplaire, se faire des ennemis, entendre des reproches.
    Je vois qu'à priori concepteur est un métier contraignant que tu ne connais absolument pas. Je ne supporte pas de me dire qu'un de mes "bébés" dysfonctionne et j'y ferai toujours ce qu'il faut. Ceux qui ont voulu les migrer dans des big bangs fabuleux ce sont toujours cassés les dents, sans que je les pousse d'ailleurs.
    Ce n'est pas drôle non plus de voir passer les patchs de maintenance d'un développeur qui n'a rien compris au sujet et qui a créé une dérivation dangereuse.

    L'intelligence de faire de la modélisation objets, ce n'est pas de le faire dans eclipse avec un plugin UML; c'est d'avoir un esprit suffisamment clair pour le faire de la façon la plus optimale possible.

  11. #111
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 819
    Points
    12 819

    Par défaut

    d'ailleurs, à l'inverse, maintenir une application superbement conçue est un plaisir aussi bien intellectuel que pratique...


    (ce qui justement était le cas de l'application dont je parlais plus haut, que certains ont poussé (et réussi malheureusement) pour une décision de refonte...)
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  12. #112
    Membre émérite
    Homme Profil pro
    Inscrit en
    décembre 2003
    Messages
    396
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : Conseil

    Informations forums :
    Inscription : décembre 2003
    Messages : 396
    Points : 819
    Points
    819

    Par défaut

    Citation Envoyé par fcharton Voir le message
    Ca c'est le discours avant la refonte, celui que tient le jeunot qui n'a pas envie de se cogner du CDA (code des autres, 90% du travail en informatique), et qui croit qu'il saura bâtir en 6 mois ce qu'on n'a pas réussi à refondre en 10 ans...
    Desfois ça marche !

    Citation Envoyé par fcharton Voir le message
    Si cette estimation était correcte, et que la refonte dure 1 an, note qu'il faudrait quand même près de 5 ans pour l'amortir au travers des économies de maintenance réalisées. Je connais pas mal de décisionnaires qui hésiteraient: ce n'est pas un bon retour sur investissement. (5 ans, c'est souvent plus que la durée de vie du DSI qui prend la décision...)
    C'est vrai que l'amortissement sur 5 ans de mon exemple est peut être mal choisi.

    Citation Envoyé par fcharton Voir le message
    Mais le vrai problème, c'est que les 50€ par an, ils sont connus, certains, sans risque. Les 200€, ils ont tendance à devenir 500, et puis, ils mettent 2 ou 3 fois plus de temps que prévu à arriver (donc on continue à payer les 50 pendant ce temps). Et même si on arrive à quelque chose qui marche aussi bien que l'appli d'origine (je connais pas mal de contre exemples), on découvre à ce moment que la maintenance coutera plus de 5€, parce que dans les 50, il y avait toute une maintenance évolutive qu'on n'avait pas compté dans les 5... En fin de course, on va payer 500, et réaliser une économie de 25 (vs les 200 et 45 prévus) et là, le système s'amortit sur 20 ans... La refonte n'est plus rentable !

    Et ca, bien sur, c'est quand tout va bien... Parfois, le nouveau projet n'aboutit pas, et on reste avec le vieux système, après que le jeune chef de projet qui a vendu la refonte ait décidé de larguer le projet en route, ou que la super techno de la mort sur laquelle on comptait n'a pas tenu ses promesses... Et là, il y a toujours quelqu'un pour dire que moyennant 200 euros de refonte, on pourrait...
    Discours relativement pessimiste. Je le pense malheureusement réaliste, mais de mon expérience de chef de projets, je n'ai pour l'instant que des contre exemple à ce discours. Je garde espoir!

    Citation Envoyé par fcharton Voir le message
    Sérieusement, la plupart des décideurs (DSI et financiers) connaissent ce discours, et ont une mauvaise opinion de la capacité des informaticiens à évaluer les couts et les charges de travail (et ils ont raison).
    C'est de toute façon leur travail de s'assurer de tout ça.


    Citation Envoyé par souviron34 Voir le message
    Je me permet de constater qu'il semble bien il y avoir une différence de point de vue entre "vieux routards" et "jeunes lascars"
    Entre les jeunes fougueux qui veulent tout rénover et les vieux routards qui refusent de prendre le moindre risque, on arrive généralement à de bon compromis
    C'est cosmic

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 139
    Points : 9 158
    Points
    9 158

    Par défaut

    Moi je vois que vous vous concentrez sur une seule source de couts : le développement. Mais il y en a d'autres. Les machines, bien sur, mais aussi et surtout les bugs. Une banque qui envoie un courrier faux, voire ridicule, à 500 gros clients, ça lui coute extrêmement cher en termes d'image. Et dans ce cas, on regarde de plus près les méthodes. Et si on s'aperçoit que le système est tellement mal foutu(ce qui ne dépend pas forcément de son âge) que la moindre maintenance est un risque majeur de bugs, alors le prix de refonte, voire de maintenance de l'appli refondue, on s'en fout, ça sera toujours inférieur au cout du bug.

    C'est dans ce cadre(enfin, presque, en assurances) qu'on m'a demandé de refondre une appli qui tournait comme du papier à musique depuis plus de 35 ans, mais à laquelle personne ne comprenait rien : le risque d'erreur était devenu trop grand en cas de maintenance. Je pense que les couts de maintenance ont été réduits, mais ça n'est pas là le principal intérêt de la manœuvre. L'intérêt, c'est que l'ensemble des mécanismes fonctionnels ont été découpés et isolés, et sont ainsi facile à corriger en cas de bug.

  14. #114
    Membre confirmé
    Profil pro Lépine Kong
    Inscrit en
    janvier 2010
    Messages
    207
    Détails du profil
    Informations personnelles :
    Nom : Lépine Kong
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2010
    Messages : 207
    Points : 219
    Points
    219

    Par défaut

    Citation Envoyé par B.AF Voir le message
    Facile à dire sur le papier, créer une application pro, c'est pas une histoire de technique, c'est une histoire d'expérience.
    Tout le monde peut assembler des technos et des processus, tout le monde ne peut pas concevoir une application avec tout ce que cela implique. Et souvent, ce sont les moins créatifs qui critiquent le plus l'existant. Pour créer du neuf, il faut aimer déplaire, se faire des ennemis, entendre des reproches.
    Je vois qu'à priori concepteur est un métier contraignant que tu ne connais absolument pas.
    Je ne sais pas danq quel environnement tu travailles mais moi ça fait 20 ans que je travaille dans des multinationales et vois-tu quand je conduis un projet c'est pas pour quelqu'un fasse mumuse sur des technos pas mûrs. Effectivement ce n'est pas sûr qu'on s'entende

    Citation Envoyé par B.AF Voir le message
    Je ne supporte pas de me dire qu'un de mes "bébés" dysfonctionne et j'y ferai toujours ce qu'il faut. Ceux qui ont voulu les migrer dans des big bangs fabuleux ce sont toujours cassés les dents, sans que je les pousse d'ailleurs.
    Ce n'est pas drôle non plus de voir passer les patchs de maintenance d'un développeur qui n'a rien compris au sujet et qui a créé une dérivation dangereuse.

    L'intelligence de faire de la modélisation objets, ce n'est pas de le faire dans eclipse avec un plugin UML; c'est d'avoir un esprit suffisamment clair pour le faire de la façon la plus optimale possible.
    Quel lyrisme, si le développeur a pas compris c'est peut-être qu'il fallait le former

  15. #115
    Membre Expert
    Inscrit en
    février 2005
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 1 243
    Points : 1 702
    Points
    1 702

    Par défaut

    Citation Envoyé par lepinekong Voir le message
    Je ne sais pas danq quel environnement tu travailles mais moi ça fait 20 ans que je travaille dans des multinationales et vois-tu quand je conduis un projet c'est pas pour quelqu'un fasse mumuse sur des technos pas mûrs. Effectivement ce n'est pas sûr qu'on s'entende


    Quel lyrisme, si le développeur a pas compris c'est peut-être qu'il fallait le former
    C'est peut être surtout qu'on rencontre au quotidien beaucoup de gens qui réagissent comme toi : plutôt que d'essayer de comprendre, tu ironises et te moques.

    Donc, j'arrête. Je comprends bien que tu es un planificateur et pas un créateur, et que par définition, je suis ce que tu déteste le plus.

    Le dernier comme toi à m'avoir répondu cela en vrai m'a dit que je ne savais pas planifier, c'est probablement vrai, mais comme je lui ai dit, lui ne sait pas avoir d'idées.

    Moi mon job, c'est d'avoir des idées pour que ma boite vende. Rien de plus.
    Pouir cela au quotidien, je prends des risques d'archi, de techno, de spécifications. Et j'assume. Le risque zéro en informatique n'existe pas.
    Et ce n'est certainement pas la planification qui donne l'intelligence d'une solution. Pas plus que les visions surrannées ou les technos hypes.

    Un bon chef de projet, il code, il pige, il fédére et il vend. Pour le reste, c'est du contrôle de gestion et de la communication d'entreprise. Bref, des anxyolitiques pour gens ordinaires qui cherchent un CDI dans une multinationale pour y rester au chaud.

  16. #116
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 819
    Points
    12 819

    Par défaut

    hum.....

    Calmez-vous un peu, tous les 2

    En ce début d'année, soyez zen
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  17. #117
    Membre Expert
    Inscrit en
    février 2005
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 1 243
    Points : 1 702
    Points
    1 702

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    hum.....

    Calmez-vous un peu, tous les 2

    En ce début d'année, soyez zen
    Face à l'irrespect, je ne garde jamais mon calme, ça n'en vaut pas la peine.

  18. #118
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Moi je vois que vous vous concentrez sur une seule source de couts : le développement. Mais il y en a d'autres. Les machines, bien sur, mais aussi et surtout les bugs. Une banque qui envoie un courrier faux, voire ridicule, à 500 gros clients, ça lui coute extrêmement cher en termes d'image. Et dans ce cas, on regarde de plus près les méthodes. Et si on s'aperçoit que le système est tellement mal foutu(ce qui ne dépend pas forcément de son âge) que la moindre maintenance est un risque majeur de bugs, alors le prix de refonte, voire de maintenance de l'appli refondue, on s'en fout, ça sera toujours inférieur au cout du bug.
    C'est effectivement une bien meilleure raison que l'économie sur la maintenance. Maintenant, l'analyse est assez compliquée. D'abord, parce que le cout des bugs n'est pas simple à évaluer, et ensuite parce que si l'application actuelle souffre de régressions quand on la maintient, il y a gros à parier que la future arrive avec son lot de nouveaux bugs, qu'il faudra corriger, et qui entraineront (peut être) de nouvelles régressions.

    Bref, on échange des régressions connues et actuelles contre des bugs futurs et inconnus. Au global, on y gagne souvent, parce qu'il y a un effet d'apprentissage, mais la bonne question (du point de vue du donneur d'ordre, toujours un financier) c'est "est ce que ca en vaut la peine?".

    Mon impression c'est que les entreprises oscillent sans cesse entre deux postures extrèmes :
    - la résignation vis à vis du système informatique, et de ses bugs: depuis des années, on nous dit que c'est comme ca, alors, on s'habitue, à la longue. C'est la position normale.
    - l'exaspération vis à vis du système actuel, une sorte de panique vis à vis des "vieilles technologies" et la certitude que les nouvelles vont magiquement régler tous les problèmes. C'est la situation exceptionnelle, qui déclenche la refonte.

    En fait, la décision de refondre est presque toujours irrationnelle...

    Francois

  19. #119
    Expert Confirmé

    Profil pro Franck Soriano
    Leader Technique
    Inscrit en
    juin 2005
    Messages
    1 757
    Détails du profil
    Informations personnelles :
    Nom : Franck Soriano
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2005
    Messages : 1 757
    Points : 3 661
    Points
    3 661

    Par défaut

    Citation Envoyé par B.AF Voir le message
    Facile à dire sur le papier, créer une application pro, c'est pas une histoire de technique, c'est une histoire d'expérience. Tout le monde peut assembler des technos et des processus, tout le monde ne peut pas concevoir une application avec tout ce que cela implique. Et souvent, ce sont les moins créatifs qui critiquent le plus l'existant. Pour créer du neuf, il faut aimer déplaire, se faire des ennemis, entendre des reproches.
    Je vois qu'à priori concepteur est un métier contraignant que tu ne connais absolument pas.
    Je trouve ta réaction exagérée et disproportionnée. Tu décris le travail et les compétences de l'architecte. lepinekong ne s'en prenait pas à l'architecte, mais faisait le constat de ce que tu récupères au final en maintenance.

    Une fois que l'architecte a pondu son oeuvre d'art, cette dernière va être réalisée par une armée de petits développeurs débutants (voir des prestataires payés pour faire acte de présence (dont certains seront peut-être en réalité des stagiaires)) qui vont tout massacrer, avec un CP qui ne se souciera que de la date de livraison.

    Au début, tout le monde dira oh oui c'est beau, on fait mumuse avec les dernières technos, on utilise pleins de design-pattern et autre. On va faire les choses bien...
    et puis la deadline va arriver. Très vite, l'ambience va devenir : on est à la bourre, il faut livrer.... le CP dira : "l'architecte (ou le responsable technique, ou le responsable qualité) je l'emmerde, c'est pas lui qui doit respecter la date de livraison, peu importe comment c'est fait, l'important c'est que ça marche"... la doc sera sacrifiée pour rattraper le retard. Puis les tests seront baclés car plus le temps de tester...

    Au final, le CP parviendra a livrer un truc qui marchote dans les délais. On le bricolera à coups de rustines pour passer la recette...
    Et son projet sera considéré comme une réussite parce qu'il aura passer la recette dans les temps.

    Par contre, lorsque derrière tu récupères le projet en maintenance, tu subis les contraintes d'un existant que tu n'as pas choisi. Tu dois maintenir en fonctionnement un truc branlant qui défie toute logique, dont la doc est inexistante, voir pire obsolète et contraire à ce que fait réellement le système.
    Tu dois faire évoluer le tout, garantir l'absence de regressions, mais tu ne sais déjà pas toi-même comment le système est censé fonctionner.
    On t'impose une obligation de résultat face à des problèmes dont tu n'as parfois aucune compréhension, voir sur lesquels tu n'as parfois aucune emprise.

    Bref, dans un cas tu fais une oeuvre d'art mais de toute façon on ne te jugera pour ainsi dire que sur ta capacité à livrer dans les délais.
    Dans l'autre, on te demande de faire des miracles, tu seras toujours considéré comme responsable de tous les maux de l'offre, tu auras envi de faire une oeuvre d'art pour remplacer le tas de bouses mais on ne te donnera jamais les moyens de la refonte (qui il est vrai serait probablement réalisée selon le même processus que le développement initial ).

    Je trouve aussi qu'en termes de responsabilités, il est beaucoup plus facile d'assumer un nouveau projet que de maintenir un produit existant.

    Citation Envoyé par B.AF
    Face à l'irrespect, je ne garde jamais mon calme, ça n'en vaut pas la peine.
    Je ne trouve pas l'attitude de lepinekong irrespectueuse, mais plutôt réaliste par rapport à ce qu'on rencontre généralement en entreprise.
    Tu te sens aggressé parce que dans ton cas de figure tu arrives à maîtriser la réalisation pour qu'elle colle parfaitement à ton idée initiale (ou tes projets sont suffisamment petits pour que tu puisses tout coder toi-même), mais dans les grandes boîtes, ça se passe rarement comme ça.
    (sans oublier que des architectes qui pondent des usines à gaz pour résoudre un problème trivial, ça existe aussi)

    Et pourtant, je suis l'architecte dont le travail se fait massacrer par des CP qui sont prêts à tous les sacrifices sur la qualité pour livrer la liste de livraison la plus longue possible au moment de la mise en prod !

  20. #120
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 819
    Points
    12 819

    Par défaut

    Citation Envoyé par fcharton Voir le message
    Bref, on échange des régressions connues et actuelles contre des bugs futurs et inconnus.


    Et c'est bien tout le problème...

    Et la croyance dans "on a une méthode sûre qui fait qu'il y aura pas de bugs" est aussi stupide que de dire que l'existence de Dieu est prouvable (ou improuvable)...



    Citation Envoyé par fcharton Voir le message
    Au global, on y gagne souvent, parce qu'il y a un effet d'apprentissage
    Eh malheureusement non !!

    Ceci supposerait que l'équipe est stable...

    Or justement quand il y a refonte le plus souvent on change d'équipe, soit parce qu'on l'estime "incapable", soit parce qu'elle est partie (trop vieille, à la retraite, "dépassée"..) soit parce que la boîte a été rachetée, et qu'on change l'équipe... ou bien parce qu'il y a un nouveau Directeur Technique, qui croit tout savoir (ou qui se résigne parce que tous les jeunes qu'il embauche sont incapables de faire autre chose que du .Net ou du C# et sont dépassés dès qu"on n'utilise pas UML ou qu'on leur donne pas à la becquée tous les mots technocratiques qu'on leur a foutu dans le crâne à l'école, ou si on leur parle de "fonctions enregistrées"))

    En très gros, et ce que tu dis plus bas le confirme :


    Citation Envoyé par fcharton Voir le message
    une sorte de panique vis à vis des "vieilles technologies" et la certitude que les nouvelles vont magiquement régler tous les problèmes. C'est la situation exceptionnelle, qui déclenche la refonte.

    En fait, la décision de refondre est presque toujours irrationnelle...
    Ce qui, compte-tenu de l'extrême rareté de la situation que tu envisageais ci-dessus (l'équipe est la même, donc il y a apprentissage), amène dans la quasi-totalité des cas à un coût (très) largement supérieur à moyen terme (3 à 5 ans).

    Et surtout qu'on re-crée des bugs, qui avaient déjà été corrigés dans les versions précédentes, provoquant un ras-le-bol, puis un fatalisme, des utilisateurs..

    Et des développeurs, quand ils voient eux-aussi que le bug avait déjà été corrigé 6 ans avant...

    Ce qui fait que tout le monde y perd :

    • l'entreprise, qui dépense des sous et du temps qu'elle aurait pu passer à améliorer le produit.

    • Les utilisateurs, qui se foutent pas mal de savoir quelle techno on utilise, du moment que ça fait le boulot, et qu'on ne revient pas en arrière.. Mais qui auraient préféré avoir très nettement plus de fonctionalités que une re-mouture de l'ancien..

    • Les développeurs "anciens", qui ont vu leur bébé se faire démanteler, et qui éventuellement se sont fait virer (ou mis de côté)

    • Les développeurs nouveaux, qui, après s'être bien éclatés, s'aperçoivent qu'il faut reprendre un à un tous les bugs depuis 10 ans.... et qui perdent donc tout intérêt , car c'est un travail fastidieux.. et qui pour eux est .. humiliant : ils pensaient avoir tout fait bon !!! Et que le temps qu'ils fassent ça, ils sont à leur tour "dépassés" par une nouvelle techno à la mode...





    et on répond donc à el_slapper par la même occasion : ton bug de ta banque aurait été très vraisemblablement plus facilement corrigé (et à moindres frais), et SANS regénérer de nouveaux bugs (ni mobiliser toute une équipe pendant 3 ou 5 ans, et donc des ressources considérables) si on avait pris la décision de le corriger plutôt que de tout refaire... Et ton 'impact" sur les utilisateurs sera pire si il faut leur ré-expliquer que ça, qu'ils voient sur leur relevé, ah ben "c'est une erreur de l'info.. Oui, c'est vrai, il y avait déjà eu ce problème il y a 3 ans, mais vous en faites pas, ça va être corrigé le mois prochain"






    Citation Envoyé par Franck SORIANO Voir le message
    Une fois que l'architecte a pondu son oeuvre d'art, cette dernière va être réalisée par une armée de petits développeurs débutants (voir des prestataires payés pour faire acte de présence (dont certains seront peut-être en réalité des stagiaires)) qui vont tout massacrer, avec un CP qui ne se souciera que de la date de livraison.
    ..
    Et pourtant, je suis l'architecte dont le travail se fait massacrer par des CP qui sont prêts à tous les sacrifices sur la qualité pour livrer la liste de livraison la plus longue possible au moment de la mise en prod !


    Sauf quand le CP est un vieux de la vieille, qui prend son boulot à coeur et sait ce qu'il fait...


    Mais il y en a comme des bons patrons.. Rarement...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

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
  •