Laurent HAUSERMANN

Depuis plusieurs années, j'ai eu la chance de me voir confier des responsabilités : j'encadre des techniciens et des ingénieurs qui conçoivent, développent ou encore diagnostiquent les produits de mon entreprise (des systèmes de sécurité pour réseaux professionnels). Pour bien faire, j'essaie de ne pas sombrer dans le micro-management et je recherche une agilité constante.

Toutes les semaines, j'échange avec des clients finaux et nos partenaires qui revendent nos solutions ; régulièrement, je lis le code source (ce qu'on appelle communément « le programme ») des logiciels développés par l'équipe. Souvent, je consulte des fichiers de traces (« les logs ») des clients ou d'incidents remontés via notre département support. Du coup, je suis toujours connecté aux problématiques techniques rencontrées et aux rouages internes de nos produits.

Quand un collègue passe dans l'OpenSpace et découvre mon écran partagé entre des traces réseau (Wireshark), des fichiers de logs et du code source (GNU Emacs), les réactions sont parfois gênées ou bien vives (c'est vrai qu'on pouvait dire... Oh Dieu ! bien des choses en somme !) :

• Paternaliste : Ce n'est plus pour toi !
• Moqueur : Tiens, tu t'amuses ?
• Agressif : Tu codes encore, ca m'étonne pas que nos logiciels soient encore tous buggés !
• « Sage »  : Moi, je suis passé à autre chose.
• Ironique : Tu as la belle vie  !
• Expert : Un manager, ça ne fait pas ça !
• (Ma préférée) Donneur de leçons : Tu as le temps de faire ça, toi ?

A leurs yeux, mon travail devrait se concentrer uniquement à lire des emails, des rapports ; à demander des comptes – as-tu rempli ton reporting horaire cette semaine ? – ; à suivre l'activité d'autres. Je devrais contrôler l'amont en validant les spécifications techniques qui seraient un pavé d'une centaine de pages. Côté service client, je relirais des comptes rendus de conférences téléphoniques ou des messages de clients mécontents. Je devrais m'attacher à mettre la pression : fixer des jalons arbitraires, relancer sans cesse, exiger des réponses ASAP...

Bref, mon travail serait de travailler au travers d'éléments intermédiaires : plutôt que de rendre visite à un client, lire un compte-rendu ; plutôt que de comprendre un code source, lire une spécification.....Non !

Il n'est bien entendu pas question de faire à sa place le travail de l'équipe. Ni même d'être dans tout, de prendre toutes les décisions ou de construire un organisation pyramidale incapable de vivre par elle-même (voir à ce propos la jolie thèse de Didier sur l'entreprise organique). Il n'est pas non plus question de ne rien formaliser. Passer par l'écrit doit permettre l'expression d'objectifs communs et une meilleure communication.

Mais quand on est responsable, il est impératif d'aller à la source, sur le terrain. Il faut éviter de prendre des décisions hâtives sans avoir confronté ses idées aux réalités concrètes. Les comptes rendus sont des filtres qui déforment la vérité ; les documents sont des abstractions toujours soumises à interprétation : donnez le même texte à 100 personnes différentes et vous aurez 100 représentations différentes, chacun se construisant sa propre image mentale.

Rencontrer en personne un client prend du temps (transport, hôtel, taxi, TGV, etc...) mais crée une expérience unique et commune. L'avoir au téléphone permet de comprendre sa perception des choses, de saisir son point de vue. Rien de tout cela n'est possible au travers d'un texte si bien écrit soit-il. Si vous encadrez des développeurs, lisez leurs programmes. Un bon logiciel doit être bien écrit et ainsi faciliter la lecture et la compréhension. Vous ne le comprenez pas ? Un bon expert doit être capable d'expliquer son travail, les problématiques auxquelles il fait face et comment il les résout.

N'écoutez pas les grincheux qui théorisent sur les vrais managers. Si besoin, raisonnez par l'absurde :

• Connaissez vous un chef de chantier qui suivrait un chantier en regardant des photos ?
• Pensez vous qu'un chirurgien peut évaluer un étudiant en internat depuis son bureau ?
• Imagineriez vous vivre en Allemagne sans parler un mot d'allemand ?

S'ils insistent, soyez savant et revendiquez-vous de la philosophie Gemba :

Gemba (現場, gemba) is a Japanese term meaning "the real place." Japanese detectives call the crime scene gemba, and Japanese TV reporters may refer to themselves as reporting from gemba. In business, gemba refers to the place where value is created; in manufacturing the gemba is the factory floor. It can be any "site" such as a construction site, sales floor or where the service provider interacts directly with the customer.

Imai, Masaaki (1997). Gemba Kaizen

Vous qui lisez ce blog : la prochaine fois que vous croiserez dans votre entreprise un responsable d'équipe plongé dans une activité technique, ne soyez pas moqueur ou pire, donneur de leçons. Votre collègue fait son travail...!!