On entend souvent dire en France que le métier de chef de projet est l’évolution « naturelle » du métier de développeur. Mais finalement, est-ce si certain ? Et surtout, quels sont les pièges et les situations à éviter à tout prix autour de ce métier très en lien avec les développeurs ? Nous allons le voir dans cet article.
Inscris-toi pour recevoir les + belles offres de job technique
Update 2020 : Cet article est importé depuis Jobprod suite à son acquisiton par WeLoveDevs. Afin de compléter votre lecture, nous vous conseillons de lire l’article de Marcy au sujet des bonnes pratiques du manager/chef de projet.
D’ailleurs, on t’invite à nous dire en commentaire quelle a été ton expérience en tant que manager/chef de projet, on est curieux de te lire ! Toi aussi, tu penses que ça n’est pas une évolution automatique ?
L’équipe WeLoveDevs.
Ce paragraphe peut vous sembler évident, et pourtant… Si vous prenez différentes entreprises, je suis sûr que pas une seule ne vous donnera la même réponse sur le rôle qu’ont les chefs de projet techniques au sein de leurs organisations.
Tout d’abord, un chef de projet technique est un manager. Autrement dit, comme tout chef, il doit pouvoir transmettre les messages entre sa hiérarchie et les équipes qu’il encadre, ce qui implique que le chef de projet est capable de comprendre les besoins et attentes de part et d’autres.
Dit comme ça, ça paraît évident, et pourtant, dans la réalité, j’ai pu voir de nombreux chefs de projets techniques qui ne comprenaient pas grand chose à ce que faisaient les gens du projet qu’ils géraient. Par ailleurs, et c’est aussi son rôle de chef, il doit assurer un rôle de firewall en protégeant son équipe des interactions vis-à-vis du monde extérieur, mais aussi en la défendant face à la hiérarchie (en évitant de dire « c’est tel membre de mon équipe qui a fait ça »). Au risque, s’il ne le fait pas, d’être perçu comme un rôle fantôme au sein de son équipe. Enfin, vous devrez faire des arbitrages, par exemple donner la priorité à tel développement sur tel autre.
Autant le dire tout de suite, ce n’est pas un métier où vous ferez de la technique, donc si c’est cette dernière qui vous passionne, je vous conseille clairement de passer votre chemin. Néanmoins vous devez avoir un bagage technique pour comprendre vos interlocuteurs.
Chef de projet est un métier différent du métier de développeur, et donc qui requiert une formation. Il faut notamment des compétences en management, un peu de psychologie aussi, et on n’apprend pas ça sur le tas. Pour vous donner une idée mon premier chef avait au départ très mal commencé, en prenant tout le monde de haut, et très vite il s’est fait détester par son équipe. Après une formation d’une semaine il a complètement changé, se mettant à faire un rôle d’arbitrage et à protéger son équipe, et en quelques semaines nous nous sommes mis à vraiment l’apprécier ! Bref si on vous propose de passer chef de projet sans la formation adéquate, passez votre chemin c’est un piège !
Comme dit plus haut, l’évolution naturelle du métier de développeur est bien l’expertise technique et pas le management, alors que chef de projet est justement un métier de management. En France le chef de projet technique est mieux payé que le développeur, mais cela ne fait pas sens étant donné qu’il ne s’agit absolument pas du même métier. D’ailleurs comme le dit cet article un chef de projet est plutôt un développeur qui a échoué, alors que le développeur qui a réussi passe architecte. Pour en rajouter une couche, il n’y a absolument pas besoin d’être une brute technique pour être chef de projet, par contre il faut un bon background technique et de bonnes capacités de communiquant. De même le chef de projet ne doit pas travailler sous les ordres d’un architecte, mais avec l’architecte, ce dernier étant membre de l’équipe qu’il encadre (ou d’une autre équipe) et définissant les solutions technique de l’application.
Un chef de projet doit savoir motiver ses équipes, notamment en assurant une bonne répartition entre les gens des tâches intéressantes et pénibles. Par ailleurs, il doit pouvoir négocier avec sa hiérarchie suffisamment de temps pour que les projets puissent sortir dans un état qualitatif correct. Cela implique notamment de pouvoir se battre pour repousser les dates de livraison si besoin, en effet mieux vaut sortir un produit un peu en retard mais bien fini plutôt qu’à l’heure mais inutilisable. En effet les clients seront bien plus contents, et d’autre part ça coûtera moins cher en maintenance. Cela dit de temps en temps il faut aussi être en mesure d’expliquer à ses équipes qu’il faut mettre un coup de boost, ce qui est parfaitement acceptable dès que ce n’est pas trop fréquent !
Tout d’abord, en tant que chef d’équipe, vous devez avoir un budget alloué pour faire votre travail, vous laissant de la marge, notamment pour recruter de nouvelles personnes si besoin. De même pour les tâches qu’on vous demande on doit vous laisser de la marge, histoire de bien faire le boulot et d’assurer les inévitables tâches de refactoring de votre application. En effet en tant que chef de projet vous êtes responsable de votre application, et serez l’interlocuteur du monde extérieur par rapport à celle-ci (et à ses dysfonctionnements…)
Par ailleurs la notion de marge est très importante car c’est ça qui vous permet d’assurer votre rôle de chef. Dans le cas contraire, vous ne serez que le fusible qui tombera au premier dysfonctionnement !
En France on trouve de tout sous la désignation « chef de projet technique ». On peut cependant identifier des profils type d’offres à éviter. Pour les débusquer, n’hésitez pas à interroger votre interlocuteur longuement, car une fois le contrat signé, ce sera trop tard.
Le chef de projet technique Excel passe son temps en réunion à noircir des fichiers Excel et à participer à des réunions, mais n’assure absolument pas son rôle. En fait, il n’a pratiquement pas de contact avec son équipe, ce qui retire l’essentiel de l’intérêt du job. Par contre en cas de souci, c’est lui qui prend. Bon, pas la peine de faire un dessin, je crois que vous avez compris. 😉
Ce type d’offre est bien plus redoutable, mais en même temps plus facile à discerner. En effet, dans l’intitulé, on demandera au chef de projet de s’occuper en plus du reste de tâches de développement et de tâches de mise en production, ce qui sort de son domaine de compétences ! Un tel chef de projet doit en fait assurer le travail de trois ou quatre personnes, avec des horaires à rallonge et tout le reste. Dans une telle situation attention au burn-out !
J’ai tenu à écrire cet article car j’ai moi-même été chef de projet dans une entreprise où l’on m’a demandé d’assurer les tâches de dév, de mise en prod, de maintenance, de correction des bugs de prod, de planning, et aussi de négociation des specs avec la MOA, le tout sur fond de réduction drastique des effectifs dans l’équipe. Lorsque j’ai demandé des ressources supplémentaires on me l’a refusé au motif que « les budgets ont été votés et il n’y a pas le budget », alors que dans le même temps on me submergeait de demandes et on me reprochait les dysfonctionnements de l’appli que j’avais remontés au moment d’entrer en fonction. Et pour rire un peu à un moment j’ai demandé une barrette de 2 Go de RAM pour mon ordi et même pour ça j’ai bataillé pour l’avoir… Lorsque j’ai quitté le poste j’ai parlé avec le DSI de la situation pour éviter à mon successeur ce qui m’était arrivé, et il m’a répondu « de toutes façons si le projet change tous les trois mois de responsable on trouvera du monde pour te remplacer ». Enfin bref tout ça pour dire que je ne souhaite à personne ce qui m’est arrivé, et qu’il s’agit à un niveau caricatural d’un poste de chef de projet à fuir. D’ailleurs en deux ans il y a eu six personnes différentes à occuper mon poste, c’est dire…
Un dernier mot aussi pour remercier Nicolas Martignolle du blog le touilleur express qui m’a donné l’idée de cet article.
Besoin de tester ton niveau en développement informatique ?
Cet article vous a plu ? Vous aimerez sûrement aussi :
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
Changer d’entreprise, c’est excitant. Nouveau challenge, nouveaux collègues, nouveau café. Mais, bien souvent, on oublie…
Ça n’étonnera personne si nous affirmons que le monde du développement logiciel est en constante…
En Allemagne, le travail en tandem à temps partiel, aussi appelé « jobsharing » est…
On se retrouve comme d'habitude pour le début du classement qcm saison automne ! Mais…
La saison printemps des tests techniques WeLoveDevs s'est terminée le 31 mai, et c'est Axel…
View Comments
Ah... les classiques des SSII qui te demandent de tout faire avec zéro moyens!
Que de "souvenirs" que cette atroce habitude du "si ton prédécesseur a réussi, tu devrais pouvoir le faire", alors que, techniquement, ledit prédécesseur s'est tiré A CAUSE de ces problèmes.
De fait... c'est que trop courant: quand tu es dev, tu croises des CP qui sont soit les rois d'Excel et qui délèguent à mort, soit des anciens devs qui savent de quoi ils parlent.. .et qui n'arrivent pas assez à décrocher de la technique, au point de devenir invasifs dans le cycle de développement.
Les grosses SSII ont pour énorme tare d'être si grosses qu'elles pensent (à tort) qu'un CP peut très bien être le premier dev venu, alors que la réalité est autrement plus délicate.
Pour ma part, j'ai fait les deux: dev, puis CP/DEV, CP "pur"... Au final, la réalité est un mélange de tout ce que tu as pu dire, en y ajoutant aussi qu'il y a un autre "loup" camouflé, celui du "CP pompier". Celui-là, on ne l'annonce jamais ou presque! C'est le profil qui doit reprendre une situation merdeuse (client pas content, devs fatigués et/ou démotivés...), qui se prend la chevrotine dès son arrivée, et qui aura toutes les peines du monde à réorganiser l'équipe, parce que l'inertie et les freins créés par la situation sont souvent très difficiles à faire sauter!
Merci Julien pour cet article.
Plutôt que "chef de projet" je préfère parler de "chef d'équipe". Dès que tu parles d'équipe plutôt que d'un projet, cela résume bien ce que tu dis : ce rôle est avant tout un rôle humain, de leader et de manager. Les chefs de projets sont parfois des Ministres des Finances, mais rarement des bons gestionnaires d'équipe. J'ai aussi travaillé sur des projets en double commande (comme dans un avion de ligne). D'une part un responsable du budget, du suivi et des relations avec l'extérieur. D'autre part, une autre personne chargée d'animer le développement, d'aider les développeurs et de s'assurer que la cohésion dans l'équipe fonctionne bien.
Tout ceci est sur le blog "le Touilleur Express" pour en savoir plus
Nicolas Martignole
C'est vrai que souvent dans chef de projet il y a tout et n'importe quoi. Pour tout te dire il y a pas mal d'ambiguïtés sur ce titre, dans certains cas chef de projet = chef d'équipe, dans d'autres ce sera uniquement la personne qui fait du reporting sur un projet, en disant "tiens faudrait faire ça" mais qui ne gère pas directement son équipe... Il y a autant de définitions du poste que d'entreprises.
Tu pourrais donner le lien des articles en question sur ton blog ? Merci. :-)
C'est tout à fait vrai... le problème est qu'on retrouve aussi ça chez pas mal d'éditeurs... :-( Et oui j'ai connu le coup du CP pompier, enfin ce n'était pas au niveau de l'équipe mais au niveau du projet (une appli web qui détruit ses données toute seule comme une grande, et que tu dois fixer quotidiennement en prod'...)
Cet article est vraiment intéressant. En le lisant j'ai reconnu bien des situations.
Merci pour cet article intéressant. par contre, l'architecte décrit la solution et la manière dont on doit l’implémenter. c'est bien lui qui s'engage directement avec le client. Le CP s’engage avec le client sur la mise en place de la solution telle qu'elle a été imaginée par l'architecte ainsi que les délais de cette mise en place. ni l'architecte travaille sous l'ordre de CP, ni le CP travaille sous l'ordre de l'architecte. chacun a ses engagements.
Dans le monde moderne (bonjour SAFe), il y a 3 types d'Architectes. Les Architectes Systèmes (Leadtech, Responsables techniques, whatever sont tous les mêmes mots) qui sont au niveau PROJET(s) et définissent le COMMENT sous la vision de ceux qui suivent, les Architectes Solutions/Entreprise au niveau DIRECTION (ce sont eux les vrais managers techniques: solution/stratégie entreprise en décrivant le POURQUOI et le QUOI et s'arrête là, et ont très généralement une casquette de management RH. On ne va pas se mentir, il faut plutôt être HPI/HPE sur ce profil... tellement on t'en demande. Parfois une seule personne assure les 2 rôles, c'est mon cas, je coach la carrière de 8 personnes en plus et mon boulot consiste à produire des documents pour les directeurs commerciaux/projets, discuter avec les techs leads et faire des réunions toute la journée :D)
Problème: cette organisation est nécessaire pour nos projets de plus en plus complexes mais aucune entreprise ne met les moyens. C'est souvent le mur qui attend.