La hantise des chefs. Faire du micromanagement. Derrière ce terme barbare se cachent des activités simples, réalisées par des responsables et qui apportent peu de valeur. C’est en observant les objectifs d’une entreprise que ce terme prend tout son sens. Mais avant cela, il faut répondre à la question “Quelle est la valeur ajoutée d’une entreprise ?”.
Prenons le cas d’une entreprise qui crée des logiciels. Le patron a pour objectif d’engranger les bénéfices. Pour cela, il a deux options pour se distinguer de la concurrence :
- par la performance de ses logiciels personnalisés sur des secteurs de niche,
- en noyant le marché de logiciels peu chers voire gratuits.
Dans un cas comme dans l’autre, bien évidemment, ce n’est pas le patron qui code. Il en serait bien incapable. Il va donc s’entourer de développeurs pour réaliser son produit et appliquer sa stratégie. Le patron se situe au niveau organisationnel. En haut de la hiérarchie. Il imagine, Il fixe les grands principes, le cap. Il organise les équipes.
Il faut se rappeler que dans chaque entreprise sont représentées 7 activités principales. Dans notre cas, l’activité industrielle permet de concevoir et produire le logiciel. Pour autant, les autres activités (commerciale, marketing, financière, …) restent sous la responsabilité du directeur.
Ainsi, s’il exprime le besoin et reste tenu informé des versions précédents la commercialisation, il ne sera jamais derrière le dos des développeurs afin de contrôler si ces derniers respectent les conventions. Pour s’assurer de cela, il va mettre en place une organisation et déléguer à des chefs de projets (CdP).
S’il agit autrement, s’il contrôle chaque action de ses collaborateurs, 24 heures ne seront pas suffisantes dans une journée. Même le pointilleux Steve Jobs ne faisait pas cela avec ces équipes. Il observait l’évolution du produit et recadrait les chantiers suivant l’évolution de sa vision. Jamais plus.
Le patron se contente de se placer à l’entrée et à la sortie de l’usine logicielle. Si le résultat ne correspond pas à ses attentes, lors de points intermédiaires, il corrige les objectifs initialement définis afin de recadrer le produit. Mais à aucun moment il ne commente étape par étape le travail de ses équipes.
Même les CdP impliqués n’ont pas la pleine connaissance du travail des développeurs. Ils doivent quand même avoir la compréhension du domaine technique pour pouvoir suivre l’avancée du projet. Ainsi, ils peuvent mettre en place des réunions de suivi, des outils d’audit de code, des étapes de validations et de tests, …
Mais ils ne se placeront jamais au-dessus du clavier des développeurs … tant que tout se passe bien. C’est lorsque les difficultés arrivent que les responsables ajoutent des tâches de contrôle là où ils devraient se concentrer sur leurs principales missions. Il est normal de chercher une solution à un problème, mais c’est un travail en plus.
Le micromanagement n’est pas que la hantise des responsables. La situation est aussi pénible pour l’exécutant observé. Il doit justifier son activité, fournir les éléments attendus, écrire des documentations supplémentaires (qui ne seront sûrement jamais lues) … au détriment de son activité initiale.
La phase de micromanagement n’est pas censée durer. Elle permet d’évaluer une situation et de trouver une solution pérenne. Si elle persiste, le problème peut être d’ordre organisationnel (méthode de gestion non adaptée) ou structurel (compétences absentes ou insuffisantes sur le projet, mauvaise répartition des tâches, …).
Imaginons un CdP qui n’a jamais codé. Comment sait-il si son développeur est compétent ? Comment peut-il estimer la durée d’une tâche ? N’en déplaise aux puristes des méthodes agiles, les développeurs savent tricher au planning poker. Et les tâches sont surestimées même si les dates de livraisons restent figées.
Le CdP met alors en place des méthodes de flicage afin de s’assurer de cela, grevant ainsi l’activité de ses collaborateurs. Si le micromanagement peut être une solution, il sert aussi à masquer un problème de compétence.
Sur un projet parfait, les gens sont consciencieux, bien formés et en nombre suffisants … et le micromanagement n’existe pas. Dans le monde réel, un peu de surveillance permet de recadrer un projet, même si on a vu qu’en informatique l’échec est très présent. Mais si le micromanagement persiste, c’est qu’un manque doit être comblé avant de continuer.