Problème de riche

| 2 Comments | 5 minutes read

La scène n’est pas très complexe à imaginer : un manager vient présenter à son équipe une nouvelle mission. Avant d’évaluer l’intérêt ou la complexité de la dite mission, l’un des membres de l’équipe interroge le manager sur la difficulté de l’insérer dans un plan de charge déjà extrêmement fourni. Et invariablement la réponse du manager est “t’inquiète pas, ça c’est un problème de riche”.

clin d-oeilUne telle scène, comme beaucoup, je l’ai vécue à de nombreuses reprises, aussi bien dans le rôle du collaborateur inquiet que du manager “rassurant”.

La réponse semble immuable; le ton même de la réponse l’est également. A la fois péremptoire pour couper court et complice, avec sourire entendu, voire clin d’oeil : “t’inquiète pas” – clin d’oeil – “ça c’est un problème de riche” – fin du clin d’oeil, et de la discussion.

Consensus général donc sur cette question. Certes, à l’inverse on entend bien qu’un plan de charge trop réduit soit un problème (de pauvre ?). Mais si le terme “riche” est employé, posons nous la question de la création de richesse associée à cette situation.

Bien évidemment si le gain pour l’entreprise d’un nouveau projet amène à recruter, éventuellement à sous-traiter, et à se développer, la création de richesse est naturelle. Le propos ici est bien celui de situations où cette nouvelle mission va induire l’obligation pour une équipe de gérer un plan de charge et un ensemble de contraintes et de contentions dont on sait d’avance qu’elles ne sont pas gérables, qu’elles généreront des retards, de l’insatisfaction client, une forte pression sur les équipes, notamment les ressources clés, … Situations malheureusement bien connues de tous.

Certes cette pratique n’est pas l’apanage du service informatique, et quiconque a eu l’occasion de faire faire des travaux chez lui a de fortes chances  d’avoir subi le “surbooking” de chantiers et la difficulté de faire avancer le sien. Mais est-ce ce que nous souhaitons pour notre profession ?

Le principe du surbooking existe chez les transporteurs aériens, visant à optimiser le taux de remplissage en allant au delà des capacités réelles d’accueil d’un vol et en anticipant des défections de dernière minute, anticipation j’imagine basée sur des statistiques de retours d’expériences. Il s’agit d’une pratique légale et encadrée, prévoyant des compensations financières pour les clients ayant à subir le système.

On peut évidemment contester cette pratique, mais c’est un modèle réfléchi, avec une  cohérence économique, et le garde-fou des compensations, certes imposée par le législateur, mais qui joue un rôle efficace de régulateur.

Pour revenir à notre propos d’origine, quel parallèle peut on faire ? Le “surbooking” d’une équipe au travers une prise de commandes supérieure aux capacités de production. Ce “surbooking” ne trouvant pas a priori prétexte dans l’anticipation de défections de commandes (rare), mais dans une optimisation (extrême) du taux d’activité. Ses clients qui ne sont pas au courant (généralement), qui en subiront les conséquences (toujours), sans bénéficier de compensation

Le parallèle s’arrête là. On voit bien qu’il n’y a pas de modèle dans cette pratique. Que le client est perdant. Que les collaborateurs sont perdants, et ici, contrairement aux avions, la “ressource” est humaine; ce n’est pas un simple siège. Et si gain économique il y a pour l’entreprise, ce ne sera qu’à la marge tant la situation nécessitera forcément des ajustements (plannings et engagements non tenus, nécessité au final d’ajouter des ressources, problèmes de qualité, …).

Le scénario est joué d’avance, et il est toujours perdant. Il est illusoire de penser que ces “problèmes de riches” créent de la richesse.

Ceci n’est qu’une illustration supplémentaire d’un manque de maturité fréquent de l’univers du service informatique et de l’industrie du logiciel; Dont les causes sont multiples, mais l’une en particulier me semble fondamentale.

Contrairement aux compagnies aériennes qui dans leur modèle de surbooking ont intégré la capacité finie de remplissage d’un vol, on fait mine de raisonner comme si l’on disposait d’une capacité infinie de production. Ce qui n’est évidemment pas vrai.

Les personnes ” clés” d’un projet, experts techniques ou fonctionnels, architectes, designers, développeurs seniors*, directeurs de projets, scrum master, product owner… constituent une “ressource” intrinsèquement finie et limitée. Et il en est de même de l’ensemble des intervenants d’un projet.

Le mythe du mois-homme**, le mythe de l’interchangabilité des ressources, sont des erreurs profondes et fondamentales d’une industrie qui a pensé justement devenir industrielle en érigeant et en faisant mine de croire à de tels mythes.

 

* : l’un de mes “dadas”, le manque de reconnaissance des développeurs seniors 

** l’ouvrage de référence The Mythical Man-Month: Essays on Software Engineering paru en 1975 et un clin d’oeil intéressant le mythe du mois-homme indien 

 

Share Button

Laurent Blondon Author: Laurent Blondon

Plus de 20 ans dans l'économie du logiciel.
Ingénieur de formation, ayant participé aux tous premiers projets Objet en France puis aux prémices du MDA, avant d’exercer d’autres rôles (formateur, commercial, manager), et de prendre part à de très belles réussites d’entreprises.
Un temps client d'ekito, observateur attentif de son projet novateur, finalement rejoint début 2010.
Pour contribuer à faire vivre et développer son modèle d'expertise technologique et d'innovation organisationnelle.
Et l'ambition de faire d'ekito l’entreprise de référence pour tout architecte, agiliste, expert, passionné, et impliqué ; le lieu incontournable de réussite des projets technologiques ambitieux.

2 Comments

  1. Guillaume Cerquant

    J’en retiens que la formule est faite pour qu’on retienne le mot “riche”, sans s’apercevoir qu’on va avoir un “problème”.
    Merci pour cette perspective !

  2. Pingback: Problème de riche - ekito people | Surbo...

Leave a Reply

Required fields are marked *.


CommentLuv badge