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 ".

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.

Ça ne me parait pas si contre intuitif que ça, finalement. Après les nombreuses citations déjà partagées, il y a celle de Jean de La Fontaine: « 5 iris ne sont guère plus majestueux qu’un iris si tant est qu’il le soit, qu’il le fut et qu’il y succombe  » Absolument superbe.

Pour l'unité, je pense que c'est soit en jours, soit la durée du retard au moment de l'ajout de la personne. Supposons que le retard soit de 3 jours et qu'on rajoute 2 personnes. 2(2-1) = 2. Exemple avec unité= jour, le retard passe à 3+2=5 jours. Exemple avec unité = durée du retard, le retard passe à 3+2×3=9 jours. Dans ce cas on est sur un rapport exponentiel, plus le retard est grand à la base, plus l'ajout de personnes va plomber le projet. Ça me semble plus logique que ce soit en jours.

Je dirai plutot: Quand un projet est mal calibré depuis le début alors c'est des ennuis jusqu'à la fin et un résultat médiocre...rajouter du personnel - en cours de projet - ne permet generalement pas de finir dans le temps voulu mais - au moins - de terminer en limitant la casse. La recherche maximum de profits tend à sous evaluer les effectifs. Vos derniers commentaires me rassurent sur la vision réaliste que vous pouvez avoir concernant la gestion de projets.

Les deux analogie censé illustré le phénomène ne fonctionnent pas. Car l'anecdote stipule que vous ajouter des gens au projet et non pas juste dans la pièce. Le fait d'ajouter des femmes dans la pièce ou des cuisinier dans la cuisine ne fait pas augmenter le temps de gestation proportionnellement ou le temps de cuisson. Une fois l'oeuf dans l'eau ou la gestation amorcé les temps sont fixe, non flexible et indépendant de l'action humaine. Surtout que cette affirmation n'a pas vraiment de réalité chiffrable mais ressemble plutôt à un exercice de pensé. Puisque cela dépend du niveau d'avancement du projet, de la qualité du code déjà écrit, de l'expérience des anciens, de l'expérience des nouveaux, du temps restant au projet, du retard déjà accumulé, du programme de formation, du management des équipes, de la rémunération, de l'investissement, de l'ambiance général des équipes, des languages et librairies utilisés etc. Bien trop de variable pour sortir une loi de proportionnalité aussi simpliste et universelle que n(n-1). Le truc qu'est vraiment bizarre pour moi c'est que la productivité individuelle et le temps pour atteindre une productivité optimale n'est pas pris en compte. En gestion et conception de projets on calculerais le coût de formations, le manque a gagné du fait de cette formation, on aurait calculé le temps qu'il faudrait et le nombre de chaussures a produire pour que l'ajout de personne deviennent rentables. Nous somme 2 pour fabriquer dix milles paires de chaussures en un mois. Ça fait 5000 paire a produire chacun au rythme de 10 par jour. On arrivé à 300 par individu maximum, 600 a deux et donc on observe un retard de 9400 paires. Combien de personnes dois je recruter et combien de temps les former pour que (temps restant - temps de formation) x nombre d'individus x productivité individuelle = temps suffisant.

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. »

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...

Bah j'en déduis qu'il suffit de retirer des personnes du projet ! Et hop on rattrape le retard !

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

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.

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.

Donc, une seule personne doit suffire à rattraper le retard puisque 1(1-1)=0

les taches d'un projet => ce sont plutôt des tâches...

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 ".

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 ?