Mettre de l’empathie dans sa gestion de projet web

Quand j’ai démarré à ce poste de chef de projet web, je n’avais rien compris à la mission liée à ce poste. Mais rien de rien. Je sortais d’un cursus lettres/communication à une époque où les chefs de projet web étaient des techniciens, non des communicants, et j’entendais bien faire d’un site web un véritable outil de communication, de captation, de transformation. Si cela parait évident aujourd’hui, remettons en contexte : il fût une époque où mettre de jolis gifs animés sur un site institutionnel ne choquait personne. Il fallait changer ça et c’est ce qui s’est produit sur les 10 dernières années. Mais dans ce contexte où la technique primait sur la communication, j’avais (et ai parfois encore) un très gros complexe vis à vis de mon manque de compétences techniques. Alors pour palier à ça, j’ai appris à faire une maquette PSD, à découper, à intégrer, j’ai appris à mettre en ligne un site sur un serveur : en bref, j’essayais de comprendre comment fonctionnait toute cette chaîne technique de bout en bout, pour ensuite mieux conseiller. Cela me paraissait logique au début et encore plus aujourd’hui.

La maîtrise technique n’est pas suffisante

Ce métier, si je l’ai embrassé avec passion à mes débuts, je l’ai très vite détesté au point de songer à changer de métier à de multiples reprises. Je l’ai même caricaturé en parlant de poste tampon, voire de putching ball. C’est simple : au moindre couac sur un projet, c’est sur le chef de projet que l’on râle (on = client ou membres de l’équipe projet ou manager ou patron. Oui… ça fait du monde…). Et selon les sensibilités des uns et des autres, on supporte plus ou moins bien cette position, et pour moi ça été très difficile à vivre. Le problème ne venait pas de la partie technique à laquelle je m’attelais depuis le début.

J’ai alors cru que le problème était lié à mon manque de connaissances dans les outils de gestion de projet. GanttProject, MSProject, DotProject… j’ai testé de multiples outils, j’ai également beaucoup lu sur le sujet. Vue le peu d’envergure des projets que j’avais en charge, tous ces outils se sont révélés beaucoup trop chronophages, et, en prime, inutilisés ou mal utilisés par les équipes. Quel intérêt de remplir des plannings et des délais si personne ne rempli rien sauf la pauvre chef de projet qui tente bon gré mal gré de faire avancer ses projets. Ma pire expérience étant un outil « maison » de suivi des temps de travail par tâche. Je ne comprenais plus où passait mon temps, c’était tellement fastidieux à remplir : 10 min au téléphone avec un client, 10 min avec un intégrateur, et combien d’heures sur la rédaction d’un document où j’ai été coupée 10 fois, sans compter le temps à remplir tout ça et la vaste sensation de n’avoir rien produit à la fin de la journée. Idée renforcée bien souvent par les dires des équipes… c’est bien connu : un chef de projet ne fait pas grand chose.

J’ai complètement abandonné ces outils déprimants. En réalité, dans ces 10 minutes d’échange avec le client, j’ai pu lui expliquer un point technique important, j’ai pu le rassurer… Dans ces 10 minutes avec l’intégrateur, j’ai pu préciser une fonctionnalité, éviter une mauvaise compréhension de la demande. En bref, j’ai fait avancer le projet dans le bon sens en communiquant. J’ai fait mon job.

Écouter, comprendre, communiquer et faire comprendre

Bien communiquer avec tous les intervenants du projet, à mon sens, c’est cela la mission essentielle du chef de projet. La première chose que j’ai apprise en cours de « théorie de la communication » c’est que la communication est aussi et surtout non verbale. Intonation, attitude, gestuelle… Les paramètres qui nous permettent de communiquer sont tellement nombreux. Et pourtant que faisons nous, tous ? Se cacher derrière des écrits, des mails, derrière nos écrans. La chose qui m’angoissait le plus quand j’ai commencé à travailler : prendre le téléphone, aller voir les gens. Cela peut paraître ridicule et pourtant, un appel ou un rendez-vous désamorce souvent des incompréhensions qui seraient restées, voire se seraient amplifiées, si l’échange s’était cantonné à des mails.

Attention, je ne dis pas qu’il ne faut pas écrire de mail, je suis la première à en écrire de très très (très) longs, mais appeler au moindre doute, au moindre besoin de précision, fait avancer les choses un peu plus vite et… mieux.

Cette attitude fonctionne avec le client mais aussi avec ses équipes. En bonne élève modèle, j’ai longtemps pensé qu’aller parler avec mes collègues autour du café était de la perte de temps. Il fallait que je produise des documents, du concret. Puis, je me suis rendue compte que c’était un moment d’échange indispensable : les designers, intégrateurs, développeurs bloquent parfois sur certaines choses, et en parler de façon très informelle peut débloquer rapidement un collègue ou éviter l’incompréhension.

Communiquer pour limiter les risques

Les risques dans un projet web ce sont notamment des délais non respectés, des fonctionnalités qui ne correspondent pas à ce qu’attendait le client, des points techniques mal anticipés etc. Tous ces risques ont en commun des incompréhensions, des non-dits, parce que trop évidents a priori… Les clients ne maîtrisent pas la chaîne technique, ne maîtrisent pas tous les pans de la communication numérique, le rôle du chef de projet est de les sensibiliser et les guider pour qu’ils effectuent leurs choix ou préparent bien les tâches qui les concernent. Que va-t-il se produire sinon ? Il sera frustré que vous ne l’ayez pas prévenu, il sera face au fait accompli, devra payer un avenant, il aura moins confiance en son prestataire.

Mais si le chef de projet ne comprend pas les attentes et les besoins de son équipe, ça ne marchera pas non plus. Et j’en reviens à mon aspect technique qui reste essentiel. Si en tant que chef de projet, on ne s’intéresse pas un tant soi peu au travail de son équipe, à leurs contraintes, on ne peut pas se faire comprendre non plus, ni se faire respecter au passage. Attention, je ne dis pas qu’il faut tout savoir, mais quand on ne sait pas, on consulte son équipe, on échange. Le mot « échanger » est incontournable ! Cela va dans les deux sens : les membres de l’équipe ne doivent pas hésiter à échanger verbalement sur le projet à expliquer leur contrainte. Quand on rédige des spécifications fonctionnelles & techniques, il y a toujours une marge d’interprétation, et ce malgré la meilleure volonté du monde à vouloir être précis.

J’ai trop souvent entendu les chefs de projets dire que les développeurs ne comprenaient rien et vice versa. À l’école finalement, on ne nous apprend absolument pas ce qui est vital au poste de chef de projet : de la communication et de l’empathie. Ce que j’entends par empathie, c’est la compréhension des besoins de son équipe et de son client pour leur donner les bons outils de travail.

Et si la qualité de notre travail commençait basiquement par la qualité de nos échanges ?

Laisser un commentaire

Votre commentaire sera publié sans modération initiale et modéré par la suite. Merci de rafraîchir la page pour afficher votre commentaire. Votre adresse de messagerie ne sera pas publiée.