Être chef de projet c'est has been

"Cette article Damien, c’est suite a une experience douloureuse avec un chef de projet a grosse quequette?"

C'est l'impression que ça donne non ? :-)

Je me suis senti offensé malgré le fait que je suis, je pense, quelqu'un qui me souci de l'équipe (j'ai pas dit "mon" note le bien) et qui ne se sent pas une âme de chef mais plutôt de décisionnel (bah oui, c'est le CdP qui arbitre et doit prendre certaine décisions face au client...)

Je me suis senti offensé parce que le ton de cet article tend à généraliser ta vision, ta mauvaise expérience, malgré tes dernières phrases...

Hummm ... Assez d'accord avec l'article (et les commentaires) dans son ensemble ... Toutefois, comme dit dans les commentaires, il ne faut pas faire de généralités ... Certes la filière technique est généralement mal vue en France ( et pas que là d'ailleurs), mais il y a quand même des exceptions (ou des collisions, certaines boites "mixant" la filière management et technique ...).

Quant aux jeunes ingénieurs ... disons qu'une partie de la faute revient directement aux Ecoles ( je me souviens avoir reçu un CV dont l'auteur avait une spécialisation en management IT, et donc trouvait naturel d'être manager lors de son premier job), mais les élèves eux-même ont leur part (faut quand même savoir être lucide et se rendre compte que pour gérer des gens -- techniquement ou non d'ailleurs -- il faut quand même avoir une certaine expérience, ne serait-ce que pour être crédible)...

Par contre, je ne suis pas d'accord avec la description du Scrum Master en tant que "chef de project idéal": le rôle du chef de projet est principalement de faire que son projet se termine dans les délais: il est responsable de la delivery du produit dans les temps, alors que le Scrum Master est là principalement pour enlever les blockers de la Scrum Team: la responsabilité de délivrer le produit est dans les mains des devs (ce qui a le très bon effet de les rendre réellement partie prenante du projet, et pas seulement "éxécutants", chargés de coder le design pondu par un "architecte")

Très vrai tout ça. Mais le problème est profond en France, la technique est considérée comme sale et n'est pas valorisée par le salaire. De plus le chef de projet fait souvent office de traducteur entre la technique, la direction et les clients, car il n'y a bien souvent pas de technicien dans les cadres supérieurs, chose très surprenante mais courante dans les sociétés d'informatique ... D'ailleurs il est étonnant qu'il n'y ait presque jamais de chef de projet technique faisant office d'architecte mais que des chefs de projet commerciaux.

Bref, pour enfoncer le clou, sur ce sujet qui mérite d'être creusé, je remarque que la majorité des sociétés ayant réussi ont à leur tête ou parmi les fondateurs un techos, au hasard : Google, Ebay, Yahoo, Apple, ...

Mais bon en France, on préfère des gens qui sortent des grandes écoles de commerce qui vendent l'informatique comme des patates, il faut pas s'étonner du résultat.

Voici un article très intéressant qui est tout à fait justifié. Mais outre qu'il y a un concours de **** en dirigeant plein de développeurs, il y a très vite une question de sous.

Un chef de projet a fréquemment une prime sur ses projets que n'ont pas les développeurs. Ceci implique qu'il fera tout pour sortir le projet au plus vite. Cette état d'esprit peux être contre productif. La direction a sa part de responsabilité à prendre.

La problématique du salaire aussi, car un développeur expérimenté n'arrivera pas à augmenter de salaire au bout d'un moment si il ne veux faire que de la technique. On lui demandera d'être chef de projet pour gagner plus.

Le poste d'architecte est un poste quasi-inexistant en France. C'est vraiment ce poste qui manque. Ainsi plus de querelle technique entre le chef de projet et les développeurs. C'est l'architecte qui tranche.

Un architecte doit avoir une position transverse.

D'accord avec tout ce qui a été dit. A mon avis il y a aussi un problème au niveau de certaines écoles d'ingénieur, l'incompétence se construit doucement mais surement.

Si des mecs se retrouvent chef de projet à 23 ans en sortant d'école, c'est aussi parce qu'il y a une tendance lourde en école pour délaisser la technique (qui est l'affaire des assistants/BTS/DUT/etc.) au profit du management. C'est bien plus noble.

Je me souviens le nombre de cours de management, de socio et comm' que j'ai eu, c'est vraiment effrayant, la technique n'a vraiment pas pesé lourd dans mon cursus à l'école. Et au début de mon 1er job, ma chef m'a immédiatement prévenu que je n'étais pas là pour faire de la technique, qui était le boulot des techniciens et des sous-traitants. Enfin, je suis ravi de ne pas l'avoir écoutée :)

JB : Ce que tu dis a un second effet pervers. Du coup, ces décideurs qui n'y connaissent rien en technique vont faire des choix technologiques n'allant pas à leur avantage.

Le résultat : des usines à gaz en J2EE qui ne voient jamais le jour. Oups pardon y'en a une qui a vu le jour : Voyages SNCF ;)

Plutôt d'accord avec Romain, le métier n'est pas has been mais le comportement du Chef de Projet doit évoluer.

Je pense même que les méthodes agiles devraient être beaucoup plus utilisées et pas seulement dans notre métier. Toyota et son Lean Management sont exemplaires à ce niveau sans pour autant appartenir au monde du web.

Quoi qu'il en soit et comme le dis Romain, l'effort doit être donnant/donnant et il faut prendre une décision à un moment. Si je prends du temps pour demander l'avis d'une ou plusieurs personnes et partager avec elles, ce n'est pas pour que l'un d'entre elle change d'avis en cours de route en brandissant la wildcard "méthode agile".

Il ne faut pas oublier que dans beaucoup de cas, un développeur verra le chef de projet comme un cravaté, la direction verra le chef de projet comme un développeur et que finalement lui, ce n'est rien que le spiderman qui essaie de rendre tout le monde heureux.

Sur qu'il y a matière à débattre à ce niveau... :)

Evidemment c'est à chacun de savoir rester à sa place. Mais changer d'avis tous les 3 mois est proscrit par les méthodes agiles elles mêmes. En conséquent ce genre d'attitude n'est pas à considérer comme agile.

Certaines réponses sont révélatrices de la mauvaise perception ou de la mauvaise communication des méthodes agiles :(

"Le gros problème avec les chef de projet aujourd’hui, c’est qu’ils cherchent à fliquer les personnes qui travaillent sur le projet avec eux."

J'aime pas les generalites. Une grosse part des chefs de projet sont comme cela et en particulier en France. Je pense que cela vient principalement du systeme hierarchique francais qui est particulierement archaique. On conserve le modele technicien, contre-maitre, managers et ce meme dans les domaines du developpement informatique et autre. Et ce n'est pas uniquement du "flicage" mais plus que le chef de projet defini les taches, les assigne et en fait leurs suivis... c'est la qu'arrive le flicage!

Je rejoins fredix sur le fait que la technique n'est pas valorisee en France. En Amerique du nord et en Irlande (mais pas que!) les roles de guru technique ou technical leads existent et sont ma foi bien payes! De mon experience chez IBM en Irlande le Manager gerait la communication entre equipes, l'equipe gerant la repartition des taches.

Concernant les grandes ecoles, ceux qui en sortent et qui on en une grosse (je confirme) et qui veulent gerer des equipes de gens plus vieux.... ben j'aime toujours pas les generalites. L'INSA fait miroiter a leurs "eleves" qu'ils seront des Managers. Les SSII recuperent des INSAliens, les forme comme developpeurs et leurs font miroiter qu'ils deviendrons tous managers. De la jolie supercherie a cretins organisee. J'imagine bien que certaines boites prennent un ingenieur "junior" a pas cher et lui demande de gerer leur equipe cependant...

Je rejoins donc l'article sur "les methodes agiles, c'est bien". Plus de "chef de projet" qui liste, assigne et fait le suivit des taches mais un "scrum master" ou "agile coach" qui assure que l'equipe respecte la methodo agile, assure la communication avec le client et garde une vision large sur le projet. L'equipe (de developpeurs (=ingenieurs), designers, deployers etc) est auto-geree quand a l'assignement des taches.

Et la plannification fait parti de la methode agile. Le changement de decision doit etre pris en equipe au sein d'une retrospective.

Ensuite, tout ca, c'est la theorie - pas facile a mettre en pratique au jour le jour. Et je recommande Agile Coaching, chez PragProg. :)

Cette article Damien, c'est suite a une experience douloureuse avec un chef de projet a grosse quequette?

M'est avis que le titre n'est pas bon, que ce n'est pas une fonction "has-been", juste peut-être mal interprétée ou pas exécutée comme elle "devrait" l'être. Après il y a aussi tout un tas de chef de projets, dont les chef de projets "techniques" (c'est un peu ma casquette dans ma boite) qui eux vont quand même trancher ces choix techniques, c'est bien beau de laisser les développeurs décider, à un moment faut quand même modérer.

Pour le reste, je suis d'accord, il n'y a rien de plus chiants et de plus contre-productif qu'un chef de projet dictateur :)

@davidm : Effectivement, «Chef de projet» est une mauvaise traduction de «project manager». Il est parfois difficile de faire comprendre aux gens qu'ils doivent se placer en tant que "manager" plutôt qu'en "leader".

Le poste de "Scrum Master" est malheureusement difficile à faire comprendre dans la plupart des entreprises. Même en étant directeur technique et co-fondateur de sa boîte (c'est mon cas), ce n'est pas toujours évident de former les membres de son équipe ; et c'est encore plus dur avec les non-techniques. Au final, j'ai créé un poste de "chef de projet fonctionnel", qui revient exactement au même, mais qui est plus "parlant" (ou en tout cas moins exotique) pour tout le monde. Et les développeurs sont responsabilisés : ils gèrent leurs listes de tâches, écrivent les spécifications techniques de ce qu'ils vont développer, assurent le suivi des projets sur lesquels ils travaillent. Je suis là pour orienter les développements et guider les choix techniques, et les sujets complexes sont discutés par l'équipe technique entière. Et nous faisons une réunion technique tous les matins, qui peut servir au suivi des tâches (et éviter ainsi d'être sans arrêt sur leur dos pour savoir où ils en sont) aussi bien qu'aux discussions techniques au sens large.

Dernière chose : les mauvais développeurs ne font jamais de bons chefs de projet techniques. Des chefs de projet fonctionnels, pourquoi pas ; des technico-commerciaux, OK. Mais il est très difficile d'encadrer des développeurs compétents si on n'est pas capable de "challenger" leurs choix techniques, si on ne peut pas les aider en cas de besoin, si on ne peut pas faire une revue de leur code, si on ne peut pas engager notre propre responsabilité sur la qualité du travail fournit. Alors les gars qui sortent d'école en pensant qu'il vont immédiatement encadrer une équipe de 15 personnes, ils tombent souvent de haut.

Ici (SSII généraliste) le CdP a un rôle exorbitant, il gère le client, assure le reporting à sa hiérarchie et gère son équipe. Il n'est pas difficile de comprendre sur lequel des 3 la plus faible priorité est mise quand le CdP n'arrive plus à assurer sur tous les tableaux. En théorie avec Scrum rien de tout cela puisque ces rôles sont caduques : Le lien avec le client est implicite car le client fait partie de l'équipe, c'est Product Owner. Le lien avec l'équipe est implicite également, le Scrum Master n'est pas un chef, c'est un guide, un facilitateur qui agit de manière transverse. Reste le reporting à la hiérarchie. Si le projet joue fondamentalement le jeu du périmètre mouvant / volume constant, que l'équipe se connait bien et que la confiance s'est installée, ça ne devrait pas poser de problème. Mais dans la vraie vie, le poids des habitudes, cela fait beaucoup d'hypothèses...

je dirais aussi que le développeur à tendance à se mettre des œillères (moi le premier). Parlez donc de la qualif ou du support à un développeur et observez sa réaction.

@Damien petite précision : il ne faut surtout pas présenter le Scrum Master comme un substitut du CdP, c'est le meilleur moyen d'échouer. Scrum c'est toute une organisation qui est différente, un total changement de culture.

@shingara dans ma boite le rôle d'architecte apparait clairement dans les classifications de poste

@JB si les écoles délaissent la technique, c'est que ce genre de job part beaucoup en Inde. Je l'observe chaque jour, nous n'embauchons localement plus que des profils techniques extrêmement ciblés et rarement des jeunes diplômés. Je pense que c'est parti pour durer.

L'analyse qui ferait des CDP des flics et/ou des commerciaux me semble un peu simplificatrice... je pense que tout les "bons" chef de projet sont déjà largement dans l'approche décrite en début d'article à ce détail près que le chef de projet a quand même une place un peu particulière : c'est lui qui a la vision d'ensemble du projet, c'est lui qui est responsable si le projet foire, c'est lui qui est le "point de contact" entre toutes les parties prenantes. Moins qu'un chef, pour moi le CDP est un "noeud" du réseau projet. A ce titre il a une place particulière qu'on le veuille ou non.

Chef de Projet est une très mauvaise (et très française) traduction de Project Manager, qui n'est pas propre à la fonction de CDP mais à la culture pyramidale à la française (chef par ci chef par là... totalement old school). Project Manager est plus révélateur de la véritable fonction du CDP : être manager d'un projet. Et être manager ça n'est pas seulement gérer c'est aussi prévoir, anticiper, animer, communiquer et savoir écouter... ce à quoi s'ajoute une notion de leadership à mon avis indispensable à la réussite des projets (particulièrement essentiel pour les plus difficiles d'entre eux).

Oui les méthodes agiles et le rôle de Scrum Master est très différents (et sans aucun doute plus moderne) mais cela suppose aussi d'avoir une organisation du travail et des projets en adéquation avec ce type de méthode. A nous de savoir les vendre en interne et auprès des clients :) En attendant que les méthodes agiles soient la règle, et que les entreprises adoptent des organisations plus modernes et flexibles, on peut faire de la gestion de projet "bien" sans agile.

Attention : le chef de projet est censé avoir une vision du projet que les développeurs n'ont pas (forcément). Le développeur n'a pas forcément connaissance des contraintes planning/délais/coûts. Il se focalise sur le job : développer (et bien si possible).

Le développeur n'est donc pas à même de pouvoir TOUT arbitrer : c'est le job du chef de projet ou de l'architecte. Quel choix de lib etc.

Scrum est super dans la mesure où effectivement, tout le monde est au même niveau : la secrétaire comme le CP peuvent exprimer leur avis, et on écoute. Mais là encore, faut que ça soit bien appliqué. J'ai vu des cas où Scrum foirait parce que les gens cachaient des informations.

Et là, le problème, c'est pas le chef de projet : c'est l'homme.

Il n'y a pas de méthodes agiles, il y a des bons et des mauvais.

Et sinon, du haut de mon bac +0 d'autodidacte, je trouve hallucinant qu'en France on persiste à penser la différenciation au niveau des diplômes et du cursus. :) Et qu'on persiste à voir une logique "chef de projet > développeur", d'ailleurs.

Toutes les équipes ne sont pas composées de personnes d'un bon niveau technique, qui s'investissent dans le projet et sont capables de s'autogérer. Quand votre équipe est à majorité composée de personnes qui trainent les pieds ou qui sont dépassées par la technique (beaucoup de débutants), toutes les méthodes agiles du monde vous mèneront droit dans le mur. J'ai été architecte sur un projet avec une telle équipe et j'avais parfois l'impression de faire du baby sitting technique, et avec le chef de projet, nous avons tenu le projet pour ne pas qu'il coule. Je peux vous dire que quand vous passez votre temps à colmater des brèches, vous finissez par devenir un peu autoritaire, mais parfois c'est le seul moyen de faire passer des messages.

Par contre, avec une équipe de développeurs (remarquez que je l'emploi pour la première fois) autonomes et qui s'impliquent, je prends beaucoup plus de plaisir à travailler en tant que technical leader ou architecte quelque soit l'organisation du projet (méthode agile ou non).

Je ne jette pas nécessairement la pierre aux autres, le problème est beaucoup plus vaste: on considère de moins en moins que l'informatique est un apport générateur de plus value, mais de plus en plus que ce n'est qu'une dépense à réduire à sa plus simple expression.

Il faut arrêter de croire que les jeunes CDP sont comme ceux qui sortent d'une école de commerce. On ne joue pas à celui qui a la plus grosse justement... Et si cet article m'offense ce n'est pas parce que je ne suis pas d'accord avec cet article, bien au contraire, mais parce qu'il attaque les jeunes diplômés, que je suis, en soutenant qu'ils se croient leaders après avoir suivi une formation de management. Ce n'est le cas que pour une minorité. Les formations de management de projet sont aujourd'hui axés sur la délégation et la communication au sein de l'équipe et de l'entreprise, non pas sur le directif. Les experts techniques sont, par contre, imbus d'eux mêmes vis à vis des jeunes CDP sous prétexte qu'ils ont plus d'expérience. Ils ont des choses à nous apporter et nous sommes prêts à les accepter, mais malheureusement ils n'apportent que des critiques non constructives. Les attaques de cet article ne sont fondées, je suppose, que sur une mauvais expérience personnelle et non sur un avis général, c'est bien dommage.