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.
@Amaury tu oubli un autre scénario possible, que je vis actuellement, découlant de la conjonction de deux phénomènes :
– Un existant implémentant tous les anti-patterns, non-documenté, bref qui devrait disparaître au profit d’une refonte total. (base technique « nœud gordien »)
– Un impératif de livrable avant livraison de la refonte à cause de la dépendance d’une application cliente tierce. (temps limité)
Ce qui se passe est tout simplement l’impossibilité d’évaluer la charge du fait de la complexité initiale et de l’impératif temps, puisqu’elle ne tient pas dans cet impératif. Ce qui amène le développeur, moi, à être en surcharge, stressé, et donc délaisser les rapports quels qu’ils soient pour entrer dans un mouvement brownien de codage/debuggage aussi frénétique qu’improductif.
Tous le monde est perdant.
Heureusement j’ai déjà levé les alarmes, mais mon pseudo chef de projet ainsi que le DSI ne semblent pas avoir compris, donc je vais plus ou moins leur expliquer ceci.
@Kane : Du point de vue du chef de projet, ce dont tu parles n’est pas vraiment de l’effet tunnel à proprement parler. Si le développeur a fait toutes les remontées d’information nécessaires, il est normalement possible de prendre des décisions. L’effet tunnel, c’est quand on est dans l’impossibilité de prendre des décisions, justement à cause du manque d’information.
Plus concrètement, la première chose que tu dois faire doit être de lister les besoins sur le projet, des les analyser finement, et enfin de faire une estimation de leur durée. Cela permettra d’éviter les frustrations. Si malgré ton évaluation et tes alarmes, on continue à te demander de faire 2 mois de boulot en 10 jours, tu pourras répondre «OK, mais je vous aurai prévenus !».
@Amaury : C’est exactement ce que j’ai fait !
Mais, si si ! Il y a l’effet tunnel, du moins une sensation.
Car pour une tâche, fonctionnellement simple, découpée en sous-tâches de forte cohésion avec la base technique, le temps d’évolution pour chacune varie au-delà du double ou triple.
Et in fine, le développeur ne peut pas donner un pourcentage d’avancement ou des retours satisfaisants et/ou semblant complets, car lui-même ne sait pas où il se trouve.
Dans mon cas je fais des journées composées de presque 80% de rétro-ingénierie.
Ce cas est le symptôme d’un projet déficient, car il n’y a eu aucune considération pour une éventuelle étude approfondie de l’existant.
J’appelle cela aussi « The Winter is Coming » : on laisse/sous-estime un point important au début du projet, on l’ignore totalement, et à un moment critique on en paie le prix fort avec une période d’obscurité et de stress intense.
@Kane : Oui, je vois ce que tu veux dire. Sur ce genre de cas, il vaut mieux se donner le temps d’une vraie analyse technique avant de faire le moindre planning. «Planning is guessing», mais c’est encore plus vrai lorsqu’il y a une dette technique ou qu’il faut faire du reverse-engineering sur l’existant.
Ah la la…
Les chefs de projets en SSII font du « harassment » et non pas du « management » aujourd’hui..
C’est facile de venir chaque 2 heures demander à un développeur où il en est….tout le monde peut faire ça les doigts dans le nez..
Dommage que le travail informatique est devenu si ingrat en France..à cause de personnes incompétentes qui sont malheuresement monté trop haut dans la hiérarchie.
@Def890 : Voilà une vision bien pessimiste des choses.
Le premier conseil qui me vient à l’esprit, c’est de chercher un poste chez un client final ; c’est peut-être le milieu − très particulier − des SSII qui ne vous convient pas.
Ensuite, je chercherais à comprendre pourquoi mon chef de projet se comporte de la sorte. Peut-être qu’il n’a pas absolument tous les torts, et qu’il est effectivement placé dans un tunnel par ses développeurs, qui ne lui remontent pas les bonnes informations (en qualité et/ou en quantité) sur l’avancement de leurs tâches.
Merci pour cette remarque. La solution a ceci passe par une bonne division de la tache en plusieurs petites taches indivisibles dont chacune est atributé à une personnelle ou un groupe de personnes pour une exécution a durée déterminée.
QUE DITE VOUS D’UN SUPÉRIEUR QUI DIT: MOI CE QUI MARCHE NE M’INTÉRESSE PAS , C’EST CE QUI NE MARCHE PAS QUI M’INTÉRESSE
Le premier réflexe est évidemment de se dire que c’est un « supérieur » qui n’a rien compris à rien.
Mais en fait, tout dépend du contexte.
Tournons les choses dans l’autre sens : “Dans quels cas un manager peut légitimement s’intéresser à ce qui ne marche pas plutôt qu’à ce qui marche ?”
Le principal cas, c’est lorsqu’il a réussi à mettre en place une organisation où chaque membre de l’équipe est fortement responsabilisé (avec les moyens et les outils nécessaires pour remplir les responsabilités demandées). Si tout est en place, structurellement, pour que chacun puisse faire son travail correctement en temps normal, le rôle du manager devient alors de « supporter » (dans le bon sens du terme) son équipe. Il lui apporte son aide en cas de questions ou de problèmes ; c’est donc logique qu’au quotidien il s’intéresse en priorité à ce qui ne marche pas comme ça devrait.
Ce cas, c’est celui que tout manager devrait viser, quelque part.
Mais on est d’accord que ça ne doit pas empêcher de voir et récompenser le bon travail.
Il est fondamental que les tâches soient bien atomisées et distribuées aux personnes qu’il faut en temps réel.
Vraiment cet article est génial et très instructif. Pour ne pas avoir l’effet tunnel il d’abord mettre un PDCA et des objectifs SMART.Dans ce cas prévoir des jalons intermédiaires..sans oublier d’analyser la matrice SWOT en mettant laccesur Le QCD..
CAR LE TEMPS EST IMPORTANT POUR ATTEINDRE LES OBJECTIFS.COMME L’A DIT ATKINSON LE TEMPS EST POUR LE CADRE UN OUTIL PRÉCIEUX S’IL ARRIVE A LE MAÎTRISER IL MAITRISERA TOUS LES AUTRES PARAMÈTRES. JE SUIS QUAND MÊME FAISEUR DE MIRACLES CAR JE SUIS CONFIANT DE MOI-MÊME.
MERCI
Si je devais me classer dans une case se serait « la faiseuse de miracles » car je tiens beaucoup à mon indépendance et j’ai beaucoup de réticences à donner des ordres.
Le tronçonnage des tâches est donc un bon outil car cela permet de clarifier les demandes et donner un caractère commun à chaque étape
Je pense qu’il est important de faire comprendre l’enjeu du projet aux membres de l’équipe du projet et le rôle que chacun joue pour l’aboutissement dudit projet.
aussi, les tâches doivent être planifiées avec des délais de rigueurs à ne pas dépasser sauf cas de force majeur.