Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Débat Carrière : Quelles sont les qualités et les compétences que doit avoir un Chef de Projet ?

Le , par magiklife

0PARTAGES

0  0 
Bonjour

Quels sont les qualités et les compétences que doit
avoir un Chef De Projet en informatique ??

Merci

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de jeromechezgdf
Membre régulier https://www.developpez.com
Le 25/05/2007 à 14:54
Cela dépend aussi de la culture du pays dans lequel tu bosses... Mais y'a des constantes :

1 - Avoir une capacité de travail énorme.
2 - Comprendre l'ensemble des métiers concernés par le projet.
3 - Savoir évaluer les gens et arriver à tirer le meilleur des gens.
4 - Savoir prendre sur soi.
5 - Savoir communiquer.
6 - Etre expert dans son core-business...
6 - Savoir prendre des décisions et les imposer de force si besoin.
7 - Bosser, bosser, bosser...

Les erreurs à ne pas faire selon moi :
- Se décharger sur un des membres de son équipe auprès du client en cas de problême.
- Répondre "ce n'est pas mon problème" à un de ses membres d'équipe. Quand un développeur a une merde c'est tout le projet qui est dans la merde.
- Avoir peur de remettre en place un membre de son projet, voir de le sortir du projet.
- Se faire la peau d'un membre de son projet devant les autres...

voilou
2  0 
Avatar de
https://www.developpez.com
Le 25/01/2010 à 20:06
Citation Envoyé par Emmanuel Deloget Voir le message
Il faut être honnête : nous faisons un travail de fainéant. Le fond même de notre travail est d'autoriser le monde à être encore plus fainéant. Nous y arrivons en simplifiant les manipulations qu'un tiers dois faire en lui fournissant un logiciel adapté à ses besoins. C'est la même chose pour nous : nous cherchons sans arrêt à limiter notre charge de travail avec des artifices techniques (scripts de génération) ou liés au processus (gestion de configuration, tests automatisés, ...). Nous cherchons avant tout à faire ce que nous considérons comme le minimum vital pour obtenir le résultat recherché.
Ces deux idées me paraissent douteuses...

D'abord, sur l'informatique...

Dans la plupart des cas, l'informatique ne permet pas aux gens d'être fainéants, mais chômeurs. Quand on informatise la compta ou la gestion, on ne rend pas les comptables plus paresseux ou moins occupés, mais moins nombreux... Quand on permet (via la bureautique) à chacun de taper son courier ou d'envoyer ses lettres, on déplace le travail d'une profession dédiée (les secrétaires) vers une autre (l'employé lambda), et en fin de compte, il y a un peu moins de monde dans l'entreprise.

Ensuite, l'informatique permet souvent de faire des choses qu'on ne faisait pas avant (tout ce qui tourne autour de la CAO, ou des calculs d'éléments finis, par exemple, ou les jeux vidéos, ou les diverses "activités" facebook). Dans ces cas, l'informatique crée plus de "travail".

Bref, je ne crois pas que l'informatique ait pour mission (ou pour effet) de rendre les gens fainéants, ni même de leur simplifier le travail. Je crois en revanche que, comme l'utilisateur final, est presque toujours un non informaticien, qui se méfie de l'ordinateur (à juste titre, il va peut être le mettre au chomage...), il est indispensable que les programmes soient relativement simples à utiliser.

Sur les informaticiens, maintenant.

Les meilleurs programmes sont courts, simples, faciles d'emploi, intuitifs... Mais le processus qui permet d'y arriver ne l'est pas. En général, la première version est bête, mal pensée, naive, inmaintenable. C'est la troisième, ou la quatrième, nourrie par les défauts des précédentes qui est souvent la meilleure.

La paresse, en informatique, c'est se contenter de la première, et de choisir celle qui "prend le moins de temps" (entendre: qui demande le moins de réflexion). Souvent, on appelle ca "ne pas réinventer la roue", ce qui revient à utiliser (de travers parce que lire la doc prend du temps) un outil mal adapté (parce qu'on n'a pas compris l'énoncé du problème, lire les specs ca prend du temps), sans bien se rendre compte que le temps qu'on va perdre à l'ajuster est bien plus important que celui qu'on a gagné, pour un résultat moins bon... Aussi, ce type d'approche ne procure aucune expérience: au fil des années, l'informaticien "minimaliste" n'a pas beaucoup progressé, sauf en salaire... En général, ca finit mal.

Bien sur, une fois qu'on est arrivé à la solution élégante, courte, minimaliste, on a beau jeu de louer la "paresse", mais c'est un peu hypocrite : cette solution courte est obtenue au terme d'un processus très long.

Croire que pour être bon en informatique, il faut être paresseux, c'est très très naif... (à mon avis, pour être bon en informatique, il faut être insatisfait, et en général, ca rime avec bosseur...)

Francois
2  0 
Avatar de B.AF
Membre chevronné https://www.developpez.com
Le 26/01/2010 à 12:06
En fait je crois que vous avez tous les deux trouvée la réponse :

- La technocratie des processus et le mythique "mode projet" ont contribué à la destruction lente mais certaine de la compêtence métier en entreprise. On tend aujourd'hui à avoir un lambda qui apprendre à se servir d'une application métier plutôt que d'avoir un spécialiste pour des motifs de soi disant coût (avec une bonne vue courte de contrôleur de gestion)

- L'informatique évolue dans ce sens : les langages sont de plus en plus haut niveau, les formations de plus en plus "marketing", les outils de developpement de plus en plus "frameworkisés". Le développement ressemble plus aujourd'hui à de l'assemblage syntaxique qu'a un raisonnement logiciel. Donc on se retrouve avec des lambdas qui developpent sans raison, avec des processus qui tournent en boucle en cherchant surtout à identifier une chaine de responsabilité, puisqu'il parait normal que personne ne prenne le risque de s'engager sur ce qu'il ne connait.

Et oui messieurs, l'entreprise moderne est une gigantesque psychopate au sens clinique du terme :
L’indifférence froide --> Aucune considération humaine, l'expandable asset !
L’irresponsabilité --> la plupart des entreprises aujourd'hui n'ont que faire de la destruction du tissu social qu'elles provoquent en délocalisant ou en restructurant
Difficulté de maintenir une relation avec autrui --> Personne n'aime finalement les entreprises, mais nous sommes bien obligé
Intolérance à la frustration où comment le patron de JP Morgan ose menacer le premier ministre britannique, ou comment le patron d'Oracle insulte la commission européenne
Absence de culpabilité, aucune entreprise n'a de remord de laisser 1500 ouvriers sur le carreau
Tendance à blâmer autrui, et oui ! Car quand tout va mal, c'est la faute des français qui sont fainéants, des taxes, des taux de change, jamais la faute des décideurs de la boite ! Ce sont de pauvres malheureux persécutés.

Ce dont a besoin le monde aujourd'hui c'est de réserves d'haldol et de psyhiatres. Pas d'informaticiens !
2  0 
Avatar de Janitrix
Membre expert https://www.developpez.com
Le 17/05/2007 à 10:11
Un membre plus expérimenté que moi aura une réponse plus réaliste, mais je pense avant tout qu'un chef de projet doit avoir l'expérience du terrain, c'est donc pas un gamin qui sort de son école d'ingénieur qui va commencer par être chef de projet. Il doit avoir un bon contact social pour discuter avec le client, en bon sens d'organisation et des responsabilités. Il doit être capable de remotiver tout le monde si le projet s'enlise. C'est la vision que j'ai d'un chef de projet, mais ce n'est que la mienne, et elle est basée sur rien...

Au revoir et pense à poster dans le bon forum la prochaine fois. Merci.
1  0 
Avatar de BLeguillou
Membre régulier https://www.developpez.com
Le 29/05/2007 à 8:41
Au Japon pour être cadre supérieur, il faut avoir occupé tous les postes de subalternes de l'entreprise!

Sayonara
1  0 
Avatar de sroux
Membre confirmé https://www.developpez.com
Le 29/05/2007 à 11:14
Hello,

Voici quelques idées tirées de mon expérience:

- Etre très patient, surtout quant il s'agit de faire monter en compétence des stagiaires appelés également "consultants juniors" chez le client...
- Compétent techniquement sur le sujet en question... indispensable
- Savoir effectuer une recherche sur le web et accessoirement lire/comprendre l'anglais
- Savoir bien manger et bien parler à table = bonne culture générale et relationnel
- Avoir un PC à la maison et la connexion au web qui va avec, ainsi qu'une femme/mari/compagne/ami compréhensive/compréhensif
- Pas être forcément un AS du fonctionnel
- Savoir également poser ses coui**** sur la table (quand et quand ne pas...)

Cdlt,

SR
1  0 
Avatar de _solo
Membre éprouvé https://www.developpez.com
Le 29/05/2007 à 16:10
Citation Envoyé par BLeguillou
Au Japon pour être cadre supérieur, il faut avoir occupé tous les postes de subalternes de l'entreprise!
tout les chefs de projet que j'ai rencontrer jusqu'a maintenant devait ont tous surement travailler au japon avant de revenir en france alors en tout cas c'est sympa de travailler avec des gens qui maitrise leur sujet mais c'est tres rare ses oiseaux la.
1  0 
Avatar de Katyucha
Expert confirmé https://www.developpez.com
Le 06/06/2007 à 13:07
Je ne pense pas qu'on puisse comparer au sport, l'activité n'est pas la même.

Je trouve qu'il y a un élément indissociable pour les chefs des projets, c'est la compétence technique !
Un chef de projet qui vient te demander en combien de jours, tu peux faire un dev, n'a rien a foutre à son poste.
J'ai rencontré différents CdP, et ceux avec qui les projets marchaient le mieux, c'était les "vieux" CdP, ceux qui ont été dev, puis Responsable d'Application avant de faire réellement de la gestion de projet. Leur approche du problème était plus raisonnable et ils ne s'envolaient pas dans des délais intenables dès qu'ils étaient devant le patron.
1  0 
Avatar de lepinekong
Membre averti https://www.developpez.com
Le 06/01/2010 à 12:20
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
1  0 
Avatar de Emmanuel Deloget
Expert confirmé https://www.developpez.com
Le 25/01/2010 à 14:11
Sur les codeurs et les architectes

Je suis architecte logiciel, mais bon, il fut un temps ou j'étais considéré comme un simple codeur. Mais tout comme il y a des bons et des mauvais chasseurs, avec tout ce que ça implique comme difficulté pour reconnaitre lequel est le bon et lequel est le mauvais, il y a aussi des bons et des mauvais codeurs. Un bon codeur n'est différent d'un bon architecte logiciel que de par l'étendue de ses connaissance - donc, son expérience. Son code sera propre, évoluera aisément, et aura des performances décentes. Pour être franc, je me surprend des fois à régresser : mon code est bien souvent moins lisible qu'il y a quelques années (parce qu'il fait la part belle à des technologies que je ne devrais pas employer). Ca me va, mais je ne travaille pas tout seul - et un jour, il faudra bien que quelqu'un d'autre que moi lise ce code...

Il faut être honnête : nous faisons un travail de fainéant. Le fond même de notre travail est d'autoriser le monde à être encore plus fainéant. Nous y arrivons en simplifiant les manipulations qu'un tiers dois faire en lui fournissant un logiciel adapté à ses besoins. C'est la même chose pour nous : nous cherchons sans arrêt à limiter notre charge de travail avec des artifices techniques (scripts de génération) ou liés au processus (gestion de configuration, tests automatisés, ...). Nous cherchons avant tout à faire ce que nous considérons comme le minimum vital pour obtenir le résultat recherché. Dans ce cadre, il ne faut pas s'étonner de voir des collègues faire ce qui est à leur yeux le minimum vital - qui nous choque parce que nous, nous aurions forcément fait mieux. D'ailleurs, on fait toujours mieux que son voisin de table : nos bugs sont des bugs moins graves, notre code est toujours plus lisible, il est toujours plus efficace, etc. A partir de là, il ne faut même pas chercher à se demander pourquoi notre voisin de table ne fait pas plus attention à la qualité de son travail - après tout, il a tout à fait le droit de penser la même chose que nous...

Sur les compétences normales d'un développeur

Ben oui, un développeur typique à un set de compétence typique. C'est le pragmatisme qui l'enseigne. Dans le monde idéal, un développeur sait programmer dans plusieurs langages, a une vision englobante de sa tâche, est capable d'écrire du code propre avec un minimum de bugs. Il sait aussi lire le code des autres et le cas échéant le débugger. Il sait s'adapter à une nouvelle technologie ou à un nouveau métier (passer du bancaire à la photographie par exemple). Tout ça, c'est bien beau - mais dans la pratique, un développeur lambda :
  • Ne connait qu'une seul et unique langage de programmation, et bien souvent il le connait imparfaitement. Bien souvent, certaines subtilités lui échappe. Il n'est pas rare de rencontrer un programmeur Java qui sait qu'il faut utiliser .equals() pour comparer deux chaines de caractère, mais qui ne sait pas vraiment pourquoi c'est nécessaire (autrement que "parce que == ça marche pas".
  • A bien du mal à relire son propre code, parce qu'il est bien souvent écrit sans véritable réflexion. Heureusement, les IDE modernes aident à la mise en page du code avec une indentation complètement automatique.
  • A énormément de mal à relire et comprendre le code de ses collègues (principalement parce que ses collègues sont comme lui).
  • A des difficultés énorme à intégrer une nouvelle technologie.
  • A des difficultés énorme à comprendre les enjeux d'un métier particulier, et aura du mal à faire la transition vers un métier nouveau.
  • N'a qu'une vision partielle du travail qu'il doit effectuer et de la façon dont ce travail s'inscrit dans le projet en cours. Notez que ce problème récurrent est quelques fois lié à la structure du projet lui même (on ne va pas demander à l'équipe responsable de l'écriture de MS Paint de comprendre les tenants et les aboutissants du système qui virtualise la mémoire des cartes graphique dans Windows Vista) ou au contraire lié au management projet, qui souhaite compartimenter le développement au maximum - souvent à tort, car la compartimentation (sic) enferme les développeurs dans une spécialisation dont il est difficile de les faire sortir tout en augmentant le risque lié à la défection d'un élément critique dans l'équipe (puisque le nombre d'éléments critiques augmente de fait).
  • Se croit doué quand même, et le montre en plaisantant dans le code - avec des noms de fonction comme SauceGrandVeneur(). Si, je l'ai déjà vu.


Je conçoit que c'est un peu pessimiste comme vision, mais après avoir travaillé une dizaine d'année dans différents secteurs, c'est hélas le constat que je fait. Le développeur lambda ne s'intéresse à l'informatique que parce que c'est son métier - il ne visite pas ce site web (à moins qu'il soit bloqué par un problème), il ne cherche pas à s'intéresser à de nouvelles technologies lorsqu'il a du temps libre, il ne programme pas en dehors des heures d'ouverture de son bureau, etc. Ce n'est pas pour autant un mauvais développeur - c'est un développeur lambda.

En résumé, il vit son métier comme il est logique de vivre son métier - pour paraphraser Molière, il faut travailler pour vivre, et non pas vivre pour travailler.

Ce programmeur là aura peut-être du mal à devenir chef de projet ou à obtenir des responsabilités sur un ou plusieurs projets, mais vu qu'après plusieurs années à faire les mêmes choses il est tout à fait compétent dans son métier, il y a quand même de bonnes chances qu'il y accède. Le manque de qualité supposé de son travail de programmeur n'a que peu d'influence sur son métier de chef de projet - puisqu'il pourra s'appuyer sur une batterie de programmeurs pour faire le travail technique.

Sur le Cloud Computing

Citation Envoyé par lepinekong Voir le message
Ce n'est pas l'objectif déclaré du cloud que ce soit dans la bouche de Mac Nelly PDG de SUN ou les conséquences sur l'emploi du cloud computing prédit par les cabinets du domaine dans 10 ans: le métier de programmeur n'aura plus lieu d'être - enfin en exagérant il y a toujours des ouvriers dans l'industrie mais beaucoup moins qu'avant et l'emploi y est très précaire. Ils prédisent des emplois surtout de support help desk ou d'infrastructure.

En attendant les programmeurs ont encore quelques belles années devant eux je pense mais il faut voir un peu plus loin compte tenu qu'il faut tenir jusqu'à 60/65 ans
Il est assez incroyable qu'encore à notre époque des dirigeants de grandes sociétés informatique continuent de dire qu'un jour, le métier de programmeur sera has been - étant donné que c'est ce métier de programmeur qui leur permet de vendre des machines, c'est en plus un contresens au niveau business. Pire encore, prétendre vouloir remplacer les programmeurs par des métiers métant en avant que les logiciels sont mal conçus et difficiles à utiliser (d'où un besoin accru de help desk), c'est vraiment tout faire pour se tirer une balle dans le pied.

Le cloud computing génèrera du travail pour les programmeurs. Les logiciels qui vont supporter cette architecture ne vont pas s'écrire tout seul. Ils ne vont pas évoluer tout seul. Et je doute que les équipes qui vont les écrire seront plus petites que les équipes actuelles.

Cabinets d'analyse. En voilà un joli business. Tant que les "prédictions" de ces cabinets sont à court terme, ils arrivent globalement à être à peu près juste (et encore : ils n'ont pas été capable de prévoir l'effondrement du marché de la photo argentique, par exemple, alors que celui-ci a été très rapide. Ils n'ont pas non plus été en mesure d'annoncer l'explosion du téléchargement illégal, alors que tous les signes étaient là. Eut-il été annoncé plus tôt, je peux vous assurer que les majors auraient probablement changé de stratégie plus tôt). Dès qu'ils s'essaient à des prévisions à long terme (10 ans pour l'informatique, c'est quand même très long), ils ont une tendance nette à se tromper avec une violence rare. En même temps, dire à des sociétés qui en font une stratégie à moyen-long terme que le cloud, ça ne marchera pas (et j'aurais tendance à dire que ça ne marchera pas), ça n'est pas très vendeur.

Le cloud computing a quand même quelques problèmes.

  • Premièrement, rien n'indique qu'il est moins cher à utiliser qu'une architecture traditionnelle (moins cher à la mise en place, mais plus cher à l'utilisation : c'est ce qui ressort actuellement).
  • Deuxièmement, rien n'indique non plus que son niveau de spécialisation sera assez fort pour que les entreprises lui fasse confiance. Si utiliser des applications en CC me fait perdre le bénéfice d'applications spécialisée et ciblant mon métier, que intérêt ? C'est même un retour en arrière qui n'a pas vraiment de sens au niveau business.
  • Troisièmement, je dois quand même faire confiance à un tiers pour tout ce qui est du traitement de mes données et des mes applications. Je ne suis plus maitre de ma configuration logicielle de travail (si mon provider décide de ne plus supporter la version de telle ou telle application dont j'ai absolument besoin, hop, je l'ai dans l'os). Je ne suis plus maître de la sécurité et de la confidentialité de mes données (les accords signés entre mon provider et les gouvernement des différents pays peuvent prévaloir sur la confidentialité de mes informations, notamment si je travaille dans un secteur sensible).
  • Quatrièmement, impossible d'avoir un avantage concurrentiel grâce à mes outils informatique. Si toute mon infrastructure est externalisée, je n'ai plus la possibilité d'avoir un système qui a été développé spécialement pour moi et qui pourrait potentiellement m'offrir un avantage concurrentiel énorme. Si j'ai ce système sur une infrastructure CC publique, alors mes concurrent aussi et je perd cet avantage concurrentiel.


Le Cloud Computing peut avoir un intérêt, mais aujourd'hui j'ai bien du mal à voir lequel. Ca demande beaucoup de dépenses, ça coute cher dans le long terme, et ça n'apporte rien puisqu'il faut continuer à maintenir des couts de license prohibitifs et des systèmes lourds en interne pour avoir accès aux applications maison. Ceci dit, à budget élevé, prime élevée une fois que le projet a été mené à bien...
1  0