Profession burette d’huile

Carine Sobisiak 23 décembre 2020 ~ 17 minutes

Je me présente, Carine, cheffe de projet technico-fonctionnelle. Je suis le genre de personne qu’on oublie un peu quand tout va bien et qu’on vient chercher quand tout va mal. Et aujourd’hui, j’aimerais partager avec vous quelques petits trucs sur la chefferie de projet de manière non conventionnelle.

Quand certains parlent de gestion de projet, ils pensent à des listes de qualités attendues, à des connaissances, à des savoir-faire nécessaires, à des méthodes, à du jalonnement, à de la gestion de risques, bla bla bla. Est-ce que ça vous intéresse vraiment ? Moi pas. C’est souvent un peu creux, du beau bullshit enrobé dans un beau papier d’alu.

Ce n’est pas forcément ce qui va aider quand on est confronté à la réalité du terrain. On peut apprendre des techniques et des méthodes, il y en a des dizaines différentes, mais aucune n’est 100 % efficace dans 100 % des situations, et c’est la cheffe de projet qui vous le dit.

La réalité du terrain, c’est souvent un espace en perpétuel changement, où la stabilité est parfois très temporaire. Ce n’est pas simple tous les jours, mais c’est extrêmement vivant et source de très beaux défis qui rendent la vie passionnante. Mais dites-donc, cela ne fonctionnerait pas aussi comme définition du Web ça ?

Mine de rien, mener un projet avec des équipes disparates et/ou hétérogènes, réussir à faire bosser les gens ensemble, sans pouvoir formel et/ou décisionnel (que ce soit dans un cadre professionnel ou dans une équipe bénévole, comme Paris-Web par exemple, où j’ai été fourmi-présidente-à-tout-faire), sans brider les gens et en tirant d’eux le meilleur, c’est un sacré challenge !

Chef de projet, un métier réellement connu ?

Certains ne doutent absolument pas de l’utilité d’un·e chef·fe de projet et/ou savent exactement ce à quoi cela correspond, maiiiiiiis… pas tout le monde. D’expérience, c’est souvent un métier assez mal compris.

Best-of non exhaustif de certaines incompréhensions que j’ai pu rencontrer :

Des développeurs·ses qui s’estimaient supérieur·e·s parce qu’eux touchaient au code, produisant quelque chose de tangible, et pensaient que les chef·fe·s de projet ne servaient à rien, ne savaient même pas coder, n’avaient pas de conseils à leur donner et j’en passe (psstt, un chef de projet peut avoir été développeur… mouche ton nez bébé).
Des futurs chef·fe·s de projet en devenir, qui voulaient absolument prendre ce rôle et estimaient à tort que c’était facile et que n’importe qui pouvait le faire (hummm, rira bien qui rira le dernier).
Des responsables d’équipe et/ou potentiels employeurs qui voulaient un·e chef·fe de projet seulement pour manier le fouet et mener les développeurs à la baguette (merci, mais non merci).
Des chefs de projet qui ne voyaient pas ce qu’ils apportaient réellement à l’équipe et qui avaient un syndrome de l’imposteur aussi lourd qu’un trente-trois tonnes lancé à fond sur l’autoroute (rassurez-vous, personne n’est parfait, ne jamais douter de rien serait plus grave).
Des personnes qui voyaient dans ce rôle le Graal de la capacité à diriger/contrôler les autres et à imposer des décisions… et qui se trompaient lourdement (courage, fuyez-les).

Les préjugés ont la vie dure.

Chef de projet, qu’est-ce que c’est alors ?

Je suis cheffe de projet moi-même et j’aime le travail que je fais. J’aime coordonner des équipes, mener des projets, et ça fait maintenant des années que je le fais. Et pourtant je ne compte plus les fois où je me suis demandée ce qui faisait réellement un « bon » chef de projet, quel était réellement son rôle et quel sens on pouvait y trouver.

Récemment j’ai intégré une équipe qui manquait cruellement d’un chef de projet et qui avait fait contre mauvaise fortune bon cœur pendant de longs mois. Bizarrement j’ai compris plus de choses en voyant les conséquences de l’absence d’un chef de projet, qu’en ayant travaillé pendant des années avec des équipes habituées à avoir des chefs de projet. Quelques exemples : spécifications incomplètes ou pas vraiment challengées, manque d’organisation ou de coordination, manque de communication, tests et recettes difficiles, découverte a posteriori de loups qui auraient dû être débusqués à la conception, perte de temps, découragement et impression de projets dont on ne voit jamais le bout. Tout le monde participait, faisait de son mieux et en traitait des petits bouts par-ci par-là, mais le hic c’est que quand tout le monde est responsable, eh bien personne n’est responsable.

C’était juste évident et l’arbre ne cachait plus la forêt : clairement, c’est un métier. Un chef de projet sait faire cela, est dédié à cela et s’y consacre pleinement.

Est-ce que je serais pour autant capable d’expliquer ce que fait un chef de projet en quelques mots ? Je pourrais dire qu’un chef de projet est la personne chargée de mener à bien un projet tout au long de son déroulement, en coordonnant l’équipe pendant toute sa durée. Certes, mais encore ?

J’en ai croisé beaucoup des chefs de projet au long de ma carrière, tous avaient le même intitulé de poste, et pourtant les différences entre eux sont parfois comme le jour et la nuit. Quelques exemples :

Des managers de projets, sans compétences techniques propres, mais hyper-pointus en organisation et en suivi de tâches.
Des responsables très techniques, capables d’aiguiller sur la solution à mettre en place ou de mettre les mains dans le cambouis lorsque les développeurs tombaient sur un os et n’y arrivaient plus.
Des chefs de projet qui jouaient aux éminences grises, présents le plus souvent dans l’ombre, là pour leurs équipes, mais n’étant au contact des clients finaux qu’en tout début de projet ou uniquement s’il y avait un gros problème en cours de projet.
Des personnes transverses qui touchaient un peu à tout, qui faisaient l’interface entre les différentes parties prenantes d’un projet, à chaque moment du projet.

Eh bien, tous sont de « vrais » chefs de projet, qui couvrent un besoin donné dans un contexte donné.

Le mot est lâché : dans un contexte donné. Peu importe la méthode, du moment qu’elle est en réelle adéquation avec le besoin et le contexte.

Certains diront qu’un chef de projet est un facilitateur de projets. C’est un peu ronflant, mais pourquoi pas ? C’est plutôt représentatif, mais personnellement je préfère le tourner en dérision : pour parler de manière imagée, un chef de projet c’est un peu une burette d’huile. Oui, vous pouvez rigoler.

J’ai probablement de la chance de travailler dans une société un peu tentaculaire, agrégeant des dizaines d’équipes et des centaines de métiers, d’y occuper un rôle très transversal et d’être une passerelle entre les gens. Alors, dans mon contexte, un chef de projet est là pour abattre les murs entre les gens et les aider à bosser au mieux en mettant de l’huile dans les rouages. Eh oui, de l’huile, une burette d’huile !

Aujourd’hui en tant que cheffe de projet, si je délègue énormément de choses et si ce n’est plus moi qui code avec mes petits doigts, je n’en suis pas moins la personne :

qui prépare les choses,
qui insuffle de l’énergie au départ ou quand ça s’essouffle un peu,
qui s’assure que tout le monde a tout ce qu’il faut pour travailler au mieux,
et qui fait des pieds et des mains pour que les engrenages puissent tourner sans accroc.

Cela peut sembler trivial et ridicule, mais vous pouvez me croire, il en faut de l’huile pour tout cela. Et je suis fière d’être là pour cela.

Un mot clé : comprendre

Évidemment, être chef de projet demande des compétences organisationnelles, cela va de soi. Il serait difficile de mener un projet sans être capable d’en prendre la mesure, de choisir le type de production et/ou le mode de livraison, d’organiser les différentes étapes et de poser des jalons si besoin, et j’en passe.

Cela fait partie du métier et c’est évident pour tout le monde. Mais les compétences organisationnelles seules ne sont pas suffisantes. Quelque chose que beaucoup de personnes sous-évaluent, ce sont les compétences relationnelles et sociales que ce genre de métier comporte. Nous sommes rarement des bêtes gestionnaires qui appliquent bêtement des méthodes.

Mener un projet sans comprendre sa finalité, c’est risquer d’aller dans le mur. Un chef de projet doit être capable de suffisamment d’empathie pour se mettre à la place de l’ensemble des intervenants et/ou des utilisateurs finaux, de vivre le projet suivant leur point de vue, d’autant plus lorsqu’il participe à la conception de la solution.

Pour cela, il faut être ouvert aux autres métiers, être curieux et parfois poser des questions qui n’ont pas forcément un rapport immédiat avec le projet pour mieux comprendre et être capable de voir un peu au-delà de ce qui est exprimé.

On a tous déjà croisé des images rigolotes sur la compréhension d’un projet par ses différents acteurs, des parallèles entre ce que le client voulait réellement et comment cela a été compris aux différentes étapes de la chaîne de production, avec souvent des produits totalement inutilisables en bout de chaîne.

C’est une caricature, mais il n’empêche pas moins que c’est toujours un risque. Si on respecte les délais et les coûts attendus, en suivant scrupuleusement le cahier des charges, mais qu’on en arrive à livrer une solution de mauvaise qualité ou inadaptée au besoin, on peut légitimement se dire qu’on a raté une étape quelque part.

Avant de se lancer dans un projet, il faut s’assurer que les spécifications sont compréhensibles par toutes et tous, et qu’elles sont en adéquation avec le besoin à couvrir. On n’est pas toujours en position de pouvoir refuser un projet, mais suivre bêtement des spécifications qui semblent absurdes n’est à l’avantage de personne. Le besoin n’est pas forcément absurde, mais il peut avoir été mal exprimé et/ou nécessiter des connaissances purement métier qu’un développeur lambda n’aura pas. Le chef de projet est aussi là pour faire clarifier les choses et/ou pour recueillir ces connaissances.

Parfois il faut être capable de s’asseoir un peu sur sa fierté, avouer qu’on ne connaît pas encore et, surtout, ne pas hésiter à poser des questions qui peuvent paraître bêtes. C’est un état d’esprit : il n’y a pas de questions bêtes. Tant que l’on cherche à comprendre et à faire avancer un sujet, presque toutes les questions sont permises. Comprendre les choses peut faire des miracles, ou a minima éviter de se prendre des murs plus tard de manière douloureuse.

Et comprendre la finalité d’un projet, c’est aussi demander quels en sont les enjeux. C’est peut-être bête à dire, mais on n’organisera pas de la même manière :

un projet pour du long terme ou pour une solution temporaire ;
la réalisation d’un produit minimum viable qui sera ensuite géré en amélioration continue ou la réalisation d’une solution métier qui aura un impact critique sur des données et ne saurait souffrir aucune erreur de conception.

J’ai déjà eu ces différentes combinaisons à gérer. C’est une certaine gymnastique mentale de passer de l’une à l’autre mais presque tout est possible tant que l’on a conscience du contexte. Parfois il faut demander pourquoi on nous demande de procéder ainsi, surtout quand ça paraît atypique : mieux comprendre son projet permet de mieux le porter.

Certains disent « Explique-moi ton besoin, je te dirai comment t’en passer ». Sur certaines demandes en amélioration continue, il m’est arrivé de demander des explications et de me faire charrier avec cette citation. On en rit encore avec certains de mes collègues, mais il m’est effectivement arrivé de répondre « Non. Ne mets pas la charrue avant les bœufs en présumant la solution. Explique-moi ton besoin et on verra ensemble quelle solution on peut trouver. »

Cela peut être une manière d’établir un climat de confiance, ou un exercice de franchise pour d’autres. Personnellement je préfère dire franchement que cela ne sera peut-être pas possible exactement de la manière dont c’est demandé, mais qu’il faut en discuter, voir et peut-être trouver une autre solution qui répondra au besoin. C’est faire savoir :

qu’on a à cœur de trouver une solution,
qu’on ne dit pas non sans raison,
et qu’on n’est pas là pour mettre des bâtons dans les roues.

Savoir dire « non » ou « minute papillon », c’est tout un art.

Mon métier, c’est de comprendre le métier des autres, de leur faire comprendre le mien, et de les aider à mieux faire leur métier en leur fournissant les outils et les solutions qui répondent bien à leurs besoins… le tout sans perdre le sens des réalités.

Un chef ou un leader ?

Être chef de projet, c’est aussi manager ses équipes. Là-dessus, on peut quasiment tout lire. Certaines personnes sont plus difficiles à encadrer que d’autres, mais quand on essaie de comprendre les gens et quand on part du principe qu’ils font de leur mieux, ça va souvent mieux. Ce n’est pas toujours possible, mais dans un monde idéal il faut savoir faire confiance à son équipe, lâcher un peu prise et les laisser faire de leur mieux.

On peut être chef de projet ou coordinateur d’équipe sans pour autant être un « chef » à proprement parler. Prendre le rôle de chef pour le plaisir de contraindre les gens et/ou de donner des ordres et/ou de manier le fouet, certains le font, mais c’est dommage. Quand le chef de projet est là pour aider/organiser/soutenir ses équipes, pour créer de la cohésion et de l’entrain, pour lever les barrières, cela fonctionne souvent mieux.

Dans beaucoup de situations, ce n’est pas d’un chef dont on a besoin, mais d’un leader : pas quelqu’un qui donnera des ordres pour donner des ordres, mais quelqu’un qui coordonnera les gens, qui mènera la barque, qui mettra la main à la pâte si besoin, qui donnera le meilleur et qui donnera l’envie aux autres de donner le meilleur.

Quelques petites astuces en vrac

Je vais prendre un premier exemple très bête, avec l’étape où on explique aux équipes quel est le rôle du chef de projet dans leur contexte spécifique à eux, avec des mots qu’ils peuvent comprendre et qui leur parlent. Parfois c’est le responsable d’équipe qui s’en charge à l’arrivée d’un nouveau chef de projet, mais le plus souvent c’est au chef de projet de le faire, d’expliquer ce qu’il fait, pourquoi il le fait, en quoi il peut aider et en quoi on peut l’aider pour que les projets se passent au mieux.

Un exemple bateau… sur un sujet sensible : il peut m’arriver de demander une estimation à un développeur. Je vous laisse imaginer que ça peut être un excellent moyen de s’attirer ses foudres, si on ne met pas au clair que :

l’estimation n’est pas un contrat gravé dans le marbre qu’il devrait impérativement respecter sous peine d’être fouetté sur la place publique, :)
l’estimation n’est qu’une approximation pour m’aider moi à caler d’autres choses – en bref, faire mon travail, :)
si l’estimation s’avère fausse dans un sens ou dans l’autre, ce n’est pas nécessairement un problème, du moment qu’on est prévenu et qu’on peut réajuster les choses ensuite – en bref, faire mon travail, deuxième édition. :)

Je peux aller au devant de gros ennuis et braquer inutilement cette personne ! Cela a l’air totalement idiot, mais c’est vital : communiquez !!!

Considérer que les rôles et les tâches de chacun sont connues de manière implicite par tous, c’est risquer de grandes déconvenues et de belles incompréhensions. Il y a mille façons de gérer les projets et/ou les équipes ; ne tenez pas pour acquis que la vôtre sera forcément connue. Être présenté et/ou se présenter, expliquer et dire les choses, c’est important.

Une autre chose que je trouve importante, c’est de faire un « RACI » en début de projet. C’est un acronyme un peu barbare pour :

Responsible : qui est responsable et/ou décisionnaire pour le projet ;
Accountable : qui est acteur, partie prenante, en charge de la réalisation ;
Consulted : qui a été consulté pour concevoir la solution ;
Informed : qui doit être informé des différentes étapes et du résultat.

En clair, c’est une simple matrice de responsabilités. C’est l’étape où sont identifiés clairement les participants d’un projet, où sont déterminés leurs rôles, leurs responsabilités, mais aussi leur périmètre de connaissances.

Cela peut sembler trivial à certains, mais dans certains cas d’organisations tentaculaires, c’est une question de survie. La première chose qu’on fait dans un projet c’est quand même de demander à qui on s’adresse. Il est donc hyper important d’identifier en amont chez qui rechercher quelles informations, ou encore qui solliciter à quel moment. Il est difficile d’articuler un projet sans connaître cela… et pourtant tout le monde ne le fait pas.

Ensuite, il est aussi important de savoir terminer un projet. Lorsque c’est possible, je trouve important d’organiser une réunion avec l’ensemble des parties pour faire ce que certains appellent un « post-mortem » et ce que d’autres appellent une rétrospective. Le principe est de parler de ce qui a bien fonctionné, de ce qui n’a pas bien fonctionné et surtout de ce qu’on peut faire pour que les prochains projets se passent mieux.

Pour que ce genre de réunion se passe bien, la base est de commencer en expliquant qu’on n’est pas là pour blâmer qui que ce soit et qu’on part du principe que tout le monde a fait de son mieux avec les moyens qu’il avait. Car dire quand les choses vont mal c’est important, mais c’est encore plus essentiel de savoir dire quand les choses sont bien. C’est important d’entretenir le moral et la motivation des membres d’une équipe.

De la même manière, il faut être capable de dire merci. Certains ont du mal avec cela, mais parfois un simple e‑mail de fin de projet pour lister et remercier toutes les personnes qui ont participé au projet, c’est bête comme la lune, mais ça fait du bien à tout le monde.

En conclusion

Le chef de projet est souvent un élément clé car c’est quelqu’un qui fait le liant entre toutes les parties d’un projet, mais il faut aussi se rappeler qu’il ne ferait rien tout seul. La réussite d’un projet est dans l’ensemble des parties et tous les métiers sont importants. Alors que vous soyez chef de projet ou pas, soyez fier de vous et de votre métier. Comme on le disait à Paris Web en 2016, on a toutes et tous un rôle à jouer.

Merci de votre lecture. ;-)