Das beste Entwicklerteam, das ich kenne, hat ein Projekt gegen die Wand gefahren. Vier Leute, die ihr Handwerk beherrschen, sauberer Code, ordentliche Tests, ein Stand-up, das funktioniert. Sie haben in zehn Wochen geliefert, was bestellt war — und nach der Abnahme stand der Fachbereich davor und sagte den Satz, der in solchen Momenten immer fällt: „Aber so haben wir das nie gemeint." Es lag nicht am Code. Der Code war gut. Es lag daran, dass niemand zu Ende geklärt hatte, was gebaut werden sollte, bevor sie angefangen haben, es gut zu bauen.
Das ist die unbequeme Wahrheit hinter den meisten gescheiterten Softwareprojekten im Mittelstand. Man sucht den Fehler im Team, im Stack, im Dienstleister. Man fragt, ob die Entwickler schnell genug, erfahren genug, teuer genug waren. Und übersieht dabei den größeren Hebel, der fast nie im Code liegt: die Klarheit dessen, was überhaupt entstehen soll. Ein schwaches Team baut langsam das Richtige nach. Ein starkes Team baut schnell das Falsche. Geschwindigkeit in die falsche Richtung ist kein Fortschritt. Sie ist nur ein Vorsprung, den man später wieder einholen muss.
Warum die Anforderung der teurere Posten ist
Einen schwachen Entwickler erkennt man, und man tauscht ihn aus. Das ist unangenehm, aber lösbar — eine personelle Frage mit einer personellen Antwort. Eine falsch verstandene Anforderung erkennt niemand, solange das Projekt läuft. Sie sieht im Code völlig korrekt aus, weil sie korrekt umgesetzt wurde. Sie fällt erst auf, wenn jemand das fertige System benutzt und merkt, dass es etwas anderes tut, als er im Kopf hatte. Bis dahin wurde sie gebaut, getestet, dokumentiert und abgenommen. Und dann baut man sie noch einmal.
Das ist der eigentliche Grund, warum Anforderungen so teuer sind: Ein Fehler in der Spec multipliziert sich durch jede Stufe, die danach kommt. In der Anforderungsphase kostet ein Missverständnis ein Gespräch. Im Design kostet es eine Skizze. In der Entwicklung kostet es einen Sprint. Im Betrieb kostet es einen Sprint plus die Datenmigration plus das Vertrauen des Fachbereichs, der jetzt glaubt, die IT habe nicht zugehört. Derselbe Fehler, an vier Stellen, mit vier völlig verschiedenen Preisschildern. Wer ihn vorne findet, zahlt eine Stunde. Wer ihn hinten findet, zahlt ein Quartal.
Schlechte Anforderungen kosten mehr als schlechte Entwickler.
Zwei Größen, die niemand verwechseln will
Es hilft, zwei Dinge auseinanderzuhalten, die im Alltag dauernd zusammenfallen: die Qualität der Umsetzung und die Klarheit der Anforderung. Beide sind wichtig, aber sie hebeln unterschiedlich stark. An der Umsetzungsqualität schraubt jeder gern, weil sie sichtbar ist — sauberer Code, schnelle Tickets, ein Team, das liefert. An der Anforderungsklarheit schraubt fast niemand, weil sie unsichtbar ist und sich nach Verwaltung anfühlt, nicht nach Fortschritt. Genau deshalb ist sie der unterbesetzte Hebel. Dort, wo keiner hinschaut, liegt der größte Effekt.
Ein Projektleiter sitzt genau auf dieser Bruchstelle. Er verantwortet die Spec, nicht den Code. Er ist der, an dem hängenbleibt, ob das Team das Richtige gebaut hat — und nicht, ob es schön gebaut wurde. Und er ist der Einzige im Raum, der in dem Moment, in dem alle „ja, machen wir so" sagen, die undankbare Frage stellen muss: Meinen wir gerade alle dasselbe? Meistens lautet die ehrliche Antwort nein. Nur merkt es keiner, weil das Wort, über das man redet, für jeden am Tisch etwas anderes bedeutet und trotzdem gleich klingt.