La loi de Brooks est une prédiction contre-intuitive sur la productivité des projets, principalement informatiques, et qui pourrait s'énoncer ainsi : "Ajouter des personnes à un projet en retard accroît son retard de façon proportionnelle à n(n-1) (où n est le nombre de personnes impliquées)".
En effet, ajouter du personnel n'est pas gage d'une productivité plus élevée car les taches d'un projet ne sont pas nécessairement faciles à partager et l'ajout de personnel rajoute du travail de formation et de communication.
Commentaires préférés (3)
C’est toujours assez compliqué de faire passer le message. On est débordés, en retard, mais on ne pourra quand même pas finir plus tôt avec plus de monde.
Mon exemple préféré pour expliquer le concept : Si une femme met 9 mois à concevoir un enfant, est-ce que vous pensez que deux femmes peuvent le faire en 4 mois 1/2 ?
Tiré de la 1ère source également :
" être 300 dans une cuisine ne fera pas qu'un œuf au plat sera servi 300 fois plus vite ".
Ou pour qu'un arbre devienne centenaire, tu peux l'arroser tant que tu veux...il faut quand même attendre cent ans. (Dixit Patrick Bosso).
Tous les commentaires (30)
C’est toujours assez compliqué de faire passer le message. On est débordés, en retard, mais on ne pourra quand même pas finir plus tôt avec plus de monde.
Mon exemple préféré pour expliquer le concept : Si une femme met 9 mois à concevoir un enfant, est-ce que vous pensez que deux femmes peuvent le faire en 4 mois 1/2 ?
Tiré de la 1ère source également :
" être 300 dans une cuisine ne fera pas qu'un œuf au plat sera servi 300 fois plus vite ".
Ou pour qu'un arbre devienne centenaire, tu peux l'arroser tant que tu veux...il faut quand même attendre cent ans. (Dixit Patrick Bosso).
les taches d'un projet => ce sont plutôt des tâches...
Donc, une seule personne doit suffire à rattraper le retard puisque 1(1-1)=0
Non, cela veut juste dire qu'ajouter 1 personne n'augmente pas le retard...
En revanche il n'y a pas d'unité notifiée dans l'anecdote... Le retard se mesure en quoi ?
A ne pas généraliser quand même. Si un projet prend une ampleur qui n'avait pas été correctement anticipé a la base des compétences peuvent venir à manquer. Sans celles-ci le projet va patiner alors que si on les ajoute a l'équipe la situation va se débloquer et le projet avancera bien plus vite.
Il ne fait oublier que c'est une loi vieille de plusieurs dizaines d'années et que les logiciels, la façon de travailler et de manager n'était pas identique à nos méthodes actuelles. On a fait beaucoup de progrès sur les aspects collaboratifs.
L'anecdote dit qu'ajouter 1 personne va au contraire accroître le retard. Donc, n'en n'ajouter aucune est la meilleure solution.
À moins que l'anecdote soit en partie fausse.
Édit.
Mieux ! Une personne a mi-temps en plus devrait permettre de rattraper le retard car la dérivée 1ère de n(n-1) est égale à 0 quand n=1/2 ^^
Tu as raison, ce n’est pas aussi binaire. Aha.
D’ailleurs, en sénaire (base six), ça ne marche plus du tout car: si six scies scient six cyprès, six-cent scies scient six-cent cyprès.
Il y a l’exemple similaire avec le jeu Among us, le studio a sorti le jeu en 2018, dans l’indifférence. En 2020, des dizaines de millions se mettent à jouer, les joueurs pressent le studio de sortir de nouvelles maps, des nouveautés etc. (Le jeu n’était plus développé).
Problème : le studio n’a que 3 personnes et les développeurs ont eu bien du mal à expliquer que recruter ne serait-ce qu’une personne est contreproductif à court et moyen termes : il faut dégager du temps pour faire une annonce, recruter, faut des entretiens, former la personne, répartir les tâches, comme l’explique l’anecdote
Bah j'en déduis qu'il suffit de retirer des personnes du projet ! Et hop on rattrape le retard !
Ou on supprime le projet, affaire résolue !
ça c'est plutôt évident, tout chef de projet là déjà vécu, ce qui est contre intuitif c'est que ajouter des personnes implique parfois un délai supplémentaire.
ce qui est un peu touchy, c'est que dans ce délai supplémentaire sont inclus la formalisation (documentation et recettes complètes par exemple). Pour un produit avec des contraintes de sécurité et/ou à maintenir longtemps, cette formalisation est souvent nécessaire, à différents degrés, donc l'effet de l'anecdote est moins présent. Avec des exemples :
pour un site internet d'une association, il y'a peu de contraintes, un développeur seul peut faire une bonne partie du travail, le valider, et si le site doit évoluer on fera appel à la même personne,ou à la même compétence car le produit n'est pas trop compliqué. il suffit de lire le code. Si on ajoute une personne dans le projet, le developpeur initial devra lui expliquer sa vision, il y'aura des reprises au moment d'assembler les 2 travaux... donc l'effet est important.
Pour un système de télésurveillance dans le ferroviaire (c'est mon boulot !), il faut une carte d'acquisition, une passerelle, un serveur... avec chacun des environnements et donc des compétences différentes. Le produit vivra 20 ans, avec des évolutions, il faudra le maintenir car il est cher à remplacer. Il est probable que les développeurs qui ont développés tout ça ne soient pas disponibles sur la durée de vie du produit. le produit utilise des protocoles de communication spécifiques (faits sur mesure), qui doivent donc été décris et testés. iL faudra testés beaucoup de modes de défaillances qui sont "cachés" car c'est un produit de sécurité et une panne à un impact plus lourd qu'un site Web indisponible. Bref c'est beaucoup plus lourd que le site Web de l'associé, et la partie documentation devient importante, pour maîtriser le produit sur la durée, pour montrer sa robustesse, et pour faire travailler ensemble des compétences différentes. L'effet est donc existant, mais diluer dans cette masse.
Il est plus facile de collaborer peut être (je n'en suis pas certain du tout) mais la loi dit que rajouter une PERSONNE va ralentir le projet in fine, et plus il y a de logiciels, au plus il faut former à employer ces logiciels.
Par expérience, un projet, une signature ou une discussion ne fonctionne pas mieux devant un logiciel que devant un verre ou un repas.
On dit que pour construire un bateau il ne faut pas donner d'ordre, mais l'envie de voyager loin ^^
Par contre, on peut dire que 300 œufs seront servis dans le même laps de temps. Tout dépend du projet analysé : « faire un œuf » ou « restaurer les clients ».
Oui la loi dit ça et je remet cela en question. Comme je l'expliquais, si ton équipe manque de compétence apporter ces compétences revient a ajouter des personnes et à accélérer le projet. Par exemple dans ton équipe personne ne sait vraiment faire d'IA et manque de pot dans ton projet se pose la question de l'IA. Former un membre du projet a l'IA peut prendre plus de temps que former un spécialiste de l'IA au projet. Auquel cas tu ajoutes une personne et tu accélères le projet. Et il en va de même pour toutes les autres compétences informatiques que tu ne possédez pas nécessairement dans ton équipe. Comme par exemple développer une application mobile. Tous les développeurs ne savent pas tout faire...
Voilà pourquoi je dis que cette loi est à prendre avec des pincettes car ajouter des gens dans certains cas va permettre au projet d'aller plus vite.
Au sujet de la communication les avancées technologiques, telles que les méthodologies agiles, les outils de gestion de projets modernes et les plateformes de collaboration en ligne, ont considérablement amélioré la communication et la coordination au sein des équipes de projet. A l'époque la gestion de projet était tout autre.
Avec les méthodes agiles (qui rencontrent un grand succès dans les DSI), le développement d'une nouvelle application est parfois "trop" efficace. Une équipe de développement est montée pour une nouvelle application et travaille étroitement avec son client pour sortir une application à sa mesure et qui répond à ses attentes. Puis... l'équipe est dissoute et chaque membre de l'équipe va vaquer à ses occupations sur d'autres projets, souvent dans d'autres entreprises.
Jusque-là, rien à redire.
Mais, lorsqu'il va s'agir de faire évoluer cette application, c'est là qu'on se rend compte que la rédaction de documentation n'est pas l'apanage des développeurs (ni de beaucoup de professions, d'ailleurs), que ça prendre beaucoup plus de temps que prévu et qu'il aurait été judicieux d'internaliser le savoir :)
Sources : une mission en tant que CP dans une banque...
Tout à fait d'accord j'ai eu les même expériences, des clients qui discutaient des devis de site Web parce qu'à l'époque il y avait la pub pour un site Web à 1 € sur TF1, je leur fixais déjà un rendez-vous pour dans 6 mois.
Et effectivement, c'était envoyé vers l'Inde ou la Roumanie et bonne chance pour retomber sur le gestionnaire de projet, au mieux ils avaient quitté le navire, au pire personne ne savait même qui avaient bossé sur quoi.
Les outils sont très bien et de plus en plus performants, même trop comme tu dis, les développeurs (et ça vaut pour beaucoup de corps de métiers) doivent s'adapter aux logiciels et outils alors que l'apanage d'un outil est d'être adapter à celui qui l'emploi, pas le contraire.
Rien ne remplace un être humain qui suit un projet et qui sera encore là pour les mises à jour, les retouches ou les évolutions, ça vaut pour le programmeur, le tailleur, le mécanicien, le boulager ou le serveur, ça se perd et c'est bien dommage.
Et une loi fondamentale de la gestion de projet et à connaître, la loi de Hofstadter énoncée de la façon suivante:
« Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter. »
Ca me fais penser à une règle d'or dans la marine:
Pour estimer à vue à quelle distance est un navire, on fait ça au pif, et on multiplie par 2.
Source: Papa ;)