Discussion :

[Hanoni]

Bonjour à tous,

actuellement en quatrième année d'école supérieure d'informatique, je commence à me poser des questions sur la manière de m'y prendre dans ma future carrière.

Dans l'idéal, j'aurais aimé être développeur pendant quelques années avant de passer chef de projet. Seulement, ce que je lis à droite à gauche et avec les estimations que certains formateurs nous donnent sur la forme du marché de l'emploi en informatique dans les années qui viennent, je m'inquiète un peu...

En effet, j'ai quand même bien l'impression que le développement "pur" est destiné à quasiment disparaître en France à terme. Les entreprises font quand même globalement de plus en plus faire leurs développements dans les pays à faible coût de main d'oeuvre à tel point que l'on a l'impression que pour un jeune diplômé qui veut s'assurer une carrière longue et heureuse, il est indispensable de s'orienter le plus rapidement possible sur un poste de chef de projet...je suis peut être pessimiste, mais mieux vaut prévenir que guérir et je ne me vois pas miser sur un hypothétique revirement général de situation...et de toute façon, là n'est pas l'objet de ma question.

Ce que je voudrais savoir, et cette question s'adresse donc prioritairement aux actuels chefs de projet, c'est comment mettre un maximum d'atouts de son côté pour parvenir rapidement à décrocher un tel poste ?

Mon ami, qui travaille également dans une grosse structure informatique pense qu'il faut que j'évite si possible, et ce dés le début de ma carrière, les postes trop techniques de développement et que je m'oriente très rapidement sur des postes d'analystes...mais est-ce que le raisonnement qui consiste à faire passer chef de projet d'avantage d'analystes que de développeur est tenu par toutes les entreprises ?

En tout cas, ce raisonnement paraît cohérent par rapport à ce qu'on peut lire sur les compétences "prioritaires" d'un chef de projet à savoir le côté relations MOE/MOA, cahier des charges parfait (s'il en existe :p), un minimum de maîtrise des outils de gestion de projet, et surtout le côté management, social, charisme...

Si vous pensez que je me trompe ou bien si vous avez des idées et suggestions sur la manière de m'y prendre, je suis très preneur !

J'aimerais aussi avoir quelques retours d'expérience

Merci d'avance

[el_slapper]

Moi, ce que je vois, c'est un chassé-croisé permanent entre les gens qui partent en Inde et les gens qui en reviennent. Ils en reviennent tous pour la même raison : le décalage horaire rend impossible le bon suivi des projets. Et ça va très souvent dans le décor, bien plus souvent qu'en France.

Alors évidemment, l'Afrique francophone, elle, permet des projets coordonnés à moindre coût, mais sa démographie informaticienne est bien moins menaçante. Estimations SOPRA(en 2006, mais ça n'a pas du beaucoup changer) : à terme, l'Inde représentera 7 à 10% du marché, sur quelques niches. Peut-être le double sur l'Afrique francophone(ça c'est perso). Vu que les besoins croissent fortement, je trouve ton postulat de départ un tantinet alarmiste.....

[Hanoni]

J'admet que je suis carrément alarmiste, c'est vrai

Mais bon, je suis du genre excessivement prudent d'où mes questions sur le "comment devenir chef de projet rapidement ?".

Dans tous les cas, même si la situation des développeurs en France est bonne dans 10-20-30 ans, je ne me vois pas coder toute ma vie, je pense qu'au bout de 10 ans max, je voudrais changer, et le problème qui se posera alors justement, c'est que peut-être qu'on considèrera que je suis "trop" technique...ça, ce n'est qu'une idée perso, je ne sais pas justement si dans une boîte, on fait évoluer facilement quelqu'un qui est resté trèèèèès longtemps développeur vers un poste de chef de projet, ça fait partie de mon questionnement.

Je ne voulais pas lancer un débat sur le devenir des développeurs en France dans les prochaines années mais vraiment savoir "Comment devenir chef de projet ?", "Comment orienter sa carrière et ses choix pour le devenir rapidement ?".

Merci de ta réponse quand même

[ToTo13]

Moi, ce que je vois, c'est un chassé-croisé permanent entre les gens qui partent en Inde et les gens qui en reviennent. Ils en reviennent tous pour la même raison : le décalage horaire rend impossible le bon suivi des projets. Et ça va très souvent dans le décor, bien plus souvent qu'en France.

+1... et oui tu es alarmiste.
Par contre, il y a de plus en plus de délocalisation/sous traitance au Vietnam avec quasiment pas de retour. On dirait que là-bas ils savent programmer.

Par contre pour répondre à ta question : il n'y a aucun avenir de carrière pour un développeur. Certains parviennent toutefois à se faire reconnaître "expert développement sénior", mais c'est long et moins payé.
Si tu es carriériste, il faut que tu passes chef de projet au plus vite.
Voire même le mieux est que tu fasses une cinquième année en management et plus du tout en technique. Cela t'ouvrira plus vite les portes de chef de projet, voire de technico-commercial.
Il faut savoir que la majorité des chefs d'agences sont des anciens commerciaux/manageurs et presque jamais des développeurs.

[Mat.M]

Mon ami, qui travaille également dans une grosse structure informatique pense qu'il faut que j'évite si possible, et ce dés le début de ma carrière, les postes trop techniques de développement et que je m'oriente très rapidement sur des postes d'analystes...mais est-ce que le raisonnement qui consiste à faire passer chef de projet d'avantage d'analystes que de développeur est tenu par toutes les entreprises ?

Absolument.
Développeur / Anaylste-Programmeur c'est un emploi qui tend à être une "voie de garage" ( et j'en sais quelque chose )
Les perspectives d'évolution professionnelles sont minces si tu veux devenir chef de projet il faut que tu sois très bon techniquement que tu aies un minimum de leadership..
est-ce que tu estimes avoir du leadership , être capable de gérer une équipe ?

Pour ce qui est des délocalisations off-shore c'est inévitable les entreprises commerciales cherchent à réduire les couts et les charges financières d'un projet informatique par tous les moyens

Dans tous les cas, même si la situation des développeurs en France est bonne dans 10-20-30 ans, je ne me vois pas coder toute ma vie, je pense qu'au bout de 10 ans max, je voudrais changer, et le problème qui se posera alors justement, c'est que peut-être qu'on considèrera que je suis "trop" technique...ça, ce n'est qu'une idée perso, je ne sais pas justement si dans une boîte, on fait évoluer facilement quelqu'un qui est resté trèèèèès longtemps développeur vers un poste de chef de projet, ça fait partie de mon questionnement.

Encore une fois il n'y pas que le coté technique !
Chef de projet c'est aller voir tes collaborateurs , leur donner du travail à faire, écrire des spécifications , savoir précisément ce que tu attends de tes collaborateurs bref un grand sens de l'organisation.
Il ne faut pas perdre de vue que tu seras amené à gérer des conflits "d'ego".
Prenons un cas extrême : si tu me donnes du travail et que moi je t'envoie ballader que je te discrédite devant tout le monde comment vas-tu réagir ?
Il ne faut pas voir seulement le titre "chef de projet" c'est bon à mettre sur le papier ce titre mais dans la réalité il en va autrement.
La plupart des sociétés de services avec lesquelles j'ai travaillé en France il y avait des relations conflictuelles ; sans compter qu'en France le patron est toujours mal considéré ( l'inverse est vrai également ).

Donc il y a tout un aspect psychologie des choses à avoir pas seulement que le coté technique..

[la drogue c'est mal]

Prenons un cas extrême : si tu me donnes du travail et que moi je t'envoie ballader que je te discrédite devant tout le monde comment vas-tu réagir ?

je te demande de me suivre pour qu'on en discute en tete à tete.

si tu refuses, on en reste la et je te vire dans les jours qui viennent.


Dans tous les cas, ne jamais aller à l'affrontement en publique. Ca serait lui donner l'occation de se justifier de son comportement devant tout le monde et donc créer une division dans l'équipe. Si on reste dans les situations que je propose, je reste "dans mon bon droit".

[ZeRevo]

je te demande de me suivre pour qu'on en discute en tete à tete.

si tu refuses, on en reste la et je te vire dans les jours qui viennent.


Dans tous les cas, ne jamais aller à l'affrontement en publique. Ca serait lui donner l'occation de se justifier de son comportement devant tout le monde et donc créer une division dans l'équipe. Si on reste dans les situations que je propose, je reste "dans mon bon droit".

A la première brindille tu vires ton collaborateur. Un chef de projet qui travaille seul n'est pas un chef de projet.

[Hanoni]

La moindre brindille...ben ça dépend déjà de la manière d'envoyer balader. Je sais bien qu'un chef doit savoir encaisser de sa hiérarchie et de ses subordonnés. Garder son calme et en discuter en aparté dans un premier temps me paraît pas mal.

Un avertissement pour remettre en place les choses en prévenant qu'un autre incident comme ça et c'est la porte, mais bon, un développeur agressif qui envoie balader son chef ou qui discute chaque directive, même s'il est très bon, c'est un boulet dans une équipe, je me trompe ?

De toute façon, la situation que tu me présentes peut n'avoir que quelques origines à mon sens :

- soit la personne ne t'aime pas, dans ce cas là, tu n'y peux pas grand chose à part lui dire de garder ses ressentiments à ton égard de côté au travail

- soit tu prends réellement de mauvaises décisions, et à ce moment là, tu lui dis en aparté que son idée était bonne mais qu'il y a des manières plus intelligentes de les exposer

- soit tu es face à un asocial ou un anti-patron basique et stupide, et dans ce cas là, je ne vois pas ce que tu peux faire d'autre que de le mettre à la porte parce que tu n'arriveras à rien avec lui


Je ne trouve pas qu'envoyer balader son chef en public soit une petite brindille, c'est même une faute grave, après, il faut aussi que le chef sache se montrer diplomate, calme et patient pour réellement cerner l'origine du problème plutôt que de s'emporter.

Mais bon, je ne peux parler de ça qu'en théorie, ça revient au même que d'être critique envers ses parents, tant qu'on a pas vécu les mêmes situations, on ne peut pas savoir ce qu'on fera exactement, juste essayer au mieux de s'y préparer...

[la drogue c'est mal]

A la première brindille tu vires ton collaborateur.

c'est la 2e :
la premiere, il envoit balader
la deuxieme, il refuse ma convocation pour un entretien en tete à tete

les 2 "brindilles" se font en publique.

Un subordonné qui m'envoie balader et qui refuse de me parler, que puis je faire de plus ?

Quand je dis que je le vire, c'est surtout parce que je bosse qu'avec des prestas donc j'ai la possibilité de le faire.

Un interne c'est plus... procédurale.

fin du HS ?

[el_slapper]

Il y a "non" et "non".

"_Bon, puisque tu as fini le programme, merci de me faire la doc
_Non, je ne ferais pas de doc
_Tu est ingérable!
_....silence méprisant"

"_Euh, c'est urgent, mais le plus urgent, c'est les OPCVM, fais juste les OPCVM, on verra après pour le reste
_Non, je ne sais pas faire ''juste'' les OPCVM en les séparant du reste. Mais tu auras tous les traitements dans le délai prévu, OPCVM compris
_Tu est sur de ton coup?
_Oui, c'est ma seule chance de tenir les délais, faire un programme groupé".

dans quel cas la solution de la drogue c'est mal est-elle appropriée, et dans quel cas est-elle de l'autoritarisme imbécile?

[Ubiquité]

Après si le personnage satisfait l'employeur depuis de nombreuses années vous allez peut-être lui accorder ça non ?

[gangsoleil]

"_Bon, puisque tu as fini le programme, merci de me faire la doc
_Non, je ne ferais pas de doc
_Tu est ingérable!
_....silence méprisant"

Ici, tu es face a un mauvais element : s'il ne comprend pas que faire la doc fait partie de son projet - ou tout du moins aider une personne du departement documentation a faire cette doc - alors tu dois te separer de cette personne, ou lui proposer un poste en adequation avec ses capacites.

"_Euh, c'est urgent, mais le plus urgent, c'est les OPCVM, fais juste les OPCVM, on verra après pour le reste
_Non, je ne sais pas faire ''juste'' les OPCVM en les séparant du reste. Mais tu auras tous les traitements dans le délai prévu, OPCVM compris
_Tu est sur de ton coup?
_Oui, c'est ma seule chance de tenir les délais, faire un programme groupé".

Ici, tu es face a une personne qui sait prendre ses responsabilites, et qui sait egalement motiver ses choix. A toi chef de projet d'etre suffisamment competent dans le domaine pour savoir si tu te fais enfumer ou non. Si c'est le cas, il est urgent d'en discuter pour savoir ce qui te fait penser que le projet n'est pas realisable.

[gangsoleil]

Bonjour,

Je reviens un peu plus sur le sujet initial : comment devenir chef de projet, et eviter ainsi les voies de garage ?

Dans ce que je lis ici, vous dites que les postes trop techniques, et en particulier le developpement d'applications, sont des voies de garage, et que ces postes sont de moins en moins nombreux en France.

Avez-vous regardez les postes que proposent aujourd'hui les SSII, qui sont tout de meme, qu'on le veuille ou non, un bon indicateur ? Y voyez-vous beaucoup de poste de chef de projet ? Et des postes de developpeur ?


Au cours de ma courte carriere, j'ai deja croise beaucoup trop de chefs de projets incompetents techniquement, qui se font regulierement enfumes par de beaux parleurs, mais qui sont tres bien vu de leur hierarchie.
A l'oppose, les bons chefs de projet que j'ai croises sont souvent mal percus par les chefs, car ils n'ont pas le discours politique de cirage de pompe.

Un bon chef de projet doit avoir de l'experience : il doit avoir participe a des projets pourris, avoir ete confronte a des situations desesperantes, mais aussi avoir vu des projets rondements menes, ou tout s'est bien passe.
Une fois qu'il aura vu tout cela de l'interieur - donc en tant que developpeur ou assimile - alors seulement il aura une chance de devenir un chef de projet correct.

Pensez-vous par ailleurs qu'on puisse raisonnablement esperer que tous les nouveaux diplomes deviennent architectes/chef de projet/responsable d'equipe/que sais-je encore tres (trop) rapidement - a supposer qu'ils en aient envie, ce qui est loin d'etre le cas.

Bien sur, ce discours ne s'adresse pas a ceux pour qui la carriere est a mettre au premier plan. Pour ceux-ci, cirez des pompes, faites-vous mousser, appliquez betement et sans comprendre les decisions de vos chefs, meme si vous sentez que c'est une connerie : vous grimperez dans la hierarchie selon le principe de peter ou de dilbert, a votre choix.

[ame="http://fr.wikipedia.org/wiki/Principe_de_Peter"]Principe de Peter[/ame] : Dans une entreprise, les employés compétents sont promus et les incompétents restent à leur place. Donc un employé compétent grimpe la hiérarchie jusqu'à atteindre un poste pour lequel il ne sera pas compétent. À ce stade, il devient donc un incompétent qui va occuper son poste indéfiniment.

[ame="http://fr.wikipedia.org/wiki/Principe_de_Dilbert"]Principe de Dilbert[/ame] : Les gens les moins compétents sont systématiquement affectés aux postes où ils risquent de causer le moins de dégâts : l'encadrement.

[el_slapper]

@Gangsoleil : +2!

***Pour ta réponse à mon post, c'est effectivement ce qu'il aurait fallu faire. Mais dans le premier cas, la chef était faible. Et dans le second, le programmeur qui a fait cette réponse(moi) était le seul(avant de répondre, parcequ'après.....) à ne pas être enseveli sous le boulot. Et donc personne n'avait le temps de vérifier mon architecture(qui à ce moment n'existait que dans ma tête) dans le délai de 2 jours imparti pour faire tourner les OPCVM.

D'ailleurs, quand j'ai passé la main de ce programme à mon successeur, j'ai mis plus d'une journée à faire un schéma complet de l'algorithme pour pouvoir l'expliquer. Le CdP était obligé de me faire confiance - tout simplement parceque le simple fait de vérifier nous aurait mis dans le rouge. Pas un cas à généraliser j'en conviens.

***pour ta réponse générale, j'aie bien peur que pour la plupart des cas, tu aie raison. Mon expérience personelle, c'est 60% de Dilbert, 30% de Peter, et 10% d'autres(souvent positifs). Evidemment, mon expérience est limitée(une douzanie de missions, presque toujours en bancaire, toujours en financier, à l'exception d'une pige chez un éditeur de logiciels clairement dilbertien).

Je nuancerais ausi ton point de vue sur la maitrise technique. Un CdP qui assume son manque de maitrise technique peut s'en sortir, à condition de savoir s'appuyer sur des indicateurs fiables. A consition aussi de ne pas se contenter d'un seul son de cloche et d'être méfiant(règle des 3 C : la Confiance sans Contrôle, c'est de la Connerie). Evidemment, c'est fort rare. Mais ça existe, j'en ai vu.

D'ailleurs, je suis en train de me rendre compte que je suis en train de tourner beau parleur, je vois des chefs qui me font une confiance aveugle. C'est grave, docteur?

[Jimmy_]

En 12 ans de carrière j'ai rencontré beaucoup de chef de projet.
Il y a de tout, il est certain que si tu es très bon techniquement tu seras moins facilement taillé pour un poste comme chef de projet.
Mais j'ai vu aussi des chefs de projet qui n'avaient que le titre et c'était les techniciens qui dirigeaient la barque, car justement ils n'y connaissaient rien mis à part word et excel. Après j'ai eu aussi un chef très technique qu'il était impossible de rouler. Je passe sur les chefs de projet qui étaient chef d'eux même et qui passaient leur temps dans le bureau de leur n+1 pour se plaindre ou critiquer les autres.
Un profil aux dents longues qui sais bien s'entourer de gens sachant travailler peut y arriver, mais dès qu'il embauche les mauvaises personnes, c'est fini pour lui. Et fatalement ça arrivera.
Il y a aussi les promotions canapés, c'est amusant, ça arrive souvent quand l'environnement est propice.

Bref, le meilleur profil d'un chef de projet pour moi en tant qu'expert technique est celui qui sais dire non à sa hierarchie en particulier sur les délais délirants et les modifications intempestives de spécification. Ca c'est un bon chef. Après il y a toujours des gens caractériels à manager, mais bon des qualités humaines standard suffise.

Il faut aussi savoir qu'une fois chef de projet et après il n'y a plus de technique, c'est de la politique et de la diplomatie, c'est tout. Tu trouveras toujours un expert comme moi pour te pondre une architecture ou une configuration particulière, il te restera plus qu'a deviner si c'est du lard ou du cochon et ça il n'y a que l'expérience pour te sauver. Car des pseudos informaticiens qui veulent te vendre des salades avariées il y en a à la pelle.

bon courage,

[ZeRevo]

Le principe de Peter existe en France car il faut occuper des postes d'encadrement pour obtenir plus de flexibilité, pour manager d'autres personnes, pour monter dans l'échelle sociale et pour obtenir un meilleur salaire.

En France la technique est mal perçue pourtant c'est beaucoup plus compliqué de développer une application sans bug que de manager une team surtout quand les développeurs sont compétents et motivés.

[Ecva233]

Etre chef de projet, tout le monde peut prétrendre l'être.

Etre un bon chef de projet, j'ai ai pas connu beaucoup en un peu plus de 20 ans dans l'informatique.

Je pense qu'il faut avoir connu le technique, et avoir ensuite évoluer vers des postes de chef de projets, soit par des formations internes ou externes. Mais connaître les impératifs de développement, d'analyse, d'architecture, ... par la pratique est un atout inon négligeable.

Ensuite l'enfumage, il existe et existera toujours. Donc quel que soit ton statut dans une équipe si tu te fais enfumer, tu sera beaucoup plus méfiant la fois suivante. Toute expérience est bonne à prendre.

Et puis un truc important, un bon chef de projet doit savoir rester humble, et mettre en avant le travail de son équipe, et pas le sien, lors d'une revue de bilan de projet, et pas seulement pour la galerie. Car un chef de projet qui tire la couverture à lui, cela va se savoir, et ses prochains projets seront peut être beaucoup plus problématiques à gérer pour lui.

Il doit savoir reconnaître ses lacunes et s'appuyer sur les compétences des gens qu'ils encadrent. En gros être honnête avec lui même et avec les autres.
Il doit savoir dire non, et pas seulement à sa hiérarchie ou à son équipe, mais aussi à d'autres chef de projet ou directeur de projet.
Il doit savoir prendre les baffes et pas se défausser sur tel ou tel membres de son équipe. Après entre quatres yeux, il peut les redistribuer . Et c'est pas aussi jouissif qu'on pourrait le croire.
Il doit savoir expliquer et communiquer, et non pas juste te dire "faut faire cela", comme j'ai tendance à le voir de plus en plus. C'est impératif de le faire, et de prendre du temps pour le faire.

En gros un bon chef de projet, c'est un mélange d'énormément de qualité, donc c'est cela qui fait qu'ils sont rares. Même si une école t'y prépare, rien ne vaut l'expérience professionnelle en entreprise pour évoluer vers ce type de poste.

Enfin c'est ma perception de la chose.

[rakakabe]

Un truc sur le sujet : ici

[Leodams]

Bonjour,

Issue du technique je vais passer sur poste de chef de projet infra chez un client.
Je connais les méthodes de travaille d'un chef de projet, mais je me pose la question suivante :
comment gérer des projets sur des technos que je ne maitrise pas ?

Si j'ai besoin de découper des tâches (WBS) sans connaître réellement l'ensemble des actions à effectuer.
Comment je peux les déterminer ? Pensez-vous que puisse m'appuyer sur un contributeur qui gère ce sujet sans passer pour un clown.

Exemple : Si j'ai besoin d'effectuer une migration Oracle.
A part demander à Google de m'expliquer quelles sont les grandes étapes. Comment puis-je déterminer ce découpage au sein d'une entreprise?

Mon expertise sur cette techno n'est pas assez grande pour être sûr de ne rien oublier.

Merci pour vos avis.

[autran]

bonjour Leodams,

Pour ta moralité et ton honeteté intelectuelle, je souhaiterais que tu sois mon chef de projet !

Amicalement Kevin