Sie haben also ein Projekt mit einer sich ständig ändernden Teamgröße und Ihr Chef möchte, dass Sie ihm eine genaue Schätzung über die Dauer des Projekts geben? Das können Sie tun, solange Sie den Unterschied zwischen genau und präzise nicht aus den Augen verlieren. Ihre Genauigkeit hängt weitgehend von der Anzahl der Elemente und der Granularität (Untergliederung) der einzelnen Elemente ab. Je mehr Elemente Sie haben, desto mehr wirkt das Gesetz der großen Zahlen für Sie, das Über- und Unterschätzungen ausgleicht.
Ihre Genauigkeit ist eine Funktion des Vertrauens. Beachten Sie, dass Schätzungen keine Ein-Punkt-Werte sind, sondern eine Spanne mit Zahlen und einem prozentualen Vertrauensbereich. Eine korrekte Schätzung wäre zum Beispiel nicht "2 Wochen", sondern "mit 50%iger Sicherheit 2 Wochen, mit 80%iger Sicherheit 4 Wochen".
Wenn ich die Person wäre, die mit der wenig beneidenswerten Aufgabe betraut ist, eine Schätzung bis zur Fertigstellung für ein Projekt abzugeben, das so willkürlich verwaltet wird wie im ursprünglichen Beitrag, würde ich versuchen, eine Spanne auf der Grundlage der Mindestanzahl der zugewiesenen Personen zu ermitteln (z.B. "48 bis 66 Wochen bei 2 Entwicklern [50 % bis 80 % zuversichtlich]") und eine Spanne in Verbindung mit der durchschnittlichen Anzahl der zugewiesenen Personen (z.B., "25 bis 45 Wochen mit 5 Entwicklern [50 % bis 80 % zuversichtlich]"), und verwenden Sie die niedrige Zahl der durchschnittlichen Zahl zusammen mit der hohen Zahl der Mindestzahl (z. B. "25 bis 66 Wochen mit 2 bis 5 Entwicklern [50 % bis 80 % zuversichtlich]"), und selbst dann würde ich einen Haftungsausschluss einfügen ("plus 10 % für die verlorene Zeit aufgrund von Kontextwechsel").
Besser noch, ich würde genau erklären, warum dieses Arrangement, um es höflich auszudrücken, suboptimal war und warum Multitasking ein Hauptwegweiser auf dem Weg zur Projekthölle ist.
Wie jemand anderes vorgeschlagen hat, könnte es eine gute Strategie sein, den Arbeitsablauf von iterationsbasiert auf flussbasiert (Kanban) umzustellen. Bei Kanban werden Änderungen der Projektprioritäten durch Änderung der Priorität der Elemente im Rückstand behandelt; sobald ein Element vom Team in Angriff genommen wurde, ist es im Allgemeinen fertig (es fließt den ganzen Weg durch den Arbeitsablauf, die Beteiligten dürfen das Team nicht stören, indem sie an der laufenden Arbeit herumschrauben). Ich habe Kanban für nachhaltige technische Projekte verwendet und es hat sehr gut funktioniert. Zur Frage, wie es bei Schätzungen helfen würde: Der Schlüssel zu einem kontinuierlichen Fluss liegt darin, dass jedes Arbeitsobjekt ungefähr die gleiche Größe hat (1x, 2x, 3x, nicht 10x, 20x, 100x). Sie sollten die Bewegung der Elemente durch den Arbeitsablauf verfolgen, indem Sie die Daten der Prozesszustandsänderungen verfolgen, z. B. Warteschlange 1/15, Entwurf 1/22, Entwicklung 1/24, Test 2/4, Integration 2/7 usw., und dann regelmäßig ein kumulatives Flussdiagramm erstellen, um die Dauer der Zustandsänderungen im Laufe der Zeit zu bewerten. Die Berechnung, wie lange das Projekt dauern sollte, wenn man die Größe der einzelnen Elemente und die Zeit durch den Workflow für die Elemente kennt, ist eine triviale Rechenaufgabe, die dem Leser überlassen bleibt. (Die interessantere Frage ist, wie man Einschränkungen erkennt ... und wie man sie dann beseitigen kann. Tipp: Achten Sie auf lange Zeiten in den Zuständen, da sich die Arbeit vor den Beschränkungen stapelt.)
