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.
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.
Perso, je suis un bon glandeur naturel, mais le pire est que je peux passer 2 jours à développer une appli qui parse du CSV et « fait des trucs avec » plutot que de passer 20 minutes à faire des copier-coller sur excel parce que « ce n’est pas intéressant ».
Et là, que faire pour me soigner ? :]
@niahoo : C’est déjà bien de t’en rendre compte !
Ce qu’il faut faire, c’est de découper les tâches, et de se fixer des objectifs en fonction de l’estimation que tu peux en faire. Découpe le plus finement possible, avec des durées assez courtes (quart de journée). Quand tu auras passé une demi-journée à glandouiller, tu verras ta todo-list qui ne se vide pas, ça va te pousser à avancer.
Je trouve ce petit article fort pertinent, m’étant moi-même créé récemment une TODO liste et me cognant aux murs du tunnel plus souvent qu’à mon tour.
C’est toujours de la faute du développeur c’est bien connu, ça!
Mon ancien chef a dû apprendre cet article par coeur.. ça a pas mené bien loin.
‘by the way’, l’effet tunnel peut aussi être le fait d’un chef de projet qui passe sa semaine à faire autre chose que de suivre le projet.. et vient taper sur le développeur au bout d’une semaine.
Tout cela, parait donc en fait être une affaire de point de vue.
@Yoyoz : Ne mélangeons pas tout. Le défaut de suivi est tout aussi néfaste pour un projet, nous sommes d’accord. Un chef de projet qui ne s’occupe pas bien de son projet place son propre supérieur dans un tunnel. Mais un développeur qui a besoin d’un chef de projet pour se rendre compte qu’il prend du retard sur ses tâches, et qui n’en averti personne…
Ce qu’on appelle « l’effet tunnel », c’est véritablement le résultat d’un manque d’information sur la durée de réalisation d’une tâche (ou d’un ensemble de tâches).
À chacun de se responsabiliser suffisamment pour être capable d’estimer la durée de ses tâches, puis de s’y tenir − ou au moins de remonter les éventuels problèmes assez tôt pour pouvoir y remédier sans être systématiquement en retard.
Très interessant Amaury.
Une solution pour éviter l’effet tunel ne serait-elle pas de faire des points très régulier avec les membres de l’équipe et avec le client, même si les taches individuelles ne sont pas terminées.
De mon coté c’est ce que je fais systématiquement : au moins une heure une fois par semaine.
Sinon dans le cas des glandeurs naturels et des faiseurs de miracles comme tu dis, j’ai pour ma part une solution assez radicale. Il n’ont pas la place dans l’équipe. Le management d’un équipe projet ce n’est pas comme le management d’un service. (voir mon article sur le sujet 7 differences entre un chef de projet et un chef de service)
Amicalement
CaptainProjet
@CaptainProject : Je ne suis pas tout à fait d’accord. Ou plutôt, je suis plus nuancé.
Pour commencer, si tu appliques la méthode Scrum, tu fais un « scrum meeting » tous les matins. Ça aide déjà infiniment à détecter les dérives au plus tôt
Ensuite, n’importe qui peut être un glandeur ou un faiseur de miracle par moments. Même une personne qui est naturellement organisée aura parfois des coups de mou ou se sentira dépassée par les évènements. Ce n’est pas pour autant qu’il faut les éjecter dès le moindre faux-pas.
C’est alors au manager de trouver les ressorts qui permettront à ces personnes de progresser vers un comportement plus professionnel. Je donne des pistes concrètes dans l’article.