A titre d'information complémentaire, voici les 46 compétences d'un chef de projet selon l'ICBv3 :
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
A titre d'information complémentaire, voici les 46 compétences d'un chef de projet selon l'ICBv3 :
...
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é.
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é.Envoyé par B.AF
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.
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."
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.
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....
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
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
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.
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.
Je n'ai jamais dit le contraire pour l'industrie
ç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..
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
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.
+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) ...
Tiens, j'avais perdu ce fil de vue..... je crois que je vais faire du mauvais esprit
sauf que quand ce sont des gens ordinaires à qui on demande de créer, il faut souvent des gens extraordinaires pour maintenir.....
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
C'est la différence entre entrepreneur et gestionnaire, entre créer et améliorer, entre innover et utiliser de l'innovation.[/QUOTE]
+1
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.
+1
va expliquer ça à un banquier.....
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.
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.
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
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
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
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
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
Le post le plus pertinent du topic !
Bien dit
en quelques mots :
maitriser son métier, clairvoyant sur les enjeux, judicieux, charismatique, psychologue, politicien et parfois politicard.
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager