Scope Creep im KI-Zeitalter: Prioritäten setzen, wenn jede Funktion billig wirkt

Priorisierung und Anforderungsinflation (Scope Creep) gehören heute zu den größten Herausforderungen in Softwareentwicklung und Produktmanagement. Die Zahl der Funktionen, die ein System aus Sicht der Stakeholder „haben sollte“, wächst rasant und oft unkontrolliert, und mit ihr die Komplexität. Und zwar nur deshalb, weil KI-Tools es leichter gemacht haben, diese Funktionen zu erzeugen und umzusetzen.

Früher war Scope Creep ein schleichender Prozess: hier ein zusätzlicher Bericht, dort noch ein Feld im Formular. Mit KI geht das schneller, denn die Bremse ist weg. Damals musste man jede Idee in Wochen Entwicklungsarbeit beziffern, und schon dieser Preis hat viele Wünsche aussortiert. Heute steht die erste Version einer Funktion nach einer Stunde. Die Kosten, die wirklich zählen, kommen erst später, und sie fallen weniger auf.

Die Anforderungsinflation ist eine der Folgen der Verschiebung, die wir im Beitrag über Projektmanagement im Zeitalter von KI-Agenten beschreiben: Die Umsetzung wird kürzer, und das Gewicht im Projekt wandert zur Definition des Problems und zur Prüfung des Ergebnisses.

Warum KI die Anforderungsinflation antreibt

Prototypen zum Nulltarif und die Illusion billiger Funktionen

Ein KI-Assistent schreibt in wenigen Minuten den Code für ein Formular, einen Bericht oder eine Anbindung. Ein lauffähiger Prototyp überzeugt mehr als eine Folie. Da liegt der Schluss nahe: Was sich schnell bauen lässt, lohnt sich auch. Dabei ist das Schreiben des Codes nur ein kleiner Teil der Kosten. Den Rest zahlen Sie über Jahre hinweg: für Tests, Fehlerbehebung, Updates, Support und Sicherheit.

Anforderungen, die sich selbst schreiben

KI erzeugt nicht nur Code, sondern auch Spezifikationen. Eine Bitte wie „User Stories für das Abrechnungsmodul“ genügt, und eine Minute später haben Sie vierzig davon, jede sinnvoll und sauber formuliert. Eine Anforderungsliste, für die früher eine Woche Workshops nötig war, wächst heute an einem Nachmittag. Was nicht im selben Tempo wächst: die Fähigkeit des Teams, zu beurteilen, welche davon wirklich gebraucht werden.

Alle haben ihren eigenen Prototyp

Ideen kommen nicht mehr nur als Tickets. Immer öfter bringt jemand aus dem Vertrieb oder der Buchhaltung einen fertigen Prototyp mit, in Eigenregie mit KI gebaut: „Läuft schon fast, muss nur noch angebunden werden.“ Etwas abzulehnen, das fertig aussieht, fällt schwer. Bis zur Produktionsreife fehlen aber noch Berechtigungen, Fehlerbehandlung, Daten aus echten Systemen und Tests.

Der Druck, „etwas mit KI“ zu haben

Manche Anforderungen entstehen nicht, weil Nutzer ein Problem haben, sondern weil die Technik da ist: „Die Konkurrenz hat einen Assistenten, also brauchen wir auch einen.“ Bei so einer Funktion steht die Lösung am Anfang, das passende Problem sucht man sich hinterher. Hinzu kommt: Funktionen auf Basis von Sprachmodellen bringen ihre eigene, versteckte Komplexität mit. Ihre Antworten sind nicht ganz vorhersehbar. Deshalb müssen Sie sie bewerten und überwachen, und jemand muss im Blick behalten, auf welche Daten das Modell zugreifen darf.

Der Demo-Effekt

Aus einer beeindruckenden Demo, die in zwei Tagen entstanden ist, wird schnell ein Versprechen an Kunden oder an die Geschäftsführung. Eine Demo zeigt aber den Idealfall. Sonderfälle, Performance mit echten Daten, Berechtigungen und rechtliche Vorgaben bleiben in der Demo außen vor. Zum Projektumfang gehören sie trotzdem.

Die Folgen der Anforderungsinflation

Die Folgen zeigen sich nicht sofort, und genau das macht sie gefährlich. Jede einzelne Funktion wirkt harmlos, erst die Summe wird zum Problem.

• Steigende Wartungskosten. Jede Funktion bedeutet: Code testen, aktualisieren und absichern, Dokumentation schreiben, Fragen der Nutzer beantworten. Auch KI-generierten Code muss man erst verstehen, bevor man ihn korrigieren kann. Und fremden Code zu verstehen kostet Zeit, auch wenn eine Maschine ihn geschrieben hat.
• Ein verwässertes Produkt. Je mehr Optionen es gibt, desto schwerer finden Nutzer die wenigen, für die sie eigentlich gekommen sind. Neue Leute brauchen länger, bis sie sich zurechtfinden, und Fehler und Support-Anfragen nehmen zu.
• Der Nutzen kommt langsamer an. Das Paradoxe daran: Code entsteht schneller, aber wichtige Änderungen erreichen die Nutzer langsamer. Das Team verteilt seine Aufmerksamkeit auf Dutzende kleine Funktionen, und jede braucht ein Review, Tests und Integration.
• Technische Schulden und Qualitätslücken. Funktionen, die „nebenbei“ dazukommen, haben selten ordentliche Tests und selten eine klare Zuständigkeit. Nach ein paar Monaten weiß niemand mehr, wer sie nutzt und ob man sie gefahrlos ändern kann.
• Größere Angriffsfläche. Jedes neue Formular, jede neue Anbindung und jeder KI-Assistent ist eine weitere Stelle, über die Unternehmensdaten laufen. Sie müssen klären, wer darauf zugreifen darf, in wessen Namen das System handelt und wo festgehalten wird, was es tut.
• Kosten, die mit der Nutzung steigen. KI-Funktionen werden oft pro Modellaufruf abgerechnet. Ein Pilotprojekt mit zehn Personen sieht günstig aus, die Rechnung für das ganze Unternehmen kann völlig anders ausfallen.
• Priorisierung wird zum Theater. Ein Backlog mit mehreren hundert Einträgen taugt nicht mehr als Entscheidungshilfe. Alles ist „wichtig“, und in der Praxis kommt zuerst dran, wer am lautesten ruft.

Was hilft: Priorisierung im KI-Zeitalter neu denken

Die Entwicklungskosten filtern nicht mehr von selbst. Also müssen Sie den Filter bewusst einbauen. Drei Werkzeuge helfen dabei: der Blick auf die Gesamtbetriebskosten (TCO), ein sauber definiertes MVP und der Test der riskantesten Annahme (RAT).

TCO: Rechnen Sie mit der ganzen Lebensdauer, nicht nur mit dem Code

Die Gesamtbetriebskosten (Total Cost of Ownership, TCO) umfassen alles, was eine Funktion über ihre gesamte Lebensdauer kostet, nicht nur in der Entwicklung. Bevor jemand „Machen wir“ sagt, lohnt es sich, kurz diese Liste durchzugehen:

1. Entwicklung: mit KI oft der günstigste Posten.
2. Prüfung: Code-Review, Tests, Kontrolle der KI-Ergebnisse.
3. Wartung: Updates der Abhängigkeiten, Fehlerbehebung, Anpassungen an Schnittstellen.
4. Sicherheit und Compliance: Berechtigungen, Datenschutz, Audits.
5. Betrieb: Infrastruktur und die Kosten der Modellaufrufe bei voller Nutzung.
6. Menschen: Dokumentation, Schulungen, Support für die Nutzer.
7. Rückbau: was es kostet, die Funktion zu entfernen, wenn niemand sie mehr braucht.

Verbreitete Bewertungsmethoden wie RICE oder WSJF teilen den Nutzen durch den Aufwand. Mit KI sinkt der geschätzte Entwicklungsaufwand, und plötzlich scheint sich jede Funktion zu lohnen. Setzen Sie statt des Aufwands die TCO ein, und schon stimmt die Rangfolge wieder. Eine einfache Kontrollfrage: Wer kümmert sich in zwei Jahren um diese Funktion, und was kostet es diese Person?

MVP: Fangen Sie beim Problem an, nicht bei der Funktionsliste

Ein MVP (Minimum Viable Product) ist die kleinste Version eines Produkts, mit der Sie prüfen können, ob Sie ein Problem lösen, das echte Nutzer wirklich haben. Mit KI ist die Versuchung groß, „Minimum“ als „alles, was wir bis zur Deadline generieren können“ zu verstehen. Doch „Minimum“ bezieht sich auf den Umfang, nicht auf den Aufwand.

Ein gut definiertes MVP beginnt mit ein paar schriftlichen Antworten:

• Welches Problem lösen wir und für wen? Ein, zwei Sätze, ohne Funktionsnamen.
• Woran erkennen wir den Erfolg? Ein messbares Ergebnis, etwa kürzere Bearbeitungszeiten oder weniger Fehler, nicht „Modul eingeführt“.
• Was gehört nicht dazu? Eine Liste der Dinge, die wir in dieser Version bewusst nicht machen. Oft ist das der wichtigste Teil des Dokuments, denn gerade diese Liste schützt das Projekt vor der Anforderungsinflation.
• Wer entscheidet über Änderungen am Umfang? Jede neue Anforderung geht an eine Person oder ein Team, das weiß, wozu das MVP da ist.

Vieles davon erledigen Sie in der Analyse vor der Einführung. Wenn KI die Entwicklung verkürzt, wird eine gute Analyse am Anfang noch wichtiger. Denn ein Fehler im Umfang wird heute schneller als je zuvor zu fertigem Code.

RAT: Testen Sie zuerst die riskanteste Annahme

Der Riskiest Assumption Test (RAT) denkt andersherum. Er fragt nicht „Was bauen wir in der ersten Version?“, sondern „Welche Annahme bringt die ganze Idee zu Fall, wenn sie nicht stimmt?“ Dann sucht er den günstigsten Weg, genau diese Annahme zu prüfen. Oft müssen Sie dafür gar kein Produkt bauen.

Mit KI bekommt dieser Ansatz einen neuen Sinn. Ein billiger Prototyp ist keine Verpflichtung mehr, sondern ein Werkzeug zum Experimentieren, das Sie danach wegwerfen können. So kann das aussehen:

1. Annahmen aufschreiben. Dass die Nutzer dieses Problem haben, dass sie bereit sind, anders zu arbeiten, dass die Daten verfügbar und gut genug sind, dass sich der Betrieb rechnet.
2. Die riskanteste auswählen. Die Annahme, die am unsichersten und zugleich am wichtigsten für den Erfolg ist.
3. Den günstigsten Test planen. Gespräche mit fünf Nutzern, ein Mock-up, ein Prototyp, mit KI an einem Tag gebaut, oder ein Service, den jemand „hinter den Kulissen“ von Hand erledigt.
4. Das Kriterium vorher festlegen. Bevor Sie die Ergebnisse sehen, schreiben Sie auf, welcher Ausgang „weitermachen“ bedeutet, welcher „Richtung ändern“ und welcher „aufhören“.
5. Entscheiden und festhalten. Nach dem Test wandert der Prototyp in den Papierkorb, oder Sie planen eine saubere Umsetzung. Direkt in die Produktion geht er nie.

Regeln für den Alltag

TCO, MVP und RAT wirken am besten, wenn das Team ein paar einfache Gewohnheiten pflegt:

• Jede Anforderung beginnt mit einem Problem. Auf den Wunsch „Wir wollen einen KI-Assistenten im Modul X“ kommt eine Rückfrage: Welches Problem soll er lösen, und woran messen wir, dass er es gelöst hat?
• Ein Komplexitätsbudget. Legen Sie fest, wie viele neue Funktionen das Produkt in einem bestimmten Zeitraum verkraftet. Ist das Budget ausgeschöpft, kommt eine neue Funktion nur noch, wenn eine andere geht.
• Ein Prototyp ist kein Versprechen. Kennzeichnen Sie Prototypen als Wegwerfversionen. Zeigen Sie sie Kunden erst dann als Vorschau auf das Produkt, wenn das Team das entschieden hat.
• Regelmäßig aufräumen. Prüfen Sie einmal im Quartal, welche Funktionen niemand nutzt, und planen Sie ihren Rückbau. Eine entfernte Funktion kostet nichts mehr.
• Entscheidungen nachvollziehbar machen. Halten Sie fest, wer eine Priorität gesetzt hat, wann und auf welcher Grundlage. So können Sie in einem halben Jahr bewusste Entscheidungen von denen unterscheiden, die „einfach passiert“ sind.

Fazit

KI hat die Anforderungsinflation nicht erfunden, aber die Bremse gelöst. Wenn eine Funktion in einer Stunde gebaut ist, verliert die Frage „Geht das?“ ihren Sinn. Entscheidend ist eine andere: „Lohnt es sich, das zu haben und zu pflegen?“ Teams, die mit den Gesamtbetriebskosten rechnen, sich an ein eng gefasstes MVP halten und zuerst ihre riskantesten Annahmen testen, nutzen KI, um schneller zu lernen, nicht um ihr Produkt schneller aufzublähen.

Möchten Sie den Umfang Ihres Projekts in den Griff bekommen? Schreiben Sie uns.