Hauptgedanke

Einer Spezifikation, einem PRD, einem Mockup wirft man Lügen vor, sobald man den Abstand zwischen dem entdeckt, was sie ankündigen, und dem, was das Produkt tut. Der Vorwurf trifft das falsche Objekt: Diese Dokumente haben sich nicht geirrt, sie erfüllen bloß nicht mehr die Funktion, für die sie geschrieben wurden.

Vor dem Go-live dient eine Spezifikation dem Gespräch. Sie gibt dem Product Manager, den Entwicklern und den Fachbereichen etwas, an dem sie sich reiben können: Mit ihr lässt sich eine Annahme erkunden, ein Umfang abstecken, ein Dissens sichtbar machen, bevor er teuer wird, eine Entscheidung treffen. Ihr Wert liegt nicht darin, dass sie stimmt, sondern darin, dass sie Einwände hervorruft — ein Dokument, über das niemand diskutiert hat, ist gescheitert, selbst wenn es genau beschreibt, was ausgeliefert wird.

Der Übergang in die Produktion nimmt ihr diese Funktion. Die während der Entwicklung geschlossenen Kompromisse, die entdeckten Grenzfälle, die in einem Merge Request getroffenen Abwägungen sind ins Produkt eingegangen, ohne noch einmal durch das Dokument zu laufen. Was es über das Verhalten sagte, ist kein Vorschlag mehr, über den man diskutiert: Es ist eine konkurrierende Beschreibung zu der, die das Repository enthält, und die unterlegene. Das Artefakt wird nicht falsch, es wird neu generierbar — was es über das Verhalten aussagt, lässt sich aus dem Code rekonstruieren, und es von Hand zu pflegen heißt, ein Duplikat zu unterhalten, das abdriftet.

Der Umschlagpunkt hat also ein Datum, und es ist nicht das der Niederschrift. Dasselbe Dokument ist vor der Auslieferung legitim und danach nicht mehr, ohne dass sich ein einziger seiner Sätze geändert hätte.

Warum das wichtig ist

Das löst das falsche Dilemma zwischen „Wir brauchen bessere Specs“ und „Wir sollten aufhören, welche zu schreiben“. Beide Lager setzen voraus, dass die Spezifikation einen einzigen Status hat; sie hat zwei, und der übliche Fehler besteht darin, den ersten über den Moment hinaus zu verlängern, in dem er abläuft.

Es lenkt auch die Anstrengung um: Statt ein Dokument nach jeder Auslieferung neu zu schreiben, damit es stimmt, schreibt man es offen für das Gespräch, das es eröffnen soll, und nimmt hin, dass es mit dem Go-live veraltet ist. Die Sorgfalt wandert zur Qualität der Diskussion davor und zur Fähigkeit, danach neu zu generieren — zwei Dinge, die anders als die Pflege von Hand mit der Zeit nicht verfallen.

Nuancen und Grenzen

Der Umschlag betrifft nur den beschreibenden Teil. Eine Spezifikation enthält fast immer, in denselben Absätzen vermischt, die Beschreibung eines Verhaltens und den Grund, aus dem man es gewählt hat — Letzterer lässt sich aus keinem Repository neu generieren und muss das Dokument überdauern.

Eine Spezifikation kann außerdem rechtlich verbindlich sein: Anhang eines Kundenvertrags, Teil einer regulatorischen Akte, schriftliche Zusage in einer Ausschreibung. Dann behält sie eine rechtliche Autorität, die ihr der Go-live nicht nimmt, auch wenn das Produkt von ihr abweicht — und gerade diese Abweichung wird dann zum Thema.

Schließlich setzt „der Go-live“ eine scharfe Grenze voraus. Ein schrittweises Ausrollen hinter einem Feature Flag, eine Auslieferung an wenige Pilotkunden, ein Rollback ziehen den Moment des Umschlags in die Länge, statt ihn zu markieren.

Offene Fragen

• Was markiert diesen Statuswechsel konkret am Dokument selbst, damit jemand, der es acht Monate später wieder öffnet, weiß, in welchem der beiden Zustände er es liest?
• Schreibt man eine Spezifikation anders, wenn man weiß, dass sie mit der Auslieferung veraltet sein wird — kürzer beim Verhalten, länger bei den verworfenen Alternativen?