Das ist doch schnell gemacht.

Manche Fehler erkennt man nicht an einer Entscheidung, sondern an einem Satz, der sich wiederholt. Diese Geschichte handelt von einem solchen Satz. Sie ist bewusst allgemein gehalten — ohne Kunden, ohne Projekt, ohne Zeitpunkt. Was bleibt, ist das Warnsignal und die Lektion dahinter.

Situation

In einer Zusammenarbeit sollte immer wieder gebaut werden, bevor verstanden war, was gebaut werden soll. Jede Frage nach den Anforderungen, jede Überlegung zur Struktur wurde mit demselben Satz beiseitegeschoben: „Das ist doch schnell gemacht." Analyse galt als Verzögerung, Architektur als Umweg. Der Wunsch war eindeutig: sofort anfangen, sichtbar liefern, das Nachdenken weglassen.

Ausgangsannahmen

Wir hielten den Satz zunächst für gewöhnliche Ungeduld — eine Vorliebe, über die man reden kann. Die Annahme war, dass sich der Wert des Vorausdenkens von selbst zeigt, sobald erst gebaut wird: Man würde die Analyse eben still im Hintergrund machen, die Architektur unsichtbar mittragen und den Wunsch nach Tempo an der Oberfläche bedienen. Ungeduld, dachten wir, ließe sich mit Ergebnissen beruhigen.

Problem

Der Satz meinte nicht Tempo. Er drückte eine Überzeugung aus: dass Analyse und Architektur keinen Wert haben — dass das sichtbare Tippen die eigentliche Arbeit sei und alles davor Overhead. Unter dieser Überzeugung erschien jede Stunde, die dem Verstehen des Problems galt, als Verlust und jede Architekturfrage als Bremse. Die Zusammenarbeit war so aufgebaut, dass der wertvollste Teil der Arbeit der am wenigsten willkommene war. Nacharbeit, Missverständnisse, wanderndes Ziel — jedes davon wurde nicht als der vorhersehbare Preis der übersprungenen Analyse gelesen, sondern als unser Versäumnis, schnell genug zu sein.

Ursache

Die Ursache war nicht die Ungeduld und keine einzelne Entscheidung. Sie war ein Auseinanderfallen der Vorstellungen davon, woher der Wert von Software kommt. „Das ist doch schnell gemacht" nimmt an, der schwere Teil sei das Schreiben des Codes. In Wahrheit ist der schwere Teil, zu entscheiden, was gebaut wird und wie es zusammenpassen muss. Treffen diese beiden Vorstellungen aufeinander, kann kein Tempo genügen — denn das Übersprungene ist genau das, was die Probleme verhindert, die später der Langsamkeit angelastet werden. Wir hatten einen Unterschied im Weltbild wie einen Unterschied im Geschmack behandelt.

Entscheidung

Die Entscheidung war kein besserer Prozess für solche Projekte, sondern der Verzicht auf sie. Wir lernten, den Satz als das zu hören, was er ist: ein verlässliches, frühes Signal dafür, dass der Teil des Engineerings, der Software haltbar macht, nicht gewollt ist. Batunet lehnt Projekte, die so beginnen, heute bewusst ab — nicht aus Stolz, sondern weil man dort keine gute Arbeit machen kann, wo die Grundlage guter Arbeit unerwünscht ist. Die Zusage „schnell gemacht" wird am Anfang getroffen, am breitesten Punkt der Unsicherheit, bevor irgendetwas verstanden ist. Sie zu geben hieße, das Raten zuzusagen.

Trade-offs

Ein Projekt abzulehnen hat einen Preis. Wir weisen Vorhaben zurück, die vielleicht gut gelaufen wären, und verzichten auf Umsatz, der greifbar war. Wir nehmen in Kauf, dass das Signal nicht perfekt ist — mancher, der den Satz sagt, käme im Verlauf zur Einsicht. Wir lehnen trotzdem ab, weil die Asymmetrie klar ist: Der Preis der seltenen falschen Absage ist ein verlorenes Projekt; der Preis der falschen Zusage sind Monate Arbeit auf einem Fundament, dem niemand zugestimmt hat, mit beiderseitiger Enttäuschung am Ende. Anders entscheiden wir, wenn der Satz eine einzelne beiläufige Bemerkung ist und keine wiederkehrende Haltung — Ungeduld ist menschlich; ein Weltbild zeigt sich im Muster.

Was wir gelernt haben

Ein Teil der wichtigsten Information über ein Projekt liegt darin, wie es beginnt. Ein Satz kann ein ganzes Modell davon tragen, was Software ist. Die Lektion ist nicht „immer analysieren" als Regel — Regeln ersetzen das Denken. Sie ist, dass die Bereitschaft, vor dem Bauen zu verstehen, keine Phase ist, die man überspringen kann; sie ist die Voraussetzung für alles danach. Wer sie überspringen will, bittet nicht um Tempo, sondern um eine andere Art von Arbeit als die, die hält. Ohne Analyse zu schätzen ist nicht schnell — es ist früh raten und spät zahlen.

Wie das Batunet verändert hat

Der Satz ist intern zu einem gemeinsamen Vokabular geworden. Wenn wir ihn hören — von einem Interessenten, in einem ersten Gespräch —, benennen wir ihn und nehmen ihn als Signal ernst, statt ihn zu glätten. Er hat verändert, wozu wir Ja sagen. Wir machen lieber weniger Projekte richtig als mehr Projekte auf Fundamenten, von denen wir wissen, dass sie tragen sollen und nicht können. Früh Nein zu sagen ist heute Teil davon, wie wir die Arbeit schützen.

Weiterführend

• Guide: Software, die in zehn Jahren noch läuft — warum die Entscheidungen vor der ersten Zeile Code über die Lebensdauer bestimmen.
• Decision: Modularer Monolith als Ausgangspunkt — Struktur wird bewusst gewählt, nicht übersprungen.
• Playbook: Eine öffentliche API entwerfen — entwerfen, bevor gebaut wird.
• Opinion: Warum vorzeitige Abstraktion Komplexität schafft — vor dem Bauen verstehen heißt nicht, Struktur zu bauen, die man noch nicht braucht.
• Glossar: Cone of Uncertainty — warum „schnell gemacht" am Anfang nichts über Aufwand aussagt.

Der teuerste Satz in einem Projekt ist selten der, der laut ausgesprochen wird. Er ist der, den man für harmlos hält und deshalb überhört.