L'effet tunnel
Par Amaury le mardi 17 février 2009, 20:45 - Organisation d'équipe - Lien permanent
Toutes les personnes qui ont géré une équipe connaissent l'effet tunnel. C'est lorsqu'il vous est impossible de connaître l'état d'avancement d'une tâche ou d'un projet et que vous n'avez pas d'autre solution que d'attendre que le travail soit terminé pour pouvoir l'évaluer.
Avant d'étudier les origines de ce mal et comment le prévenir, voyons pourquoi l'effet tunnel est très mauvais :
- Vous n'avez aucune visibilité sur le planning. Comme il est impossible de savoir si la tâche sera terminée demain ou dans 2 semaines, il est tout aussi impossible de prévoir les retards sur l'ensemble du projet. Comment répartir les tâches et affecter les ressources lorsque vous ne maîtrisez pas la réalisation du travail ?
- Vous ne pouvez pas redresser le tir si le projet part dans une mauvaise direction. Vous pourrez évaluer les dégâts qu'une fois que tout sera terminé. Et bien souvent, vous aurez alors le choix entre vous satisfaire d'une réalisation bancale (travail incomplet, qui ne répond pas aux spécifications, insensé à maintenir) ou tout recommencer à zéro.
L'effet tunnel a toujours pour origine les choix des individus à qui vous confiez les tâches, et la manière dont ils les abordent. Dans tous les cas, vous pouvez l'éviter avec de la diplomatie et de la méthode.
Le glandeur naturel
La plupart du temps, l'effet tunnel est le fait d'une personne à qui vous avez laissé la possibilité de glandouiller tranquillement. Laissez 5 jours à un développeur pour créer un nouveau module, et vous pouvez être certain qu'il va passer 3 jours à faire autre chose, puis 1 journée à se demander ce qu'il va faire et à se motiver pour le faire, puis passer 3 jours à coder comme un fou. Résultat, il sera en retard et aura oublié qu'il devait faire une documentation succincte.
Lorsque vous demandez à un glandeur naturel ce qu'il est en train de faire, il ne va pas vous répondre "Je surfe sur des sites de foot parce que le nouveau championnat commence bientôt", même si c'est ce qu'il a fait pendant les 3 dernières heures. Il va plutôt prendre un air très affairé, peut-être même semblera-t-il agacé que vous lui fassiez perdre son temps, pour vous faire comprendre qu'il est vraiment plongé dans le boulot jusqu'au cou. Vous repartirez avec pour seule information "Je suis en plein dedans, c'est bientôt fini, je te préviendrai quand ce sera bon", et une indéfinissable impression de vous être fait bananer.
J'appelle ce genre de personnes les "glandeurs naturels", car c'est un comportement visible chez tout le monde, à différents niveaux.
La première chose à faire, c'est d'expliquer à ces personnes en quoi ce comportement est néfaste. Illustrez votre propos en citant les précédents projets qui ont pris du retard à cause de cela. Usez de doigté : si vous semblez être en train de faire des reproches, votre interlocuteur va se braquer. Une fois que le constat sera clair pour tous, il faut s'organiser de manière à ce que cela ne puisse se reproduire.
Pour cela, la logique générale est de tronçonner les tâches pour quelles soient les plus "atomiques" possible. Prévoyez des activités qui ne prennent pas plus de deux jours à effectuer. Un jour maximum par activité, c'est encore mieux. Astreignez-vous ensuite à passer en revue quotidiennement les tâches, pour vous assurer qu'il n'y a pas de dérive.
Le faiseur de miracles
Un autre type de personnes participe à l'effet tunnel, ceux qui veulent ménager un effet de surprise et maximiser la reconnaissance qu'ils peuvent récolter pour leur travail. C'est visible chez les développeurs qui pratiquent le codage comme un moyen d'expression artistique, mais encore plus chez les "vrais créatifs" comme les infographistes ou les webdesigners.
Peut-être avez-vous déjà vécu ce genre de situation : La maquette d'un nouveau site web doit être réalisée, mais à chaque fois que vous voulez jeter un oeil sur le travail en cours toutes les fenêtres sont refermées, et vous avez droit à une remarque enjouée "Ah non, on ne regarde pas tant que je n'ai pas terminé !". Plusieurs jours passent, et quand vous avez enfin les maquettes sous les yeux, vous voyez immédiatement trois cents choses à refaire. Votre graphiste est très fier de son boulot, et attend de vous que vous poussiez des cris d'admiration. Mais ce qui vous énerve, c'est que si on vous avait permis de recadrer au fur et à mesure de l'avancée de la maquette, il n'y aurait pas besoin de jeter les 2 derniers jours de boulot, ni d'y reconsacrer 2 journées supplémentaires...
Le principal souci, c'est que la personne y a mis toutes ses tripes, et prendra toute critique comme une attaque personnelle. Il est alors compliqué de leur faire admettre que certains de leurs choix sont mauvais ou ne respectent pas les directives qu'ils avaient reçues. Il faut être très factuel dans son discours : lister les points qui posent problème et expliquer pourquoi. Une fois que cela devient un fait établi, vous pouvez revenir plus tard pour dire qu'une démarche plus ouverte aurait permis de ne pas se retrouver dans une telle situation. Il est important de laisser se passer du temps (au moins une nuit) entre ces deux phases.
Il est important de faire comprendre à vos collaborateurs que vous pouvez juger leur travail sans que ça ne les remette eux en question.
Commentaires
aÏe aïe
Je pense être un glandeur naturel doublé d'un "développeurs qui pratiquent le codage comme un moyen d'expression artistique".
Leçon comprise : atomiser les tâches
Eh oui
Lecture suivante : Découper les tâches comme un gnome
D'où la nécessité d'une bonne planification de projet avec des jalons adaptés ainsi qu'un plan de communication de projet adapté et bien défini
^^
Oui, bien sûr ! Mais le problème apparaît quand on pense avoir bien planifié un projet, alors que l'une des tâches est en fait un sous-projet à part entière. Si on ne fait pas l'effort de découper, on prend le risque de ne pas voir venir les soucis.
Et pour découper, il faut déjà se poser les bonnes questions, donc faire un minimum de spécification, d'analyse, de projections. Ça paraît évident, mais c'est souvent le problème numéro 1 dans la gestion de projets.