Ein Kreuz (+) bedeutete, dass der Bote schrittweise zum Ziel gelangen konnte, zwei Kreuze (++) bedeuteten einen Luchs, drei Kreuze (+++) - ein sofortiger Galopp. Daher wurde der Galopp in der Armee inoffiziell als der Reiz der drei Kreuze bezeichnet , und später trat dieser Ausdruck in die russische Sprache ein, was die schnellste Ausführung von Befehlen der Behörden bedeutete. [Wikipedia]
Teergrube (englisch, wörtlich Teerpech ) - 1) ein unlösbares Problem, 2) ein Bitumensee (ein Ort, an dem unterirdisches Bitumen an die Oberfläche kommt und einen Abschnitt aus natürlichem Asphalt bildet). [Englisch-Russisches Wörterbuch] In Bitumen gefangene Tiere können nicht herauskommen, daher sind solche Seen ein großartiger Ort, um prähistorische Skelette auszugraben [Wikipedia].
„Imagination repräsentiert Dinosaurier, Mammuts und Säbelzahntiger, die versuchen, sich vom Harz zu befreien. Egal wie stark oder beweglich das Tier ist, am Ende wird es für den Tod bestimmt sein. In den letzten zehn Jahren hat eine solche Teergrube große Systeme programmiert ... “ [1, S.16] Mit diesem beeindruckenden Bild begann das klassische Buch von Frederick Brooks, das erstmals im fernen 1975 das Licht erblickte. Ein anderes klassisches Buch, das im selben alten 1987 veröffentlicht wurde, beginnt nicht besser: "Und zu dieser Zeit stirbt das Projekt irgendwo" [2, S.23]. Jahre vergehen, die Menschheit tritt in ein neues Jahrtausend ein, aber 2014 beginnt ein weiterer Bestseller mit derselben ewigen Geschichte: „Am 3. März 2010 beschloss das Federal Bureau of Investigation, seinen groß angelegten und vielversprechenden Plan zur Modernisierung des Informationsmanagements auszusetzen ... Das Büro versuchte, sein Computersystem zu aktualisieren seit mehr als zehn Jahren, und es scheint, dass eine Katastrophe sie getroffen hat “ [3, S.14].
44 Jahre nach Brooks können wir mit gutem Gewissen wiederholen: Wenn Sie jetzt diese Zeilen lesen, versinkt das nächste Projekt wie seine Vorgänger in derselben Teergrube . Die Erfolgschancen im Projektmanagement sind geringer als beim Werfen einer Münze, und es scheint nicht viel zu wachsen:
Nach CHAOS-Studien der Standish-Group [4]
Warum hat der Fortschritt in der Managementwissenschaft (enthalten in 6 Ausgaben von PMBoK und Dutzenden anderer dicker Bücher) seit 40 Jahren (!) Nie zu einer Verbesserung der Qualität des Managements selbst geführt (es sei denn, unter der Qualität des Managements wird natürlich die Wahrscheinlichkeit verstanden, an einem bestimmten Punkt anzukommen)? Um dieses Problem zu lösen, beginnen wir mit dem Hauptproblem eines Projekts, das im gesamten berühmten Brooks-Buch beschrieben wird.
Das erste Problem: die Komplexität des zu erstellenden Produkts
Wenn Sie den ersten IT-Spezialisten fragen, der auf etwas gestoßen ist: "Was ist die Hauptsache im mythischen Mannmonat?" - Die Antwort dürfte lauten: "Daß alle Mannmonate unterschiedlich sind, sind die neuen Arbeiter überhaupt nicht die gleichen wie die alten." Sogar Brooks nennt das „Gesetz“ die Bestimmung, die ganz am Anfang des Buches formuliert wurde („Wenn das Projekt die Fristen nicht einhält, wird es durch das Hinzufügen von mehr Arbeitskräften noch mehr verzögert“). Dies ist jedoch nur eine empirische Beobachtung, die allen bekannt ist, dass mindestens einmal "Pferde an der Kreuzung gewechselt" wurden; Die Frage ist, wie man ein Projekt plant, wenn alle Mannmonate unterschiedlich sind.
"Mythischer Mannmonat" wurde daher zum Bestseller, der eine Antwort auf diese Frage gibt. So formuliert Brooks sein Verständnis eines grundlegenden Designproblems:
"... die klassischen Schwierigkeiten der Softwareentwicklung ergeben sich aus dieser Komplexität des Unternehmens und seinem nichtlinearen Wachstum mit zunehmender Größe. Komplexität führt zu Schwierigkeiten im Kommunikationsprozess zwischen Mitgliedern des Entwicklungsteams, was zu Fehlern im Produkt führt, die Entwicklungskosten übersteigt und die Ausführung von Arbeitsplänen verzögert. Komplexität ist der Grund Die Schwierigkeiten bei der Aufzählung und vor allem das Verständnis aller möglichen Zustände des Programms und damit seine Unzuverlässigkeit ... Die Komplexität der Struktur verursacht die Schwierigkeit während der Entwicklung von Programmen und der Hinzufügung neuer Funktionen, damit es keine Nebenwirkungen gibt ... " [1, p. 167]
Der grundlegende Unterschied zwischen dem Projekt und jeder anderen Produktion besteht darin, dass das darin erstellte Projekt zum ersten Mal produziert wird [wir sind uns bewusst, dass viele Aufgaben wie das „Verschrauben des Besuchszählers auf der Website“ auch als „Projekte“ bezeichnet werden, aber wir sprechen von realen Projekten]. Wie jedes echte Produkt besteht dieses neue Produkt (ob Software oder Hardware) aus einer großen Anzahl von Komponenten, die zu den unerwartetsten Wechselwirkungen fähig sind (sowohl Negativ-Thalidomid als auch Positiv-Viagra). Es ist äußerst schwierig vorherzusagen, wie all dies zusammenarbeiten wird, und dies erfordert buchstäblich „bessere Köpfe“ und nicht endlose „Mannmonate“:
„Herausragende Projekte werden von herausragenden Designern erstellt. Das Erstellen von Programmen ist ein kreativer Prozess. Eine starke Methodik kann den kreativen Geist stärken und befreien, aber sie kann niemanden entzünden oder inspirieren, der mit mühsamer Arbeit beschäftigt ist ... Deshalb ... glaube ich, dass die einzige und wichtigste Anstrengung, die wir unternehmen können, darin besteht, Wege zu entwickeln, um herausragende Designer auszubilden. “ [1] , p. 185-186]
Aus der Grundposition von Brooks (Design ist Kreativität und der kreative Prozess kann nicht von der Menge ausgeführt werden) folgt direkt der gesamte eigentliche Inhalt des „Mythical Man-Month“: die Anforderungen der „Diktatur der Architekten“ und „die Wirkung des zweiten Projekts“ und die Empfehlung „Plan, die erste Version wegzuwerfen“ . Es folgt aber auch Brooks 'am meisten vergessener These - dass es im Projektmanagement "keine Silberkugel gibt ! " Die Komplexität der Projekte ist objektiv und kann weder mit Hilfe neuer Programmiersprachen (auch grafischer) noch durch die Verbindung künstlicher Intelligenz überwunden werden. Es ist notwendig, jedes Mal neu mit der Komplexität umzugehen, und wenn das Talent des Designers dafür nicht ausreicht, wird das Projekt nicht erfolgreich sein.
Der Hauptfeind des Brooks-Projekts ist die Komplexität des zu erstellenden Produkts . Mit jeder neuen Codezeile und mit jeder Seite der technologischen Dokumentation wächst diese Komplexität und wächst nichtlinear. Gleichzeitig stehen dem Manager weniger Ressourcen zur Verfügung - sowohl die verbleibende Zeit bis zum Ende des Projekts als auch das verbleibende Geld bis zum Ende des Budgets:
Am Schnittpunkt oder kurz davor wird klar, dass das Projekt tatsächlich viel mehr Geld und Zeit benötigt als ursprünglich beabsichtigt:
Das nächste Projekt namens "Sentinel", das FBI, begann sofort im Jahr 2005. Der Preis für die Emission beträgt 451 Millionen US-Dollar, und das Sentinel-System wird 2009 voll funktionsfähig sein ... Im März 2010 war Lockheed Martin, der Auftragnehmer, zu spät zum Jahr gekommen, indem er nur die Hälfte des Projekts abgeschlossen und 405 Millionen ausgegeben hat. Unabhängigen Experten zufolge würde die Fertigstellung weitere sechs bis acht Jahre und weitere 350 Millionen US-Dollar dauern. [3, S. 17-18].
Aber lass mich! Wenn wir seit 1975 wissen, dass die Komplexität von Projekten beispielsweise quadratisch zunimmt, was verhindert dann, dass das Budget und das Team auf die gleiche Weise quadratisch erhöht werden? Warum leiten alle neuen Generationen von Managern weiterhin Projekte mit einem prognostizierten Erfolg von 30%, wenn Sie nur Geld hinzufügen können ?
Jetzt ist es Zeit, mit dem nächsten Buch fortzufahren.
Das zweite Problem: die Komplexität der Zusammenarbeit
Wie wir bereits wissen, beginnt der weltberühmte Bestseller Peopleware („Personal“, übersetzt ins Russische als „Human Factor“), der zwölf Jahre nach dem Mythical Man-Month erschien, mit einer Aussage über die hohe Sterblichkeitsrate von Projekten. "Ungefähr fünfzehn Prozent der Projekte endeten mit nichts ... Bei großen Projekten ist das Bild noch schlimmer. Der Zusammenbruch umfasste fünfundzwanzig Prozent der Projekte, deren Dauer zwischen fünfundzwanzig Personenjahren lag." [2, S.24] Dies wurde 1987 geschrieben (die UdSSR lebte noch) !) unter Bezugnahme auf die Studie von 1981 (Breschnew lebte noch); und was haben wir heute
Laut CHAOS-Bericht 2015 [5]
Der durchschnittliche Entwickler kostet heute 100.000 US-Dollar pro Jahr. Wenn wir den Overhead hinzufügen, erhalten wir, dass 25 Personenjahre etwa 3 bis 6 Millionen US-Dollar betragen. Wie Sie sehen, hat sich die Situation seit diesen langen Jahren nicht geändert : 26% der mittelgroßen Projekte und 43% der großen Projekte erwarten einen Misserfolg, und wir können nichts dagegen tun. Aber warum passiert das? Demarco und Lister fragten die Entwickler nach den Gründen für die Fehler, und als Antwort erhielten sie Folgendes:
„In den allermeisten Fällen gab es keinen einzigen Grund für das Scheitern auf dem Gebiet der Technologie. Am häufigsten nannten die Teilnehmer unserer Umfragen "Politik" als Ursache für den Absturz
Es ist überhaupt nicht die Komplexität des zu entwickelnden Produkts und nicht die Unzulänglichkeit der Ressourcen, wie man es beim Blick auf das Brooks Cross erwarten könnte! "Politik", die Beziehung zwischen Menschen innerhalb und außerhalb des Teams (was Demarco und Lister lieber als "Soziologie" bezeichneten) - dies hat laut den Entwicklern den Erfolg am meisten verhindert.
Denken Sie an diese Tatsache : Dieselben Leute (Entwickler, Chefs und Kunden), die auf den ersten Blick am meisten am Erfolg interessiert waren und sich für das Projekt zusammengeschlossen hatten, arrangierten darin „Politik“, die das Projekt zum Zusammenbruch brachte! "Wir haben den Feind getroffen, und er ist wir" [6]; Das Projekt enthüllte den zweitschlechtesten Feind - sein eigenes Team.
Es ist intuitiv klar, dass je mehr Menschen an einem Projekt beteiligt sind, desto mehr Zeit sie für die Organisation gemeinsamer Arbeit aufwenden müssen und desto weniger - für die tatsächliche Entwicklung eines Produkts. Die Frage ist, wie viel weniger:
Abb. 2 aus Artikel Putnam, Myers [7]
Nachdem Putnam und Myers die numerischen Merkmale von 491 Softwareentwicklungsprojekten von 35 bis 95.000 Codezeilen erfasst hatten, kamen sie zu Ergebnissen, die kaum zu glauben sind. Projekte vergleichbarer Größe wurden fast gleichzeitig von Teams unterschiedlicher Anzahl abgeschlossen, und Teams größerer Anzahl benötigten nicht weniger, sondern mehr Zeit. Das Gesetz von Brooks („Entwickler hinzufügen - Projekt verlangsamen“) erwies sich nicht nur als drohend, das Projekt zu stören, sondern von Anfang an , beginnend mit der Hinzufügung des neunten Programmierers. Wenn Sie die gleichen Ergebnisse in Bezug auf die berüchtigten Mannmonate präsentieren, erhalten Sie einen noch aussagekräftigeren Zeitplan. Wie viel Geld (in monatlichen Gehältern) wird benötigt, um das gleiche Problem von Teams unterschiedlicher Anzahl zu lösen:
Abb. 3 aus Artikel Putnam, Myers [7]
Die erhaltenen Daten passen ungefähr in ein völlig fantastisches Muster: Die Produktivität eines Entwicklers in einem Team ist umgekehrt proportional zu seiner Größe. In diesem Fall ist der Entwicklungszeitraum für alle Teams gleich, was ungefähr den Daten von Putnem und Myers entspricht. Ob Sie es glauben oder nicht, jedermanns persönliche Angelegenheit; Aber selbst wenn Sie es nicht glauben, müssen Sie zugeben, dass die für die Politik aufgewendete Zeit nicht linear mit der Größe des Teams wächst - und daher viel weniger Zeit übrig bleibt, um tatsächlich in großen Teams zu arbeiten.
Das Buch von Demarco und Lister enthält viele Beispiele für „Soziologie“, die die Arbeit am Projekt durch die Arbeit zur Aufrechterhaltung der „Ordnung“ im Team ersetzen. Open-Space-Büros, in denen die Chefs sehen können, wer von der Arbeit wegschwingt (und die Mitarbeiter sich ständig gegenseitig ablenken); detaillierte Planung und ständige Anforderungen zur Einhaltung der Fristen (beeilen Sie sich und führen Sie zu einer Erhöhung der Fehleranzahl); geringfügige Regulierung (wodurch Sie viel Zeit damit verbringen, über geleistete Arbeit zu berichten und die Motivation der Mitarbeiter vom Code auf ein Stück Papier zu verlagern). All diese Maßnahmen scheinen für die Organisation gemeinsamer Arbeit notwendig zu sein - aber wenn sie vollständig angewendet werden, lassen sie keine Zeit mehr für die Arbeit selbst.
Jetzt können wir verstehen, warum die Methode „Nur Geld hinzufügen“ nicht funktioniert. Eine Vergrößerung des Projekts mit der modernen Arbeitsorganisation (Freiraum, enge Fristen, detaillierte Berichterstattung) führt nicht zu einer signifikanten Steigerung der Produktivität. Im Gegenteil, je größer das Projektteam ist, desto höher ist das Risiko, dass es sich vollständig in Papierkram wälzt, indem vereinbart wird, wer was tut und auf wessen Seite das Problem liegt. Das Demarco-Kreuz beendet Versuche, die Effektivität von Projekten auf „umfassende“ Weise zu steigern.
Was aber, wenn wir die Grundsätze der Organisation gemeinsamer Aktivitäten ändern? Demarco und Lister haben dies bereits 1987 empfohlen: Um Menschen im Bereich der intellektuellen Arbeit effektiv zu verwalten, müssen Maßnahmen ergriffen werden , die den oben aufgeführten entgegengesetzt sind. [d.h. Regulierung, Normung, Entlassungsarbeit und Verbot jeglicher Initiative. Es wurde angenommen, dass in Peopleware ganz klar geschrieben wurde, wie die „entgegengesetzten“ Maßnahmen aussehen sollten [tatsächlich nein]. Schauen wir uns noch einmal das Projekterfolgsdiagramm an. Und wo ist das Ergebnis des Buches noch im Muss eines Managers enthalten? Etwas nicht zu sehen.
Warum also? Gibt es wirklich ein weiteres Kreuz auf dem Weg zu einem effektiven Projektmanagement?
Drittes Problem: die Schwierigkeit, ein neues zu planen
Das dritte Hindernis für ein perfektes Projektmanagement ist auf den ersten Blick die ungewöhnliche Art und Weise, den kreativen Prozess richtig zu steuern. Eine solche Methode, die heute allgemein als Scrum bekannt ist, wurde bereits 1986 in einem Artikel [8] beschrieben, noch bevor Peopleware veröffentlicht wurde. Innerhalb weniger Jahre, 1993, verwendete Jeff Sutherland erstmals einzelne Elemente von Scrum in seinem Projekt und war mit dem Ergebnis zufrieden:
Wir haben das Softwareprodukt innerhalb von sechs Monaten pünktlich an Easel geliefert, ohne das Budget zu überschreiten und mit einer minimalen Anzahl von Fehlern - niemand konnte dies zuvor tun.
Eine detaillierte Beschreibung der Hauptideen von Scrum wurde jedoch erst zwanzig Jahre später , erst neulich, im Jahr 2014 veröffentlicht [3]. Während dieser ganzen Zeit existierte Scrum als semi-sektiererische Methode, die buchstäblich vom Lehrer auf den Schüler übertragen wurde und ausschließlich durch Mundpropaganda an Popularität gewann. Die Sache ist, dass das Hauptkonzept von Scrum, das sich direkt aus seiner Philosophie ergibt, nicht in eine vernünftige Steuerlogik passte:
Dies wiederhole ich ständig gegenüber der Führung: „Ich kann die Frist nur benennen, wenn ich sehe, wie effektiv das Team handeln wird“ [3, S. 28].
Wenn wir unter „Projektmanagement“ verstehen, dass die Erstellung eines Produkts mit bestimmten Eigenschaften rechtzeitig innerhalb des Budgets sichergestellt wird, stellt sich heraus, dass Scrum überhaupt kein „Management“ ist! Das Zentrum der Scrum-Philosophie ist die kategorische Weigerung, eine „feste Frist“ von der Obergrenze (isoliert vom realen Team und seiner Leistung) festzulegen, und die erste Folge dieser Weigerung ist ein völlig unkonventioneller Ansatz für die Projektplanung:
Ich ging zum Leiter des Unternehmens und erklärte, dass wir Gantt-Charts aufgeben. Empört über das, was er hörte, verlangte er eine Erklärung.
- Auf wie viele Gantt-Charts sind Sie in Ihrer beruflichen Laufbahn gestoßen? Ich fragte.
"Mit Hunderten", sagte er.
- Wie viele von ihnen waren wahr?
"Keine", antwortete er und dachte einen Moment nach.
Dann erklärte ich, dass wir ihm bis Ende des Monats anstelle unnötiger Grafiken und Tabellen einen Teil eines voll funktionsfähigen Systems geben werden, das er selbst testen und selbst sehen kann, ob die Entwicklung in die richtige Richtung geht " [3, S.50].
In einer von Sutherland erzählten Geschichte erklärte sich der Chef bereit, es zu versuchen. Aber wir wissen, was der "Fehler der Überlebenden" ist, und wir sind uns bewusst, dass es zehn gegen einen solchen Chef gibt, der ihn von einem solchen "Projektmanager" wegschickt. Was für ein Unsinn, ehrlich gesagt Geld zu zahlen, dass "wir arbeiten und in einem Monat etwas zeigen"? Welcher Idiot macht das?
Aus Sutherlands Buch wissen wir ziemlich genau, welches: derjenige, der bereits versucht hat, das Projekt auf klassische Weise zu gestalten , und einen katastrophalen Misserfolg erlitten hat. Nur ein Führer, der in eine Ecke getrieben wird und nichts zu verlieren hat, wagt es, das Grundprinzip des Managements "Ressourcen - nur im Rahmen des Plans für ihre Verwendung" aufzugeben. Natürlich hat sich nach zwanzig Jahren mit Scrum die Einstellung zu ihm ein wenig geändert, aber auch heute laufen die meisten Gespräche „Ich werde den Begriff und den Betrag benennen, wenn ich das Team zusammenstelle und anfange zu arbeiten“ Gefahr.
Die Scrum-Ideologie widerspricht so allgemein akzeptierten Vorstellungen über das Projekt ("Der Kunde verpflichtet sich zu zahlen und der Auftragnehmer erledigt die folgenden Arbeiten ..."), dass es an der Zeit ist, die Frage zu stellen: Warum war Sutherland gezwungen, einen solchen revolutionären Schritt zu unternehmen? War es wirklich unmöglich, die Gantt-Charts „für einen Tick“ zu verlassen und sich auf die Organisation der Arbeit des Teams zu konzentrieren (zum Beispiel bei täglichen ständigen Besprechungen, bei denen viele das Wichtigste in Scrum sehen)?
Nach der Vehemenz zu urteilen, mit der Sutherland in seinem Buch "Gantt Charts" angreift, kann man nicht:
Bei der Verwaltung von Projekten sind traditionell zwei Dinge erforderlich - Verantwortlichkeit und Vorhersehbarkeit. Ein solcher Ansatz wird unweigerlich zur Entstehung einer großen Menge an Dokumentationen, Tabellen und Diagrammen führen ... Monate Arbeit werden aufgewendet, um alles bis ins kleinste Detail bereitzustellen, eine einzelne Fehlfunktion zu verhindern, finanzielle Ressourcen nicht zu überlaufen und planmäßig voranzukommen. [3, S.23] Das einzige Problem ist, dass dieser hervorragend geschliffene Plan sofort zu Staub zerfällt, sobald er mit der Realität kollidiert. Aber anstatt sowohl den Plan selbst als auch seine Herangehensweise an ihn in den Müll zu werfen, geben Manager vor, dass der Plan funktioniert ... Tatsächlich bezahlen sie die Leute dafür, dass sie sie angelogen haben . [3, S.20]
Sie bezahlen dafür, dass sie sie angelogen haben - das ist die Sache! ( « ») , . , , (« !»). :
, , , , [3, .23]
: ( ) ( ), . «», , :
( , ), , « », . : «, , , ».
— ! [9]
, « » . , , . « - » , . (« ») . , - .
? ? — . () — . — .
. , «» . , ( «»). , . , — , . , .
- [1] . « - », , -, 2007
- [2] Demarco T., Lister T. „Der menschliche Faktor: Erfolgreiche Projekte und Teams“, St. Petersburg, Symbol-Plus, 2005
- [3] Sutherland, Jeff. "Scrum. Die revolutionäre Methode des Projektmanagements “, M., Mann, Ivanov und Ferber, 2016
- [4] de.wikipedia.org/wiki/Chaos-Studie
- [5] CHAOS-BERICHT 2015
- [6] Wir haben den Feind getroffen
- [7] Putnam, Myers "Vertrautes Metrikmanagement - Klein ist wieder schön", 1998
- [8] Takeuchi, Nonaka "Neue Produktentwicklung: Neue Spielregeln" (1986), russische Übersetzung
- [9] Makovetsky P.V. "Schau dir die Wurzel an!", M., 1966