Was eine Annahme kostet, bevor man sie aufgibt

Drei Monate für eine Funktion, die niemand brauchte

Es gibt Projekte, bei denen man hinterher genau sagen kann, wann der Irrtum begann. Nicht wann er auffiel – das kommt später, oft viel später –, sondern wann die Annahme, auf der alles aufbaute, hätte hinterfragt werden müssen.

Bei einem dieser Projekte war es ein Nutzerverhalten, das wir vorausgesetzt hatten, ohne es je gesehen zu haben. Wir bauten eine Funktion für einen Ablauf, den wir für selbstverständlich hielten. Der Ablauf existierte. Die Funktion funktionierte. Nur: Niemand durchlief ihn so, wie wir gedacht hatten.

Das wussten wir nicht sofort. Das wussten wir drei Monate lang nicht.

Was messbar war – und was wir für wahr hielten

In jedem Projekt gibt es Dinge, die sich belegen lassen, und Dinge, die man glaubt zu wissen. Der Unterschied zwischen beidem ist nicht immer sofort erkennbar – vor allem dann nicht, wenn das Geglaubte aus Erfahrung stammt, aus ähnlichen Projekten, aus Gesprächen mit Nutzern. Erfahrung erzeugt Überzeugung. Überzeugung erzeugt Annahmen. Und Annahmen fühlen sich, wenn sie lange genug ungeprüft stehen, wie Wissen an.

Was wir tatsächlich wussten

Wir wussten, dass Nutzer die Funktion aufriefen. Die Aufrufe ließen sich zählen. Wir wussten, welche Schritte sie durchliefen und wo sie abbrachen. Wir wussten, was Nutzer uns in drei Gesprächen gesagt hatten: dass dieser Schritt „wichtig" sei, dass sie ihn „regelmäßig" bräuchten, dass sie sich eine einfachere Variante wünschten.

Das war alles, was wir wussten.

Was wir annahmen

Wir nahmen an, dass „wichtig" und „regelmäßig" bedeuteten, dass die Funktion häufig und zielgerichtet genutzt würde. Wir nahmen an, dass die Abbrüche technische Ursachen hatten. Wir nahmen an, dass die drei Gespräche repräsentativ waren für alle anderen.

Keine dieser Annahmen war absurd. Keine war belegt. Der Unterschied zwischen beidem war uns zu dem Zeitpunkt nicht klar genug.

Wie eine Annahme zur Tatsache wird

Annahmen haben eine eigentümliche Eigenschaft: Je länger sie unwidersprochen stehen, desto schwerer lassen sie sich bewegen. Nicht weil mehr Belege für sie vorliegen, sondern weil um sie herum Arbeit entstanden ist. Entscheidungen wurden auf ihnen aufgebaut. Andere Annahmen folgen aus ihnen.

Eine Annahme, die drei Wochen alt ist, ist eine Arbeitshypothese. Eine, die drei Monate alt ist, ist im täglichen Gespräch fast zur Tatsache geworden – und wird auch so behandelt. Nicht aus Nachlässigkeit. Aus dem normalen Bedürfnis, weiterzumachen, während man arbeitet.

Das gilt in Entwicklungsteams. Es gilt genauso überall dort, wo Entscheidungen unter unvollständiger Information getroffen werden: wer welches Angebot weiterentwickelt, welche Dienstleistung beworben wird, welche Kunden man priorisiert. Die Mechanik ist dieselbe.

Die ruhigen Wochen vor dem ersten Zeichen

Es gab Wochen, in denen nichts Auffälliges passierte. Die Funktion wurde genutzt – nicht so oft wie erwartet, aber genutzt. Das genügte. In einem aktiven Projekt gibt es immer genug zu tun; eine Funktion, die nicht dramatisch versagt, gerät aus dem Fokus.

Das ist der ruhigste Teil eines Irrwegs. Keine Alarmzeichen, keine Krisen – nur Zeit, die vergeht. Und Arbeit, die sich auf etwas aufbaut, das noch niemand laut in Frage gestellt hat.

Das erste Signal

Es kam nach etwa sechs Wochen. Eine Nutzerin schickte eine kurze Rückmeldung: Sie würde die neue Version „gelegentlich" verwenden, aber meistens doch den alten Weg nehmen.

Wir interpretierten das als Gewöhnungsfrage. Der alte Weg war vertraut, die neue Version noch neu. Das stimmte. Es war auch eine Erklärung, die uns erlaubte, weiterzumachen.

Das zweite Signal kam zwei Wochen später. Die Nutzungszahlen stiegen nicht. Sie stiegen überhaupt nicht.

Im Team wurde das besprochen. Jemand meinte, es brauche Zeit. Jemand anderes fragte, ob man die Funktion besser kommunizieren müsste. Man einigte sich darauf, einen Monat zu warten und die Zahlen dann neu zu bewerten.

Warum man nicht aufhört, wenn es Zeit wäre

Das ist die Frage, die uns danach länger beschäftigt hat als die Frage, wie wir die Funktion hätten besser bauen können.

Es ist keine Frage der Fähigkeit. Die Leute im Team, die entschieden hatten weiterzumachen, konnten rechnen. Sie hatten die Zahlen gesehen. Sie hatten die Rückmeldung gehört. Sie hatten beides erklärt – auf eine Weise, die vorläufig plausibel war und die ursprüngliche Annahme intakt ließ.

Das Erklären ist das eigentliche Problem. Nicht weil Erklärungen falsch wären. Sondern weil man für jede abweichende Beobachtung eine Erklärung finden kann, solange man sich nicht entschieden hat, die Annahme selbst zu prüfen.

Die entscheidende Frage ist nicht, ob das erste oder zweite Signal eine Erklärung hatte. Die Frage ist, wie viele Signale nötig sind, bevor man nicht länger die Signale erklärt – sondern die Annahme.

Was das Signal war, das schließlich zählte

Es war keine neue Erkenntnis. Es war die Summe. Nach drei Monaten lagen fünf oder sechs Beobachtungen vor, die alle in dieselbe Richtung wiesen. Jede einzeln hatte eine Erklärung gehabt. Zusammen waren sie nicht mehr erklärbar.

Als wir sie nebeneinanderlegten, war klar: Die Annahme trug nicht. Nicht wegen eines einzelnen Widerspruchs, sondern weil es keinen plausiblen Grund mehr gab, an ihr festzuhalten.

Das hätte früher passieren können. Sechs Wochen früher, acht Wochen früher – mit denselben Mitteln, denselben Gesprächen, denselben Zahlen. Wenn wir früher gefragt hätten: Was müsste eintreten, damit diese Annahme falsch ist?

Diese Frage hatten wir nie laut gestellt. Das ist kein dramatischer Fehler. Es ist ein gewöhnlicher.

Was es gekostet hat

Drei Monate Entwicklungszeit – nicht vollständig, die Funktion war nicht der einzige Arbeitsstrang. Aber sie war der größte in diesem Zeitraum, und am Ende stand etwas, das kaum jemand nutzte.

Der direkte Aufwand ist dabei noch der kleinere Teil. Schwerer zu beziffern ist das, was in dieser Zeit nicht entstanden ist. Was hätte gebaut werden können, wenn diese drei Monate anders verwendet worden wären? Welche andere Annahme hätte geprüft werden können, welcher andere Weg hätte früher begonnen werden können?

Hinzu kommt etwas, das sich noch schwerer benennen lässt: das Vertrauen des Teams in seine eigenen Einschätzungen. Wenn man lange genug an einer Annahme festhält, die sich dann als falsch erweist, stellt man nicht nur die Annahme in Frage – man stellt auch die Fähigkeit in Frage, beim nächsten Mal früher zu merken. Dieses Zögern hat seinen Preis.

Diese Fragen haben keine Antwort. Das macht sie nicht leichter.

Was sich verändert hat – und was geblieben ist

Seitdem benennen wir Annahmen expliziter – bevor Arbeit beginnt, nicht nachdem sie schon weit fortgeschritten ist. Das passiert nicht als formaler Schritt, sondern als kurzes Gespräch im Team. Die Fragen darin sind einfach:

• Was wissen wir – und woraus wissen wir es?
• Was nehmen wir an – und warum?
• Was müsste eintreten, damit diese Annahme falsch ist?
• Bis wann soll sich das zeigen?

Das verhindert nicht, dass Annahmen sich als falsch erweisen. Annahmen bleiben Annahmen, solange sie nicht überprüft sind. Aber es wird klarer, welche Beobachtung eine Annahme erschüttern würde – und wie lange man auf sie warten will.

Was geblieben ist: die Versuchung, ein Signal zu erklären statt es ernst zu nehmen. Sie taucht auf, wenn Arbeit schon getan ist. Wenn man Überzeugung investiert hat, Zeit, manchmal Geld. Wenn eine Kursänderung bedeutet, etwas zurückzulassen.

Diese Versuchung ist kein Versagen. Sie gehört zur Entscheidung unter Unvollständigkeit – und Unvollständigkeit ist der Normalfall, nicht die Ausnahme. Die Projekte, die Innosirius begleitet, beginnen selten mit vollständigen Informationen.

Gelernt haben wir, das früher auszusprechen. Ob das beim nächsten Mal reicht, weiß man erst hinterher.