Loi de Brooks

L’un des sujets les plus « touchy » de la gestion de projet est de savoir comment composer avec un projet en retard. Il y a quelques années en arrière, alors que je rencontrais un développeur de ma connaissance qui travaillait alors sur un projet très complexe (dû en parti à une vision produit très floue de la part du Project manager), je me hasardais à lui demander des nouvelles sur l’avancée des développements.
Le projet avait déjà pris beaucoup de retard, de nombreuses features avaient été rajoutées au dernier moment mais pire que tout m’expliqua ma connaissance, il se faisait bombarder de CV par son chef de projet qui avait décidé que la meilleure solution pour finir le projet dans les temps étaient d’embaucher 2 ou 3 développeurs supplémentaires. Autant dire que la perspective de devoir procéder au recrutement et à la formation de nouveaux développeurs en plus de sa masse de travail ne l’enchantait guère.
Résultat, quelques mois après notre rencontre, je retrouvais ma connaissance dans une nouvelle startup et apprenait que la fin du projet avait non seulement été chaotique mais que le produit avait été livré avec des semaines de retard, et qu’il ne convenait pas au client.
Le chef de projet avait reporté la faute sur le manque d’investissement des développeurs et était passé à un autre projet car « nobody ever got fired for buying IBM ». Le chef de projet en question ne devait sans doute pas connaître la loi de Brooks, sinon il n’aurait pas centré sa stratégie sur l’ajout de nouveaux membres à une équipe déja débordée et stressée.

Que dit la Loi de Brooks

« Allouer plus de ressources à un projet en retard accentue ce retard », c’est ce qu’explique Fred Brooks, ingénieur informatique, dans son livre de 1975 « The mythical Man-Month ».

L’idée peut sembler contre intuitive, surtout pour les entreprises qui estime en Jour/Homme ou moi/homme, le temps nécessaire pour accomplir une tâche.  Néanmoins, si on se penche un peu plus sur la question, cette loi peut se comprendre assez facilement pour qui connait un peu la gestion de projet ou le développement de logiciel.

Complexité et canaux de communication

1. Les projets de développement logiciel sont des opérations complexes et chaque nouveau membre ajouté au projet doit dans un premier temps, être formé sur le projet (méthodes, outils, code base…). Ce qui engendre alors une augmentation des canaux de communication, une augmentation des informations échangées et un ralentissement du temps et de la qualité de traitement de ces informations.
   Il existe une formule pour évaluer le nombre de canaux de communication entre les membres d’une équipe.

(n² – n) / 2

Exemple : Pour une équipe de 6 personnes, il existe 15 canaux de communications. Parfois, une image est plus simple a appréhender qu’une formule mathématique 👇

1. Ce moment de prise de poste à un impact sur la productivité car non seulement la nouvelle recrue ne participe pas encore positivement mais surtout car cela détourne des ressources vers un temps de formation (le nouveau membre de l’équipe va devoir être formé et supervisé par un membre de l’équipe qui, ne pourra donc plus se concentrer sur son travail en cours). Il est aussi possible, qu’indépendamment de ses compétences, le nouveau membre de l’équipe introduise des bugs qui ralentiront aussi la productivité.
   On parle alors d’effet de courbe en J.

Pour aller plus loin

Fred Brooks l’a dit lui même dans son livre, cette loi est une simplification de la réalité. Rien n’est gravé dans le marbre, il existe tout de même des pistes de solutions qui permettent de ne pas tomber sous le coup de la loi de Brooks.

1. Un développeur n’est pas interchangeable avec un autre. Néanmoins, avec une bonne réflexion concernant les problématiques du projet et une bonne évaluation du profil recherché, il peut être positif pour un projet de rajouter à l’équipe quelqu’un possédant une expertise pointue dans un domaine précis.
2. Une bonne segmentation du projet peut permettre de minimiser les besoins de communications entre les membres de l’équipe.
3. Une question de timing : il est possible de rajouter des personnes sur un projet plus tôt dans le processus. Pour cela il faut que le chef de projet se remette rapidement en question, vérifie le scope et l’évaluation de son planning (peut-être était-il trop optimiste).