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

Le , par magiklife, En attente de confirmation mail
Bonjour

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

Merci


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Franck SORIANO Franck SORIANO - Membre expert http://www.developpez.com
le 14/01/2010 à 13:54
Citation Envoyé par souviron34  Voir le message
Parce qu'un architecte se considère comme "à part", et que l'industrie et les architectes (et CP) en général considère(nt) les "codeurs" comme simplement des pisseurs de lignes.. d'où éventuellement délocalisation..

Faut pas vous plaindre, vous le cherchez..

Et tu voudrais faire comment ?
Dans l'informatique, il y a d'énormes différences de compétences d'un individu à l'autre. Entre le débutant fraichement sorti de l'école et l'expert expérimenté il y a qu'en même un gouffre !

Si tu mets tout le monde dans le même panier, tu fais un nivellement par le bas. L'expert s'ennuie, a le sentiment de perdre son temps et ira voir ailleurs. Le débutant s'imagine qu'il vaut largement l'expert et n'en fait qu'à sa tête. Tu as une armée de débutant qui veulent appliquer la solution de facilité, l'expert est le seul à voir que les conséquences à long termes seront catastrophiques, mais comme on a mis tout le monde au même niveau, on finit par un vote à la majorité et une cata à la fin...

Ou alors tu acceptes que tout le monde n'a pas les mêmes compétences et tu essaies d'organiser les choses au mieux pour tirer le meilleur de chacun. Et tant que tu y es tu essaies de faire en sorte que les débutants apprennent aux contacts des gens plus expérimentés.

Citation Envoyé par fcharton
Oui, mais dans la mesure où cette personne peut écrire son code (tu disais que tu as très vite débugué le problème du développeur), ne faudrait il pas remplacer 10 développeurs à moufles par 3 architectes programmeurs? ou si on ne peut faire autrement, aller chercher des développeurs dans les pays chauds, où les salaires sont plus bas, et où l'on ne met pas de moufles?

Ca c'est la belle théorie.
Mais dans la pratique, on sait très bien que le problème est plus compliqué. La réussite d'un projet ne dépend pas que de la technique.

Il faut aussi des gens plus orientés côté fonctionnel (personnellement, je ne sais pas calculer un bulletin à la main). En général les experts techniques s'intéressent assez peu au fonctionnel et vis-versa.
Ajoute à ça le fait que tu ne choisis pas toujours ton équipe de développement, et qu'avant d'être doué techniquement il a bien fallu débuter un jour...
Avatar de lepinekong lepinekong - Membre actif http://www.developpez.com
le 18/01/2010 à 22:28
Citation Envoyé par el_slapper  Voir le message
Venant moi-même du monde industriel, je vois quand même une différence flagrante : le produit logiciel est immatériel. Ce qui signifie que la demande(comme l'offre) peuvent aller de manière exponentielle, bien plus que les produits industriels. Peut-être est-il possible d'industrialiser le processus de création logiciel(je n'y crois pas beaucoup, mais après tout, pourquoi pas?), mais celà va créer un appel d'air et une demande de traitements encore bien plus forte. D'ou un besoin constant de professionels, même en période de forte croissance de la productivité.

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
Avatar de Emmanuel Deloget Emmanuel Deloget - Expert confirmé http://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...
Avatar de souviron34 souviron34 - Expert éminent sénior http://www.developpez.com
le 25/01/2010 à 17:35


Un grand merci pour cette contribution constructive, bien écrite, pensée, construite, et argumentée..

Avatar de - http://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
Avatar de souviron34 souviron34 - Expert éminent sénior http://www.developpez.com
le 26/01/2010 à 0:29
Citation Envoyé par fcharton Voir le message
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.
Sur ce point, cela se discute beaucoup..

Je me souviens, il y a.. snif sniff.. 22 ans, pourtant au Laboratoire Central de Recherches d'un des 4 grands groupes mondiaux d'électronique (et le plus grand français, si vous voyez ce que je veux dire ... ), m'être, de concert avec le Chef du SI central, écharpé avec les représentants syndicaux du CE pendant un an.. Représentants qui défendaient ce point de vue contre ..... l'introduction d'un traitement de texte uniforme dans l'entreprise...

Même le syndicat des ingénieurs était contre...

Alors, pour eux, j'avais déjà tenu le langage que je ne voyais pas trop la différence entre tapoter un clavier d'un oscillo numérique ou de leur ordi pour faire un prgramme et celui d'un ordi pour préparer leur demande de brevet...

Mais, pour les secrétaires, j'avais également posé la question crûment de ce qui arrivait régulièrement.. : étant dans un Centre de Recherche mondial d'une boîte employant plus de 300 000 salariés et possédant plus de 1000 usines dans le monde, présente sur tous les continents et avec des SAV également sur tous les continents, il arrivait presque tous les week-end qu'un ingénieur, un technicien, un directeur de labo, ou même le Directeur, débarque à Roissy un samedi matin par exemple en provenance des US et doive repartir le dimanche direction le Japon ou les Emirats, en ayant modifé sa présentation ou créé une nouvelle.. Quelle secrétaire, y compris celle du Directeur, accepterait d'être appelée à son domicile le samedi vers 16h pour venir travailler samedi soir jusque tard pour taper la présentation du patron ??? (et même en semaine, ce qui était fréquent pour les gars du SAV)

Alors ce n'est pas forcément partout, ni quoi ni qu'est-ce, mais ce n'est pas blanc et noir...

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


Et malheureusement, quand je compare avec les années de mon début de carrière, je trouve que cette tendance est de plus en plus répandue.. Justement pour les raisons que tu cites si bien...

Avatar de B.AF B.AF - Membre chevronné http://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 !
Avatar de - http://www.developpez.com
le 26/01/2010 à 20:43
Citation Envoyé par B.AF Voir le message
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
Sur ce point, les responsabilités sont partagées,

- d'un côté on a des entreprises qui n'attachent pas beaucoup d'importance à l'individu et sa spécialisation métier
- de l'autre des salariés qui vivent leur travail comme une corvée, et leur entreprise comme une ennemie (et n'ont donc aucune envie de faire l'effort de se spécialiser)
- le tout encouragé par des sociétés de services qui affirment (contre toute évidence) que le savoir faire métier peut avantageusement être délégué à la machine...

Parfois, j'ai l'impression que l'entreprise moderne et l'individu moderne forment un couple parfait, et que l'informatique moderne est un enfant à leur ressemblance...

Francois
Avatar de B.AF B.AF - Membre chevronné http://www.developpez.com
le 27/01/2010 à 12:21
Citation Envoyé par fcharton Voir le message
Sur ce point, les responsabilités sont partagées,

- d'un côté on a des entreprises qui n'attachent pas beaucoup d'importance à l'individu et sa spécialisation métier
- de l'autre des salariés qui vivent leur travail comme une corvée, et leur entreprise comme une ennemie (et n'ont donc aucune envie de faire l'effort de se spécialiser)
- le tout encouragé par des sociétés de services qui affirment (contre toute évidence) que le savoir faire métier peut avantageusement être délégué à la machine...

Parfois, j'ai l'impression que l'entreprise moderne et l'individu moderne forment un couple parfait, et que l'informatique moderne est un enfant à leur ressemblance...

Francois
Ah ça l'entreprise, ca ne reste jamais qu'un troupeau d'hommes. Je pense juste que l'entreprise est aussi un modéle de société "underground", et qui devient de plus en plus effrayant, vu que maintenant, c'est la société qui est aus service de l'entreprise, et que l'entreprise ressemble plus souvent à un régime despotique si pas fasciste en comparaison.
Avatar de Mister_Bean Mister_Bean - Membre à l'essai http://www.developpez.com
le 26/09/2012 à 21:22
Dans ma boîte, un bon chef de projet, c'est un chef de projet qui commence des projets mais n'est plus là lors de la mise en prod.
Avatar de okaparka okaparka - Membre régulier http://www.developpez.com
le 05/10/2012 à 17:47
Citation Envoyé par magiklife Voir le message
Bonjour

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

Merci
Dans l'ordre ...
- des qualités de notaire ( pour recalculer à la petite cuillère , les chiffrages faits à la louche, et pour rajouter les frais qui vont bien...)
- des qualités de juriste ( pour savoir détecter les virgules mal placées, et les non-dits des contrats flous, savoir exploiter à son avantage exclusif les contrats flous est un vrai talent ...)
- des qualités de politicien comme déja dit ( les promesses sur les délais de livraison n'engagent que ceux qui y croient...)
- des qualités de comptable (déja dit)
-etc, à compléter , mais de telle sorte que le candidat chef de projet ne se rende pas compte qu'il aurait dû ,ou devrait , demander 30 K€ de plus
Offres d'emploi IT
Ingénieur Etudes et Développements JAVA/J2EE/Finance H/F
People Centric - Ile de France - Paris (75000)
Développeur fullstack - h/f
UpSourcing - Ile de France - Paris (75000)
Ingénieur jee (h/f)
Atos - Provence Alpes Côte d'Azur - Sophia Antipolis

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Emploi informatique et développeurs