Stellen Sie sich das Landen eines Flugzeugs vor. Bei einer guten Landung befindet sich das Flugzeug danach in einer Position, die den nächsten Start erleichtert – zum Beispiel sind die Tragflächen noch dran, das Fahrwerk funktionstüchtig und die Crew am Leben. Man braucht jetzt nur mehr Kerosin, einen Flugplan und ein Sandwich für den Piloten. Das Ende eines Meilensteins sollte ähnlich ablaufen. Je größer der Anflugwinkel ist, wenn Sie einen Meilenstein abschließen, desto größer ist die Wahrscheinlichkeit, dass sich das Projekt nach dem Abschluss des Meilensteins in einem nicht so guten Zustand befindet.

Anflugwinkel

Der einfachste Zeitplan für Entwicklungsprojekte kann in ein schlichtes Diagramm umgewandelt werden, das in Abbildung 15-3 zu sehen ist. Diese Zeichnung geht davon aus, dass die Fortschrittsrate konstant ist und das Projekt genau den Zeitplan erfüllen wird, wenn es diese Rate beibehält. Das ist natürlich Wunschdenken. Dieses Diagramm wird nie die Realität widerspiegeln, da der Fortschritt und die Effizienz des Teams nicht konstant sind (aus vielen Gründen, die in diesem Buch schon beschrieben wurden).

Abbildung 15-3: Das ist der einfachste Meilenstein-Zeitplan der Welt, mit idealen Annahmen, die auf Wunschdenken basieren.

Stattdessen enden die meisten Projekte so, wie es in Abbildung 15-4 dargestellt ist. Zu einem bestimmten Zeitpunkt bemerkt das Team, dass die Arbeit nicht schnell genug vorangeht. Das kann daran liegen, dass neue Arbeit hinzugekommen ist (siehe den Abschnitt »Änderungen managen (Change Control)« in Kapitel 14) oder die Schätzungen des Teams nicht zutreffen. Egal aus welchem Grund es passiert ist, das Team steht nun vor einer Entscheidung: Wie kann das Ziel noch erreicht werden? Es gibt nur drei Möglichkeiten:

• 1. Den Zeitplan nicht einhalten.Verschieben Sie das Abschlussdatum nach hinten, um das neue Wissen über die Fortschrittsrate einzubauen.
• 2. Den Winkel ändern.Überzeugen Sie sich selbst davon, dass Sie das Team dazu bringen können, schneller zu arbeiten, um die Lücke noch zu schließen (bereiten Sie sich also auf eine Bruchlandung vor). Sie können das versuchen, müssen aber einen Preis dafür bezahlen. Das Risiko, Fehler zu machen, ist größer, und das Team wird beim Start des nächsten Arbeitszyklus müder und ausgelaugter sein.
• 3. Den Termin mit dem, was man hat, einhalten.Ermitteln Sie die Features oder Arbeitspakete, in denen noch die meiste restliche Arbeit oder das höchste Risiko steckt. Dann nehmen Sie sie entweder aus dem Plan heraus und verschieben sie auf den nächsten Meilenstein (wenn es einen gibt), oder Sie ignorieren die Qualität und geben sie so heraus, wie sie sind (schluck).

Abbildung 15-4: Die Wirklichkeit des Zeitplans stimmt häufig nicht mit der Planung überein. Die Abschlusskriterien entscheiden dann, wie man etwas dagegen tun kann.

Welche Wahl getroffen wird, sollte vollständig von den Abschlusskriterien abhängen. Das ist genau die Situation, die am meisten davon profitiert, wenn man genaue Vorstellungen davon hat, wie ein Meilenstein enden soll. Anstatt die Kriterien jetzt, mitten im Stress einer schwierigen Landung, auszuarbeiten, müssen Sie nur einen Blick zurück werfen und die Kriterien anpassen, die Sie Wochen zuvor erstellt haben. Entscheidungen in schwierigen Endspielsituationen lassen sich leichter treffen, wenn es Referenzkriterien gibt, mit denen das Team schon vertraut ist.

Warum das Ändern des Winkels nicht funktionieren kann Wenn wir die Flugzeuganalogie nochmals verwenden, sorgt das Ändern des Winkels, um mit der restlichen Zeit hinzukommen, dafür, dass das Ganze instabil wird. Projekte lassen sich wie Flugzeuge nicht sehr gut beherrschen, wenn sie sich mit hoher Geschwindigkeit abwärts bewegen. Es gibt zu viele Dinge, die man gleichzeitig machen muss, als dass man bei dieser Geschwindigkeit stabil bleiben könnte. Wenn Sie sich in einem Flugzeug befinden, das sich der Landebahn nähert, und Sie feststellen, dass der Anflug nicht funktionieren kann, drehen Sie ab und starten einen neuen Versuch (die Landebahn zu verschieben ist, anders als bei Terminen, nicht möglich). Bei schlechtem Wetter starten Verkehrsflugzeuge im Zweifel durch und wiederholen den Anflug. Projekte haben damit meistens Probleme. Sie sind eher wie Flugzeuge mit zu wenig Treibstoff: Es gibt nur genug Ressourcen für einen Versuch. In solchen Fällen gehen vernünftige Piloten sehr vorsichtig und vorausschauend vor. Vernünftige Projektmanager sollten das Gleiche tun. Wenn Ihr Termin oder die Features nicht verschoben werden können (wie eine Landebahn), müssen Sie mit der Planung für die Landung früher beginnen.

Warum es schlimmer wird

Ein grundlegendes psychologisches Prinzip bestimmt, wie die meisten Menschen ihre Arbeit priorisieren. Wenn alle Dinge gleich sind, tendieren sie dazu, Dinge zu vermeiden, die sie nicht machen wollen.4 Das bedeutet, dass mit fortschreitender Zeit die schwierigen und unliebsamen Arbeitspakete oder Fehlerkorrekturen übrig bleiben. Und selbst wenn die verbleibende Arbeit wahnsinnig viel Spaß macht, Teams aber dafür belohnt werden, wie viele Fehler sie pro Tag oder Woche beheben, gibt es einen natürlichen Druck, Fehler auszuwählen, die sich leicht lösen lassen, um die Quote zu erfüllen.

Am Ende der Meilensteine neigen die Mitarbeiter dazu, ermüdet, frustriert und gestresst zu sein – Bedingungen, die zu geringerer Leistung führen. Schwierige Fehler, die nicht eindeutig in einen Bereich fallen, wandern in der Regel bis zum Schluss des Zeitplans in einem Entwicklungsteam hin und her (die »heiße Fehlerkartoffel«). Ein Programmierer schaut sich einen dieser Fehler an, erkennt, dass er schwer zu lösen ist, spürt den Druck seiner restlichen Arbeit und weist den Fehler einer anderen Person zu, die möglicherweise dafür verantwortlich sein kann. Wie Weinberg schreibt: »… Probleme werden nicht gelöst, sie kreisen bloß herum.« Selbst die besten Programmierer erliegen dieser ganz natürlichen Versuchung von Zeit zu Zeit.

Das Verschieben schwieriger Arbeit gilt ebenfalls beim Suchen von Fehlern – auch wenn dahinter keine psychologischen Gründe stecken. Fehler, nach denen man länger suchen muss oder die erst später innerhalb des Projekts erscheinen, sind meist diejenigen, die am kompliziertesten sind5 (wie in Abbildung 15-5 zu sehen). Bei komplexen Fehlern, die aber eine niedrige Priorität haben, ist das nicht so schlimm, aber bei denen mit hoher Priorität ist diese Tendenz ein ernsthaftes Problem. Es dauert nicht nur durchschnittlich länger, sie zu finden, es ist auch mehr Zeit nötig, um sie zu lösen. Die in Abbildung 15-4 gezeichneten geraden Linien sind beide falsch: Ein Projekt nähert sich einem Termin im Ergebnis nahezu asymptotisch und sieht eher so aus wie in Abbildung 15-6. Das Team arbeitet vielleicht so hart wie zuvor, aber die Ergebnisse – bezüglich des Fortschritts auf die Ziele hin – lassen nach. Je näher Sie an Ihrem Termin sind, desto mehr trifft das zu.

Abbildung 15-5: Schwierigere Fehler werden häufig erst später im Projekt entdeckt und behoben. Das bedeutet, dass der Anflugwinkel keine gerade Linie ist, sondern eine Kurve, die gegenüber dem Fortschritt angeglichen ist (siehe Abbildung 15-6).

Abbildung 15-6: Ein generisches, aber realistisches Diagramm für den Anflugwinkel, wobei ein konstanter Aufwand des Teams angenommen wird.

Ein grober Leitfaden für den Anflugwinkel

Der Anflugwinkel für Meilensteine oder Projektabschlüsse ist kein Geheimnis. Wie bei allen anderen Aufgaben, die mit dem Zeitplan zu tun haben (siehe Kapitel 2), gibt es bestimmte Überlegungen, die daran mitwirken, wie exakt ein Anflugwinkel sein wird. Hier sind die wichtigsten Faktoren, die man bedenken muss:

• Schauen Sie sich frühere Leistungen des Teams und des Projekts an. Um den Winkel zu planen, untersuchen Sie, wie gut sich das Team im Endspiel früherer Projekte ähnlicher Art geschlagen hat. Bei Projekten mit mehreren Meilensteinen schauen Sie sich die geplanten im Vergleich zu den tatsächlichen Verlaufskurven früherer Meilensteine an (nicht schummeln: verwenden Sie den ursprünglichen Plan und den letztlich realen Zeitplan). Nehmen Sie, egal was Sie tatsächlich vermuten, an, dass die zu planenden Meilensteine viel schwerer zu erreichen sein werden als die vorangegangenen es waren. Wenn Sie keinerlei Daten haben, auf deren Basis Sie den Anflugwinkel berechnen können, warum glauben Sie dann, Sie würden bei seiner Planung mehr tun als einfach nur schätzen? Wenn Sie schätzen müssen, schätzen Sie zurückhaltend.
• Machen Sie ordentliche Schätzungen. Der Winkel ist nur eine weitere Schätzaufgabe beim Zeitplan. Holen Sie sich die entsprechenden Personen zusammen, teilen Sie die verbleibende Arbeit in Aufgaben auf, diskutieren Sie Risiken und Annahmen und ermitteln Sie schließlich Schätzungen. Wenn er sonst nichts bringt, sorgt dieser Ablauf wenigstens dafür, dass das letztendliche Vorgehen als Teamaufwand gesehen wird, bei dem die Mitarbeiter das Gefühl haben, dass sie am Prozess beteiligt wurden und den Winkel gemeinsam definiert haben. Die Moral wird dabei den Winkel unterstützen, anstatt gegen ihn zu arbeiten.
• Planen Sie eine sanfte Kurve, keine gerade Linie. Planen Sie, auch ohne Daten zu haben, ein, dass die Fortschrittsrate sinken wird, wenn die Anzahl der Fehler steigt (siehe Abbildung 15-6). Gehen Sie davon aus, dass die Arbeit schwieriger abzuschließen sein wird, je näher Sie der Deadline kommen. Arbeiten Sie mit Kurven, nicht mit Linien.
• Planen Sie eine sanfte Kurve, keine gerade Linie. Planen Sie, auch ohne Daten zu haben, ein, dass die Fortschrittsrate sinken wird, wenn die Anzahl der Fehler steigt (siehe Abbildung 15-6). Gehen Sie davon aus, dass die Arbeit schwieriger abzuschließen sein wird, je näher Sie der Deadline kommen. Arbeiten Sie mit Kurven, nicht mit Linien.
• Nutzen Sie eine Blackbox. Wenn nichts anderes geht, stellen Sie sicher, dass die echten Leistungsdaten erfasst werden (siehe nächster Abschnitt). Nach der Bruchlandung haben Sie dann Beweise dafür, was falsch gelaufen ist, und besitzen nun gute Argumente für Anpassungen im nächsten Projekt oder Meilenstein.

Wie es weiter geht, wie Sie ihre Projekte realistisch planen und Teams effektiv führen, erfahren Sie in dem Buch Die Kunst des IT-Projektmanagements.