1La loi de Brooks énonce qu’augmenter le nombre de collaborateurs ne permet pas automatiquement de réduire le temps nécessaire pour réaliser un projet. Bien au contraire ! Dans certains cas, cette multiplication comporte plus d’inconvénients que d’avantages…
2Cette “loi” a été établie par Frederick Brooks lorsqu’il dirigeait le projet du système d’exploitation OS/360 chez IBM. Il a ainsi pu expérimenter par lui-même les retards “boule de neige” des projets informatiques… Expérience cuisante dont il a tiré une “bible” : Le Mythe du mois-homme (The Mythical Man-Month: Essays on Software Engineering).
3En effet, toutes les activités ne sont pas “portionnables” : diviser une tâche en une multitude de sous-tâches, ne permettra pas d’aller plus vite si cette tâche doit être menée selon une logique donnée ou dans la continuité. C’est la limite de ces calculs en mois/homme parfois surréalistes…
« Neuf femmes ne font pas un enfant en un mois ». Frederick Brooks
4Intégrer de nouveaux collaborateurs peut s’avérer une fausse bonne solution car elle implique une double perte de productivité. Non seulement les nouveaux ne seront pas productifs dans un premier temps, plus ou moins long, mais les personnes en place – et donc déjà productives – devront arrêter de produire pour les former et les guider.
5Être plus nombreux sur un projet signifie aussi que les interactions seront plus nombreuses. Le temps consacré à se synchroniser n’est pas consacré à la production. Se réunir ou travailler, il faut choisir !
6Donc, même si la perspective semble alléchante, il est préférable de refuser l’apport de nouvelles recrues si votre projet est déjà en retard. En revanche, il est beaucoup plus intéressant d’obtenir que l’équipe en charge puisse consacrer un plus grand nombre d’heures à votre projet…
“Adding manpower to a late software project makes it later”. Brooks
7Une exception : les projets collaboratifs en open source ou les hackatons. Cette fois, on sort de la logique taylorienne de division du travail, en optant pour l’hyper collaboration. Dans ce cas, plus on est de fous, plus on trouve… car ce sont les effets de la loi de Linus (en hommage à Linus Torvalds, le créateur du noyau Linux) qui l’emportent. Mais nous aurons l’occasion d’y revenir.
La leçon à tirer
C’est si tentant de se laisser emporter par la magie des formules toutes faites…
Pour aller plus loin
- Notre article “7 about… Le “planning fallacy”
- Notre article “7 about… La “productivity shame”
Cet article vous a plu ? N’hésitez pas à le faire suivre à vos amis… Vous pouvez aussi vous abonner à notre Newsletter pour recevoir nos articles directement dans votre boîte mail chaque vendredi.
