Spec-Driven AI Operating Model: Wer den Geschäftsprozess besitzt

Eine Spezifikation, ein Abweichungsregister, drei Prüfschichten, und eine Sperre, die Code daran hindert, die Spezifikation zu ändern: Das war der erste Text zu diesem Geschäftsprozess. Offen blieb, wer die Sperre verteidigt, wenn es unbequem wird.

Die Interessenlage, die die Logik kippt

Zwei Rollen führen den Geschäftsprozess im Alltag aus. Die fachliche Seite schreibt die Anforderung, die Entwicklung baut sie. Keine von beiden kann ihn verteidigen, wenn er unter Druck gerät, weil beide ein Interesse an der Umgehung haben. Die fachliche Seite will eine Änderung schnell, die Entwicklung will ein Ticket abschließen. Der erste Text hat genau diesen Moment beschrieben: Freitag, das Ticket ist fast fertig, die Spezifikation anzupassen geht schneller als der Weg über das Register. Das Muster wiederholt sich, solange niemand explizit dafür zuständig ist, an dieser Stelle Nein zu sagen.

Deshalb braucht es eine dritte Rolle. Nicht die fachliche Seite, nicht die Entwicklung. Ihr einziger Auftrag: eine Spezifikation abweisen, bevor gebaut wird, wenn sie nicht prüfbar ist.

Vier Entscheidungen, die bisher nirgends zugeordnet sind

Im laufenden Betrieb fallen täglich vier Entscheidungen. Bisher ist für keine von ihnen klar, wer sie trifft.

Die zweite Zeile ist die unbequeme: Wer eine Spezifikation geschrieben hat, darf sie nicht selbst für prüfbar erklären. Das fühlt sich nach Misstrauen an und ist dasselbe Prinzip wie beim Code-Review. Niemand genehmigt den eigenen Pull Request, nicht weil er unehrlich wäre, sondern weil er die eigene Lücke nicht sieht. Dieselbe blinde Stelle gibt es bei einer Anforderung. Wer sie geschrieben hat, kennt die Lücke nicht, sonst hätte er sie geschlossen.

Die dritte Zeile trägt den Betrieb. Läge die Einstufung bei der Partei, die den Abschluss will, würde sie umgangen, nur unauffälliger als bei der zweiten Zeile.

Was diese Rolle nicht tut

Sie priorisiert nicht, schätzt nicht, entscheidet keine Architektur. Das sind andere Rollen, mit anderen Interessen. Ein Architekt entscheidet, wie etwas gebaut wird. Diese Rolle entscheidet, ob es das Richtige ist, das gebaut werden soll, bevor ein Modell oder ein Mensch beginnt. Das ist eine Produktentscheidung, keine technische.

Was das für ein externes Haus bedeutet

Bei den Zielkunden baut meistens ein externes Haus, nicht die eigene Entwicklung. Für den Geschäftsprozess ändert das nichts an der Verteilung der Rollen, nur daran, wo eine Abweichung zuerst auftaucht. Der Dienstleister liest die Spezifikation vor der Umsetzung und meldet Abweichungen in das Register des Auftraggebers, nicht als Change Request in sein eigenes Ticketsystem. Sonst kostet eine Abweichung Geld, bevor überhaupt entschieden ist, ob sie eine Mehrleistung ist, und das belohnt, Lücken zu finden statt sie zu melden.

Was davon noch nicht bewiesen ist

Bisher füllt eine Person diese dritte Rolle aus, in einem laufenden Mandat, und das bin ich. Dass sie auf jemand anderen übertragbar ist, ist eine Behauptung, kein Beleg. Ein erster Datenpunkt dafür existiert: Eine Kollegin im Kundensupport hat vor kurzem eine Lücke in der Spezifikation gefunden und richtig eingeordnet, ohne dass ich den Fund angestoßen hätte. Ein Datenpunkt ist keine Serie, aber er ist mehr, als am Anfang dastand.

Was am Ende dasteht

Nicht nur eine Spezifikation, die hält. Jemand, der sie verteidigt, obwohl er sie nicht geschrieben hat, und der sie genau deshalb glaubwürdig abweisen kann.

Ich übernehme laufende Vorhaben, bis diese Rolle besetzt ist, dann bin ich raus. Das ist der Unterschied zwischen einer Regel, die hielt, solange zufällig jemand aufgepasst hat, und einer, die hält, weil jemand explizit dafür zuständig ist.