Connaissez vous la "loi de Brooks" ? Egalement connue sous le nom de "loi de Brooks sur la complexité". Elle a été proposée par Fred Brooks dans son livre de 1975 intitulé "The Mythical Man-Month: Essays on Software Engineering". La loi de Brooks stipule que "l'ajout de personnel à un projet en retard le retardera encore plus". En d'autres termes, l'embauche de plus de personnes pour accélérer un projet en retard peut en fait avoir l'effet inverse en raison de la complexité accrue de la communication et de la coordination entre les membres de l'équipe. Brooks a expliqué que cela était dû au fait que l'ajout de personnel à un projet existant augmentait la complexité de la communication et de la coordination nécessaire pour achever le projet. Il a également souligné que le temps nécessaire pour former de nouveaux membres de l'équipe pouvait également retarder le projet. La loi de Brooks a été largement acceptée et est souvent citée dans le domaine de l'ingénierie logicielle et de la gestion de projets. Elle met en évidence l'importance de la communication et de la coordination dans les projets de grande envergure et souligne la nécessité de prendre en compte la complexité lors de l'ajout de personnel à un projet.
En d'autres termes, quand un projet n'est pas sur la bonne trajectoire (délais ou coûts), le renforcement des ressources, sans recentrage de la stratégie est souvent un échec. Il ne faut renforcer les équipes du projet qu'après audit de ce dernier, puis suivant les conclusions, le recalage des feuilles de routes des participants.
C’est évidemment très approximatif. Par l’absurde, faut il réduire la taille des équipes pour obtenir de meilleurs résultats selon Brooks? Il est évident qu’une clarification des objectifs et une organisation simple et lisible peuvent plus aider à éviter des échecs qu’une simple augmentation de moyens. En revanche, de nombreux echecs ne dont ils pas liés à une sous estimation des moyens et des choix indispensables (notamment dans les phases amonts engageant les « métiers »)? Réunir peu de gens permet de faire des choix très vite, pas nécessairement les plus pertinents.
Logique: Si L(p) est le nombre de lignes pour P personnes, alors L(p+1)=L(p)+P. L(1)=0. L(2)=0+1=1 L(3)=1+2=3…. L(p)=1+2+3+…+(p-1)=(p*(p-1))/2 {Gauss} C’est une fonction quadratique. Résolution: « Diviser le problème en tâches simples à résoudre » {Descartes} En gestion de projets: le WBS (work breakdown structure) En développement logiciel: la programmation structurée (puis objet, puis le SaaS)
Si je puis me permettre c'est certainement vrai pour le codage par exemple mais pour l'organisation sur un projet sur le côté humain donc organisationnelles j'ai des doutes. Il y a beaucoup de facteurs à prendre en compte. La motivation des personnes, la communication, l'intégration de la personne dans le projet en cours de route, les outils..... Car si il y a plus de personnes dans le projet il y aura aussi plus d'astuces, d'autres angles de vue qui peuvent aussi faire avancer plus vite le projet. Mais la théorie de Brooks est très intéressante merci pour le partage 😊. Bonne journée.
C’est comme l’organisation d’un voyage plus il y a de personne plus il est compliqué d’organiser une activité. Pour cela que si on prend un nombre supérieur à trois tout projet se retarde comme toute planification puisque l’information prend du temps à circuler et plus il y a de variable à prendre en compte plus il en devient complexe pour exécuter une simple road map.
C'est l'une des raisons pour laquelle l'innovation pourrait s'arrêter. Maitriser un sujet (électronique, médecine, etc.) devient de plus en plus difficile et long car la quantité de savoirs à intégrer a explosé. Une des solutions c'est de spécialiser les gens toujours plus... mais ça nécessite des équipes plus grandes, donc loi de Brooke. L'autre solution c'est que les gens apprennent les sciences plus vite (en optimisant les cursus et les méthodes), mais on prend le chemin inverse...
Pourtant c'est ce qu'ils ont fait à l'INPI pour le projet informatique visant à centraliser tous les centres de formalités des entreprises (CFE).préalablement gérés par les Chambres de Commerce: 300 personnes recrutées en.urgence pour résoudre les bugs et finaliser le projet. Cela augure rien de bon au vu de cette analyse...
As illustrated by computer chips it depends on tasks, and tasks can be designed or refactored. https://caminao.blog/knowledge-kaleidoscope/anatomy-of-complexity/
Acheteur maintenance pièces et prestations chez Tokheim sofitam france
1yje vais prendre 2 exemples : le 1er vous confiez à un programmeur la tache de réaliser un logiciel , il est en retard, vous vous dites , je prends deux autres personnes , donc au lieu de 8 H théorique de travail vous passez à 24 . Echec car vous avez 3 écritures différentes pour arriver au même finish , mais on ne peut pas rabouter les écrits. exemple 2: c'est le mille feuilles de l'administration, je vous défie quand vous déposez un permis de construire d'avoir l'aval des différents services non communiquant et jouant leur partition solo . Pour un lotissement ou vous construisez une maison connu référencé au catalogue que l'administration voit au quotidien , il faut 3 mois , si une peccadille ne déboute pas votre 1er essais . Je vous laisse faire le SWOT de cette situation, les paramètres une matrice N entrés , N freins, N décideurs , N conflits , N -X la sortie et dresser la probabilité du nombre de cas favorables, par rapport aux nombres de postulants .