Et pour être clair, je n'ai pas de recette magique pour devenir un bon
chef de projet.
Si j'étais cynique, je dirais que pour devenir un bon chef de projet, il faut :
- Apprendre la patience, pour pouvoir supporter des réunions durant lesquelles des problèmes improbables sont discutés pendant des heures alors que des problèmes réels sont ignorés ;
- Maîtriser parfaitement Excel ou MS Project afin de pouvoir générer des plannings qui ne seront jamais tenus et des tableaux de bord remplies de statistiques (truquées) à destination de sa direction ;
- Être capable de dire tout et son contraire en moins de 10 secondes ;
- Savoir prendre des décisions techniques sans fondement en toute autorité sans demander l'avis des gens qui font vraiment le boulot.
- Et enfin pouvoir au moindre problème renvoyer la faute sur les gens qui ont fait le boulot demandé sans avoir été consulté sur la façon de le faire ;
Cette philosophie
est d'ailleurs assez bien retranscrite par ce graphique :
Mais comme je suis tout sauf cynique (n'est ce pas ?) je dirais que pour devenir un bon chef de projet
, il faut paradoxalement ne pas chercher à devenir un chef.
Une équipe de développement n'est pas une tribu d'écervelés qui ont besoin d'un guide pour savoir quoi faire, comment le faire et quand le faire.
Dans la grande majorité des cas, les membres d'une telle équipe sont au contraire des professionnels qui savent ce qu'ils ont à faire avec bien souvent une idée très précise de la façon de le faire le mieux possible.
Dans ce contexte, un bon
chef de projet doit donc être capable de reconnaître cela et faire confiance à son équipe à tout les niveaux en lui permettant de faire les choses comme elle l'entend, indépendamment de ses propres idées.
Et à contrario, si, pour une raison ou pour une autre, l'équipe ne sait pas travailler correctement, un bon
chef de projet ne doit pas l'enfoncer, mais au contraire savoir la porter, la soutenir, la guider, réveiller les compétences ou permettre de les acquérir, afin de la mettre sur le bon chemin.
Dans les deux cas, un bon
chef de projet résous donc les problèmes de l'équipe, qu'ils viennent de l'extérieur ou de l'intérieur.
Un chef de projet doit donc à minima :
- Être attentif aux autres ;
- Avoir envie de résoudre les problèmes des autres ;
- Être capable de défendre les idées des autres ;
- Protéger, assister et aider les autres lorsque les choses vont mal ;
- Encourager, motiver et aider les autres lorsque les choses vont bien ;
- Pouvoir prendre ses responsabilités lorsqu'il le faut ;
- Chercher à s'améliorer et à améliorer les autres, en permanence ;
- Penser au bien de l'équipe avant de penser au sien ;
Il n'est donc pas question de compétences techniques et tout cela, ça ne s'apprend ni sur les bancs de l'école, ni dans un livre.
Pour autant, un peu de bon sens permet de trouver les bonnes pratiques techniques en adéquation avec le rôle.
En effet, vu que le chef de projet doit être attentif aux autres, il doit à la fois pouvoir communiquer avec eux pouvoir les faire communiquer entre eux.
En conséquence, la mise en place d'outils permettant de partager l'information et de travailler collectivement sur un même projet de la manière la plus efficace possible doit être sa priorité.
Il doit donc avant tout parler, discuter, échanger avec chacun des membres de son équipe le plus régulièrement possible, à la fois pour qu'il sache ce qu'ils font mais aussi pour qu'eux sachent ce qu'il fait pour les aider.
Ensuite, il doit permettre aux membres de l'équipe de travailler ensemble, et cela veut dire qu'ils doivent être en mesure de se partager du code, donc disposer d'un logiciel de gestion de version.
Ils doivent également partager la connaissance et la mettre à jour, ce qui veut dire pouvoir écrire et mettre à jour le plus simplement possible une documentation, via par exemple un wiki.
Ils doivent de plus connaître la qualité de ce qu'ils produisent, ce qui sous-entend une usine de code capable de faire de l'intégration continue mais également un outil permettant de garder la trace des problèmes.
J'ajoute que les conditions de travail doivent être adaptées, ce qui peut vouloir dire aménager les horaires ou investir dans du matériel ou des logiciels plus récent et/ou plus performants.
Et potentiellement beaucoup, beaucoup d'autres choses, en fonction de l'expérience individuelle et collective de l'équipe et du projet sur lequel elle travaille.
Au final, la meilleure méthode pour devenir un bon
chef de projet est donc en fait d'essayer de se mettre le plus possible à la place des membres de l'équipe, afin de ne pas leur faire ce qu'on ne voudrait pas qu'on nous fasse et surtout comprendre leurs besoins ou leurs problèmes afin de pouvoir y apporter la réponse la plus adaptée.
6 réactions
1 De Arnaud - 17/04/2012, 10:13
D'une manière générale, j'ajouterai qu'un chef (de projet ou pas...) doit toujours se remettre en question avant de remettre en question son équipe lorsque quelque chose ne va pas.
2 De Eric Lemoine - 18/04/2012, 23:51
Et puis il faut surtout lire (et relire) Peopleware
3 De Pierre Ammeloot - 26/04/2012, 12:12
J'aime beaucoup ton approche et ton humour. Cela reflète bien la réalité de certains chef de projet, qui ne retienne que le mot "chef" de leur titre. Il en oublie que c'est le projet et les Hommes qui le font qui le paie !
Merci pour ce rappel des bases.
Pierre
4 De Amok - 03/05/2012, 09:43
Même avis que Pierre, merci pour ce billet
5 De Romain - 19/10/2012, 02:08
Pour devenir un bon chef de projet, il faut d'abord être un excellent technicien, afin d'être respecté et crédible.
Il faut avoir de compétences, ce que tu appelles "penser au bien de l'équipe avant de penser à soi". J'ai deux autres manières de le dire: "Pour les problèmes, tappe sur le chef, pour les compliments, adresse toi à l'équipe". L'autre manière de le dire, c'est que le chef/manager n'est là que pour faire briller ses équipes, pour les pousser, les encourager, les former ... Bref tirer la quintessence de leur savoir et de leur personne, pour servir un projet commun.
Après il faut savoir ce qu'on veut et ce qu'on veut pas.
Je pense qu'il faut avoir été développeur sur des projets qui se sont mal passés, pour savoir si on veut plutôt faire de l'agilité, ou du classique (je conseille à tout le monde de s'intéresser dans un premier temps à Kanban, puis à Scrum, puis au Lean software development (si vous êtes courageux)).
Après, il faut savoir que ça prends du temps pour être rodé, et il faudra certainement 5 à 10 ans pour passer du "petit chef de projet minable" au "bon chef de projet respecté et pertinent".
Bref, ce n'est pas un boulot simple, en tout cas si on veut le faire correctement. Après il est très simple d'être un petit chef de projet minable que les équipes dénigrent. Tu tappe sur les gens, gueule, gigote les bras. Tu pourras travailler en SSII parisienne quelques années, tu feras faire de la merde aux gens, derrière tu demandera une augmentation, et au final tu ne fera qu'alimenter le management type HEC, qui une fois qu'il t'aura jeté, ne te laissera que tes yeux pour pleurer (ah ouais tiens, ça rejoint un peu ta version cynique, en fait).
Article très pertinent je pense.
6 De Arnaud - 15/01/2013, 11:38
Bonjour,
Je pense que nous parlons ici essentiellement de la maitrise d'oeuvre, soit la réalisation du projet. Pas forcément sa construction (l'idée, les gains attendus, l'estimation des ressources,...).
Dans chef de projet, 2 notions : CHEF et PROJET. Ah bon ? Si si. Donc si je rejoins Frédéric sur les qualités à minima, celles-ci relèvent plutôt du chef, du manager, mais pas du chef de projet cependant. Dans le cas d'un développement logiciel, les arguments de Frédéric sont logiques, et couramment appliqués, mais ce n'est pas non plus nécessaire : j'ai piloté des projets avec absolument aucun outil de communication à part des réunions régulières, des comptes rendus, et dire bonjour toutes les semaines aux équipes. Mes suivis d'action étaient un bête tableau sans couleur, sans macros. Idem pour les outils de gestion de version : si votre code est "simple", une excellente organisation commune répondra au besoin (et vous n'aurez pas à acheter un outil très cher, et former pendant des jours tout le monde pour l'utiliser). Enfin, d'autres points relèvent de la gestion de la boîte, pas du projet : faire progresser l'équipe, avoir du matériel récent,... Mais Frédéric a raison, un bon chef de projet est avant tout un bon chef. Il est alors intéressant de se demander ce qu'est un bon chef avant tout, et ce n'est pas dans les livres. Faites un sondage auprès de vos collègues, vous aurez 1000 avis différents.
OK et donc pour le projet ? En fait, comme souvent, il s'agit simplement de se poser quelques bonnes questions. Quel est votre rôle, qu'est-ce qu'on attend de vous, pourquoi on vous paie ? En gros, vous êtes là pour que le projet soit réalisé (que son but soit atteint), généralement en respectant les contraintes de coût et délais. On vous donne des bras et des compétences pour réaliser un certain nombre de tâches du projet (vous pourriez tout faire par exemple). Vous allez déléguer ces tâches aux bras et suivre leur réalisation. On rejoint l'aspect de chef, avec la coordination de l'équipe entière. S'ils sont bloqués, c'est vous qui avez l'objectif d'avancer, donc vous devrez leur trouver une solution, ou faire en sorte qu'ils en trouvent une par eux-même. Vous avez vos objectifs (finir le projet), à vous de fixer ceux des bras et qu'ils les atteignent.
En réalité, il n'y a pas une grande différence entre un chef de projet et un chef, SAUF qu'un chef de projet n'a pas de pouvoir hiérarchique sur les équipes en général ! C'est une notion très importante, source de difficultés (et d'avantages). Pas de pouvoir donc pas de pression directe, ni de carotte pour motiver. Egalement, le chef de projet coordonne généralement des compétences très variées (analyste fonctionnel, développeur, architecte hardware, ingénieur mécanique, projeteur, expert acoustique,...). Il ne pourra pas maîtriser l'ensemble des compétences mais devra s'appuyer sur elles. Un chef de projet compétent techniquement pourra donc très rapidement orienter le travail des bras, mais ce n'est pas nécessaire s'il est un minimum intelligent et capable d'écouter ce que ses bras lui diront (à défaut, il pourra s'entourer d'un référent technique). Dans mon expérience, un chef trop technique aura tendance à orienter les solutions, être très directif, et au final ne pas déléguer aux bras. Ca peut donner des résultats très rapidement, comme ça peut aussi démotiver et déresponsabiliser les bras (voir même complètement planter le projet). Et inversement, quelqu'un qui n'y connait rien ne pourra jamais trancher ou même définir clairement ce qu'il veut. De bonnes bases sont donc très utiles, mais pas besoin d'avoir codé en MS-DOS pour utiliser Windows 8.
Un moyen excellent de coordination est par exemple par une relation de client fournisseur : je te demande cela, dis moi de quoi tu as besoin, quand peux-tu livrer, ou en es-tu,... On voit mal un développeur java exiger d'un mécanicien un train d'atterrissage d'avion en composite parce qu'il sait que c'est très léger, il a acheté son dernier vélo à Décathlon.
Enfin, concernant la crédibilité : être excellent suffit. Un excellent technicien ne sera pas plus crédible s'il devient dépassé par la techno (et cela arrivera un jour).
Du dernier paragraphe, on déduit que le projet va souvent consister à se mettre d'accord entre les différents bras pour atteindre le but final. Le rôle du chef de projet va consister alors à prévoir au mieux ce qui sera fait, faire en sorte que le réalisé colle au mieux au prévu, et re-négocier en interne (et externe vers le client) le "comment atteindre le but final". Pour répondre au mail initial, une bonne méthode n'est pas très différente entre un gros et un petit projet : grosso modo, vous allez juste déléguer à plus de gens qui vont à leur tour déléguer à plus de gens. Chacun va gérer à son niveau et vous allez coordonner au vôtre. Sur un projet gigantesque, vous n'allez pas titiller le technicien tout en bas, mais son chef sur un point macro. Lui viendra surement le titiller sur le détail. Dans mon expérience, je vous conseille ceci :
- Lisez quelques méthodes qui vous donneront des fondamentaux. Ne passez pas trop de temps à essayer de comprendre les points de détails, apprendre des méthodes compliquées, des diagrammes de roue de deming,... De toute façon vous ne les appliquerez pas avec efficacité (si quelqu'un y arrive d'ailleurs). Sur les points de base, comprenez bien à quoi ça sert, et pourquoi. Essayer de transposer dans votre cas à quoi ça sert (avant même d'essayer de l'appliquer bêtement). Ainsi vous saurez ce qui est important, ce qui ne sert à rien,... Cela vous paraîtra évident mais vous allez économiser de l'énergie par la suite.
- Discutez avec vos équipes, vos collègues, vos chefs,... Faites vous une expérience sur la gestion des projets dans votre entreprise, les compétences des gens, comment ils travaillent. Prenez un café avec eux et voyez comment ils ont résolu tel ou tel point dans le passé. Ce n'est pas parce que vous êtes chef qu'ils n'ont pas de bonnes idées et une expérience. Dans le meilleur des cas, apprenez ce qui n'a pas marché et comprenez pourquoi. Les gens se lâchant facilement sur tout ce qui ne tourne pas rond, ça devrait être facile.
- Demandez vous toujours : d'où je viens et où je vais. En déduire le comment est facile. Au pire, plein de gens auront plein d'idées, il suffit juste de faire le tri, pour répondre au "où je vais". Dans mon expérience, être claire sur le "où je vais" est l'étape la plus compliquée et la plus bâclée, d'où plein de projets qui tournent à la catastrophe.
- Enrichissez constamment votre expérience et adaptez-vous. Vous êtes le bienvenue sur le blog que je lance www.seek-different.com, pour échanger vos expériences et essayer de résoudre des problèmes jamais très compliqués au fond.