Schätzung der Projektlaufzeit. Warum ist es fast immer sehr untertrieben und was tun?

Bei der Berechnung der Projektlaufzeit bewerten wir traditionell die Dauer der Zwischenschritte, fassen sie dann zusammen und fügen einen Puffer für alle Arten von Unfällen hinzu. Dann halbiert uns die Führung in dieser Zeit. Im Rahmen dieses Hinweises wird der Autor an unseren Berechnungen interessiert sein, da selbst ein Projektmanager mit umfassender Erfahrung häufig versteht, dass der berechnete Zeitraum zu kurz ist und manchmal zu viel im Widerspruch zu seiner persönlichen Experteneinschätzung steht. Ja, er wird die Schätzungen der Projektbedingungen und Zwischenschritte zu seiner Expertenbewertung korrigieren und mit wahrer Beherrschung einiger Verarbeitungszeiten die Frist mit einer Genauigkeit von 15% einhalten, aber das Sediment bleibt erhalten.

In diesem Hinweis wird der Grund für die Diskrepanz zwischen Experten- und theoretisch berechneten Schätzungen erläutert. Es wird auch berücksichtigt, warum die „überbewertete“ Expertenbewertung normalerweise unterschätzt wird, wenn sie nicht auf der Grundlage von Statistiken über die Durchführung ähnlicher Projekte erfolgt. Am Ende wird gezeigt, wie die Projektlaufzeit korrekt berechnet und den Interessenten vor Projektbeginn oder während des Projekts die Situation erklärt werden kann.

Die Wurzel des Fehlers

Wenn wir den Implementierungszeitraum einer Arbeit bewerten, bestimmen wir die wahrscheinlichste Zahl. Es kann sich um eine Expertenbewertung zu einem Punkt oder zu drei Punkten handeln, wie bei PERT. In einem komplexen Projekt kann dies eine parametrische Modellierung sein. In allen Fällen machen wir den gleichen Fehler. Tatsache ist, dass bei allen klassischen Schätzmethoden angenommen wird, dass wir eine Normalverteilung des geschätzten Wertes haben - nach Gauß. Theoretiker lieben diese Verteilung sehr.

Normalverteilung bedeutet, dass ein Projekt mit einer korrekt geschätzten Dauer von 6 Monaten mit gleicher Wahrscheinlichkeit in 9 Monaten oder 3 Monaten abgeschlossen wird. Bei gleichen Abständen vom Verteilungszentrum ist die Wahrscheinlichkeit des Abschlusses des Projekts gleich - dies ist ein Merkmal der Gauß-Kurve. Andererseits sahen in der Praxis nur wenige Menschen ein IT-Projekt, das doppelt so schnell abgeschlossen wurde (nach 3 Monaten), aber Projekte, die sich anderthalb Mal verzögerten (9 Monate), sehen wir regelmäßig. Darüber hinaus würde bei einer Normalverteilung die Hälfte unserer Projekte vor der geschätzten Zeit und die Hälfte danach enden. Dies wird aber auch in der Praxis nicht beobachtet. Dies deutet darauf hin, dass die Normalverteilung für die Schätzung von Fristen nicht anwendbar ist. Das heißt, wir haben keine Normalverteilung, sondern eine andere mit unterschiedlicher Wahrscheinlichkeit der Fertigstellung vor und nach dem wahrscheinlichsten Datum.

Betrachten Sie die logarithmische Normalverteilung als Beispiel für eine solche Verteilung. Es zeigt uns die Merkmale dieser Verteilungsklasse. Für die logarithmische Normalverteilung liegen der Median und die mathematische Erwartung deutlich über dem Peak:



In der dargestellten Grafik zeigt der Peak die größte Wahrscheinlichkeit des Abschlussdatums des Projekts. Diese Zahl enthält normalerweise diese Zahl plus einen bestimmten Spielraum. Der Median gibt einen Trennungspunkt an, an dem die Hälfte der Projekte vor Ablauf dieser Frist und die zweite Hälfte danach abgeschlossen wird. Die mathematische Erwartung gibt den Durchschnittswert der Projektdauer an. Für ein Arbeitsfragment weist die Verteilung dieselben Merkmale auf: einen großen Unterschied zwischen dem am meisten erwarteten Zeitraum für die Implementierung des Arbeitsfragments (Pläne basieren traditionell darauf) und dem Durchschnittswert des Begriffs.

Um die Dauer des Projekts vorherzusagen, bestimmen wir die längste Kette in der Zeit und addieren die Dauer seiner Fragmente. Wenn wir die nach Gauß verteilten Werte addieren, sollte im Durchschnitt der richtige Endterm erhalten werden. In der Tat wird die Hälfte der Fragmente der Arbeit vorzeitig fertiggestellt, die Hälfte später, und diese Heterogenitäten werden sich gegenseitig aufheben. Je mehr Fragmente vorhanden sind, desto genauer werden die Inhomogenitäten kompensiert. Außerdem können wir den Fehler berechnen und die Frist je nach den Folgen der Frist um ein oder zwei Sigma verschieben.

Wir haben aber keine Gaußsche Verteilung. In unserem Land ist es viel wahrscheinlicher, die Ausführungszeit für jedes Werk zu verlängern, als es um den gleichen Betrag zu verkürzen. Wenn wir also die Fristen für die wahrscheinlichste Fertigstellung jedes Werks hinzufügen, werden die Heterogenitäten in Bezug auf die Fertigstellung nicht kompensiert, sondern verstärkt. Darüber hinaus verstärken sie sich in Richtung einer Verlängerung der realen durchschnittlichen Laufzeit des Projekts im Vergleich zur Schätzung. Was wir im wirklichen Leben beobachten: Wenn der erste Begriff überfällig ist, sind alle anderen Begriffe überfällig, während die Verzögerung nur zunimmt. Nur durch zusätzliche Anstrengungen kann die Projektverzögerung gestoppt werden.

Ein Merkmal dieser Berechnungsmethode ist eine bekannte Tatsache: Je kleiner die Fragmentierung der Arbeit zur Beurteilung der Projektdauer ist, desto ungenauer ist die Schätzung. Obwohl theoretisch genau das Gegenteil der Fall sein sollte. Der Grund dafür ist, dass unsere Expertenbewertung für die gesamte Arbeit und für ihre Bestandteile aus Erfahrung stammt. Die Erfahrung bewertet jedes Element unabhängig und nicht arithmetisch, wonach die Dauer der Arbeit die Summe der Dauer seiner Bestandteile sein sollte. Arithmetik funktioniert hier nicht, da die Summe der wahrscheinlichsten Fristen für die Fertigstellung von Teilen nicht die wahrscheinlichste Frist für die Fertigstellung aller Arbeiten ergibt - nur mathematische Erwartungen können korrekt summiert werden.

Wenn wir versuchen, den geschätzten Term für das gesamte Projekt oder seine Teile geringfügig um ein oder zwei Sigma zu verschieben, wobei die Verteilung als normal angesehen wird, hilft dies nicht viel, da der Verteilungsende viel dicker als die Gaußsche Kurve ist. Infolgedessen kann man aufgrund einer solchen Erhöhung der Laufzeitschätzung nicht einmal den Median erreichen, ganz zu schweigen vom Durchschnittswert der Projektdauer in Form einer mathematischen Erwartung.

Was zu tun ist

Einerseits sollten mathematische Erwartungen hinzugefügt werden. Andererseits sind wir keine Mathematiker. Wir kommen aus dem wirklichen Leben und verstehen das Problem der Berechnung der Parameter von Graphen, selbst wenn dafür Zeit und einige akkumulierte Statistiken Zeit sind. Es gibt aber auch andere Möglichkeiten. Am Ende hat das Problem, den Zeitpunkt von mehr als einem Dutzend Jahren einzuschätzen, und die Praktiker gelernt, damit zu arbeiten.

Brooks-Methode : Wir betrachten den Implementierungszeitraum des Programms als „frontal“ (der Benutzer ist der Programmierer selbst) und multiplizieren mit 3 für das Softwareprodukt (der Benutzer ist ein unbegrenzter Personenkreis) oder den Softwarekomplex (in der aktuellen Realität - eine Reihe von Mikrodiensten) und 9 für das Systemsoftwareprodukt ( in der gegenwärtigen Realität eine Reihe verwandter Infrastrukturkomponenten). Woher diese Koeffizienten kommen, ist im ersten Kapitel von Brooks 'Buch Mythical Man-Month theoretisch gut begründet, und diese Beschreibung von 1975 ist gut auf die aktuellen Realitäten verschoben.

Scrum-Methode : Wir führen eine abstrakte Zwischeneinheit der Komplexität der Implementierung der Funktion ein, betrachten die Statistik der Implementierung der Funktion, die in den angegebenen Einheiten der Funktion gemessen wird, und bitten das Team, die Komplexität der Projektaufgaben zu bewerten, die Einheiten in die Scrum-Iteration (Sprints) bekannter Länge zu übersetzen und eine Schätzung der Begriffe für dieses Entwicklungsteam zu erhalten. Da wir mit tatsächlich gesammelten Statistiken arbeiten und das Team für die Schätzung der Komplexität verantwortlich ist, ist die Bindung der Dauer an die Arbeitseinheit eine mathematische Erwartung, und daher endet die Hälfte der Sprints etwas früher, die Hälfte etwas später. In der Praxis muss das Team in halben Iterationen von Scrum an den Aufgaben teilnehmen und in der Hälfte ungeplante Aufgaben hinzufügen, damit die Sprintlänge konstant bleibt.

Die Aufgabe, die Scrum-Bewertung eines Teams auf ein anderes Team zu übertragen, ist eine Kunst. Sie können nicht einfach durch Einführen eines Umrechnungsfaktors für die Arbeitseinheiten eines Teams in die Arbeitseinheiten des anderen Teams übertragen werden. Tatsache ist, dass ein Team ein gutes Front-End in seiner Zusammensetzung hat, aber keinen guten Basisspezialisten, und das andere Team einen guten Basisspezialisten, aber die Front-Line-Aufgaben dafür sind von zunehmender Komplexität. Unterschiede in der Spezialisierung der Entwickler führen dazu, dass in Bezug auf Backend-Aufgaben ein Team eine übermäßige Komplexität in Bezug auf Aufgaben in der Datenbank und das andere auf der Vorderseite aufweist. Darüber hinaus bestimmt das Team selbst das erforderliche Niveau der internen Qualität des Produkts, und verschiedene Teams bestimmen es auf etwas andere Weise als die benachbarten Teams, was es auch schwierig macht, Arbeitseinheiten neu zu berechnen. Das heißt, es ist möglich, die Zwischeneinheiten eines Teams in die Zwischeneinheiten eines anderen Teams zu übersetzen, indem Schätzungen ähnlicher Aufgaben verglichen werden. Diese Aufgaben sollten jedoch aus verschiedenen Arten von Aktivitäten übernommen werden, wobei die Stärken und Schwächen der Teams zu berücksichtigen sind und die Besonderheiten der Einrichtung ihres Scrums zu berücksichtigen sind.

Funktionselementmethode : Wir führen eine Zwischeneinheit des Arbeitseinsatzes ein, erstellen eine Liste der Funktionselemente (Bildschirme in einem Browser, Microservices, benutzerdefinierte Infrastrukturelemente usw.) und schätzen den Arbeitsaufwand für jedes Funktionselement in Zwischeneinheiten. Anschließend bewerten wir basierend auf unserer Expertenerfahrung in der Arbeit mit einem bestimmten Entwicklungsteam den Umrechnungsfaktor der Zwischeneinheit über die Zeit. Persönlich bewerte ich die Umrechnungsfaktoren für verschiedene Arten von Aktivitäten immer noch unabhängig voneinander: Analyse, Entwerfen, Schreiben von Aufgabenanweisungen, Schreiben von Code, Layout, Testen, Integration usw. Danach sollte die Reihenfolge der Operationen, die charakteristische Zeitverzögerung zwischen dem Abschluss der vorherigen Operation und dem Beginn einer neuen Operation berücksichtigt und die Dauer des Projekts durch die Methode des kritischen Pfades bestimmt werden.

Bisher haben wir mit den internen Faktoren des Projekts gearbeitet. Wir haben aber auch externe: externe Auftragnehmer, verwandte Abteilungen, Lieferanten und den Kunden. Die Probleme mit ihnen sind genau die gleichen: Sie reagieren zweimal oder schneller oder seltener als eineinhalb Mal länger als der wahrscheinlichste Wert. Das heißt, es gibt auch keine normale Zeitverteilung. Dies sollte auch auf der Grundlage von Statistiken über die Arbeit mit Kunden, Auftragnehmern und verwandten Einheiten festgelegt und berücksichtigt und, wenn möglich, mit Hilfe von Strafen geschützt werden.

Zeitliche Rechtfertigung

Daher haben wir die geplante Projektdauer geschätzt. Wie kann man die erhaltene Frist rechtfertigen? Basierend auf den durchgeführten Berechnungen. Beispielsweise erstellt der Autor einer Notiz für Nicht-Scrum-Projekte in Google Sheets normalerweise eine große mehrzeilige visuelle Tabelle mit einer detaillierten Berechnung nach der Methode der Funktionselemente. Die Berechnung basiert auf der Praxis, alle Koeffizienten und Parameter sind visuell, und die Praxis für interessierte Parteien ist normalerweise ein starkes und gutes Argument, auch wenn sich herausstellt, dass es für bestimmte Personen eine unangenehme Zeit ist. Insbesondere ist die Praxis visuell und wird im Rahmen des aktuellen Unternehmens erlangt.

Werden Stakeholder wie das Management einer gut gemachten und gut informierten Zeitplanbewertung zustimmen? Nicht immer, auch wenn die Interessenten die Einschätzung vollständig verstehen und erkennen. Manchmal ist die Bewertung aus externen Gründen nicht akzeptabel, aber dies ist bereits ein Schmerz für die interessierten Parteien, was zu einer schwierigen Entscheidung des Managements über den Zeitpunkt führt. Wenn die Berechnungen jedoch auf Erfahrung basieren, haben das Management und andere interessierte Kreise die Möglichkeit, die endgültige Laufzeit des Projekts vorhersehbar zu beeinflussen, indem zusätzliche Ressourcen und Befugnisse zugewiesen werden. Manchmal verkürzt das Management, das die Zeitsituation versteht, weiterhin die Fristen, ohne zusätzliche Ressourcen und Befugnisse zuzuweisen. Wie man damit lebt, ist das Thema einer separaten Notiz.