TheWhiteCode

Der Balken war grün, 80 Prozent, und das Feature existierte nicht. Nicht „fast fertig", nicht „im Review": Es gab eine Datenbanktabelle und einen Endpunkt, der immer 501 zurückgab. Die 80 Prozent waren ein Gefühl, das jemand in ein Feld getippt hatte, und danach hat es niemand mehr angefasst.

Ich habe das in einem Praktikum gesehen und mich damals über die Person geärgert, die die Zahl eingetragen hat. Heute ärgere ich mich über das Feld: Ein Eingabefeld für Prozent ist eine Einladung, eine Zahl zu erfinden.

Was ein Gantt-Balken wirklich kodiert

Ein Balken kodiert drei Dinge gleichzeitig: einen Anfang, ein Ende und die Behauptung, dass dazwischen nichts Unerwartetes passiert. Die ersten beiden sind Datumsangaben. Die dritte ist eine Aussage über die Zukunft, die niemand treffen kann, und sie wird trotzdem in derselben Schriftgröße dargestellt wie die beiden anderen.

Das Problem ist nicht die Visualisierung, sondern die Auflösung. Ein Balken hat keine Unsicherheit. Es gibt keine Variante, die „zwischen Oktober und Dezember, wahrscheinlich November" sagt, weil das nicht wie ein Plan aussieht. Also schreiben wir ein Datum, und das Datum wird kopiert, und nach dem dritten Kopieren ist es eine Zusage.

Drei Lügen, die in jedem Plan stecken

Die erste Lüge ist der Fortschritt in Prozent. Prozent wovon? Von den Aufgaben, die jemand vorher aufgeschrieben hat, und die Liste ist genau so gut wie die Person, die sie geschrieben hat. Ein Fortschritt ohne Definition von „fertig" ist eine Stimmung mit Nachkommastelle.

Die zweite Lüge ist die Abhängigkeit. Ein Pfeil von A nach B sagt, dass B auf A wartet. In der Realität wartet B auf eine Entscheidung, die in A getroffen wird, und diese Entscheidung kann man nicht einplanen, weil sie oft darin besteht, dass jemand Nein sagt. Der Pfeil sieht aus wie eine technische Beziehung und ist in Wahrheit eine soziale.

Die dritte Lüge ist der Puffer. Wer einen Puffer einplant, versteckt ihn, weil ein sichtbarer Puffer sofort gestrichen wird. Also liegt er in den Schätzungen der einzelnen Aufgaben, und niemand weiß mehr, wie viel Luft wirklich da ist. Das ist der Grund, warum Projekte „plötzlich" zwei Wochen überziehen: Die zwei Wochen waren die ganze Zeit da, nur unsichtbar.

Die rechte Spalte ist unspektakulär, und darum geht es. Eine Bandbreite ist keine schlechtere Planung, sie ist eine ehrlichere. Wer „Mitte November, plus minus zwei Wochen" sagt, wird seltener überrascht als jemand, der den 14. sagt und am 15. erklärt, warum es nicht geklappt hat.

Warum trotzdem alle Gantt mögen

Weil es schnell geht. Ein Gantt-Diagramm ist in zwanzig Minuten gebaut und sieht nach Kontrolle aus. Eine ehrliche Planung mit Bandbreiten und offenen Entscheidungen sieht nach Unsicherheit aus, und Unsicherheit muss man aushalten können, besonders wenn man sie jemandem zeigt, der ein Datum will.

Der zweite Grund ist organisatorisch: Das Diagramm ist oft nicht für das Team, sondern für die Ebene darüber. Es beantwortet die Frage „wann ist es fertig" mit einer Zahl, und eine Zahl ist leichter zu eskalieren als ein Bereich. Wer eine Zahl liefert, bekommt Ruhe; wer einen Bereich liefert, bekommt Fragen, und das ist der Grund, warum du in den meisten Planungsrunden keine Bandbreite siehst.

Deshalb funktioniert auch der moralische Appell nicht. „Seid ehrlicher" ändert nichts, solange die Belohnung für eine glatte Zahl größer ist als die für eine ehrliche Bandbreite. Was funktioniert, ist die Bandbreite zur Norm zu machen, auch bei Dingen, die sicher sind.

Was ich stattdessen mache

Ich plane in drei Zeilen pro Vorhaben: Was ist das Ergebnis, was ist die größte Unsicherheit, und was müsste passieren, damit es später wird. Die dritte Zeile ist die wichtigste, weil sie den Bereich begründet, statt ihn zu behaupten. „Später, wenn die Datenmigration länger dauert" ist eine andere Aussage als „plus minus zwei Wochen".

Die zweite Änderung ist ein Entscheidungslog, und du kannst es heute anfangen. Keine Aufgabenliste, sondern eine Liste von Entscheidungen mit Datum und Begründung. Wenn jemand in vier Wochen fragt, warum wir Format X gewählt haben, steht es dort, und niemand muss rekonstruieren, was im Meeting gesagt wurde. Das hat mir in einem Projekt mehr geholfen als jede Zeitachse, weil die meisten Verzögerungen aus übersehenen Entscheidungen kommen und nicht aus langsamer Arbeit.

Die dritte Änderung ist die Definition von fertig, und zwar vorher. Drei Sätze, die ein Außenstehender prüfen kann, ohne den Code zu lesen. Wenn du die nicht schreiben kannst, weißt du noch nicht, was du baust, und dann ist jede Schätzung geraten – auch deine.

Fazit

Eine Roadmap ist eine Geschichte über die Zukunft, und Geschichten brauchen keine Nachkommastellen. Plane mit Bereichen, benenne die Unsicherheit, die den Bereich begründet, und schreibe Entscheidungen auf, statt sie in Balken zu verstecken. Der Balken lügt nicht, er sagt nur weniger, als alle daraus lesen.

Wenn du morgen ein Datum durch einen Bereich ersetzen müsstest, welche Frage würdest du dafür beantworten müssen, und könntest du sie heute beantworten?