Wie viel Gewissheit braucht eine Entscheidung?

Wenn keine Zahl hilft und trotzdem entschieden werden muss

Es gibt Situationen, in denen man nicht mehr rechnen kann. Nicht weil die Zahl fehlt, sondern weil das, worüber man entscheidet, noch nicht existiert. Kein Vergleich, kein Vorjahr, kein Markt, den man ausmessen könnte. Der Bereich ist neu, das Verhalten der Nutzer unbekannt, und wer fragt, bekommt Meinungen, keine Fakten.

Die erste Versuchung in solchen Momenten ist, länger zu warten. Noch ein Gespräch führen. Noch einen Monat beobachten. Das Warten fühlt sich nach Sorgfalt an. Meistens ist es Vermeidung.

Was bleibt, wenn die Zahlen schweigen

Was man hat, sind Beobachtungen. Nicht gemessene, sondern erinnerte. Ein Kunde, der im Gespräch dieselbe Frage stellt wie drei andere Kunden vor ihm. Eine Funktion, die jemand auf eine Art verwendet, die niemand vorgesehen hatte. Ein Muster, das sich benennen lässt, auch wenn man es nicht belegen kann.

Wir haben einmal eine Funktion gebaut, weil drei Personen in Kundengesprächen dasselbe Problem beschrieben hatten. Keine Umfrage, keine Messung — nur drei Gespräche und ein Muster, das sich nicht ignorieren ließ. Die Funktion wurde genutzt. Aber wir wussten im Moment der Entscheidung nicht, ob das drei Ausnahmen oder drei Stellvertreter waren. Wir haben es hinterher nicht aufgeschrieben. Das war der eigentliche Fehler: nicht die Entscheidung, sondern das Vergessen, was sie getragen hatte.

Das ist die eigentliche Schwierigkeit: nicht das Fehlen einer Zahl, sondern das Fehlen eines Maßstabs für das, was man stattdessen heranzieht.

Wie weit Erfahrung trägt

Erfahrung hilft. Sie hilft, weil man ähnliche Situationen erkannt hat und weiß, wie sie ausgingen. Aber sie verführt auch, weil man neue Situationen als bekannte liest und dabei übersieht, was anders ist.

Wir haben einmal eine technische Weichenstellung auf Basis früherer Projekte getroffen, ohne zu bemerken, dass das neue Projekt andere Anforderungen an das Wachstum hatte. Die Erfahrung war echt. Die Übertragung war falsch. Wir haben das erst acht Wochen später gemerkt, als das, was früher funktioniert hatte, hier ins Stocken geriet. Bis dahin hatten wir auf einem Fundament weitergebaut, das nicht trug.

Erfahrung ist ein Hinweis, kein Beweis. Wer sie als Beweis behandelt, schützt eine Annahme, anstatt sie zu prüfen.

Die kleinste Entscheidung, die man noch korrigieren kann

Was hilft, ist nicht ein besseres Gefühl. Was hilft, ist die Frage: Was ist die kleinste Version dieser Entscheidung, die ich treffen kann, ohne mich auf Jahre festzulegen?

Nicht: Bauen wir das? Sondern: Bauen wir genug davon, um in sechs Wochen zu wissen, ob es sich lohnt, weiterzubauen? Nicht: Stimmt unsere Annahme? Sondern: Woran würden wir in drei Monaten merken, dass sie falsch war — und was hätten wir bis dahin investiert?

Das klingt wie ein Kompromiss. Es ist keiner. Es ist der Versuch, eine Entscheidung zu treffen, die man noch korrigieren kann, bevor man in einer Situation steckt, in der Korrigieren teurer ist als Durchhalten. Wer diese Grenze nicht zieht, zieht sie trotzdem — nur unbemerkt, irgendwo in der Mitte.

Was man dabei aufgibt, ist die Gewissheit. Die hatte man nie. Man gibt auf, so zu tun, als hätte man sie.

Was sich in Zahlen fassen lässt — und was nicht

Wenn ein Entwicklungsteam entscheidet, welches Feature als nächstes gebaut wird, beginnt die Diskussion meistens mit Zahlen. Wie viele Nutzer haben diesen Bereich zuletzt geöffnet? Wie lange dauert dieser Schritt im Schnitt? Wie oft schlägt er fehl? Diese Fragen sind legitim, und die Antworten sind echt — soweit die Daten reichen.

Das Problem ist nicht, dass Teams zu wenig messen. Das Problem ist, was das Messen verspricht, das es nicht halten kann.

Was sich tatsächlich abbilden lässt

Nutzungsfrequenz lässt sich messen. Wie oft eine Funktion aufgerufen wird, zu welcher Tageszeit, von wie vielen verschiedenen Konten — das liegt vor. Fehlerquoten liegen vor. Abbruchraten an bestimmten Stellen liegen vor. Zeitspannen zwischen zwei Ereignissen liegen vor.

Das sind keine Meinungen, das sind Beobachtungen. Sie sagen: Hier passiert etwas — oder: Hier passiert es nicht. Wer sich auf diese Zahlen stützt, beschreibt Verhalten. Nicht Absicht.

Was sich nicht abbilden lässt

Warum jemand aufgehört hat, lässt sich nicht messen. Ob der Abbruch an Verwirrung lag, an Zeitmangel, an einer Ablenkung oder an dem Entschluss, die Anfrage doch nicht zu stellen — das steht in keinem Protokoll. Eine Zahl sagt, dass jemand gegangen ist. Was ihn bewogen hat, bleibt offen.

Genauso wenig lässt sich messen, was Nutzer wollten, aber nie versucht haben. Wer eine Funktion nie aufgerufen hat, hinterlässt keine Spur. Das ist der blinde Fleck jeder Nutzungsauswertung: Sie erfasst, was getan wurde — nicht, was gesucht und nicht gefunden wurde.

In einem Projekt haben wir über mehrere Monate beobachtet, dass eine bestimmte Funktion kaum genutzt wurde. Die Zahl war eindeutig: unter drei Prozent aller aktiven Konten. Wir schlossen daraus, dass Bedarf fehlt. Später — in einem Gespräch, das eigentlich über etwas anderes ging — stellte sich heraus, dass die Funktion an einer Stelle saß, die niemand ohne Anleitung gefunden hätte. Die Zahl hatte recht: Sie wurde nicht genutzt. Warum, stand nicht drin.

Ähnliches gilt für Zufriedenheitswerte. Eine hohe Bewertung sagt, dass niemand laut unzufrieden war. Sie sagt nicht, ob die Erwartung niedrig war, ob der Nutzer aufgegeben hatte, bevor er zur eigentlichen Aufgabe kam, oder ob er einfach nicht wusste, was möglich gewesen wäre. Stille ist keine Zustimmung — sie ist nur Stille.

Die Versuchung, alles in eine Zahl zu fassen

Je mehr Daten vorliegen, desto größer wird die Versuchung, eine Entscheidung vollständig daraus abzuleiten. Das fühlt sich sicherer an. Es ist auch sicherer — im engsten Sinne: Wer auf eine Zahl zeigt, hat eine Antwort auf die Frage, warum er so entschieden hat. Ob die Zahl die richtige Frage beantwortet, ist eine andere Sache.

Zahlen beschreiben den Zustand. Den Grund kennen sie nicht. Wer eine Entscheidung auf eine Zahl stützt, ohne zu fragen, was die Zahl nicht sehen kann, behandelt eine Beobachtung als Erklärung. Das ist kein Fehler im Werkzeug — es ist ein Fehler im Umgang damit.

Wie lange darf eine Annahme halten

Eine Annahme hat kein Verfallsdatum, das man ihr ansieht. Sie altert still. Wer nicht aktiv nachfragt, merkt oft erst im Rückblick, dass sie schon Monate falsch war.

In unserem Arbeitsalltag treffen wir Annahmen über Dinge, die wir nicht messen können: wie oft jemand eine Funktion nutzen wird, welche Frage sie zuerst stellt, welches Problem für sie dringend ist. Diese Annahmen sind keine Nachlässigkeit — sie sind der einzige Weg, anzufangen, wenn keine Daten vorliegen.

Das Problem ist nicht die Annahme selbst. Es ist der Moment, in dem sie aufhört, als Annahme behandelt zu werden.

Der stille Übergang zur Gewissheit

Es gibt einen Übergang, den wir selbst mehrfach erlebt haben. Eine Annahme wird getroffen, eine Entscheidung darauf gebaut — und dann folgen Wochen, in denen niemand die Annahme in Frage stellt. Nicht weil Daten sie bestätigt hätten, sondern weil kein Feedback kam. Kein Widerspruch, kein Hinweis, keine Reaktion. Stille wird als Bestätigung gelesen, obwohl sie nur Stille ist.

Wir haben einmal eine Oberfläche auf die Annahme gebaut, dass Nutzer ein bestimmtes Dokument immer in einer bestimmten Reihenfolge abarbeiten würden. Acht Monate lang hielten wir daran fest. Dann zeigte eine einfache Nachfrage, dass die meisten Nutzer mitten im Dokument einsteigen — an einer Stelle, die wir für einen Zwischenpunkt gehalten hatten. Die Annahme war nicht falsch am ersten Tag. Sie war ungeprüft am achten Monat.

Was eine Annahme altern lässt

Nicht jede Annahme altert gleich schnell. Drei Faktoren bestimmen, wie lange eine Annahme stabil bleibt:

Wie viel hat sich verändert, seitdem sie gemacht wurde? Eine Annahme über das Verhalten einer Bestandskundin trägt länger als eine über neue Interessenten, die unter ganz anderen Umständen kamen.
Wie viel baut auf ihr? Je mehr Folgeentscheidungen sich auf eine Annahme stützen, desto länger bleibt sie unbefragt — und desto teurer wird die Korrektur, wenn sie fällt.
Wie leicht wäre sie zu prüfen? Annahmen, die schwer zu überprüfen sind, halten sich am längsten. Nicht weil sie stimmen, sondern weil niemand anfängt.

Die gefährlichste Annahme ist nicht die unwahrscheinlichste. Es ist diejenige, die alle für selbstverständlich halten, weil niemand sie je ausgesprochen hat.

Was wir zu spät eingeführt haben

Wenn wir heute eine Annahme treffen, notieren wir dazu: unter welchen Umständen würden wir sie verwerfen? Eine Zahl, ein Ereignis, ein Zeitraum. Nicht weil das garantiert, dass wir die Annahme zum richtigen Zeitpunkt ablösen — sondern weil es den Moment des Treffens vom Moment des Verwerfens trennt. Beides bleibt eine Entscheidung, aber die zweite wird nicht mehr durch Gewohnheit getragen.

Was wir unterschätzt haben: wie selten diese Frage gestellt wird, wenn man im Tagesgeschäft steckt. Eine Annahme aus dem dritten Sprint wird im achten nicht mehr nachgeschlagen. Sie ist einfach da. Wer sie anfasst, riskiert Diskussion und Verzögerung. Das ist kein Fehler einzelner Personen. Es ist eine strukturelle Eigenheit des Betriebs — und sie betrifft nicht nur Softwareentwicklung.

Annahmen halten so lange, wie man sie hält. Das ist der unbequeme Teil: keine externe Kraft löst sie ab. Man muss selbst fragen, ob sie noch trägt — und das zu einem Zeitpunkt, zu dem noch alles funktioniert.

Ab welchem Punkt kippt die Annahme

Eine Annahme kippt nicht, wenn sie widerlegt wird. Sie kippt, wenn man aufhört, sie zu schützen.

Der Unterschied ist kleiner als er klingt. Wer eine Annahme getroffen hat — "die Nutzerinnen werden das Formular so ausfüllen, wie wir es gebaut haben" —, sucht danach in der Regel nach Belegen, die sie bestätigen. Das erste Dutzend, das das Formular korrekt ausfüllt, gilt als Beweis. Die drei, die es abbricht, gelten als Ausreißer. Diesen Mechanismus kennt jeder, der schon einmal ein Projekt bewertet hat, das er selbst mitentwickelt hat.

Wir haben gelernt, vorab festzulegen, was eine Annahme zu Fall bringt — nicht im Nachhinein. Das klingt methodisch, ist aber vor allem ein Schutz vor dem eigenen Urteil.

Zwei Arten von Signalen

Das erste Signal ist direkt: Ein Nutzer tut nicht, was man erwartet hat. Das zweite ist indirekt: Ein Nutzer tut das Erwartete, aber das Ergebnis bleibt aus. Beides ist gleich bedeutsam, wird aber unterschiedlich behandelt — das Direkte fällt auf, das Indirekte lässt sich erklären.

Ein Beispiel aus unserem Arbeitsalltag: Wir hatten angenommen, dass eine bestimmte Funktion vor allem spät im Ablauf aufgerufen wird — nach mehreren Schritten, wenn jemand bereits tief im Prozess steckt. Die Nutzungsdaten zeigten das Gegenteil: Sie wurde früh aufgerufen, oft als erstes. Die Funktion selbst funktionierte. Aber sie war für den falschen Moment gebaut worden. Das hatte Folgen für alles, was danach kam: die Texte, die Reihenfolge, die Hilfestellungen.

Das Direkte hätten wir schnell gesehen. Das Indirekte hat länger gebraucht, weil die Zahl, auf die wir geschaut haben — wie oft wird die Funktion aufgerufen —, keine Auskunft darüber gab, wann im Ablauf das passiert.

Die Frage, die man stellt, bevor man baut

Vor einer Entscheidung hilft eine einzige Frage mehr als jede Methode: Was müsste ich sehen, damit ich diese Annahme aufgebe?

Nicht: Was könnte sie bestätigen. Sondern: Was würde reichen, damit ich sie verwerfe?

Wenn man keine Antwort findet — wenn die Annahme so gebaut ist, dass kein Ergebnis sie entkräften kann —, ist das kein Zeichen von Stärke. Es ist ein Zeichen, dass sie nicht als Annahme behandelt wird, sondern als Entschluss.

Eine Annahme über Nutzerverhalten kippt, wenn ein zweites Segment zeigt, was das erste angeblich nicht konnte — und man trotzdem weiter das erste als Referenz nimmt.
Eine Annahme über Nachfrage kippt, wenn das Signal, auf das man gewartet hat, ausbleibt — nicht erst, wenn man sich dafür eine neue Erklärung zurechtgelegt hat.
Eine Annahme über Priorität kippt, wenn jemand aus dem Team aufhört, die Frage zu stellen, weil die Antwort schon feststeht.

Das letzte ist das schwierigste zu messen. Aber es ist oft das erste Signal, dass eine Annahme nicht mehr hinterfragt wird — sondern nur noch verteidigt.

Was falsche Annahmen wirklich kosten

Der offensichtliche Preis ist Arbeitszeit. Sechs Wochen Entwicklung, die auf einer Annahme aufbauen, die sich im siebten Monat als falsch herausstellt — das sind sechs Wochen, die nicht zurückkommen. Aber das ist selten der teuerste Teil.

Teurer ist meistens, was in diesen sechs Wochen nicht gebaut wurde. Wer auf der falschen Annahme aufbaut, trifft gleichzeitig Folgeentscheidungen: Er wählt eine Richtung, die zur Annahme passt. Er schließt Wege aus, die er für unnötig hält. Er erklärt einem Auftraggeber, dass eine bestimmte Funktion nicht vorgesehen ist — weil die Annahme das so ergab.

Wenn der Irrweg sich verzweigt

In einem Projekt haben wir früh angenommen, dass Nutzer die Software überwiegend am Desktop bedienen würden. Die ersten Gesprächspartner bestätigten das. Die Annahme hielt neun Monate. Als sie kippte — gemessen, nicht vermutet — waren Teile des Systems gebaut, die auf kleinen Bildschirmen schlicht nicht funktionierten. Das war kein Fehler im Einzelnen. Es war eine Entscheidung, die sich verzweigt hatte.

Der Aufwand, das rückgängig zu machen, lag höher als der ursprüngliche Aufwand. Nicht weil die Arbeit schlecht war, sondern weil inzwischen andere Teile des Systems darauf aufgebaut hatten. Man räumt dann nicht einen Raum aus — man räumt ein Fundament aus, auf dem schon Wände stehen.

Kosten, die nicht in der Rechnung stehen

Falsche Annahmen kosten auch Vertrauen — beim eigenen Team und beim Auftraggeber. Wer zweimal erlebt, dass eine sichere Einschätzung nicht stimmte, fragt beim dritten Mal kritischer nach. Das ist richtig so. Aber es verlangsamt Entscheidungen, die keine große Absicherung bräuchten. Ein Team, das zweimal falsch lag, wird vorsichtiger — auch dort, wo Vorsicht nichts bringt.

Arbeitszeit, die nicht recycelt werden kann
Folgeentscheidungen, die auf dem falschen Fundament ruhen
Externe Kommunikation, die zurückgenommen werden muss
Vertrauen, das sich nicht mit einer Erklärung wiederherstellen lässt

Was sich in unserer Praxis gezeigt hat: Die Annahmen, die am teuersten wurden, waren nicht die großen strategischen. Es waren die mittleren — konkret genug, um Entscheidungen zu treiben, abstrakt genug, um nie wirklich überprüft zu werden. „Die meisten Nutzer werden X tun" ist eine solche Annahme. Sie klingt bescheiden. Sie steuert trotzdem monatelange Arbeit. Und sie ist selten aufgeschrieben, weil sie sich wie eine Selbstverständlichkeit anfühlt — bis sie es nicht mehr ist.