Die Anfangsanalyse eines Softwareprojekts kostet Tage an Arbeit, erscheint als Position im Angebot und bringt nichts hervor, was man sofort sehen könnte. Es gibt keine Demo, keine Benutzeroberfläche. Es werden Fragen gestellt und Dokumente verfasst. Wer bezahlt, fragt sich zu Recht, ob das wirklich nötig ist – und die Antwort fällt nicht immer gleich aus.
Wo die Kosten einer fehlenden Anforderung letztlich anfallen
Ein hypothetisches Beispiel. Ein Unternehmen beauftragt eine individuelle Auftragsverwaltung, und man legt sofort los – ohne fundierte Vorabanalyse. Die Arbeit konzentriert sich ausschließlich auf das, was explizit formuliert wurde: Aufträge schneller erfassen.
Nach einigen Wochen zeigt sich, dass das eigentliche Problem nicht nur darin bestand, Aufträge schneller zu erfassen, sondern jederzeit zu wissen, wo jeder einzelne gerade steht. Eine scheinbar einfache Frage, die weitere nach sich zieht: Wer aktualisiert den Status und wann? Was geschieht mit einem Auftrag, der blockiert oder nur teilevadiert ist? Wer muss diese Informationen einsehen können? Das System funktioniert exakt wie spezifiziert, verfehlt aber das eigentliche Ziel, für das es beauftragt wurde.
Ein Teil der Arbeit muss neu gemacht werden. Im Vertrag und im Projektprotokoll trägt dieser Mehraufwand jedoch eine andere Bezeichnung: „Change Request“, „Zusatzfunktion“ oder „Missverständnis“.
Niemand schreibt: „Diese Kosten gehen auf die Analyse zurück, die wir nicht durchgeführt haben.“ Die Kosten existieren, werden aber nicht auf ihren Ursprung zurückgeführt – und der Vergleich mit den Vorabkosten der Analyse findet nie statt.
Das ist kein rein theoretisches Szenario. In einem auf diesem Blog veröffentlichten Beitrag erinnert sich der Entwickler Raffaele Bologna an einen besonders kritischen Projektmoment: Ein bereits weit fortgeschrittenes Vorhaben, bei dem der Kunde die Anforderungen grundlegend änderte, der Termin jedoch fix blieb. Ein Teil der Anwendung musste umgeschrieben werden – und schneller zu programmieren verringert nicht den Denkaufwand, der nötig ist, um zu bewerten, was sich an der Architektur ändert, welche bestehenden Funktionen betroffen sind und welche Tests überarbeitet werden müssen.
Was die Analyse ans Licht bringt
Lautet die Anfrage „ein maßgeschneidertes System“, ist das System die Antwort, nicht das Problem. Oft ist die Individualisierung das Mittel, mit dem der Kunde hofft, schneller zu arbeiten, Kosten zu senken oder einen Prozess verlässlicher zu steuern – Ziele, die er selten explizit formuliert, weil sie ihm selbstverständlich erscheinen.
Eine fundierte Analyse macht diese Ziele sichtbar. Dabei kann sich zeigen, dass sie im Widerspruch zueinander stehen: Eine individuelle Lösung zu wollen und gleichzeitig das Budget zu minimieren, schließt sich nicht per se aus – wird aber zum Problem, wenn die Prioritäten nicht von vornherein geklärt sind. Diese Entscheidung liegt beim Kunden. Das Entwicklungsteam kann Alternativen aufzeigen, Kosten schätzen und Konsequenzen darlegen, aber es kann nicht stellvertretend entscheiden, welcher Kompromiss akzeptabel ist.
Derselbe Entwickler berichtet, dass er, seit er mit KI-Tools arbeitet, der Definition von Anforderungen noch mehr Aufmerksamkeit widmet: Eine vage Anfrage führt unausweichlich zu einem vagen Ergebnis. Diese Regel gilt zwischen Menschen genauso – mit KI wird das Scheitern nur schneller sichtbar.
Manchmal führt die Analyse auch zu dem Ergebnis, dass weniger Software nötig ist als ursprünglich gedacht: etwa indem man einen Prozess vereinfacht, bevor man ihn automatisiert, oder auf eine bereits existierende Standardlösung aufsetzt. Ein solches Resultat taucht in keinem Entwicklungsangebot auf – ist für den Kunden aber von hohem Wert.
Welche Entscheidungen sich zurückstellen lassen
Nicht jedes Detail muss vor Projektstart feststehen. Viele Zusammenhänge erschließen sich erst in der Umsetzung, und für einen Prototyp oder ein klar umrissenes Projekt ist es oft klug, schlank zu starten. Entscheidend ist die Differenzierung zwischen leicht reversiblen Entscheidungen und solchen, die das architektonische Fundament des Systems bilden.
Am Beispiel der Auftragsverwaltung: Das Layout eines Screens lässt sich meist unkompliziert anpassen. Die Statuslogik eines Auftrags und die Geschäftsregeln für dessen Zustandsübergänge nachträglich zu verändern, verursacht hingegen massive Kosten, sobald andere Teile des Systems darauf aufbauen.
Das Risiko liegt nicht darin, mit unvollständigen Informationen zu starten – sondern darin, es zu tun, ohne zu wissen, welche Entscheidungen man gerade auf die lange Bank schiebt.
