Discussion :

[stephgil29]

Je suis désolé Bourgui mais je ne suis pas totalement d'accord avec toi quand tu dit

Un gars qui connait pas le code et qui donne des délai c'est des projets livré à la bourre, a moins qu'il demande à chaques fois au dev mais dans ces cas la c'est pas un chef de projet mais un secrétaire.

Je préfère largement un cp qui demande lorsqu'il ne connait pas la réponse plutôt que de nous mettre dans une merde innommable par soucis de fierté mal placé...
J'adhère plus a la vision de bluenicolas

Quelqu'un a déjà cette compétence (développeur, db administrateur, etc) donc pourquoi ne pas lui faire un minimum confiance... et déléguer (pour moi déléguer, c'est se servir intelligemment des compétences de l'équipe et pas bêtement donner du boulot dont on ne veut pas).

Un bon chef de projet sais employer au maximum les compétences de son équipe.
Après pour l'évolution d'un dev en cp, il est clair que les compétences requises ne sont pas les mêmes. Il est dommage de sacrifier parfois d'excellent dev pour en faire des cp très mauvais... même si ce n'est quand même pas une généralitée. La place de l'architecte n'est pas suffisamment mise en valeur dans les entreprises.
Maintenant comme dit j.peg

==> le développeur expérimenté doit passer CP sinon il n'est plus rentable (CQFD).

ce qui résume bien la situation...Rentabilité.

[Alain Defrance]

Il suffit de lire : http://www.touilleur-express.fr/2009/07/27/senior/ pour se rendre compte que c'est un grave problème. En france la plupart des développeurs n'aiment pas ce qu'ils font. Heureusement il reste des survivants ...

[helmi.dridi]

Développeur avec connaissance générale : Ici le but n'est pas de devenir un expert dans un domaine, mais plutôt d'avoir une connaissance générale dans un domaine assez vaste. Ce profil ("moins bon" développeur) est beaucoup plus adapté pour devenir chef de projet !

Dans mon expérience, toutes boites qui ont fait confiance à ce type de chef de projet dans les projets se sont amenés à l'Échec. Il faut se spécialiser dans une technologie.
Un chef de projet qui connait le web en codant quelques semaines sur Webdev et fait le planning pour un projet en J2EE, Zend Framework ou symphony ?

La réalité s'est que ce n'est pas forcement les gens compétent qui deviennent manager mais les personnes qui sont la au bon moment au bon endroit et qui savent se mettre en avant et faire de la politique. Sans compter que l'on ne sort pas le héro des projets, c'est à dire que le bon développeur qui résout tout les problèmes et qui produit de la qualité, qu'il soit d'accord ou non, en général il reste développeur pour ne pas casser la production...

++

+1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 tu ne vas pas être développeur toute ta vie ?

Cette question m'a été posé par des anciens collèges, et ça ne vous paraitra pas étrange si je vous que c'est les plus incompétent de la boite à l'époque, et ils l'avouent en plus.

[chaplin]

Comment sortir du cercle vicieux ?

- Partir ou devenir manager, mais ne pas resister, ou rester entre deux eaux. Certains ne sont pas prêts mais le deviendront plus tard, d'autres jamais.

[souviron34]

Bon, je vais d'abord commencer à répondre à certains, avant de répondre au général....

tout d'abord une bonne discussion sur le forum Emplo :iQuelles sont les qualités et compétences pour être un bon chef de projet ? :

un bon développeur a tout de même des qualité commune avec le chef de projet.

Il est méticuleux et organisé, jamais on mettra chef de projet un développeur que j'applerai de "cowboy", qui peut résoudre plein de problème mais en passant par les solutions les plus dégueulasse.

Il connait le code et le système, quand il faut donner des délai c'est essentiel. Un gars qui connait pas le code et qui donne des délai c'est des projets livré à la bourre, a moins qu'il demande à chaques fois au dev mais dans ces cas la c'est pas un chef de projet mais un secrétaire.

Il sait exactement quoi dire au partenaire ou client sur les évolution faisable facilement.

ll connait les capacité technique pure des dev et peut mieux répartir les taches.

D'un point de vue personnel, j'aime le code, mais faire que ça pendant 20 berges....

Je me souviens avoir passer une fois un test psy où on tirait comme conclusion si on était plutôt "réalisateur", "artiste", ou "adminsitratif"..

Cela dépend des personalités de chacun...

Le soucis viens en grande partie du management comme on le fait en France.

Aux pays bas par exemple, il y à très peu de hiérarchie dans la boite, et, en néerlandais, on travaille avec X et non pour X.

J'ai deux personnes au dessus de moi : l'une est technique, l'autre s'occupe du coté business du projet.

Ça marche bien mieux que tout ce que j'ai vu en France.

La cathédrale et le bazar . . .

++100000

..
Je n'ai que l'expérience d'une très grosse SSII, et pendant quelques années, prendre des responsabilités a été synonyme d'éloignement de la technologie. Ne plus "pisser une ligne de code" pendant longtemps, je n'ai pas aimé. Dans cette grosse structure, l'évolution normale est de glisser vers du management, remplir des feuilles Excel, gérer les activités des uns et des autres, bref, changer de métier : évoluer vers un rôle d'architecte(*) est rare. Et hélas c'est là qu'est l'os. Le management et la technologie sont deux métiers différents, et le fait que l'un soit considéré comme l'évolution normale de l'autre est une erreur. Chacun requiert des compétences particulières ; être bon dans l'un ne signifie pas être bon dans l'autre, et vice-versa.

Après, c'est peut-être différent dans des plus petits services.

(*) Architecte, ce beau métier dont on m'a beaucoup parlé, qui a l'air très chouette mais dont on se passe par la force des choses. J'en ai vu un, une fois.

On y revient.. La "tailorisation" des métiers de l'informatique est à mon avis la cause de ceci....

==> le développeur expérimenté doit passer CP sinon il n'est plus rentable (CQFD).

assez d'accord, mais c'est aussi lié à une "marketisation" de la profession et non à une professionalisation...

Et aussi à une "reconnaissance de statut"...

En revanche pour en revenir un peu au sujet, je trouve complètement normal que les meilleurs développeurs deviennent managers. On ne peut pas déplorer, d'une part, le manque de réalisme technique de nos supérieurs, et d'autre part refuser que les meilleurs développeurs ne deviennent managers.

a chaque fois, les gens croient qu'un chef de projet est un metier sans problémes, et sans stress...et c'est absolument faux.

En faite, un vrai chef de projet est un profil a part...

C'est vrai...
Par contre :

etre un chef de projet c'est orienter sa carriere vers le management, ...

Voir plus bas et la discussion en référence..

Ce que je reproche à ce que tu dis est "carrière"..

être un Chef de projet est lié au projet.. Pas à la carrière.. Et c'est là où se situe le problème, à mon point de vue...

Dans mon expérience, toutes boites qui ont fait confiance à ce type de chef de projet dans les projets se sont amenés à l'Échec. Il faut se spécialiser dans une technologie.

Là je suis résolument contre cette opinion...

Pourquoi mettre les meilleurs développeurs à la gestion de projet ?
Alors que souvent ils ne le veulent pas. Promotion ou punition ?

Je crois que la seconde partie de la question est biaisée...

Certains le veulent, d'autres non. Dans certains projets certains le veulent, dans d'autres les mêmes ne le veulent pas...

Il y a le "management" d'un coté. Et le développement de l'autre.

Grossière erreur...

Ces deux disciplines ne demandent pas les mêmes compétences, ni les mêmes qualités (par exemple n'importe quel développeur avec la rigueur d'un professionnel du management serait licencié sur le champ, non ?).

Pas les mêmes au total, mais un recouvrement...

Pourtant nombre de projets sont dirigés par des développeurs, qui la plupart du temps ne veulent pas (ou plus) être les responsables des problèmes administratifs inhérents à toute entreprise (budgets, conflits d'équipe, négociation client, etc.)

Alors pourquoi confier une tache qui ne lui convient pas à quelqu'un qui, a priori, souhaite ne pas s'éloigner du code, domaine dans lequel il est véritablement une "star".

Car en plus cette punition touche souvent les meilleurs. Le monde à l'envers en quelque sorte.

Cette question beaucoup de développeurs ultra-doués, que leur hiérarchie a obligé à passer de "l'autre coté du miroir", se la posent en boucle.
...

Le résultat peut aller, pour certains, jusqu'à la dépression. D'autres perdent l'envie. Et en tout cas, très peu réussissent dans la gestion de projet.

Alors pourquoi continuer à confier cette tâche à des programmeurs s'ils ne le veulent pas ?

Là encore , c'est biaisé...

Un début de réponse est que les meilleurs développeurs ont tout contre eux : ils essaient d'avoir une image globale du projet, ils acceptent les responsabilités et ils se soucient réellement qu'un projet réussisse.

Là je suis d'accord...

Peut-être parce que si ce n'est pas un développeur qui s'y colle, ce sera un professionnel du Project Management avec ses travers de responsable irresponsable.

Absolument...

Comment sortir du cercle vicieux ?

Il y a à mon avis 2 grosses raisons principales : la "tailorisation" des projets informatiques découpe en "tâches", "responsabilités", "grades", des éléments qui s'inter-pénétrent et de plus changent de projets à projets.. Et la notion individuelle de statut (diplôme, grade, paie, responsabilité, etc)

On a fait un "métier" et un "grade" technique de choses qui sont plus un "overlap" entre la technique et l'humain...

Comme je l'ai répété maintes fois, pour moi une "Direction de projet" devrait, techniquement , être composé de 2 personnes (un "informaticien relativement généraliste" et un "utilisateur expert"). auquel on peut adjoindre (mais plutôt qui feront référence à) un gestionnaire financier.

Donc à mon avis la première des "solutions" serait que, dans l'esprit de chacun (et du coup cela se répecutera sur le management des SSII et autres), on se débarasse de la notion de "toujours montant" (principe de peter). On peut être en haut du projet à un moment donné, et vouloir revenir à de la prog plus tard, sans pour autant se sentir "has been" ou mal perçu.

Cela est à mon avis le plus important, car c'est tout autant personnel, que par rapport à l'entourage familial, et les rapports dans l'entreprise...

Avoir été programmeur, puis CP, puis revenir programmeur, n'est pas un échec.. Juste une différente période de la vie, associée à un différent projet..

Ce qu'il faut principalement intégrer, c'est ce qu'on souhaite, pas ce à quoi on veut correspondre dans la société...

Les dépressions dont tu parles plus haut sont à mon avis beaucoup plus liées à la perte de "statut" que d'intérêt pour le travail...


Ensuite, la "revendication" de certains (et des SSII par exemple) à s'affubler (ou affubler) du titre de CP alors qu'ils sortent de l'Ecole ou d'une formation est à mon sens 100% stupide...


On apprend des trucs pour être CP, mais cela vient après avoir eu une expérience variée... Il faut être suffisamment assis sur ses connaissances pratiques (et non théoriques) pour disposer d'une autorité naturelle, et simultanément d'une écoute qui fait (très) souvent défaut aux "frais émoulus"... remplis de leurs certitudes...

Il y a aussi une question de caractère. Certains sont naturellement sociables, ouverts, d'autres sont naturellement plutôt solitaires, ou dictatoriaux, etc...


Voir donc des annonces comme "recherche Chef de Projet 2 ans d'expérience" est absolument, irrémediablement stupide....

Y répondre et ensuite se monter le bourrichon en se vantant d'être CP est également stupide....



Sortir du cercle vicieux est donc à mon avis une question avant tout de connaissance de soi, et par conséquent d'avoir sa bonne dose d'humilité (et pas de timidité) et de confiance en soi (et pas d'arrogance).

Dans ce cas, on peut dire "non" à un certain moment, "oui" à un autre.. Sans se sentir dévaloriser, ni par rapport à soi, ni par rapport aux autres (car on est capable de justifier son choix).

Avez-vous déjà été nommé(e) responsable de projet ?

Oui, 3 fois...

L'avez vous vécu (ou le vivez-vous) comme une corvée ou comme une promotion ?

Ni l'un ni l'autre...

Comme un défi personnel. Pour 1 cas, je n'étais vraiment pas sûr de pouvoir mener à bien l'ensemble de la tâche qui m'était confiée, mais au vu du projet et de l'équipe, je pensais que j'en étais capable. Dans tous les 3 cas, le défi était de faire le meilleur projet possible, dans la meilleure ambiance possible, avec le meilleur résultat possible..

Je l'ai toujours envisagé (c'était des softs industriels) comme une séléction aux JO : être dans les 3 premiers n'est pas le but. Etre dans la sélection nationale, c'est à dire faire partie des 20 ou 30 meilleurs mondiaux oui.

Le fait d'arriver dans les 3 premiers nécessite , comme en sport, de la chance, et du bon marketing, choses indépendantes de ma volonté et de mes compétences.

[chaplin]

Pourquoi mettre les meilleurs développeurs à la gestion de projet ?
Alors que souvent ils ne le veulent pas. Promotion ou punition ?

Je crois que la seconde partie de la question est biaisée...

Certains le veulent, d'autres non. Dans certains projets certains le veulent, dans d'autres les mêmes ne le veulent pas...

Quand t'es développeur tu fais le travail qu'on te demandes, tu n'as pas le choix. En revanche, tu as le choix de partir.

"Les merdes volent en escadrille.", Jacques Chirac.

Testé et approuvé
Solution, voler au dessus d'elles . .

[free07]

J'ai lu attentivement toutes les réponses et j'aimerai ajouter que cette problématique peut être lié à pratiquement tous les corps de métiers.

Je ne sais pas si cela est un mal français mais en tout cas, il est bien réel.

Les entreprises qui valorisent le travail de chacun sont trop rares et les personnes qui connaissent cela peuvent s'estimer très chanceuses.
( en parlant valorisation je pense bien sûr à la rémunération mais aussi à la reconnaissance de chacun lors de la réussite d'un projet )

A propos de la valorisation des membres de l'équipe lorsqu'elle se doit, j'ai tellement vu de responsables de services ou de chef de projet y penser quelques semaines juste après leur formation sur ce sujet, bien après, passer à autre chose et l'oublier complètement pour surtout penser à leur carrière.

La plupart du temps, un CP est le seul responsable de la réussite d'un projet et lors de l'échec... et bien on trouve toujours d'autres excuses ou responsables.

Dans la réussite d'un projet, les directions oublient trop souvent que cela est du au travail de toute une équipe et lors des échecs, les responsables, malheureusement détestent se remettre en question.

[manpe]

Bonsoir,

Après avoir lu ce débat très intéressant, j'ai eu envie d'apporter mon avis de "jeune diplomé" (depuis 1 ans en fait) en info et donc ... développeur.
Je ne travaille pas en SSII et j'ai la chance d'être dans une boite qui reconnait le travail et propose un certain nombre d'évolutions possibles : voie technique : concepteur, architecte, expert, ou voie plus "hiérarchique" : CP etc. J'aime beaucoup mon travail et j'espère rester dans le technique longtemps sans devoir sacrifier salaire image et tout ce qui va avec.

J'ai participé une fois à une formation courte mais très bien faite de gestion de projet où le formateur, manager chevronné a commencé par :
"Qu'on soit chef de projet pour construire une maison ou un soft, c'est pareil ! Un bon chef de projet doit savoir communiquer avec son équipe pour pouvoir piloter un projet. L'essence du projet importe peu !"

A mon avis il avait bien raison ! Un chef de projet, même si malheureusement c'est sur lui qu'on tapera sur les doigts en cas d'échec, ne peut pas "tenir la baraque" d'un projet tout seul. Forcément, pour que ça marche, il faut des personnes techniquement compétentes qui donneront un avis qualitatif et quantitatif sur le travail à réaliser. Le chef de projet doit, lui, savoir mettre d'accord toutes les équipes travaillant sur le projet car il a une vue d'ensemble, et référer plus haut que ceci ou cela n'ira pas pour les raisons X ou Y. En un sens il est le piston qui fait que tout cela fonctionne. Malheureusement cela se décline par des diagrammes de Gantt à foison, du PowerPoint à outrance et du push push de mail entre les besoins des clients et ses "bras droits" techniques.

Conclusion pour moi : promouvoir un développeur, si doué soit-il, pour être CP sous prétexte qu'il "connait bien et maitrise le sujet du point de vue technique" est un peu tiré par les cheveux. Certes, si les personnes chargées de la technique lui racontent des cracs il pourra s'en rendre compte, mais si ça commence comme ça c'est que déjà on fonce dans le mur. Si ce développeur techniquement très doué passe trop de temps à ébaucher des solutions techniques, il ne pourra pas assurer son rôle de chef de projet de toute façon ...

[Fred3d]

Si le salaire suit c'est généralement une bonne opportunité pour évoluer ...

[*alexandre*]

boh c'est peut être une spécificité française mais les spécialistes gagnent mieux que les chefs de projets ici un spéclaliste junior (+ 3 ans d'expérience) gagne plus de 70'000 euro par année et ca monte à 100'000 avec 5 à 6 ans d'expertise technique

alors moi je défenderai toujours que s'orienter vers le management n'est de loin pas une promotion mais plutot une réorientation de carrière

et franchement faire du relationnel et changer les couches culottes des clients est de loin moins intéressant que de faire de l'architecture logicielle sur de grosses applications et l'implémentation de proof of concept pour valider l'ensemble des technologies

mais bon chez vous en france y a que les managers qui gagnent bien leur vie, je n'en comprend pas la raison ... les managers français sont dans le top européen au niveau des salaires mais pour les autres professions y a environ 40% de différence (dans le bas) qui peut justifier ça ?

moi je suis très fière de vivre dans un pays ou le fonctionnement se rapproche du modèle de notre cousin américain

[souviron34]

et franchement faire du relationnel et changer les couches culottes des clients est de loin moins intéressant que de faire de l'architecture logicielle sur de grosses applications et l'implémentation de proof of concept pour valider l'ensemble des technologies

et je crois que tu ne sais pas ce que c'est qu'un Chef de Projet...

Ta vison est très jeune et entièrement marquée par la structure de grosses SSII..


Je te signale que :

• primo on ne "change pas les couches culottes de ses clients", mais , en tous cas dans les projets industriels, on dialogue pour mettre au point le cahier des charges et les specs..
  
  
• secondo, on "ne fait pas du relationnel", on gère une équipe, avec de plus les relations avec les échelons supérieurs, et quand tu aimes et que tu crois dans ton projet, c'est assez intéressant de faire partager ton enthousiasme à des non-geeks...
  
  
• tertio, il n'est pas rare que le Chef de Projet soit l'architecte général...

parmi tant d'autres choses...

[Invité]

@ souviron34

J'aime bien ta mise au point mais je ne peux m'empecher de remarquer les enigmes qui ponctuent ton intervention (même si tout n'est pas flou loin s'en faut)

Ce qui me fait rebondir sur le sujet : J'ai parfois managé une partie de projet et un intégrateur qui devenait mon manageur sur une autre partie. Toute l'astuce consistait à préciser de quelle partie on parlait avant chaque phrase ou au moins laisser l'autre réflechir à sa position avant de répondre... Certes il est néerlandais et moi suisse avec une touche de suède... impossible avec un Français pas voyageur ? OUI totalement impossible par tradition .. mm

Quand on a les 2 casquettes manageur/dev , on a affaire à deux entités : une logique et une biologique : dans un cas la rigueur est obligatoire , dans l'autre c'est le contraire il faut "laisser de la place" au client pour qu'il donne son opinion

ce qui sépare les deux : la négociation

Négocier ne sera jamais une science exacte alors que développer s'en rapproche si on excepte le marketing technique des éditeurs dont on dépend
aussi

[Mat.M]

Bonjour je trouve que c'est une des discussions parmi les plus intéressantes trouvée sur DVP ( merci Gordon )

Juste pour info je suis un français expatrié au Canada la conception des choses y est totalement différente , le lien donné sur le blog et le texte de Romain ( "dégage sale programmeur") le décrit parfaitement bien.
Aux USA et en Amérique du Nord programmeur c'est plus un métier à part entière.

En France, un chef de projet, un commercial va gagner beaucoup plus qu'un développeur alors que bon, le chef de projet fait quoi :
- organiser des réunions
- participer à l'analyse mais s'il a pas fini, c'est pas grave les développeurs se démerderont avec des informations orales
- mettre la pression sur les devs pour qu'ils finissent à temps
- test de l'application
- contact avec le client

je ne suis pas trop d'accord avec toi : que se passe-t-il si toi tu deviens chef de projet et que tu fasses capoter le projet ? N'oublies-pas que tu dois payer des pénalités en cas de retard sur l'échéancier...
j'avais vu un article sur les suicides au travail dans la revue Capital, un programmeur balancé chef de projet du moins responsable du jour au lendemain il n'a pas pu tenir la pression eh bien il a décidé d'en finir avec la vie ; il avait un enfant je crois bien

Le problème en France c'est qu'on a mis fin au service militaire je trouve que c'était une excellente chose comme entrée dans la matière dans la vie civile

et le commercial :
- faire le beau gosse
- parler de sujets qui ne maitrisent pas (ils vendent des informaticiens comme on vendrait des patates sur un marché)
- appeler des clients, organiser des rendez vous
- vendre au plus cher

oui le commercial fait le beau gosse je l'ai vu souvent j'ai même vu un de ces spécimens mettre des gants pour conduire ; comme toi je n'apprécie pas trop cette espèce animale.
Mais c'est pareil si tu ne fais pas de chiffre d'affaire tu risques de te faire éjecter.

[Mat.M]

Alors pourquoi continuer à confier cette tâche à des programmeurs s'ils ne le veulent pas ?

la problèmatique est vaste ; c'est la mondialisation et Analyste/Programmeur je pense est un métier condamné tout le monde le sait parfaitement à cause de la sous-traitance offshore ( en Inde ou ailleurs...)
donc la seule alternative pour un AP c'est de monter un cran plus haut et devenir chef de projet, encadrer des gens.

[jpouly]

Cette discussion me fait penser à cet article, auquel j'adhère totalement : dégage sale programmeur !

La même chose.

La gestion de projet et le développement sont deux choses différentes, et diamétralement opposées. Même si en temps que développeurs, on est amené à discuter avec le client et ses équipes techniques, on n’a pas à s'occuper de la planification, ni des spécifications et autres joyeusetés.

Surtout que généralement, les chefs de projets ont des moyens d'actions très limités quant à l'utilisation des ressources de l'entreprise. A part gueuler, ils ne peuvent pas faire grand chose. Ils sont responsables de tout sans avoir les moyens d'assumer leurs reponsabilités.

la problèmatique est vaste ; c'est la mondialisation et Analyste/Programmeur je pense est un métier condamné tout le monde le sait parfaitement à cause de la sous-traitance offshore ( en Inde ou ailleurs...)
donc la seule alternative pour un AP c'est de monter un cran plus haut et devenir chef de projet, encadrer des gens.

Là, je ne suis pas d'accord. Quand on voit que les clients sont incapables de spécifier leurs besoins, comment voulez vous faire de l’offshore ? Les projets dont j'ai eu connaissances sont de vraies catastrophes, autant économiques que techniques. Sans parler de la perte de connaissances métiers que cela engendre dans l'entreprise (dont elle se fout royalement, mais qui lui retombe tôt ou tard sur le râble).

De plus le gain économique d'un développement offshore n'est pas avéré. C'est vrai qu'un ingénieur indien coute 500 euros par mois, mais il faut ajouter les couts de traduction, la MOA en France, la MOE (en france aussi sinon ), ...
Bref c'est rentable pour les très gros projets, avec des risques très importants de turn-over et autres qui font que le offshore peut s'avérer une vraie catastrophe.

[ZeRevo]

je ne suis pas trop d'accord avec toi : que se passe-t-il si toi tu deviens chef de projet et que tu fasses capoter le projet ? N'oublies-pas que tu dois payer des pénalités en cas de retard sur l'échéancier...
j'avais vu un article sur les suicides au travail dans la revue Capital, un programmeur balancé chef de projet du moins responsable du jour au lendemain il n'a pas pu tenir la pression eh bien il a décidé d'en finir avec la vie ; il avait un enfant je crois bien

Le problème en France c'est qu'on a mis fin au service militaire je trouve que c'était une excellente chose comme entrée dans la matière dans la vie civile

Le chef de projet aura toujours un échappatoire pour dire que ce n'est pas lui le fautif. Pour gagner un projet une entreprise peut jouer sur :
- les coûts : moins de développeurs, privilégier les développeurs les moins cher (ceux avec le moins d'expérience), on ne dépense pas en formation
- les délais : on travaille sans tests et on vend une application sans bugs bloquants

Après au cours du projet, il se peut que l'analyse des besoins soit mal réalisée ou incomplète, ou que les besoins du client changent. A ce moment, là plusieurs cas sont possibles, soit le chef de projet se place du côté du client, soit il protège son équipe de développeurs. Les meilleurs bien sûr savent faire les 2 mais ils sont plutôt rare...

Toutefois, il faut aussi admettre que certains développeurs sont aussi des cas bien particuliers dont certains sont très difficiles à gérer...

[chemanel]

J'ai l'impression que vous prenez tous les chefs de projets pour des vrais boulet. (surement parce que la majorité des gens ici sont développeur) (comme moi)...

Mais je pense pas que un boulot de chef de projet soit plus facile et du coup doit être moins bien évalué... Comme certains l'ont dis, c'est 2 métiers différents... 2 métiers, des compétences différentes... Mais a premières vue, j'en vois pas un qui soit beaucoup plus facile que l'autre. Y'a autant de glandeurs d'un coté comme de l'autre :-)

Les chefs de projets ont aussi leurs mauvaises journées... Et n'oubliez pas que quelques pars, les chefs de projets font tampons entre les clients et les chefs et vous... Du coup vous êtes tranquilles.. j'ai rarement vu un développeur final se faire engueuler parce que le projet est hors budget... (ou alors il l'a vraiment chercher...) généralement, dès que qqch va pas, c'est le chef de projet qui prend sur la gueule

[Mat.M]

Là, je ne suis pas d'accord. Quand on voit que les clients sont incapables de spécifier leurs besoins, comment voulez vous faire de l’offshore ?

c'est vrai que parfois voire souvent les clients sont souvent compliqués c'est un peu du vécu

[joseph_p]

hiba

allez, je me lance

Ayant causé de la chose avec mon allemand de collègue, il confirme qu'en Allemagne les profils techniques sont mieux payés que les chefs de projet.

En fait, ces derniers peuvent parfois même être bien peu payés, en effet leur role est considéré comme nécessitant bien moins de savoir faire. En gros, le chef de projet doit savoir communiquer, là où un expert technique doit savoir bien plus.

A noter que mon allemand de collègue distingue aussi bien le role de chef de projet de celui de chef d'équipe (ou "team leader"). Pour lui, le team leader est généralement un profil plus technique à même d'encadrer une équipe de développeur. A noter qu'il pense aussi que le titre d'architecte a été fait pour permettre à des "experts" techniques de gagner plus, et que depuis on retrouve plein de monsieurs voulant s'en prendre plein les poches qui n'ont pas forcément les qualités requises.

Pour ma part, je suis entièrement d'accord qu'en France le chef de projet est roi. Ceci dit, les boites qui n'ont aucun respect pour les développeurs n'en ont généralement pas plus pour leur chefs de projet, et en règle générale, grosse SSII ou pas, une boite sans respect vaut mieux la quitter...

D'ailleurs, j'ai encore jamais vu une boite avec un encadrement de projet tip top et un non respect des intervenants plus IT. J'ai même tout simplement rarement vu de boites "top" côté info, la plupart se contentant d'avoir collé à une mode à un instant t puis de s'y coller (sachant qu'avec de nouveaux chefs la mode peut aisément changer, surtout avec des chefs hauts dans la hiérarchie). Ceci dit, j'ai surtout bossé dans la région Est, peut être en est il autrement ailleurs...

++

[moosh]

Je suis, je pense un développeur moyen, surtout au niveau de la "programmation". J'ai plus un profil d'analyste, et de "catalyseur de synergie".

Dans mon boulot précédent j'adorais passer chez tous les acteurs du projet en cours, voir si ca allait, relever les points bloquant, déclencher les rencontres nécessaires pour débloquer, rassembler les statuts et les questions pour le product owner,...

C'est pour ca que j'ai moi-même cherché à devenir "manager".

On engage dans mon équipe et ce que je dit souvent, c'est que je cherche bel et bien des développeurs "meilleurs que moi" puisque ce sont eux qui font le boulot.

Ma philosophie (tendance Agile) est "Faites ce que je vous demande, je m'occupe de ce qui vous empêche de le faire"


Comment j'ai vécu la transition ?

• donner des ordres c'est chiant. J'aime faire des demandes justifiées, mais parfois c'est inévitable, c'est l'ordre qui descends de la hiérarchie.
• j'ai du apprendre à ne plus "travailler" : j'ai eu fort tendance à vouloir assumer une partie des tâches de l'équipe. Résultat je ne voyais que ma part et perdait le scope de l'équipe. J'ai dû stopper et dire à l'équipe "Si vous avez l'impression que je travaille, c'est qu'il y a un problème. Vous êtes l'instrument, je ne suis que le métronome( et parfois la partition)".
  A coté de cela j'ai gardé mon "jardin secret" je développe des parties non critiques hors boulot, pour rester dans le bain et vivre un peu leurs "problèmes de terrain"
• dur dur de gérer une équipe tantôt motivée tantôt fonctionnaire : j'aime travailler sur la responsabilisation de chacun. Mais parfois ca ne marche pas.et il faut devenir "sergent"