On m’a raconté une blague il y a longtemps :
C’est un employé, sur un chantier, qui appelle son patron.
− Patron, quand j’utilise ma brouette, elle grince. Elle fait couic… couic… couic… couic…
− Eh bien, j’aimerais qu’elle fasse couicouicouicouic !
J’avoue qu’elle m’avait bien fait marrer quand on me l’avait racontée. Et je me suis demandé si derrière la blague il n’y avait pas une vérité à en retirer.
Plus tard, je me suis retrouvé plusieurs fois dans une situation où quelqu’un se plaignait des outils mis à sa disposition. Une fois c’est un développeur qui veut utiliser Eclipse à la place de vi, une autre fois c’est un chef de projet qui n’est pas satisfait par la buglist, ou encore l’administrateur système qui veut expérimenter un nouveau système de fichiers…
Dans tous les cas, ma réponse a toujours tenu en 3 points :
- J’écoute attentivement ce que tu me dis, je vais réfléchir à ce que cela implique et je te demande de prendre le temps de le faire aussi.
- Remet-toi au travail, prend sur toi s’il le faut, mais le fait que la situation ne soit pas idéale ne doit pas être un prétexte pour perdre du temps.
- Quand tu auras terminé ta tâche/ton projet, mettons-nous autour d’une table pour réfléchir au meilleur moyen pour améliorer les choses, puis mettons-le en œuvre.
Il ne sert à rien de changer d’outil en cours de travail. Cela représente une importante perte de temps, et c’est souvent bâclé car mal planifié. Il vaut mieux prendre le temps d’y réfléchir calmement, de définir de manière collégiale ce qui est le mieux pour l’ensemble de l’équipe, pour enfin le mettre en place correctement.
Les réactions sont habituellement positives. Tout le monde préfère que les choses soient faites correctement, et tout le monde préfère savoir être écouté et compris.
J’ai quand même eu parfois des situations un peu plus tendues, où la personne n’avait pas la patience d’attendre et voulait que sa suggestion soit mise en œuvre immédiatement. Il faut dans ce cas user de diplomatie, faire comprendre que passer du temps maintenant pour tenter d’améliorer un peu le confort immédiat est sûrement moins productif que d’améliorer les choses plus en profondeur, quitte à attendre un peu ; et que dans tous les cas on est jugés sur notre productivité, pas sur notre confort.
Tout cela fonctionne évidemment dans un contexte où quelque chose peut être amélioré. Si les outils en place empêchent de faire le travail, c’est complètement différent.
Pour résumer : Être dans l’action, pas dans la réaction.
Réflexion intéressante et très importante quand on gère une équipe.
Personnellement j’écoute toujours ce que l’équipe a à me dire, ensuite je prend le temps de réfléchir par principe. Cela permet de se poser et de désamorcer les situations tendus.
Comme l’équipe sait que je prend toujours le temps de la réflexion (minimum une nuit, sauf urgence qui bloque la prod) alors ils me laissent le temps de réfléchir.
Ensuite on écrit ensemble un brouillon pour éxpliciter l’objectif à atteindre ou l’élément à faire évoluer. Ensemble çe net pas forcément avec tout ceux qui sont concerné. C’est dans un premier temps avec ceux qui éprouvent le besoin de mettre au clair une situation qui leur paraît anormal, puis tranquillement je fait entrer dans la boucle tout ceux concerné par la situation. Pour qu’au final chacun ai pût s’exprimer.
Mon second principe est de prendre soin de mon équipe, que ce soit chaque individu qui la compose comme le collectif. C’est important que chacun se sente à égalité avec les autre membres de l’équipe et se sache entendu et respecté dans ses demandes.
Il m’arrive de devoir trancher quand l’équipe n’arrive pas à se mettre d’accord. J’écoute les arguments de chacun puis je prend en décision en expliquant qu’elle n’est pas forcément parfaite mais qu’elle a au moins le mérite de donner une ligne de conduite claire sur le sujet abordé et qu’il sera temps de la faire évoluer après qu’elle ai fait ses preuves.
Jusqu’à maintenant cela se passe plutôt bien. 😀
Merci pour la réflexion que tu as lancé sur nos pratiques du management.
À bientôt,
Pierre
Je suis entièrement d’accord !
Par contre sur le point disant qu’on attend la fin d’un projet pour mettre en place quelque chose de mieux je ne suis pas entièrement d’accord. En fait si on travaille sur un très long projet il peut être très frustrant de devoir attendre plusieurs mois pour améliorer les choses.
Je pense de mon côté (et ça rejoint peut être ce à quoi tu penses aussi) qu’il faut faire un calcul entre l’inconfort de l’outil (et la productivité perdue par ce biais) et le temps qu’il reste à travailler sur ce projet.
De cette manière on pourra soit se dire qu’on attend la fin du projet pour changer car c’est plus rentable, soit on change tout de suite car le projet est trop long et on perdra bien plus à en attendre la fin.
@Fabien : Effectivement. C’est pour cela que je parle parfois de projets, et parfois de tâches. Dans mon entreprise, nous sommes sur des cycles itératifs mensuels (2 sprints de développement, 1 sprint de stabilisation, 1 sprint de mise en prod) ; donc le ralentissement de productivité a au maximum une durée de 2 semaines… pas la mer à boire !
@Amaury : En effet, je n’avais pas fait la différenciation entre les 2 mots, je te rejoins donc totalement sur ce point 🙂
100% d’accord moi aussi, l’avantage de Scrum, Les sprints sont cour.
J’ai vécu une autre situation, un employé qui n’a pas voulu utiliser les outils mis à sa disposition et qu’il a décidé sans en parler d’en prendre d’autre pour sa parti à lui et on ajoute aussi le fait des plainte que j’ai dû faire à cause qu’il ne commitait pas sa partie. C’est une des pire façon de faire, ça a bypassé toutes les décisions et malgré qu’il était un bon programmeur, il a du quitter l’entreprise (il y avait aussi d’autre raison, mais ça a pesé dans la balance).
Une décision en entreprise, ça se prend en groupe et doit-être réfléchis. L’employé avait décidé d’utiliser hibernate pour se connecté à la base de données. C’est une excellente librairie, je n’ai rien à dire contre, mais l’entreprise avait sa propre librairie interne. Ceci a causé un très gros conflit, puisque seul 3 employés connaissaient hibernate, donc peu de monde on pus maintenir le projet. On a du recommencé entièrement la communication en suivant les norme de l’entreprise.
Changer de logiciel ou de librairie, ça a un impact pour une entreprise. Des coûts, du temps et aussi de la formation. Si une entreprise laisserait le champs libre à 100% d’utiliser n’importe quoi, je n’imagine pas le requis d’embauche.
@Maxime : On est d’accord. Nous seulement les décisions doivent être prises « en commun » autant que possible, mais il faut que les membres de l’équipe sachent accepter les décisions − même quand elles ne vont pas dans la direction qu’ils souhaitaient.