Hauptgedanke

Eine Spezifikation beschreibt eine Absicht. Ein PRD beschreibt ein Ziel, erwartete Regeln, Szenarien. Ein Mockup beschreibt eine gewünschte Oberfläche. Keines dieser Dokumente beschreibt, worauf der Kunde treffen wird: Zwischen ihnen und der Produktivsetzung werden Kompromisse geschlossen und Details nachjustiert, Randfälle tauchen auf, technische Zwänge erzwingen kleine Änderungen am Verhalten, und im Lauf eines Pull Requests fallen Entscheidungen, die nie ins ursprüngliche Dokument zurückfinden.

Diese Abwägungen sind keine Unfälle, die man beseitigen müsste: Ein lebendiges Produkt entsteht nicht wie ein eingefrorenes Dokument. Sie haben aber eine Folge dafür, wohin man schauen muss, um ein Produkt zu kennen. Die Spezifikation bleibt eine zu einem bestimmten Zeitpunkt nützliche Annäherung; die Version in Produktion ist die einzige vollständige Beschreibung dessen, was ausgeliefert wurde.

Die Wirkung zeigt sich auch an den Werkzeugen zur Nachverfolgung: Tickets laufen genauso auseinander wie Spezifikationen, weil die während der Umsetzung getroffenen Abwägungen in keines von beiden zurückfließen.

Ergänzt durch „Das Backlog ist kein Mülleimer: Es ist ein Werkzeug zum Handeln“ (2026-06-03).

Ergänzt durch „PM, Entwickler und KI: Die Rollen verschwimmen, die Verantwortung bleibt“ (2026-08-01). Diese Abwägungen haben einen Namen und einen Urheber: Es sind Produktentscheidungen, und es sind die Entwickler, die sie treffen. Eine vollständige Spezifikation ist eine Fiktion — selbst eine gute lässt stumme Zonen: Grenzfälle, Fehlermeldungen, implizite Verhaltensweisen, Sicherheitsregeln, Ablaufzeiten, unsichtbare Prioritäten, Mikrointeraktionen, Fallback-Entscheidungen. Der Befund beschreibt also nicht nur eine Abweichung zwischen Dokument und Produktion; er benennt, wer faktisch entscheidet, worauf der Kunde treffen wird.

Warum das wichtig ist

Das verschiebt den Ort, an dem man die Wahrheit eines Features sucht: im ausgelieferten Verhalten, nicht im Ticket, das es angefordert hat. Die Abweichungen sind keine Konformitätsfehler, sie sind der eigentliche Stoff der Produktentscheidung.

Es zeigt auch, was man verliert, wenn man vorgelagert bleibt: Der Teil der Entscheidungen, der das Erlebnis des Kunden bestimmt, hat sich nach dem Dokument abgespielt, in einem Austausch, den dieses Dokument nicht festhält.

Nuancen und Grenzen

In manchen Bereichen ist die Abweichung gering und die Absicht trägt: Eine geänderte Beschriftung, ein Parameter, eine einfache fachliche Regel gehen so in Produktion, wie sie geschrieben wurden.

Und ein Produkt, das regulatorischen Vorgaben unterliegt, kehrt die Regel teilweise um: Konformität wird dort am Dokument ebenso nachgewiesen wie am ausgelieferten Verhalten, und die Abweichung wird selbst zum Mangel.

Offene Fragen

• Über welche Vorrichtung könnte eine in einem Pull Request getroffene Abwägung zu der Person zurückgelangen, die das Feature konzipiert hat, ohne den Dokumentationsaufwand wiederherzustellen, den man gerade vermeiden will?