Hauptgedanke

Ein fertiges Dokument enthält zwei Dinge, die miteinander vermischt sind: was über das Thema wahr ist, und was für genau diese Zielgruppe entschieden wurde. Der Ton, die Detailtiefe, die Reihenfolge, das Maß an Vorsicht, die Art, die Dinge zu benennen, was man offenlegt und was man als bekannt voraussetzt — nichts davon gehört zum Wissen selbst.

Wer von diesem Dokument aus das nächste produziert, erbt also diese Entscheidungen, ohne sie selbst getroffen zu haben. Ein Satz, der einen Kunden beruhigen sollte, wird zur Grundlage einer internen Dokumentation; eine Folienformulierung wird zur Anforderung in einer Spezifikation.

Der Fehler liegt nicht darin, mehrere Dokumente zu produzieren. Er liegt darin, einen Output als Quelle zu nehmen.

Ebene beigetragen von „Code centric“ (2026-04-13). Die Regel gilt auch für eine Software-Produktkette, in der fast immer gegen sie verstoßen wird, ohne dass es jemand bemerkt: Eine Spezifikation zu aktualisieren heißt, die vorige Fassung wieder zu öffnen und die betroffenen Absätze zu korrigieren — also einen Output als Quelle zu nehmen. Das Dokument erbt dann alles, was niemand noch einmal gelesen hat: inzwischen entfernte Bildschirme, Annahmen, die sich während der Entwicklung als falsch erwiesen haben. Dieser Fall hat eine nützliche Besonderheit: Die nicht ausgerichtete Quelle lässt sich ohne Diskussion bestimmen — es ist das Code-Repository —, und man kann deshalb messen, was das Erbe kostet, statt es nur zu vermuten.

Ebene beigetragen von „Informationssysteme werden nicht verschwinden. Ihre Form wird sich ändern.“ (2026-07-08). Was die Regel zu akzeptieren verlangt, ist teurer, als es scheint, und daran scheitert sie eher in Organisationen als an Methoden: Anzuerkennen, dass ein abgegebenes Dokument ein Output ist und nicht die Quelle, heißt, dem Deliverable seinen Status als Nachweis geleisteter Arbeit zu nehmen. Solange man an ihm gemessen wird, verlangt es, von etwas anderem aus neu anzusetzen, ein Material zu pflegen, das niemand ansieht.

Warum das wichtig ist

Das ist der Mechanismus, durch den zwei Fassungen derselben Wahrheit am Ende auseinanderdriften. Jede Kopie formuliert um, streicht, was die neue Zielgruppe nicht anspricht, ergänzt, was fehlt — und verliert unterwegs eine Nuance, deren Verschwinden niemand bemerkt, da sie nur im neuen Dokument fehlt.

Die Folge ist ganz praktisch: Der Support kann etwas anderes erklären als der Vertrieb, und die Spezifikation kann eine Annahme enthalten, die in der Darstellung der Geschäftsleitung fehlt, ohne dass irgendeine Prüfung es bemerkt.

Nuancen und Grenzen

Das Erbe ist manchmal gewollt: Das Vokabular eines Kunden in einem Dokument für denselben Kunden zu übernehmen, ist eine gute Entscheidung, keine Verunreinigung.

Und eine neutrale Quelle garantiert für sich allein nichts — jeder Output muss auch tatsächlich von ihr aus neu erstellt werden und nicht vom vorigen.

Offene Fragen

• Wie erkennt man ein Auseinanderdriften zwischen zwei Dokumenten, die jedes für sich korrekt wirken?