Wie viel Ungewissheit eine Entscheidung verträgt

Die Entscheidung, die immer noch wartet

Es gibt Entscheidungen, die auf dem Tisch liegen, seit Monaten. Nicht weil niemand zuständig ist. Sondern weil die Datenlage nicht klar genug scheint, um sie zu treffen.

Eine Maklerin kennt das: Soll sie eine Plattform einführen, über die Interessenten direkt Besichtigungstermine buchen können? Die Frage ist nicht neu. Die Antwort kommt nicht. Zuerst fehlte die Zeit, sich damit zu beschäftigen. Dann fehlten Zahlen dazu, wie viele Interessenten überhaupt anrufen und wie viele abspringen, weil niemand abnimmt. Dann war wieder Hochbetrieb.

Das ist keine Nachlässigkeit. Es ist eine rationale Reaktion auf echte Ungewissheit. Aber es ist trotzdem eine Entscheidung: die Entscheidung, es so zu lassen wie es ist.

Warten als Entscheidung verstehen

Jede Woche, in der eine Frage offen bleibt, ist eine Woche, in der die Antwort implizit „nein" lautet. Das gilt für kleine Fragen genauso wie für große.

In einem Büro für Hausverwaltung lag die Frage, ob Eigentümer Hinweise zu anstehenden Wartungen direkt erhalten sollten, fast zwei Jahre auf dem Tisch. Man wartete auf mehr Rückmeldungen. Die Rückmeldungen kamen in kleinen Dosen, nie eindeutig. Irgendwann fragte ein neuer Mitarbeiter, warum das noch nicht umgesetzt sei. Die ehrliche Antwort war: Weil wir nie entschieden haben, es nicht zu tun.

Der Unterschied zwischen „wir haben entschieden, es nicht zu tun" und „wir haben nie entschieden" ist größer als er klingt. Im ersten Fall weiß man, was man weiß. Im zweiten Fall weiß man nicht einmal das.

Was in dieser Zwischenzeit passiert

• Die Frage verstaubt nicht — sie zieht Energie, bei jedem Gespräch, das sie streift.
• Die Umgebung verändert sich. Was im Frühjahr eine mäßig dringende Frage war, kann im Herbst eine verpasste Gelegenheit sein.
• Die Datenlage verbessert sich selten von allein. Wer auf das entscheidende Signal wartet, wartet meistens auf etwas, das so nicht ankommt.

Das bedeutet nicht, dass man jede offene Frage sofort beantworten muss. Manche Entscheidungen brauchen tatsächlich mehr Zeit, weil sich etwas Relevantes verändert — ein Markt, ein Gesetz, ein Wettbewerber. Aber es lohnt sich, den Unterschied zu kennen: Wartet man auf etwas Bestimmtes — ein Datum, eine Zahl, eine Antwort von jemandem? Oder wartet man einfach?

Wenn die Antwort „einfach warten" ist, dann ist die eigentliche Entscheidung, die noch aussteht, nicht die über die Plattform oder den neuen Prozess. Sie ist die darüber, ob man bereit ist, mit dem zu entscheiden, was man hat. Das ist unbequem. Aber es ist präziser als zu glauben, dass mehr Zeit das Problem löst.

Was sich messen lässt — und was Annahme bleibt

Bevor eine Entscheidung getroffen wird, steht immer dieselbe Frage: Was wissen wir tatsächlich, und was glauben wir nur zu wissen? Der Unterschied klingt einfacher, als er in der Praxis ist.

Messbar sind Dinge, die bereits passiert sind. Wie viele Personen haben das Formular geöffnet — und wie viele haben es abgeschickt? Wie lange hat die Bearbeitung eines typischen Vorgangs gedauert, bevor die neue Lösung eingeführt wurde? Wie oft wurde eine bestimmte Funktion in einem Monat tatsächlich aufgerufen? Das sind Zahlen. Man kann sie falsch lesen, aber man kann sie nicht erfinden.

Annahmen sind alles andere. Dass Nutzerinnen und Nutzer eine neue Funktion wollen, weil drei von ihnen im Gespräch sagten, sie wäre praktisch. Dass der Prozess langsamer wird, sobald das Volumen steigt. Dass Kunden abspringen, weil das Formular zu lang ist — und nicht, weil sie grundsätzlich zögern. Das kann alles zutreffen. Aber es sind Annahmen, bis Daten es belegen.

Was wir in der Praxis erlebt haben

In einem Projekt war die Annahme, dass Anwenderinnen und Anwender die Filterfunktion kaum nutzen, weil die Eingabemaske zu unübersichtlich sei. Drei Monate nach dem Umbau zeigte die Auswertung: Die Filterfunktion wurde genauso selten aufgerufen wie zuvor. Die Eingabemaske war nicht das Problem. Die eigentliche Ursache lag an einer anderen Stelle — erkennbar erst durch Rückmeldungen aus dem laufenden Betrieb.

Das ist kein Versagen der Analyse. Es ist das normale Verhältnis zwischen Annahme und Messung: Man handelt auf Basis einer Annahme, weil man noch keine Daten hat. Dann misst man. Dann weiß man mehr als vorher.

• Messbar: Bearbeitungszeiten, Fehlerquoten, Abbruchstellen im Ablauf — sofern man sie von Anfang an aufzeichnet.
• Annahme: Warum jemand abgebrochen hat. Was jemand erwartet hat. Ob eine Funktion als nützlich empfunden wird oder nur als bequem.
• Graubereich: Befragungen, Testläufe, Piloten — sie geben Hinweise, aber sie sind keine Messung des echten Betriebs unter echten Bedingungen.

Die Schwierigkeit liegt nicht darin, den Unterschied grundsätzlich zu verstehen. Sie liegt darin, ihn in einer laufenden Diskussion durchzuhalten. Eine Annahme, die oft genug wiederholt wird, fühlt sich irgendwann wie Wissen an. Erst recht, wenn mehrere Personen sie teilen und niemand mehr fragt, woher sie eigentlich stammt.

Was geholfen hat: Jede Annahme, die eine Entscheidung trägt, bekommt einen Namen und eine Bedingung. „Wir glauben, dass X. Wir wissen es, wenn Y eingetreten ist." Kein spezielles Werkzeug dafür, kein Formular — nur die Gewohnheit, den Satz zu Ende zu sprechen, bevor man anfängt zu bauen.

Ab wann eine Annahme nicht mehr gilt

Die Frage stellt sich selten so klar, wie man es sich wünscht. Meistens gibt es kein einzelnes Ereignis, das eine Annahme widerlegt — es gibt eine Häufung von Zeichen, die sich erst im Rückblick eindeutig lesen.

Was hilft: Die Abbruchbedingung festlegen, bevor die Arbeit beginnt. Nicht nachher, wenn bereits Wochen darin stecken. Wer erst dann definiert, wann eine Annahme nicht mehr gilt, definiert es so, dass die bisherige Arbeit noch nicht umsonst war. Das ist menschlich, aber es ist nicht verlässlich.

Eine Annahme braucht ein Widerlegungskriterium

Konkret bedeutet das: Bevor etwas gebaut wird, wird eine Antwort auf die Frage aufgeschrieben, welches Ergebnis zeigen würde, dass die zugrundeliegende Annahme falsch ist. Nicht: „Wir erwarten X." Sondern: „Wenn wir nach N Wochen weniger als Y sehen, stimmt unsere Ausgangslage nicht."

Ein Beispiel: Ein Team geht davon aus, dass Nutzerinnen und Nutzer eine bestimmte Funktion über den Hauptnavigationspunkt finden. Die Annahme lautet: Mindestens 40 Prozent der Aktiven greifen in den ersten zwei Wochen darauf zu. Liegt die Zahl bei 8 Prozent, ist das kein Zeichen für schlechtes Marketing — es ist ein Zeichen dafür, dass der Einstiegspunkt falsch gewählt war. Wer dieses Kriterium vorher aufgeschrieben hat, erkennt das in zwei Wochen. Wer es nicht aufgeschrieben hat, diskutiert es noch nach zwei Monaten.

Der Unterschied zwischen „noch nicht" und „nicht"

Viele Annahmen halten sich, weil man sie mit „noch nicht" lesen kann. Das Produkt ist noch nicht bekannt genug. Der Markt ist noch nicht bereit. Die Nutzerinnen und Nutzer haben sich noch nicht umgestellt. Das stimmt manchmal — und manchmal ist es die Geschichte, die man sich erzählt, um weiterzumachen.

Unterscheiden lässt sich beides durch die Art des Signals. Wenn einzelne Nutzerinnen die Funktion aktiv suchen und nicht finden, ist das etwas anderes als wenn niemand danach sucht. Wenn Anfragen kommen, aber nicht die erhofften, deutet das auf ein anderes Problem als vollständige Stille. Das Muster — nicht der einzelne Datenpunkt — ist das, was zählt.

Wir haben einmal eine Exportfunktion drei Monate lang weiterentwickelt, weil die Nutzungszahlen nicht stiegen und wir davon ausgingen, dass das an der Oberfläche lag. Irgendwann haben wir direkt gefragt. Die Antwort war: Die Leute exportierten nicht, weil sie die Daten anders weiterverarbeiteten als wir angenommen hatten. Die Funktion löste ein Problem, das in dieser Form nicht existierte. Drei Monate Arbeit, die sich das hätte sparen können — nicht, wenn man früher aufgehört hätte, sondern wenn man früher gefragt hätte, ob das überhaupt das richtige Problem ist.

Wann eine Annahme als widerlegt gilt

Eine grobe Orientierung: Wenn drei unabhängige Signale in dieselbe Richtung zeigen, ist das kein Zufall mehr. Ein Signal kann Rauschen sein. Zwei können sich gegenseitig bestätigen. Drei unabhängige Quellen — Nutzungsdaten, ein direktes Gespräch, eine Supportanfrage — ergeben ein Muster, das belastbar genug ist, um eine Annahme zu verwerfen.

• Das erste Signal wird notiert, aber noch nicht gehandelt.
• Das zweite Signal macht das erste nicht mehr zur Ausnahme.
• Das dritte Signal ist der Moment, in dem „noch nicht" aufhört, eine Erklärung zu sein.

Das bedeutet nicht, dass man sofort abbricht. Es bedeutet, dass man aufhört, das Gegenteil zu behaupten. Eine Annahme, die widerlegt ist, aber trotzdem als Grundlage weiterer Entscheidungen dient, ist teurer als die Arbeit, die bereits in ihr steckt.

Was ein Irrweg am Ende kostet

Der teuerste Moment ist nicht der, in dem man merkt, dass eine Annahme falsch war. Der teuerste Moment ist vier Monate davor — als man es hätte merken können, aber nicht hingeschaut hat.

Ein konkretes Beispiel aus der eigenen Arbeit: Wir haben für ein Buchungssystem eine Funktion entwickelt, die Kunden an bevorstehende Termine erinnert. Drei Entwicklungswochen. Die Annahme war, dass Nutzer ihre Termine vergessen. Die tatsächliche Ursache für Ausfälle war eine andere: Kunden erschienen nicht, weil ihnen der Termin nicht mehr passte — und sagten nichts, weil Absagen unangenehm sind. Eine Erinnerungsfunktion löst das nicht. Wir haben sie trotzdem gebaut, weil wir die Frage nie gestellt hatten.

Was kostet das? Drei Wochen Entwicklung, eine Funktion, die niemand braucht, und ein Problem, das weiterhin ungelöst ist. Das ist der direkte Preis.

Der indirekte Preis ist schwerer zu beziffern. In denselben drei Wochen hätte das Team an etwas anderem gearbeitet — etwas, das die eigentliche Frage beantwortet hätte. Irrwege verschieben nicht nur den Fortschritt. Sie verschieben die Aufmerksamkeit. Wer gerade etwas baut, stellt keine Fragen mehr, ob es das Richtige ist.

Wenn Arbeit sich ansammelt, die niemand mehr anfasst

Irrwege hinterlassen Gewicht. Eine Funktion, die nicht genutzt wird, bleibt im System. Sie muss mitgepflegt werden, taucht in Unterlagen auf, nimmt Platz ein. Irgendwann entscheidet jemand, sie zu entfernen — das kostet noch einmal Zeit, diesmal für Rückbau statt Aufbau.

In einem anderen Projekt haben wir ein Auswertungsmodul entwickelt, das auf Annahmen über die Informationsbedürfnisse der Nutzenden basierte. Die Zahlen, die es auswarf, interessierten niemanden. Die Zahlen, nach denen tatsächlich gefragt wurde, waren im System gar nicht erfasst. Ergebnis: ein halbes Jahr Entwicklung, ein Modul, das still deaktiviert wurde, und eine Datenlücke, die das Team erst zwei Jahre später schließen konnte. Der Rückbau war dabei das Geringste. Schlimmer war, was in dieser Zeit nicht entstanden ist.

Wenn der Irrweg eine eigene Logik entwickelt

Manche Fehlentscheidungen lassen sich früh korrigieren, ohne dass viel verloren geht. Ein Konzept, das nach einem ersten Gespräch eine andere Richtung nimmt. Das schmerzt kurz, kostet wenig.

Andere Irrwege ziehen Folgeentscheidungen nach sich. Eine Grundentscheidung, die auf einer falschen Annahme beruht, bindet das, was danach kommt. Irgendwann ist der Aufwand, den Weg zu verlassen, scheinbar größer als der Aufwand, ihn zu Ende zu gehen — und genau das passiert dann auch. Der Irrweg wird fertiggestellt, weil Abbruch teurer wirkt als Weiterfahren. Was teurer wirkt, ist aber nicht dasselbe wie was teurer ist.

• Drei Wochen für eine Funktion, die niemand nutzt: direkter Verlust, sichtbar im nächsten Statusgespräch.
• Drei Wochen, in denen die eigentliche Frage offenbleibt: indirekter Verlust, der sich erst später in der Roadmap zeigt.
• Ein Jahr auf einer falschen Grundlage gebaut: struktureller Verlust, der beim Umbauen vollständig sichtbar wird.

Die Unterscheidung zwischen diesen drei Arten ist nicht akademisch. Sie bestimmt, wann es sich lohnt, einen Irrweg zu beenden — und wann das Weiterfahren tatsächlich die günstigere Entscheidung ist. Wer das nicht auseinanderhält, rechnet an der falschen Stelle.

Das Signal, das zu spät kommt

Es gibt eine Situation, die sich in vielen Projekten gleich anfühlt: Man hat eine Annahme getroffen, Wochen oder Monate danach gearbeitet, und dann kommt endlich das Signal. Die erste klare Rückmeldung. Der Moment, in dem man weiß. Nur kommt dieser Moment meistens dann, wenn das Wissen nichts mehr ändert.

Das liegt selten an Unachtsamkeit. Es liegt daran, dass manche Signale strukturell erst spät erscheinen. Eine Entscheidung über den Aufbau eines Arbeitsprozesses zeigt ihre Folgen erst, wenn dieser Prozess täglich von zwanzig Personen genutzt wird — nicht von zweien. Eine Entscheidung über die Art, wie Anfragen sortiert und priorisiert werden, zeigt erst im Volumen, ob sie trägt. Zwei Testnutzer sagen: Passt so. Zweihundert zeigen, was wirklich nicht geht.

Die trügerische Ruhe der ersten Wochen

In den ersten Wochen nach einer Einführung ist die Rückmeldung fast immer positiv. Die ersten Nutzer — intern oder extern — sind in aller Regel die, die eine neue Lösung begrüßen. Sie haben auf die Veränderung gewartet, sie probieren alles aus, sie melden Kleinigkeiten. Das fühlt sich nach Bestätigung an. Es ist meistens keine.

Das Signal aus der zweiten und dritten Welle — Menschen, die das System nutzen müssen, nicht wollen — kommt erst, wenn es läuft. Und bis dahin ist man längst weitergegangen: Der nächste Bereich ist halb fertig, die nächste Entscheidung ist schon gefällt.

In einem eigenen Projekt haben wir eine Hauptnavigation dreimal überarbeitet, bevor wir verstanden haben, warum sie nicht funktionierte. Das erste Mal nach internem Feedback. Das zweite Mal nach den ersten zehn Nutzerinnen. Das dritte Mal, nachdem die Auswertung der Nutzungsdaten belegte, was uns einzelne Gespräche nie klar gemacht hätten: dass ein bestimmter Bereich systematisch gemieden wurde, weil er nicht dort war, wo die Leute ihn erwarteten. Dieses Signal existierte ab dem ersten Tag. Aber es brauchte Volumen, um sichtbar zu werden.

Wenn das Signal kommt, ist der Preis schon gezahlt

Das eigentliche Problem ist nicht, dass das Signal spät kommt. Das eigentliche Problem ist, was in der Zwischenzeit entschieden wurde. Jede Entscheidung, die auf der falschen Annahme aufgebaut wird, zieht die nächste nach sich. Wenn man erst beim dritten oder vierten Baustein merkt, dass der erste nicht stimmte, ist die Frage nicht mehr: Bauen wir das um? Die Frage ist: Wie viel müssen wir abreißen, damit das, was darüber steht, noch steht?

Das ist der Punkt, an dem ein verzögertes Signal seinen eigentlichen Preis zeigt. Nicht die Stunden, die man in die falsche Annahme gesteckt hat. Sondern die Entscheidungen, die seither darauf aufgebaut wurden.

• Ein Bericht, der seit Wochen automatisch erstellt wird — nach einem Schema, das sich jetzt als falsch erweist.
• Eine Arbeitsroutine, die das Team um die neue Lösung herum aufgebaut hat — und die sich mit ihr nicht mehr hält.
• Entscheidungen über die nächsten Schritte, die alle auf dem Baustein aufsetzen, der nicht stimmt.

Das lässt sich nicht verhindern, solange man mit unvollständigen Informationen arbeitet — und das tut man immer. Was sich ändern lässt, ist der Abstand zwischen Entscheidung und erstem messbarem Feedback. Ein kurzer Abstand bedeutet nicht weniger Irrtümer. Er bedeutet, dass der Irrtum greifbar wird, bevor man drei weitere Entscheidungen darauf gestapelt hat.