Ich werde die Frage aus der Perspektive des Software-Engineerings behandeln, obwohl viele der gewonnenen Erkenntnisse auch für andere Projekte gelten. Das Erstellen genauer Projektschätzungen ist eine der schwierigsten Aufgaben im Software-Engineering und eine oft übersehene Fähigkeit, die die meisten Ingenieure (mich eingeschlossen) nicht gut beherrschen. Es ist auch der Fall, dass Personen, die die Fertigstellungszeiten für Projekte noch nicht schätzen mussten, die Schwierigkeit unterschätzen und ihre Schätzungen häufig um mindestens den Faktor zwei falsch einschätzen. Wie jede Fähigkeit wird man nur mit Übung besser.
Meine lebhafteste Erinnerung an schiefgelaufene Projektschätzungen entstand einige Monate nach meinem Eintritt als Ingenieur bei Ooyala, einem Startup, das eine End-to-End-Online-Videoplattform bereitstellte. Im August 2008, nur etwas mehr als ein Jahr nach der Gründung des Unternehmens, begann das Engineering-Team mit der Neufassung des Flash-basierten Videoplayers des Produkts. Unser Ziel war es, den Player modularer und performanter zu machen und eine sauberere und besser getestete Codebasis zu haben. Ein anfängliches Team von 3 Personen entwarf und schrieb einige Kerninfrastrukturen, bevor ich und der Rest des ~ 10-köpfigen Engineering-Teams hinzugezogen wurden. Sie schätzten 4 Monate für den Abschluss des Projekts, und der CTO und der Produktmanager erstellten Gantt-Diagramme, die den Projektstrukturplan und die Abhängigkeiten zusammenfassen. Der neue Player wurde 9 Monate später im Mai 2009 vollständig gestartet .
Wir haben das Ziel nicht aus Mangel an harter Arbeit oder talentierten Ingenieuren verfehlt; Es gab eine Reihe von Monaten, in denen die meisten Leute im Team 70-80 Stunden Wochen zogen (nicht empfohlen). Auf halbem Weg durch das Projekt haben wir sogar mühsam ein paar Tage lang Übungen durchgeführt, bei denen wir ziemlich detaillierten Aufgaben Stundenschätzungen zugewiesen haben. Die größten Verzögerungen resultierten fast immer aus Faktoren, viele extern, dass wir in den ersten Schätzungen nicht berücksichtigt haben:
- high priority customer deals being signed that required engineers to context switch to custom work,
- Fehler im Flash Player-Code von Adobe, die es schwierig machten, genau zu bestimmen, wann das Video tatsächlich angehalten, gepuffert und abgespielt wurde,
- schwer zu reproduzierende Videobeschädigung Fehler, die den Player zum Absturz bringen würden, wenn bestimmte Videobilder im IE gesucht werden,
- Produktentwicklung muss fortgesetzt werden 4 monate in das Projekt, um den aktuellen Kundenstamm zufrieden zu halten,
- Skalierbarkeitsprobleme, die als die Menge von analysedaten wuchsen,
- Ein früher Ingenieur verließ das Team mitten im Projekt und erforderte einen großen Wissenstransfer über wichtige Teile der Codebasis,
- usw.
Während das Umschreiben des Players für das Unternehmen definitiv notwendig war, forderte die unvorhergesehene Art und Weise, in der dies geschah, einen großen Tribut vom frühen Start. Andere Projekte, an denen ich gearbeitet habe, aus zweiter Hand gesehen oder mit anderen Ingenieuren darüber gesprochen habe, sind ähnlichen Mustern gefolgt, bei denen die tatsächliche Fertigstellungszeit die ursprünglichen Schätzungen oft verdoppelt.
Hier sind einige meiner bisherigen Lektionen zum Mitnehmen aus diesen Erfahrungen:
Lassen Sie die Personen, die die Schätzungen für eine Aufgabe erstellen, so weit wie möglich die tatsächlichen Personen sein, die daran arbeiten werden. Dies ähnelt Ian McAllisters Standpunkt, die B-Player-Schätzung zu verwenden – es ist bereits unglaublich schwierig für eine Person, genau vorherzusagen, wie lange eine Liste von Aufgaben dauern würde, selbst wenn die Aufgaben ziemlich genau sind; Es ist noch schwieriger vorherzusagen, wie lange es jemand anderes mit einem anderen Grad an Vertrautheit und einem anderen Grad an Fähigkeiten brauchen würde. Während des Neuschreibens von Ooyala wurde deutlich, dass viele der anfänglichen Schätzungen extrem aggressiv waren und die Anlaufzeit eines Ingenieurs für Teile der Codebasis ignorierten, mit denen er weniger vertraut war.
Vorsicht vor dem Effekt des zweiten Systems. In The Mythical Man-Month beschreibt Frederick Brooks aus seinen Projekterfahrungen bei IBM, wie eine menschliche Tendenz, das zweite System zu überdesignen, zu einer erheblich erhöhten Komplexität führt, wodurch die Zeitpläne von Redesign-Projekten verrutschen :
Die erste Arbeit eines Architekten ist spärlich und sauber. Er weiß, dass er nicht weiß, was er tut, also tut er es sorgfältig und mit großer Zurückhaltung.
Als er das erste Werk entwirft, fallen ihm Rüsche um Rüsche und Verschönerung um Verschönerung ein. Diese werden gespeichert, um „beim nächsten Mal“ verwendet zu werden.“Früher oder später ist das erste System fertig, und der Architekt ist mit festem Vertrauen und einer nachgewiesenen Beherrschung dieser Klasse von Systemen bereit, ein zweites System zu bauen.
Diese Sekunde ist das gefährlichste System, das ein Mensch je entworfen hat… Die allgemeine Tendenz besteht darin, das zweite System zu übergestalten und dabei alle Ideen und Schnickschnack zu verwenden, die beim ersten System vorsichtig abgelenkt wurden.
Insbesondere für ein Projekt, bei dem vorhandene Software neu geschrieben wird, ist es verlockend, eine Reihe neuer Funktionen in einem ansonsten unkomplizierten Port zu bündeln, wobei das Argument verwendet wird, dass das Team dies genauso gut tun könnte, wenn sie die Codebasis sowieso neu schreiben. Die erhöhte Komplexität kann dazu führen, dass weder das Umschreiben noch die neuen Funktionen erst wesentlich später gestartet werden.
Seien Sie vorsichtig, wenn Sie die Zeit, die die Aufgaben eines Projekts in Anspruch nehmen, mit der Zeit bis zum Abschluss eines Projekts vergleichen. Je länger ein Projekt dauert, desto höher ist die Wahrscheinlichkeit, dass externe Umgebungsvariablen ins Spiel kommen und den gesamten Projektzeitplan verlängern. Das wiederkehrende Ziehen, das Ian erwähnt, trägt zur Zeitleiste eines Projekts bei, aber auch unerwartete Ereignisse. Für Projekte, an denen ich Anfang dieses Jahres bei Quora gearbeitet habe, dauerte der Start einiger Projekte aufgrund der kumulierten Zeitkosten von länger als erwartet:
- Reaktion auf und Wiederherstellung nach einem unerwarteten, mehrtägigen AWS-Ausfall,
- Umgang mit periodischen Pager-Pflichtalarmen, um die Site am Laufen zu halten,
- geplante Ferien, die einst weit von einem Projekt entfernt zu sein schienen, sich aber letztendlich damit überschnitten,
- Vorbereitung auf und Teilnahme an Rekrutierungsveranstaltungen,
- Kontextwechsel zwischen mehreren Projekten, die es stellte sich als schwieriger heraus als ursprünglich erwartet.
Für jedes Projekt könnte man wahrscheinlich eine beliebige Anzahl von Ereignissen und Ablenkungen auflisten, die einzeln unwahrscheinlich oder unkostbar sind, die aber kollektiv passieren müssen und sich über einen ausreichend langen Zeitraum summieren. Je länger das Projekt dauert, desto mehr Ablenkungen wird es geben, und es ist wichtig, Pufferzeit für externe, unbekannte Faktoren einzuplanen.
Budgetieren Sie ausreichend Zeit für integrationsrelevante Aufgaben. Insbesondere bei Projekten mit vielen miteinander verbundenen Komponenten neigen viele Ingenieure dazu, 1) End-to-End-Integrationsaufgaben bis zum Ende zu verschieben und 2) den Zeitaufwand für die Integration aller Teile in ein funktionierendes System erheblich zu unterschätzen. Da die Integration in der Regel so weit entfernt ist und die Risiken in der Regel unbekannt sind – die Annahme bei der Integrationszeit ist, dass alle Komponenten erfolgreich isoliert arbeiten -, ist eine Unterschätzung der Integrationszeit ziemlich häufig. Projekten wird oft nur ein winziger Bruchteil der gesamten Projektzeit für End-to-End-Tests zugewiesen, obwohl dies in der Regel einer der riskanteren Aspekte eines Projekts ist und im Vergleich zu früheren Meilensteinen wesentlich mehr Kommunikationsaufwand zwischen Teammitgliedern erfordert.
Die logische Konsequenz daraus ist, so früh wie möglich mit End-to-End-Tests zu beginnen, um Integrationsrisiken und -probleme früher zu identifizieren, damit genügend Zeit bleibt, sie anzugehen.
Schätzen Sie basierend darauf, wie lange Aufgaben tatsächlich dauern, nicht basierend darauf, wie lange Sie oder jemand anderes möchten, dass sie dauern. Es wird immer Druck geben, Projekte schneller abzuschließen, entweder von Ihnen selbst, von Ihren Teammitgliedern, vom Management oder von Kunden, und oft verankert uns die emotionale Reaktion auf diesen Druck an extern geforderten Zeitplänen und führt dazu, dass wir Aufgaben systematisch unterschätzen. Psychologisch möchte niemand andere Menschen im Stich lassen, und es ist leicht, sich selbst zu sagen, dass Sie eine bestimmte Frist einhalten können, wenn Sie nur etwas härter oder effizienter arbeiten. Gerade bei langen Projekten ist diese Art des Wunschdenkens aber letztlich untragbar.
Überprüfen und überarbeiten Sie die Projektschätzungen regelmäßig im Verlauf des Projekts. So wie die meisten guten Software gebaut und schrittweise verbessert, so sind auch Projektschätzungen. Die Überprüfung von Projektschätzungen und der Vergleich von Schätzungen für Aufgaben in der vergangenen Woche mit der tatsächlich in Anspruch genommenen Zeit helfen, Schätzfehler aufzudecken und Zeitpläne basierend auf zuvor unvorhergesehenen Risiken zu überarbeiten.
Projektschätzungen neigen fast immer dazu, eher unterschätzt als überschätzt zu werden; Man hört selten von langen Projekten, die vorzeitig abgeschlossen werden. Wenn Sie sich bewusst sind, dass die Projektschätzung schwierig ist, und darüber nachdenken, warum die Schätzungen bei einem bestimmten Projekt schief gelaufen sind, können Sie kleinere Schätzfehler bei nachfolgenden Projekten vermeiden.
Die Ausführung eines Projekts umfasst viel mehr als nur die Erstellung genauer Schätzungen. Wenn Sie ein Ingenieur sind und Techniken beherrschen möchten, die von Top-Software-Ingenieuren verwendet werden, um ihre Projekte in Erfolge umzuwandeln, laden Sie ein kostenloses Beispielkapitel meines Buches The Effective Engineer herunter. Es ist vollgepackt mit Hunderten von Geschichten, Erkenntnissen und umsetzbaren Strategien von Führungskräften aus dem ganzen Silicon Valley.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html