+ Répondre à la discussion Actualité déjà publiée
Page 5 sur 8 PremièrePremière 12345678 DernièreDernière
Affichage des résultats 81 à 100 sur 147
  1. #81
    Membre habitué
    Inscrit en
    mars 2006
    Messages
    114
    Détails du profil
    Informations forums :
    Inscription : mars 2006
    Messages : 114
    Points : 138
    Points
    138

    Par défaut

    A titre d'information complémentaire, voici les 46 compétences d'un chef de projet selon l'ICBv3 :


  2. #82
    Membre Expert
    Inscrit en
    mars 2005
    Messages
    1 249
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 249
    Points : 1 884
    Points
    1 884

    Par défaut

    ...

    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é.

  3. #83
    Membre habitué
    Inscrit en
    mars 2006
    Messages
    114
    Détails du profil
    Informations forums :
    Inscription : mars 2006
    Messages : 114
    Points : 138
    Points
    138

    Par défaut

    Citation Envoyé par B.AF Voir le message
    (...)
    Chacun d'entre-nous se fait sa propre idée de ce qui est utile ou non dans un poste donné (compétences et qualités demandées). Sans nécessairement nous en rendre compte, nous utilisons tous un référentiel : pour certains, c'est leur propre expérience qui fait référence, pour d'autres, c'est la représentation qu'ils ont du métier, pour d'autres encore c'est l'idée qu'ils se font de la culture d'entreprise liée à un métier dans un secteur donné.

    Etant donné qu'il s'agissait de répondre à la question posée par notre jeune ami "magiklife", les standards internationaux cités ci-dessus sont la réponse la plus complète qu'il puisse trouver à l'heure actuelle.

    Connaitre ces référentiels professionnels est important pour pondérer son avis et intégrer les différentes opinions.

  4. #84
    Membre habitué
    Inscrit en
    mars 2006
    Messages
    114
    Détails du profil
    Informations forums :
    Inscription : mars 2006
    Messages : 114
    Points : 138
    Points
    138

    Par défaut

    Petite anecdote : Un de mes confrères (qui a, lui aussi, formé et coaché des dizaines de chefs de projet durant sa carrière) disait : "Si tu es en retard de 6 mois sur un milestone qui arrive la semaine prochaine, et que malgré cela tu es intimement convaincu que tu peux y arriver, alors tu es un chef de projet."

  5. #85
    Membre Expert
    Inscrit en
    mars 2005
    Messages
    1 249
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 249
    Points : 1 884
    Points
    1 884

    Par défaut

    Citation Envoyé par Kokett Voir le message
    Chacun d'entre-nous se fait sa propre idée de ce qui est utile ou non dans un poste donné (compétences et qualités demandées). Sans nécessairement nous en rendre compte, nous utilisons tous un référentiel : pour certains, c'est leur propre expérience qui fait référence, pour d'autres, c'est la représentation qu'ils ont du métier, pour d'autres encore c'est l'idée qu'ils se font de la culture d'entreprise liée à un métier dans un secteur donné.

    Etant donné qu'il s'agissait de répondre à la question posée par notre jeune ami "magiklife", les standards internationaux cités ci-dessus sont la réponse la plus complète qu'il puisse trouver à l'heure actuelle.

    Connaitre ces référentiels professionnels est important pour pondérer son avis et intégrer les différentes opinions.

    Tu parles d'un standard, vu la quantité de poncifs utilisés. La définition est suffisamment vague pour ne rien dire (il faut tout savoir faire) et suffisamment large pour ne pas faire d'oublis.

    Ce sont surtout des organisations qui gagnent énormément d'argent en essayant d'IMPOSER des standards et donc la certification qui va avec.

    C'est une définition purement marketing.

    Tu regardes ça :
    http://www.ipma.ch/about/people/Page...tiveBoard.aspx

    Ce que je veux dire c'est qu'un standard n'est standard que quand il y a adhésion, ces standards ont juste vocation à vendre des certifications.

    Faut aussi les prendre avec le recul.

    Si tu regardes le camembert que tu as mis dans le forum, à priori quelqu'un qui a autant de compêtences, il ne faut plus qu'il cherche à être chef de projet. Ce serait quasiment un sous-emploi.

  6. #86
    Expert Confirmé Sénior

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 200
    Points : 14 396
    Points
    14 396

    Par défaut

    Citation Envoyé par Kokett Voir le message
    Petite anecdote : Un de mes confrères (qui a, lui aussi, formé et coaché des dizaines de chefs de projet durant sa carrière) disait : "Si tu es en retard de 6 mois sur un milestone qui arrive la semaine prochaine, et que malgré cela tu es intimement convaincu que tu peux y arriver, alors tu es un chef de projet."
    Et je suis certain que ce n'est pas une blague !!!

    D'où les proverbiaux échecs d'une multitude de projets, d'où l'émergence d'une foultitude de "méthodes", "méthodologies", "certifications", "diplômes", etc etc.... qui ne changent strictement rien au fond du problème..

    On n'apprend pas à être un bon CP. On a des connaissances+qualités le permettant ou non..

    C'est comme si on "apprenait" à être un bon Chef d'Entreprise.. On voit ce que ça donne, les Ecoles...

    Il y a les "bons" (passés (Citroen, Michelin, Renault, Schneider, Ford, ...) autant qu'actuels (Gates, Jobs, le gars qui a inventé le lavage écolo des bagnoles, etc etc), qui ont fait "sur le tas" parce qu'il avaient "la bosse", et les autres, tous les autres, qui s'empêtrent dans la technocratie, la finance, la gestion "scolaire", etc etc....



    Citation Envoyé par B.AF Voir le message
    ...Ce sont surtout des organisations qui gagnent énormément d'argent en essayant d'IMPOSER des standards et donc la certification qui va avec.

    C'est une définition purement marketing.
    ...
    Ce que je veux dire c'est qu'un standard n'est standard que quand il y a adhésion, ces standards ont juste vocation à vendre des certifications.
    ..
    encore une fois je ne peux que souscrire à 100% à ce que tu dis..

    Que ce soit CMMi, ISO, etc etc, ce ne sont que des machines à faire de l'argent, et à imposer une manière de faire, dont on voit (mais personne n'y voit de mal, en ce moment, pourtant) ce à quoi ça amène (eh oui !! Il n'y a pas que dans le système financier et bancaire que l'on fait n'importe quoi).

    Les technocrates sont rassurés par des présentations technocratiques... Des choses qu'ils ont l'impression de maîtriser...

    Ce sont eux qui imposent ces "standards"...

    Cela devient des "standards" parce que le monde informatique, comme le monde financier et industriel, est maintenant dirigé par des gens qui ne savent pas de quoi ils parlent...

    Et qu'ils ne comprennent pas le fond du problème : la création de logiciel est une activité intellectuelle, et, comme toute activité intellectuelle, est soumise aussi bien à la panne, à l'éclair de génie, ou à la médiocrité....

    De la même manière que des gens comme Ford ou Gates ou Jobs ont suivi leurs idées, qui la plupart du temps étaient à contre-courant de ce que pensait la "majorité" à leur époque, parce qu'ils avaient la "fibre", la clef du succès d'un projet réside dans un Chef qui suit ses règles, à condition qu'il sache de quoi il parle...

    Ceux qui "achètent" les "standards" et "certifications" sont les mêmes qui, dans les banques, ont donné des milliards pour la "bulle des .com", ou qui, dans l'industrie, ont cru au "pouvoir tout-puissant de la finance", en oubliant simplement que vendre du vent, ça marche peut-être un peu, mais la réalité finit par reprendre le dessus...

    Une industrie dont la valeur financière n'a pas de liens avec l'activité (voir Renault et la chute de 80% des actions en un an), c'est absurde... L'entreprise est là depuis un siècle, et continuera après-demain, à fabriquer des voitures, une parmi les autres, pour équiper les +6 milliards d'habitants de la Terre.

    De même, une entreprise informatique qui suit une norme en oubliant que son but est de fournir un produit qui marche (et si possible de faire de l'argent dessus) c'est absurde... Or, si l'on tient compte de l'ensemble des coûts engendrés (il faut payer l'équipe de certification, mais auparavant il faut former les équipes, et donc payer des cours et du temps, et le respect des "processus" prend du temps, donc de l'argent) , et des résultats obtenus (il y a autant de bugs dans un soft d'aujourdhui qu'il y en a dans des softs d'il y a 20 ans), on ne peut pas dire qu'on ait franchement avancé...

    Mais visiblement, les gens "sortis des ecoles" sont plus sensibles aux arguments de la technocratie
    "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

  7. #87
    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 : 892
    Points
    892

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    On n'apprend pas à être un bon CP. On a des connaissances+qualités le permettant ou non..
    On a certes des qualités personnelles le permettant ou non, mais il y a beaucoup de chose à apprendre pour être un bon CP. C'est vraiment faire preuve d'un égo démesuré de croire que sa simple petite personne suffit à être doué.

    Tu fais une critiques acerbe des normes telles que CMMI, ISO, et bien renseigne toi un peu plus. Tu auras beaucoup à apprendre. Le seul soucis de ces normes ce sont les personnes elles même qui se disent "oh c'est bon on est certifié c'est qu'on fait tout bien". Là où cela devient compliqué c'est que l'on doit appliquer ces normes à notre organisation, et se servir d'elles comme un soutien mais pas comme l'élément essentiel.

    Et comme tu le dis, respecté tous les processus prend tu temps, donc personne ne le fait complètement => on se ramasse. On ne critique pas des process en disant "c'est nul on s'est planté en respectant les process" et après quand tu vérifie il n'y en a qu'un tiers de respecté...

    Quant au bug, oui il y en a toujours autant . Mais pour ça, on a qu'à arrêter de distribuer des bac+5 à tout le monde, et on aura moins d'incompétent sur le marché.
    C'est cosmic

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 216
    Points : 10 761
    Points
    10 761

    Par défaut

    Souviron, puisque tu parles de l'automobile, et que j'ai failli travailler dans le domaine, je vais me permettre une anecdote. Jeune ingénieur fraichement diplomé, j'ai passé des entretiens dans l'industrie(je les ai tous foiré, mais à l'époque, ma confiance en moi était inférieure au néant); notamment un site d'un équipementier automobile Français(chez qui j'avais fait mon projet de fin d'études, avant de partir à l'armée). Ils cherchaient des qualiticiens. Sur un site de 700 personnes(du balayeur au big boss), ils avaient 30 qualiticiens. 30 gugusses qui passent leur temps à vérifier la qualité des produits fournis, des process de fabrication, et des produits finis.

    J'ai un scoop pour toi : ça marche. Ca marche parceque la démarche est poussée jusqu'au bout. Ca marche parceque tout le monde adhère au projet. Ca marche parceque chacun baigne dedans du matin au soir(ou du soir au matin pour l'équipe de nuit). Ca marche parceque le client final(Renault, par exemple), exige que ça marche; et vérifie, avec des moyens gigantesques, que ça marche. Et ça DOIT marcher parceque nul n'accepterait qu'un airbag pète à la gueule du conducteur accidenté au lieu de doucement amortir la trajectoire de ladite gueule vers le volant. Ca marche bien, les airbags, j'ai testé(ce que je ne souhaite à personne, ça sauve, mais c'est violent quand même).

    Maintenant, revenons à nos moutons : l'informatique. Peut-on appliquer ce genre de méthodes à l'informatique? Réponse en 2 temps :

    1)tel que c'est fait maintenant : impossible. Les normes de qualités telles qu'elles sont appliquées à l'heure actuelle ne sont que des normes de suivi des éléments. Seul la partie gestion de projet applique ces méthodes. Ainsi, on peut garantir la parfaite execution du remplissage du planning. Mais celà n'a, tu l'as constaté comme moi, aucun impact sur la qualité du produit informatique.

    2)tel que c'est fait dans l'automobile. Je suis circonspect. Quand on fabrique un airbag, on fabrique toujours la même toile, toujours les mêmes capteurs, toujours les mêmes batons de dynamite, toujours le même timer pour décaler l'explosion des bâtons. Ce genre de produit se prête extrêmement bien à la démarche qualité. un code informatique n'est jamais identique à son voisin - car la duplication ne nécéssite pas de conception, ni de méthode dans nôtre domaine.
    Parralèllement, Il me semble possible qu'en y mettant les moyens, on puisse mettre en place des vérifications systématiques sur le process et le produit(les fournisseurs, je ne vois pas), qui permettent d'avoir des codes conformes et lisibles. Le hic, c'est qu'il faut pour celà débourser des sommes folles pour ce genre de contrôles systématiques, et qu'un gain modéré de fiabilité peut doubler le cout de l'intervention(exemple vécu - on a doublé les temps de dev pour faire des vérifications systématiques, on a réduit notablement les incidents par élément livré, sans les éliminer). Le deuxième hic, c'est qu'un équipe "agile", bien moins couteuse, peut elle aussi arriver à des résultats assez impressionants.....pourvu qu'elle soit constitué d'éléments talentueux, et qu'elle aie les moyens de bosser(contacts avec les gens qui savent, exploitation réactive, etc.....).

    Ma conclusion : avec des gens extraordinaires, on peu faire des choses extraordinaires. Avec des gens ordinaires aussi, mais sortez le chéquier.....et attendez vous à des délais.

  9. #89
    Expert Confirmé Sénior

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 200
    Points : 14 396
    Points
    14 396

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    J'ai un scoop pour toi : ça marche.
    Je n'ai jamais dit le contraire pour l'industrie

    Citation Envoyé par el_slapper Voir le message
    Maintenant, revenons à nos moutons : l'informatique. Peut-on appliquer ce genre de méthodes à l'informatique? Réponse en 2 temps :

    1)tel que c'est fait maintenant : impossible. Les normes de qualités telles qu'elles sont appliquées à l'heure actuelle ne sont que des normes de suivi des éléments. Seul la partie gestion de projet applique ces méthodes. Ainsi, on peut garantir la parfaite execution du remplissage du planning. Mais celà n'a, tu l'as constaté comme moi, aucun impact sur la qualité du produit informatique.

    2)tel que c'est fait dans l'automobile. Je suis circonspect. Quand on fabrique un airbag, on fabrique toujours la même toile, toujours les mêmes capteurs, toujours les mêmes batons de dynamite, toujours le même timer pour décaler l'explosion des bâtons. Ce genre de produit se prête extrêmement bien à la démarche qualité. un code informatique n'est jamais identique à son voisin - car la duplication ne nécéssite pas de conception, ni de méthode dans nôtre domaine.
    ça n'est pas "tel que c'est fait maintenant c'est impossible". Tu le dis toi-même dans ton 2ième paragraphe... : par principe c'est impossible..

    Ce que l'équipementier fait en fabriquant ses airbags, c'est établir une chaîne de production qui recopie le prototype.

    Ce que fait l'industrie informatique, c'est fabriquer le prototype.

    Et je suis certain, mais à 100%, que le bureau d'étude de l'équpementier ne suit pas les mêmes règles qualités que la chaîne de production..



    Citation Envoyé par el_slapper Voir le message
    Parralèllement, Il me semble possible qu'en y mettant les moyens, on puisse mettre en place des vérifications systématiques sur le process et le produit(les fournisseurs, je ne vois pas), qui permettent d'avoir des codes conformes et lisibles. Le hic, c'est qu'il faut pour celà débourser des sommes folles pour ce genre de contrôles systématiques, et qu'un gain modéré de fiabilité peut doubler le cout de l'intervention(exemple vécu - on a doublé les temps de dev pour faire des vérifications systématiques, on a réduit notablement les incidents par élément livré, sans les éliminer). Le deuxième hic, c'est qu'un équipe "agile", bien moins couteuse, peut elle aussi arriver à des résultats assez impressionants.....pourvu qu'elle soit constitué d'éléments talentueux, et qu'elle aie les moyens de bosser(contacts avec les gens qui savent, exploitation réactive, etc.....).

    Ma conclusion : avec des gens extraordinaires, on peu faire des choses extraordinaires. Avec des gens ordinaires aussi, mais sortez le chéquier.....et attendez vous à des délais.
    Pour le reste, je suis assez d'accord, mais j'avoue que je doute de la dernière partie de la phrase.

    Ce n'est pas pour rien que l'on parle de Mozart et non des milliers de musiciens de son époque, des architectes romains du Pont du Gard ou des Arènes de Nimes et non de ceux qui fabriquaient les maisons traditionnelles, de Thomas Edison ou de Marconi et non des centaines de physiciens de la fin 19ième début 20ième, des frères Renault ou Bréguet ou Bugatti et non des dizaines de mécaniciens du début 20ième, de Stradivarius et non des centaines de luthiers au cours des 6 siècles passés... De Steven Hawking, de Steven Jay Gould, de Luc Montagnier, etc, parmi tous les chercheurs des 30 dernières années, de Haroun Tazieff ou du Commandant Cousteau, etc etc...

    Dans tous les domaines, y compris l'informatique, les choses extraordinaires sont faites par des gens extraordinaires...

    Pourquoi serait-on à part ??

    Un chercheur moyen, dans toute sa carrière, aura peut-être publié un papier par an dans une revue spécialisée. Et ??

    Combien de chercheurs dans le monde et sur le nombre total de chercheurs arrivent-ils à trouver quelque chose d'extra-ordinaire ??

    Donc oui, avec des gens ordinaires, quelle que soit la durée, tu finiras par produire quelque chose.. Que ce quelque chose soit extraordinaire, j'en doute fort..
    "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

  10. #90
    Membre Expert
    Inscrit en
    mars 2005
    Messages
    1 249
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 1 249
    Points : 1 884
    Points
    1 884

    Par défaut

    Ben oui c'est la logique naturelle :
    Les gens extraordinaires créent
    Les gens ordinaires maintiennent.

    La grande différence est que pour créer, il faut entres autres savoir sortir des sentiers battus, être agnostique et sur la techno et sur la méthode.

    Si tu veux faire du nouveau; et que pour le faire tu utilises des standards, il n'y a aucun processus créatif. Donc ça ne demande aucune compêtence particuliére si ce n'est la maitrise technique.

    C'est la différence entre entrepreneur et gestionnaire, entre créer et améliorer, entre innover et utiliser de l'innovation.

    La réalité c'est que les gens ordinaires aiment le confort de la norme, les autres la déteste car c'est un environnement de raisonnement confiné, limité, dirigé, anti créatif.

    "Une confrontation permanente entre théorie et expérience est une condition nécessaire à l'expression de la créativité" - Joliot

    "La créativité et le génie ne peuvent s'épanouir que dans un milieu qui respecte l'individualité et célèbre la diversité." - Alexander

    Et cette derniére est importante. C'est celle qui définit l'inefficience des projets d'aujourd'hui : L'individu est une ressource, les formations comme elles se nomment d'ailleurs, formatent.

  11. #91
    Membre habitué Avatar de rakakabe
    Développeur informatique
    Inscrit en
    août 2007
    Messages
    122
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2007
    Messages : 122
    Points : 144
    Points
    144

    Par défaut

    Citation Envoyé par B.AF Voir le message
    Les gens extraordinaires créent
    Les gens ordinaires maintiennent.
    +1 .

    Pour moi, un bon chef de projet c'est surtout quelqu'un qui possede la culture du resultat (un projet n'est pas un succes tant qu'il n'y a pas de resultat).
    En effet, ceux qui reussissent sont souvent ceux qui veulent atteindre leur objectif.

    Apres, il doit penser gagnant-gagnant pour que tout le monde soit content (client, developpeur, son chef ...).

    Tout le reste, ce ne sont que des trucs qui aident à atteindre cet objectif (= le resultat) ...

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 216
    Points : 10 761
    Points
    10 761

    Par défaut

    Tiens, j'avais perdu ce fil de vue..... je crois que je vais faire du mauvais esprit

    Citation Envoyé par B.AF Voir le message
    Ben oui c'est la logique naturelle :
    Les gens extraordinaires créent
    Les gens ordinaires maintiennent.
    sauf que quand ce sont des gens ordinaires à qui on demande de créer, il faut souvent des gens extraordinaires pour maintenir.....

    Citation Envoyé par B.AF Voir le message
    La grande différence est que pour créer, il faut entres autres savoir sortir des sentiers battus, être agnostique et sur la techno et sur la méthode.
    et aussi(et en général c'est contradictoire) rester compréhensible pour le commun des mortels. Sinon, code inmaintenable ou invention irréalisable ==> poubelle

    Citation Envoyé par B.AF Voir le message
    Si tu veux faire du nouveau; et que pour le faire tu utilises des standards, il n'y a aucun processus créatif. Donc ça ne demande aucune compêtence particuliére si ce n'est la maitrise technique.
    C'est la différence entre entrepreneur et gestionnaire, entre créer et améliorer, entre innover et utiliser de l'innovation.[/QUOTE]

    +1

    Citation Envoyé par B.AF Voir le message
    La réalité c'est que les gens ordinaires aiment le confort de la norme, les autres la déteste car c'est un environnement de raisonnement confiné, limité, dirigé, anti créatif.
    sauf que le créateur qui ne respecte pas la norme, verra sa création ignorée par ceux qui ne parviennent pas à l'appliquer.

    Citation Envoyé par B.AF Voir le message
    "Une confrontation permanente entre théorie et expérience est une condition nécessaire à l'expression de la créativité" - Joliot
    +1

    Citation Envoyé par B.AF Voir le message
    "La créativité et le génie ne peuvent s'épanouir que dans un milieu qui respecte l'individualité et célèbre la diversité." - Alexander
    va expliquer ça à un banquier.....

    Citation Envoyé par B.AF Voir le message
    Et cette derniére est importante. C'est celle qui définit l'inefficience des projets d'aujourd'hui : L'individu est une ressource, les formations comme elles se nomment d'ailleurs, formatent.
    Certes; et tu proposes quoi à la place? de laisser des artistes faire selon leur bon vouloir avec nôtre pognon(je me replace en informatique banquaire)? Je suis philosophiquement proche de ta position, mais on fait face à des soucis contradictoires : le besoin d'innover, et le besoin de garanties.

  13. #93
    Expert Confirmé Sénior

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 200
    Points : 14 396
    Points
    14 396

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    mais on fait face à des soucis contradictoires : le besoin d'innover, et le besoin de garanties.
    Là je pense simplement que c'est la phrase (ou les soucis) qui ne sont pas les bons..

    En quoi est-ce un "besoin" d'innover ???

    C'est là où le bât blesse...

    Dans une société de consommation telle que la nôtre, les publicitaires, marketing, et autres, créent un "besoin" associé au renouvellement, et donc à "l'innovation"...

    Et nous le voyons tous les jours en informatique..

    Mais en quoi et-ce réellement un besoin ??

    Est-ce qu'un code Fortran (ou Cobol pour un autre domaine) qui fait tout ce qu'on lui demande est obsolète simplement parce qu'il n'utilise pas ce qui est dit "innovateur" ???

    Si le besoin réel n'a pas changé, pourquoi est-ce que ce qui le satisfaisait il y a 20 ans ou 10 ans nécessiterait des "innovations" ??



    La garantie que ça marche, oui c'est un besoin...

    L'innovation n'est qu'une création pure du marketing et de la société de consommation...(en ce qui concerne la ré-écriture de ce qui existait déjà, bien entendu, pas l'utilisation pour un nouveau besoin insatisfaisable par les anciens moyens)
    "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

  14. #94
    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 : 892
    Points
    892

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    Mais en quoi et-ce réellement un besoin ??

    Est-ce qu'un code Fortran (ou Cobol pour un autre domaine) qui fait tout ce qu'on lui demande est obsolète simplement parce qu'il n'utilise pas ce qui est dit "innovateur" ???

    Si le besoin réel n'a pas changé, pourquoi est-ce que ce qui le satisfaisait il y a 20 ans ou 10 ans nécessiterait des "innovations" ??
    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.
    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.

    C'est uniquement pour ça que certaines applications cobol sont migrés, pas juste pour faire joli.
    C'est cosmic

  15. #95
    Expert Confirmé Sénior

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 200
    Points : 14 396
    Points
    14 396

    Par défaut

    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.
    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.

    C'est uniquement pour ça que certaines applications cobol sont migrés, pas juste pour faire joli.

    D'une part je ne parlais pas vraiment de ça en particulier, mais plutôt de l'équation :

    besoin = innovation


    D'autre part, (comme c'est le cas pour C++), les évolutions (ré-écritures) se font beaucoup plus parce que les jeunes sortant des écoles ne savent pas faire autre chose que pour un réel besoin. Et là se pose la question : est-ce les produits qui doivent s'adapter au manque de formation adéquat, ou les fomations qui devraient (en enseignant la continuité et non seulement les "innovations") s'adapter au "parc" existant...


    Ton exemple de "maintenance coûteuse" est parce qu'on ne forme plus personne au Cobol.. Les miens de l'an dernier par rapport à un re-développement coûteux et dangereux de C en C++ est parce qu'on ne forme (formait.. ça a l'air de re-changer un peu ces temps-ci) plus personne au C "astucieux" et industriel.

    C'est donc une inadéquation entre les formations et le marché, l'existant...

    Et cela rentre en plein dans ce dont on parlait plus haut : l'innovation présentée comme un "besoin", c'est facile : on tarit les sources de continuité... D'un seul coup, ce qui était valable depuis des décennies devient obsolète... Et hop !!

    Que cela soit les pièces détachées électroniques, les cartouches d'imprimantes, les cartes des appareils photos numériques, ou les langages informatiques, même combat... La société du "on utilise. On jette. On rachète".

    Ca oui, ça coûte très très très cher...

    Peut-être qu'enfin, avec la crise et (j'espère) son approfondissement, on va revenir à quelque chose de plus raisonnable : ce qui marche et rempli le besoin marche et rempli le besoin. Point final...

    (les 2 CV et la Coccinelle ont duré de 55 à 45 ans... Un peu plus long que Vista...)
    "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

  16. #96
    Expert Confirmé Sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    4 999
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 4 999
    Points : 7 270
    Points
    7 270

    Par défaut

    Citation Envoyé par javamine Voir le message
    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.
    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.

    C'est uniquement pour ça que certaines applications cobol sont migrés, pas juste pour faire joli.
    euhh oui mais moi je tourne cela différemment : est-ce que Java ou .NET sont forcément adaptés à des projets que l'on "développait" avec Cobol ?
    Je vais te faire une réponse : COBOL me semble plus adapté parce que bien souvent c'est le COBOL du constructeur ( par exemple IBM ) ce qui s'inscrit plus dans une logique technologique.
    .NET et Java sont souvent utilisés en "front-office" pour les interfaces utilisateurs; la majorité des gros projets en SSII c'est souvent comme cela

  17. #97
    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 : 892
    Points
    892

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    Ton exemple de "maintenance coûteuse" est parce qu'on ne forme plus personne au Cobol.. Les miens de l'an dernier par rapport à un re-développement coûteux et dangereux de C en C++ est parce qu'on ne forme (formait.. ça a l'air de re-changer un peu ces temps-ci) plus personne au C "astucieux" et industriel.

    C'est donc une inadéquation entre les formations et le marché, l'existant...
    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).

    Comme le dit si bien Mat. M, on reste bloqué avec IBM (par exemple), et regardez leur prix
    Bien sûr J2EE et Dotnet ne sont pas toujours les plus adapté par rapport au Cobol.
    C'est cosmic

  18. #98
    Nouveau Membre du Club
    Inscrit en
    décembre 2006
    Messages
    62
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 62
    Points : 26
    Points
    26

    Par défaut

    Citation Envoyé par Emmanuel Deloget Voir le message
    Le problème d'un apprentissage sur les banc d'une école, c'est que vous n'allez jamais apprendre à gérer une équipe. Vous allez apprendre le coté technique de la conduite de projet, mais le coté humain (qui est la vrai valeur ajoutée) sera totalement mis de coté.

    Mais le coté technique est finalement assez simple à maitriser dans un environement normal. Mettre en place des indicateurs est une tâche qui se fait en peu de temps, pour peu qu'on vous donne la possibilité de le faire (la plupart du temps, vous ne disposerez pas de cette possibilité mais en même temps on ne vous demandera pas des indicateurs trop complexes: un planning à jour est bien souvent suffisssant, même face à un client très porté sur la qualité). Faire un planning, le tenir à jour, noter les glissements, nommer et quantifier les risques, etc, tout cela s'acquiert très rapidement avec l'expérience. La gestion de la qualité est quelque chose qui a plus trait au sens commun qu'à une connaissance pointue de la théorie sous-jacente.

    Bref, les questions techniques sont simples et ne requiert pas une formation spécialisée. Un bouquin de 150 pages vous en apprendra autant que des heures de cours ou la théorie s'éloigne de la pratique à la vitesse d'un cheval lancé au galop.

    Par contre, la gestion des conflits, la prise en compte de l'humain, la gestion du secret (ne pas trop en dire tout en tenant ses subordonnés au courant, ce n'est pas une mince affaire), le contrôle politique (si vous n'aimez pas la politique, passez votre chemin: je vous rappelle qu'au de la de votre carrière, celle des personnes qui bossent pour vous sont aussi en jeu), etc, ne sont couvert que de manière très théorique (comment faire autrement ?). Tout ça ne peut pas s'apprendre sur les bancs d'une école - il faut se confronter au terrain pour véritablement comprendre ce que ça veut dire.

    Le problème est que bien souvent et compte tenu qu'il n'est pas nécessairement capable de mettre en place ces échanges humains, le chef de projet débutant préfère s'en tenir à ses tâches techniques alors que ce n'est pas ce qu'on attends de lui (j'ai de nombreux cas ou la SSI pour laquelle je travaille a du placer des directeurs de projet au dessus des chefs de projet nouvellement diplômés et embauchés du client afin de recentrer leur travail). On souhaite le voir conduire ses troupes, les motiver, communiquer sur le projet, son avancement, les risques, les retards, etc. Bref, un chef de projet doit avant tout être capable de prévoir ce qui va se passer à court-moyen-long terme, afin de tenir sa hierarchie/son client au courant de ce qui se passe. Le coté technique est d'autant plus accessoire qu'il s'acquiert assez vite (à partir du moment ou le cerveau est un peu moins mou qu'un glaire de vache mourrante, j'entends).
    Le post le plus pertinent du topic !

    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é.
    Bien dit

  19. #99
    Inactif
    Inscrit en
    mai 2007
    Messages
    497
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 497
    Points : 279
    Points
    279

    Par défaut

    en quelques mots :

    maitriser son métier, clairvoyant sur les enjeux, judicieux, charismatique, psychologue, politicien et parfois politicard.

  20. #100
    Membre confirmé
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    207
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

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

    Par défaut

    Citation Envoyé par B.AF Voir le message
    C'est quoi une vraie école d'ingénieur ?

    Cognitives, je ne vois pas le rapport.

    De la com, de la compta de l'anglais et de la dissert', super mais en dans certaines classes de lycée aussi. C'est pas un signe de "grande capacités cognitives".

    J'aurai plutôt tendance à croire qu'un diplôme d'ingé garanti à 100% qu'une personne ne saura ni vendre, ni négocier ni manager, puisqu'à priori si tel est son souhait, il existe des formations de bien meilleur niveau et beaucoup plus pointues.
    Manager, communiquer, négocier, c'est une question de personne.

    En plus je ne fais pas non plus l'apologie des profils autodidactes, même si force est de reconnaitre qu'un autodidacte est plus souvent en nécessité d'être pro actif qu'un diplômé.
    Bon je suis chef de projet depuis 15 ans, j'ai fait une école d'ingénieur généraliste, et je vais vous donner mon avis que je pense être objectif:

    Dans ce type d'école d'ingénieur, il y a effectivement beaucoup de cours qui ne sont plus techniques au point que dans ma promo la moitié voulait se barrer au Marketing ! Beaucoup se dirigent vers l'informatique non pas par goût mais parce que c'est là où ça recrute encore (enfin bon selon les cycles), résultat ils ne savent pas et ils ne veulent pas commencer par la programmation, surtout qu'on a dégradé l'image du développeur: de mon temps les centraliens même devenaient développeur et pouvaient y rester sans que cela crée des complexes, aujourd'hui ça devient presque dégradant pour un bac + 5!

    A qui la faute ? Au marché des grands comptes avec des services achats qui cassent les prix et qui demandent des containers de développeurs comme si c'était des bananes au mieux des ressources interchangeables.

    Avec la menace d'offshorisation, ça n'arrange pas les choses, les jeunes ingénieurs se disent qu'il vaut mieux pas qu'ils commencent à être développeur et ils veulent tout de suite être chef de projet voire software architect, les plus raisonnables par Business Analysts. Or ce sont tous des postes qui requièrent normalement une expérience pour mener le projet correctement.

    A cause de la tendance au jeunisme et parce que les clients managers pas si vieux que ça aiment bien les petits jeunes pas chers et obéissants, il arrive qu'il y ait effectivement des chanceux qui puissent rentrer dans ce type de poste. Je ne trouve pas que ce soit une bonne chose.

    Pour être un bon chef de projet informatique, il faut avoir programmé un minimum dans un vrai contexte d'entreprise car la syntaxe du langage ce n'est pas tout, les cours de com à l'école c'est de la théorie qui n'a pas grand rapport avec les relations réelles cachées qui existent dans les entreprises surtout les grandes.

    J'aurai encore beaucoup de choses à dire, mais ce sera pour un autre fil peut-être

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
  •