Une croix (+) signifiait que le messager pouvait se rendre à destination par étapes, deux croix (++) signifiaient un lynx, trois croix (+++) - un galop immédiat. Par conséquent, le galop dans l'armée était officieusement appelé l' attrait des trois croix , et plus tard cette expression est entrée dans la langue russe, ce qui signifie l'exécution la plus rapide des ordres des autorités. [Wikipedia]
Goudron (en anglais, littéralement goudron ) - 1) un problème insoluble, 2) un lac de bitume (un endroit où le bitume souterrain remonte à la surface, créant une section d'asphalte naturel). [Dictionnaire anglais-russe] Les animaux capturés dans le bitume ne peuvent pas sortir, de tels lacs sont donc un excellent endroit pour fouiller des squelettes préhistoriques [Wikipedia].
«L'imagination représente des dinosaures, des mammouths et des tigres à dents de sabre essayant de se libérer de la résine. Peu importe la force ou l'agilité de la bête, elle sera finalement destinée à la mort. Au cours de la dernière décennie, une telle fosse de programmation était la programmation de grands systèmes ... » [1, p.16] Avec cette image saisissante, commence le livre classique de Frederick Brooks, qui a vu le jour pour la première fois dans le lointain 1975. Un autre livre classique, publié dans le même ancien 1987, ne commence pas mieux: "Et à ce moment-là le projet se meurt quelque part" [2, p.23]. Les années passent, l'humanité entre dans un nouveau millénaire, mais en 2014, un autre best-seller commence avec la même histoire éternelle: «Le 3 mars 2010, le Federal Bureau of Investigation a décidé de suspendre son plan prometteur à grande échelle pour moderniser la gestion de l'information ... Le bureau a tenté de mettre à jour son système informatique. depuis plus de dix ans, et il semble qu’une catastrophe leur soit arrivée » [3, p.14].
44 ans après Brooks, nous pouvons, en toute conscience, répéter: maintenant, quand vous lisez ces lignes, le prochain projet, comme ses prédécesseurs, s'enfonce dans le même goudron . Les chances de succès en gestion de projet sont moindres qu'en lançant une pièce, et elle ne semble pas grandir beaucoup:
Selon les études CHAOS de Standish-Group [4]
Pourquoi les progrès de la science de la gestion (incarnés dans 6 éditions de PMBoK et plusieurs dizaines d'autres livres épais) depuis 40 ans (!) N'ont jamais conduit à une amélioration de la qualité de la gestion elle-même (à moins, bien sûr, que la qualité de la gestion comprenne la probabilité d'arriver à un point donné)? Pour traiter ce problème, nous commençons par le problème principal de tout projet, identifié tout au long du célèbre livre Brooks.
Le premier problème: la complexité du produit en cours de création
Si vous demandez au premier spécialiste informatique qui a rencontré - "Quelle est la principale chose dans le mois-homme mythique?" - la réponse est susceptible d'être: "Que tous les hommes-mois soient différents, les nouveaux travailleurs ne sont pas du tout les mêmes que les anciens." Même Brooks appelle la «loi» la disposition formulée au tout début du livre («Si le projet ne respecte pas les délais, ajouter plus de main-d'œuvre le retardera encore plus»). Mais ce n'est qu'une observation empirique, connue de tous, qu'au moins une fois "a changé de cheval au croisement"; la question est de savoir comment planifier un projet lorsque tous les hommes-mois sont différents?
«Mythical man-month» est donc devenu un best-seller, ce qui donne une réponse à cette question. Voici comment Brooks formule sa compréhension d'un problème de conception de base:
"... les difficultés classiques du développement logiciel découlent de cette complexité de l'entité et de sa croissance non linéaire avec une taille croissante. La complexité provoque des difficultés dans le processus de communication entre les membres de l'équipe de développement, ce qui entraîne des erreurs dans le produit, dépassant le coût de développement, retardant l'exécution des horaires de travail. La complexité est la raison les difficultés d'énumération, et plus encore la compréhension de tous les états possibles du programme, et donc son manque de fiabilité se pose ... La complexité de la structure provoque la difficulté lors de l'élaboration des programmes et de l'ajout de nouvelles fonctions pour qu'il n'y ait pas d'effets secondaires ... " [1, p. 167]
La différence fondamentale entre le projet et toute autre production est que le projet qui y est créé est produit pour la première fois [nous sommes conscients que de nombreuses tâches comme «visser le compteur de visites sur le site» sont aussi appelées «projets», mais nous parlons de projets réels]. Comme toute chose réelle, ce nouveau produit (peu importe qu’il s’agisse de logiciel ou de «matériel») se compose d’un grand nombre de composants capables des interactions les plus inattendues (négatives - thalidomide et positives - viagra). Il est extrêmement difficile de prévoir comment tout cela fonctionnera ensemble, et cela nécessite littéralement des «meilleurs esprits» et non des «mois-homme» sans fin:
«Des projets exceptionnels sont créés par des designers exceptionnels. La création de programmes est un processus créatif. Une méthodologie solide peut autonomiser et libérer l'esprit créatif, mais elle ne peut pas enflammer ou inspirer quelqu'un qui est occupé par un travail fastidieux ... Par conséquent ... Je crois que le seul et le plus important effort que nous puissions faire est de développer des moyens d'éduquer des designers exceptionnels » [1 , p. 185-186]
De la position de base de Brooks (la conception est la créativité et le processus créatif ne peut pas être mené par la foule), tout le contenu réel du «Mois de l'homme mythique» suit directement: les exigences de la «dictature des architectes» et «l'effet du deuxième projet», et la recommandation «plan de jeter la première version» . Mais elle suit également la thèse la plus oubliée de Brooks - que dans la gestion de projet "il n'y a pas de solution miracle ! " La complexité des projets est objective, elle ne peut être surmontée ni à l'aide de nouveaux langages de programmation (même graphiques), ni en connectant l'intelligence artificielle. Il est nécessaire de faire face à la complexité à chaque fois, et si le talent du concepteur ne suffit pas pour cela, le projet ne réussira pas.
Le principal ennemi du projet Brooks est la complexité du produit créé . Avec chaque ligne de nouveau code, avec chaque page de documentation technologique, cette complexité croît et croît de façon non linéaire. Et en même temps, le gestionnaire a à sa disposition moins de ressources - à la fois le temps restant jusqu'à la fin du projet et l'argent restant jusqu'à la fin du budget:
Au point d'intersection, ou peu de temps avant, il devient clair que le projet nécessite en réalité beaucoup plus d'argent et de temps que prévu initialement:
Le prochain projet, appelé «Sentinel», le FBI a commencé immédiatement, en 2005. Le prix de l'émission est de 451 millions de dollars, et le système Sentinel sera pleinement opérationnel en 2009 ... En mars 2010, Lockheed Martin, l'entrepreneur, était en retard pour l'année en ne réalisant que la moitié du projet et en dépensant 405 millions. Pour terminer, selon des experts indépendants, il faudrait encore six à huit ans et 350 millions de dollars supplémentaires. [3, p. 17-18].
Mais laisse-moi! Si, depuis 1975, on sait que la complexité des projets s'accroît, par exemple quadratique, - qu'est-ce qui empêche que le budget et l'équipe soient augmentés de la même manière quadratique ? Pourquoi toutes les nouvelles générations de gestionnaires continuent-elles de diriger des projets avec un succès prévu de 30%, alors que vous pouvez simplement ajouter de l'argent ?
Maintenant, il est temps de passer au livre suivant.
Le deuxième problème: la complexité de la collaboration
Comme nous le savons déjà, le best-seller mondialement connu Peopleware («personnel» traduit en russe par le «facteur humain»), qui est apparu douze ans après le Mythical Man-Month, commence par une déclaration du taux de mortalité élevé des projets. "Environ quinze pour cent des projets n'ont abouti à rien ... Dans le cas de grands projets, le tableau est encore pire, l'effondrement comprenait vingt-cinq pour cent des projets, dont la durée variait de vingt-cinq années-personnes" [2, p.24] Ceci a été écrit en 1987 (l'URSS était toujours vivante). !), en référence à l'étude de 1981 (Brejnev était encore en vie); et qu'avons-nous aujourd'hui?
Selon le rapport CHAOS 2015 [5]
Le développeur moyen coûte aujourd'hui 100 000 $ par an, en ajoutant des frais généraux, nous obtenons que 25 années-personnes soit environ 3 à 6 millions de dollars. Comme vous pouvez le voir, la situation n'a pas changé depuis ces longues années: 26% des projets de taille moyenne et 43% des grands projets s'attendent à un échec, et nous ne pouvons rien y faire. Mais pourquoi cela se produit-il? Demarco et Lister ont demandé aux développeurs les raisons des échecs, et voici ce qu'ils ont obtenu en réponse:
«Dans la grande majorité des cas, il n'y avait pas une seule raison à l'échec dans le domaine de la technologie. Le plus souvent, les participants à nos sondages ont qualifié la «politique» de cause du crash
Ce n'est pas du tout la complexité du produit en cours de développement, et pas l'insuffisance des ressources, comme on pourrait s'y attendre en regardant le Brooks Cross! «Politique», la relation entre les personnes à l'intérieur et à l'extérieur de l'équipe (ce que Demarco et Lister ont choisi d'appeler «sociologie») - c'est ce qui, selon les développeurs, a surtout empêché le succès.
Pensez à ce fait : ces mêmes personnes (développeurs, patrons et clients) qui, à première vue, étaient les plus intéressées par le succès, unies pour le projet, y ont arrangé de la «politique», ce qui a fait s'écrouler le projet! «Nous avons rencontré l'ennemi, et c'est nous» [6]; le projet a révélé le deuxième pire ennemi - sa propre équipe.
Il est intuitivement clair que plus les gens sont impliqués dans un projet, plus ils auront de temps à consacrer à l'organisation d'un travail commun et moins - à développer réellement un produit. La question est de savoir combien moins:
Fig. 2 de l'article Putnam, Myers [7]
Après avoir collecté les caractéristiques numériques de 491 projets de développement logiciel de 35 à 95 000 lignes de code, Putnam et Myers ont abouti à des résultats presque impossibles à croire. Des projets de taille comparable ont été réalisés par des équipes de nombres différents presque en même temps, et des équipes de plus grands nombres ont eu besoin non pas moins, mais de plus de temps. La loi de Brooks («ajouter des développeurs - ralentir le projet») s'est avérée fonctionner non seulement avec la menace de perturbation du projet, mais dès le début , en commençant par l'ajout du neuvième programmeur. Si vous présentez les mêmes résultats en termes de mois-hommes notoires, vous obtenez un calendrier encore plus expressif. Combien d'argent (en salaires mensuels) est nécessaire pour résoudre le même problème par des équipes de nombres différents:
Fig. 3 de l'article Putnam, Myers [7]
Les données obtenues s'inscrivent à peu près dans un schéma complètement fantastique: la productivité d'un développeur dans une équipe est inversement proportionnelle à sa taille. Dans ce cas, la période de développement sera la même pour toutes les équipes, ce qui correspond approximativement aux données de Putnem et Myers. Croyez-le ou non, l'affaire personnelle de chacun; mais même si vous n'y croyez pas, vous devez admettre que le temps consacré à la politique croît de façon non linéaire avec la taille de l'équipe - et donc, il reste beaucoup moins de temps pour travailler réellement dans de grandes équipes.
Le livre de Demarco et Lister contient de nombreux exemples de «sociologie», qui remplace le travail sur le projet par le travail de maintien de «l'ordre» dans l'équipe. Des bureaux à aire ouverte, où les patrons peuvent voir qui s'éloigne du travail (et où les employés se distraient constamment); planification détaillée et exigences constantes pour respecter les délais (dépêchez-vous et conduisez à une augmentation du nombre d'erreurs); petite réglementation (ce qui vous fait passer beaucoup de temps à rendre compte du travail effectué et à déplacer la motivation des employés du code au «morceau de papier»). Toutes ces mesures semblent nécessaires à l'organisation du travail en commun - mais, lorsqu'elles sont pleinement appliquées, elles ne laissent plus de temps au travail lui-même.
Nous pouvons maintenant comprendre pourquoi la méthode «il suffit d'ajouter de l'argent» ne fonctionne pas. Une augmentation de la taille du projet avec l'organisation moderne du travail (espace ouvert, délais serrés, reporting détaillé) n'entraîne pas une augmentation significative de la productivité. Au contraire, plus l'équipe de projet est grande, plus le risque qu'elle se complique complètement dans la paperasserie est élevé en convenant de qui fait quoi et de quel côté est le problème. La croix Demarco met fin aux tentatives visant à accroître l'efficacité des projets de manière «extensive».
Mais que se passe-t-il si nous changeons les principes mêmes de l'organisation d'activités conjointes? Demarco et Lister ont recommandé cela en 1987: Afin de gérer efficacement les personnes dans le domaine du travail intellectuel, il est nécessaire de prendre des mesures contraires à celles énumérées ci-dessus. [c.-à-d. réglementation, normalisation, travail sous peine de licenciement et interdiction de toute initiative]. On a supposé que dans Peopleware, il était écrit très clairement à quoi devraient ressembler les mesures «opposées» [en fait, non]. Regardons à nouveau le graphique de réussite du projet. Et où le résultat du livre est-il encore inclus dans la lecture incontournable de tout manager? Quelque chose à ne pas voir.
Alors pourquoi? Y a-t-il vraiment un autre croisement sur la voie d'une gestion de projet efficace?
Troisième problème: la difficulté de planifier un nouveau
À première vue, le troisième obstacle à une gestion de projet parfaite est la nature inhabituelle de la bonne façon de guider le processus créatif. Une telle méthode, maintenant connue sous le nom de Scrum, a été décrite dans un article [8] en 1986, avant même la sortie de Peopleware. En quelques années, en 1993, Jeff Sutherland a utilisé pour la première fois des éléments individuels de Scrum dans son projet et était satisfait du résultat:
Nous avons livré le logiciel à Easel à temps, dans les six mois, sans dépasser le budget et avec un nombre minimum d'erreurs - personne ne pouvait le faire auparavant.
Cependant, une description détaillée des principales idées de Scrum n'a été publiée que vingt ans plus tard , juste l'autre jour, en 2014 [3]. Pendant tout ce temps, Scrum a existé comme une méthodologie semi-sectaire, transmise littéralement du professeur à l'élève, et a gagné en popularité exclusivement par le bouche à oreille. Le fait est que le concept principal de Scrum, qui découle directement de sa philosophie, ne correspondait à aucune logique de contrôle raisonnable:
C'est ce que je répète constamment aux dirigeants: «Je ne peux nommer la date limite que lorsque je vois l'efficacité de l'équipe» [3, p. 28).
Si nous entendons par «gestion de projet» assurer la création d'un produit avec des propriétés spécifiées à temps dans le budget, il s'avère que Scrum n'est pas du tout «gestion»! Le centre de la philosophie Scrum est un refus catégorique de proposer un «délai prédéterminé» du plafond (indépendamment de la vraie équipe et de ses performances), et la première conséquence de ce refus est une approche totalement non conventionnelle de la planification de projet:
Je suis allé à la tête de l'entreprise et j'ai déclaré que nous abandonnions les diagrammes de Gantt. Outré par ce qu'il a entendu, il a demandé une explication.
- Combien de diagrammes de Gantt avez-vous rencontrés pour votre carrière professionnelle? Ai-je demandé.
«Avec des centaines», a-t-il dit.
- Combien d'entre eux étaient vrais?
"Aucun," répondit-il, réfléchissant un instant.
Ensuite, j'ai expliqué qu'au lieu de graphiques et de tableaux inutiles, nous lui donnerons d'ici la fin du mois une partie d'un système entièrement fonctionnel, qu'il pourra lui-même tester et voir par lui-même si le développement va dans la bonne direction " [3, p.50]
Dans une histoire racontée par Sutherland, le patron a accepté d'essayer. Mais nous savons ce qu'est "l'erreur des survivants", et nous savons bien qu'il y en a dix sur un tel patron qui enverra un tel "chef de projet". Quel genre de bêtises, pour payer honnêtement de l'argent, que "nous travaillerons et montrerons quelque chose dans un mois"? Quel idiot fait ça?
Du livre de Sutherland, nous savons assez exactement lequel: celui qui a déjà essayé de faire du projet une manière classique , et a subi un échec catastrophique. Seul un leader poussé dans un coin, qui n'a rien à perdre, ose abandonner le principe de base de la gestion des "ressources - uniquement dans le cadre du plan d'utilisation". Bien sûr, après vingt ans d'utilisation de Scrum, l'attitude à son égard a un peu changé, mais même aujourd'hui, la plupart des conversations «Je nommerai le terme et le montant lorsque je rassemblerai l'équipe et commencerai à travailler» courent le risque.
L'idéologie Scrum est tellement contraire aux idées généralement acceptées sur le projet («Le client accepte de payer et l'entrepreneur fait le travail suivant ...») qu'il est temps de poser la question: pourquoi Sutherland a-t-il été contraint de prendre une mesure si révolutionnaire? Vraiment, il était impossible de quitter les diagrammes de Gantt «pour une tique» et de se concentrer sur l'organisation du travail de l'équipe (par exemple, lors des réunions permanentes quotidiennes, dans lesquelles beaucoup voient la chose la plus importante dans Scrum)?
A en juger par la véhémence avec laquelle Sutherland attaque dans son livre "Gantt Charts", on ne peut pas:
Lors de la gestion de projets, deux choses sont traditionnellement requises - la responsabilité et la prévisibilité. Une telle approche conduira inévitablement à l'émergence d'une énorme quantité de documentation, de tableaux et de diagrammes ... Des mois de travail sont consacrés à tout fournir dans les moindres détails, empêchant un seul dysfonctionnement, ne dépassant pas les ressources financières et allant de l'avant selon le calendrier. [3, p.23] Le seul problème est que dès que ce plan parfaitement affûté est confronté à la réalité, il s'effrite immédiatement. Mais au lieu de jeter à la fois le plan lui-même et son approche, les gestionnaires prétendent que le plan fonctionne ... En fait, ils paient les gens pour leur avoir menti . [3, p. 20]
Ils paient pour leur avoir menti - c'est ça! ( « ») , . , , (« !»). :
, , , , [3, .23]
: ( ) ( ), . «», , :
( , ), , « », . : «, , , ».
— ! [9]
, « » . , , . « - » , . (« ») . , - .
Pourquoi cela se produit-il? ? — . () — . — .
. , «» . , ( «»). , . , — , . , .
- [1] . « - », , -, 2007
- [2] Demarco T., Lister T. «Le facteur humain: projets et équipes réussis», Saint-Pétersbourg, Symbol-Plus, 2005
- [3] Sutherland, Jeff. "Scrum. La méthode révolutionnaire de gestion de projet », M., Mann, Ivanov et Ferber, 2016
- [4] de.wikipedia.org/wiki/Chaos-Studie
- [5] RAPPORT CHAOS 2015
- [6] Nous avons rencontré l'ennemi
- [7] Putnam, Myers "Familiar Metric Management - Small is Beautiful-Once Again", 1998
- [8] Takeuchi, Nonaka "Développement de nouveaux produits: nouvelles règles de jeu" (1986), traduction russe
- [9] Makovetsky P.V. "Regardez la racine!", M., 1966