Du bist in Kapitel neun. Du stellst ein Diagnoseframework vor, das dein Kunde — ein Führungsteam, mit dem du seit Kapitel 3 zusammenarbeitest — nun bereit ist anzuwenden. Doch das Framework erfordert eine spezifische Organisationsstruktur, die dem Ausgangszustand widerspricht, den du vier Kapitel zuvor beschrieben hast. Das Unternehmen, das du in Kapitel 3 beschrieben hast, kann auf dem beschriebenen Weg nicht in Kapitel 9 ankommen.
Du verfolgst den Faden zurück. Vier Kapitel beziehen sich auf einen Ausgangszustand, den du nun revidieren musst. Die Änderung liegt nicht im Text. Sie liegt in der Struktur. Zu wissen, wie man ein Buch strukturiert, ist nicht dasselbe wie zu wissen, wie man seine Seiten füllt.
Die meisten Autoren erkennen erst nach dem Schreiben, wie ihr Buch strukturiert ist. Softwareingenieure haben vor vierzig Jahren gelernt, dass man nicht einfach drauflos schreibt.
Marion schrieb am Dienstag über die Angst vor dem Anfangen — warum das erste Kapitel schwieriger ist, als es aussieht, und was man dagegen tun kann. Dieser Beitrag handelt davon, was nach dem Anfangen kommt: was du eigentlich baust und was es braucht, um etwas zu bauen, das hält.
Was ein Buch wirklich ist
Zwei Disziplinen haben dasselbe herausgefunden, lange bevor das Verlagswesen es tat.
Architekten wissen, dass ein Haufen Materialien kein Gebäude ist. Ein Gebäude hat tragende Wände, Räume, die in einer bestimmten Reihenfolge miteinander verbunden sind, Sanitär- und Elektroleitungen, die nach einem Plan von einer Etage zur nächsten verlaufen. Änderst du, wo die Treppe liegt, änderst du, was darüber und darunter ist. Die Materialien sind dieselben; die Struktur ist das, was sie zu einem Gebäude macht.
Softwareingenieure wissen, dass ein Ordner mit Dateien kein System ist. Eine Codebasis hat Module, Abhängigkeiten, gemeinsamen Zustand, Schnittstellen. Änderst du ein Modul, änderst du alles, was davon abhängt. Der Code ist derselbe; die Architektur ist das, was ihn zum Funktionieren bringt.
Ein Buch funktioniert auf dieselbe Weise. Genauer gesagt funktioniert es auf dieselbe Weise wie beide.
Ein Wirtschaftsbuch, eine Fallstudiensammlung, ein Methodikleitfaden: Jedes enthält Frameworks, Kundengeschichten und porträtierte Personen. Jedes Element hat einen Zustand — einen aktuellen Stand, der sich durch das Buch ansammelt und einschränkt, was als Nächstes kommen kann. Das Framework, das du in Kapitel 3 einführst, muss in Kapitel 8 noch Bestand haben. Der Kunde, mit dem du in Kapitel 2 beginnst, muss dieselbe Ausgangsgeschichte tragen, wenn er in Kapitel 7 wieder auftaucht. Die porträtierte Führungskraft, die in Kapitel 4 etwas gelernt hat, trägt dieses Wissen in Kapitel 6 weiter. Keines dieser Elemente ist unabhängig.
Ein Inhaltsverzeichnis ist das, was du zu bauen beabsichtigt hast. Das Manuskript ist das, was du gebaut hast. Diese beiden Dinge sind oft nicht identisch.
Zwei Arten des Scheiterns, die du spüren kannst
Es gibt zwei strukturelle Probleme, die in fast jedem Manuskript auftreten, das ich in der Spätrevision gesehen habe. Es sind unterschiedliche Probleme. Sie fühlen sich unterschiedlich an. Und sie haben unterschiedliche Ursachen.
Das erste Problem: wenn du eine Sache änderst und alles zusammenbricht.
In einem Beraterbuch legt eine Kundenfallstudie in Kapitel 3 den Ausgangszustand eines Unternehmens fest: die Zusammensetzung des Führungsteams, ihr Betriebsmodell, ihre erste Diagnose des Problems. Dieser Aufbau zieht sich durch den Rest des Buches. Die Framework-Anwendung in Kapitel 7 hängt davon ab, wer das Kundenteam war. Das Ergebnis in Kapitel 10 hängt von der Ausgangsdiagnose ab. Wenn du den Aufbau aus Kapitel 3 revidierst — selbst ein Detail, selbst eine Berufsbezeichnung — musst du jeden nachgelagerten Verweis verfolgen, da jedes folgende Kapitel gegen diese ursprüngliche Version geschrieben wurde.
Dieselbe Logik gilt für Personen. Eine porträtierte Führungskraft erscheint in Kapitel 1 mit einer bestimmten Denkweise und einem bestimmten Führungsansatz — ihrer Art zu denken, bevor das Beratungsmandat beginnt. Bis Kapitel 5, nach der in den Kapiteln 2 bis 4 beschriebenen Arbeit, hat die Führungskraft sich verändert. Ihre Annahmen haben sich verschoben. Ihre Sprache hat sich verändert. Wenn du die Darstellung in Kapitel 1 revidierst, bricht der Transformationsbogen. Wenn ein Dialog in Kapitel 7 dem widerspricht, was Kapitel 5 über den neuen Ansatz der Führungskraft gesagt hat, bemerkt der Leser es — auch wenn er nicht benennen kann, warum. Selbst in Sachbüchern tragen Personen einen Zustand. Charaktere in Wirtschaftsbüchern sind nicht dekorativ; sie sind strukturell.
Das ist das, was Softwarearchitekten Kopplung nennen — den Grad, in dem eine Komponente von einer anderen abhängt. Die Frage, die diese Disziplin dich lehrt zu stellen, ist schlicht: Wenn ich das ändere, was bricht sonst noch? Ein Manuskript mit vielen solcher Abhängigkeiten macht diese Liste sehr lang. Warum selbst ein Millionen-Tokens-Kontextfenster ChatGPT nicht dazu bringt, ein Manuskript konsistent zu halten, ist in diesem Beitrag über die Architektur der KI-Schreibgrenzen ausführlich beschrieben.
Das zweite Problem: wenn ein einzelnes Kapitel zu viele Aufgaben übernimmt.
Ein Kapitel, das versucht, das HYBRID-Framework einzuführen, es mit einer Kundenfallstudie zu veranschaulichen und gleichzeitig die diagnostische Methodik des nächsten Kapitels aufzubauen, übernimmt drei strukturelle Aufgaben auf einmal. Der Leser fühlt sich verwirrt. Der Lektor sagt: „Dieses Kapitel ist unstrukturiert." Beide haben recht — das Kapitel ist unstrukturiert, weil kein einzelnes Element Raum hat, anzukommen.
Das ist Kohäsion — wie gut die Elemente innerhalb einer einzelnen Einheit zusammenpassen. Der Test ist schlicht: Kannst du in einem Satz formulieren, was dieses Kapitel leisten muss? Wenn die Antwort mehr als einen Hauptsatz erfordert, hat das Kapitel ein Kohäsionsproblem.
Diese beiden Versagensarten hängen mit dem zusammen, was die Lesanalyse-Firma Jellybooks in Publisher-Tests gemessen hat: Die durchschnittliche Buchfertigstellungsrate liegt zwischen 25 und 50 Prozent; weniger als 5 Prozent der Bücher erreichen 75 Prozent Fertigstellung; die höchste Leserzahl entfällt auf Kapitel 1 und nimmt über die frühen Kapitel hinweg ab. In der Spätrevision tauchen diese strukturellen Probleme als zwei Dinge auf, die der Autor nicht immer benennen kann: Inkonsistenz (Frameworks, Kundengeschichten und porträtierte Personen, die abdriften, weil Abhängigkeiten nie gepflegt wurden) und mangelndes Engagement (das Gefühl, dass das Buch den Leser nicht vorwärtszieht, weil der strukturelle Aufbau seine Aufgabe nicht erfüllt hat). Das leserseits sichtbare Symptom ist schlicht, dass sie aufhören.
Was die Daten über Struktur sagen
Im Jahr 2016 analysierten Forscher der University of Vermont (Reagan et al., EPJ Data Science) 1.327 Romane aus der Belletristiksammlung von Project Gutenberg rechnergestützt auf ihre emotionalen Bogenformen. Sie nutzten Sentiment-Analyse, um zu verfolgen, wie die emotionale Valenz einer Geschichte über ihre Länge ansteigt und abfällt, und stellten fest, dass diese Bögen in sechs erkennbare Formen clustern.
Der Befund, der für Autoren relevant ist: Bestimmte emotionale Bogenformen korrelieren mit höheren Download-Zahlen. Die Studie maß Downloads kostenloser E-Books von Project Gutenberg — ein Proxy für Leserpräferenzen, wenn der Kostenfaktor keine Rolle spielt. Es sind keine Verkaufsdaten, aber es ist eine Messung dessen, was Leser wählen, wenn die einzige Variable das Werk selbst ist. Und das Muster ist, allgemein gesagt, dass strukturelle Komplexität der Einfachheit überlegen ist: Geschichten mit komplexeren Bogenformen — solche, die auf eine Weise fallen und steigen, die mehrere Engagementpunkte schafft — tendieren dazu, mehr Leser anzuziehen als Geschichten, die auf einem einzigen linearen Bogen aufgebaut sind.
Der arXiv-Preprint ist unter arXiv:1606.07772 zu finden, für alle, die die Studie direkt lesen möchten.
Was das für einen arbeitenden Autor bedeutet: Die strukturelle Form ist messbar und hat messbare Auswirkungen auf das Leseverhalten. Der emotionale Bogen, den du aufbaust — ob bewusst geplant oder im Laufe der Zeit entstanden — wirkt real auf deine Leser ein. Das zu wissen ist der Beginn der Fähigkeit, ihn bewusst zu gestalten.
Die Revisionsdisziplin, die aus der Software kommt
Der Aufbau von Architektur ist der Ausgangspunkt der strukturellen Metapher. Software ist der Ursprung der Revisionsdisziplin.
Jeremy Hanson-Finger ist ein Belletristikautor, der bei Invisible Publishing, einem kanadischen Literaturverlag, veröffentlicht hat. Im Jahr 2017 dokumentierte er die Verwendung von Git — einem von Softwareingenieuren verwendeten Versionskontrollsystem — zur Verwaltung seines Romans.
Git ist hier nicht als Software relevant. Git ist als Disziplin relevant. Die Praxis, die Hanson-Finger beschreibt, lautet: Jede Änderung am Manuskript musste benannt werden, bevor sie festgeschrieben wurde. Nicht nur gespeichert, sondern benannt. Eine Notiz wie „Reference Llew's bat in tub" zwang ihn, zu formulieren, was die Änderung tat und wo sie wirken würde. Er stellte fest, dass diese Disziplin Kontinuitätsfehler im Vergleich zu seinen früheren Methoden reduzierte. Die Disziplin hatte auch einen sekundären Effekt, den er nicht erwartet hatte: Das Wissen, dass jede Revision benennbar und rückgängig machbar war, befreite ihn, Änderungen vorzunehmen, die er sonst vermieden hätte.
Die strukturelle Erkenntnis betrifft nicht die Versionskontrollsoftware. Sie betrifft das, was das Benennen einer Änderung dich zwingt zu tun. Das gilt für einen Roman ebenso wie für ein Wirtschaftsbuch. Wenn du schreibst „Ausgangs-Kundenzustand in Kapitel 3 revidieren", verpflichtest du dich zu einer zweckgebundenen Änderung — und fragst implizit, wo dieser Kunde sonst noch erscheint. Eine gut benannte Änderung sagt dir etwas über ihre Reichweite.
Die meisten Autoren revidieren in einem anderen Modus: eine Sitzung, ein Durchlesen, eine Handvoll Änderungen, ein neues Speichern. Die Änderungen häufen sich an. Ihre Wechselwirkungen sind implizit. Niemand hat sie benannt. Der Autor, der in Kapitel neun feststellt, dass vier Kapitel überarbeitet werden müssen, war in diesem Modus — und das Problem war nicht, dass die Änderung notwendig war. Das Problem war, dass die Reichweite der Änderung unsichtbar war, bis sie unvermeidbar wurde.
Die Disziplin ist ohne jegliche Software erlernbar. Benenne die Änderung, bevor du sie vornimmst. Frage, was sie berührt. Nimm jeweils eine Änderung vor. Das klingt schlicht. In einem 70.000-Wörter-Manuskript in der Spätrevision ist es überhaupt nicht schlicht — was genau der Grund ist, warum es wichtig ist, eine Methode dafür zu haben.
Wie man ein Buch strukturiert: Vier Praktiken
Vier Praktiken, übertragbar auf jedes Manuskript:
Bevor du ein Kapitel schreibst, benenne seine strukturelle Aufgabe. Eine Aufgabe, klar formuliert. „Dieses Kapitel legt den Ausgangszustand des Kunden fest." „Dieses Kapitel schließt das Argument für die Diagnosemethodik." Wenn der Name mehr als einen Hauptsatz enthält, muss das Kapitel aufgeteilt oder der Umfang geändert werden.
Nach jeder wesentlichen Entscheidung über eine Fallstudie, ein Framework oder eine porträtierte Person frage, was die Entscheidung berührt. Die Rolle eines Kunden ändert sich. Ein Framework wird verfeinert. Der Bogen einer Führungskraft verschiebt sich. Schreibe für jedes dieser Elemente eine kurze Liste der nachgelagerten Kapitel — der Kapitel, die die frühere Version vorausgesetzt haben. Die Liste muss nicht vollständig sein. Sie muss existieren.
Wenn etwas nicht funktioniert, frage zuerst: Kopplung oder Kohäsion? Handelt es sich um ein „zu viele Dinge hängen von dieser einen Sache ab"-Problem oder ein „dieses Kapitel versucht zu viele Dinge zu tun"-Problem? Die Antwort bestimmt die Lösung. Das eine verlangt die Trennung von Fäden; das andere verlangt die Klärung des Fokus.
Strukturelle Revisionen zuerst, Prosa-Revisionen danach. Es hat keinen Sinn, einen Absatz zu straffen, den du später kürzen wirst. Zu korrigieren, wo ein Kapitel in der Struktur sitzt — was es tut, womit es verbunden ist — ist architektonische Arbeit. Diese Arbeit gehört vor den satzebenen Durchgang. Architekten korrigieren den Plan, bevor die Handwerker die Böden schleifen.
Noch eine Sache, die es wert ist, benannt zu werden: Ein menschlicher Lektor ist das strukturelle Review. Wenn jemand fragt „Warum erscheint dieser Kunde hier?" oder „Ich habe den Faden aus Kapitel drei verloren", betreibt er Kopplungs- und Kohäsionsanalyse, ohne es so zu nennen. Das ist das Pair-Programming-Äquivalent — die strukturelle Prüfung, die du von innen des Gebäudes, das du gebaut hast, nicht sehen kannst.
Die Autoren auf unserer Seite mit veröffentlichten Büchern umfassen Menschen, die speziell in der Phase der strukturellen Revision zu uns kamen, als sie die Worte, aber nicht die Architektur hatten. Die strukturelle Arbeit fand in der Zusammenarbeit statt, Kapitel für Kapitel.
Wo du anfangen solltest, wenn deine Struktur bereits in Frage steht
Ein Buch zu schreiben ist ebenso ein struktureller Akt wie ein kreativer. Marion schrieb am Dienstag über den Mut zum Anfangen. Darum geht es hier: um die Disziplin, etwas zu bauen, das hält, sobald man begonnen hat.
Die meisten strukturellen Probleme werden nicht entdeckt, wenn sie noch klein sind. Sie tauchen in Kapitel neun auf, oder in einem Entwicklungslektorat, oder wenn ein Leser das Buch weglegt, ohne zu wissen, warum. Die Autoren, die diesen Punkt vermeiden, sind keine talentierteren Schriftsteller. Sie sind bewusstere Architekten.
Wenn du an dem Punkt bist, an dem du begonnen hast zu schreiben und dich fragst, ob das, was du baust, strukturell solide ist, würde ich gern von deinem Projekt hören. Ein Book Positioning Report ist eine Möglichkeit, frühzeitig strukturelle Klarheit zu gewinnen — bevor die Kosten einer Korrektur sich aufschaukeln. Oder wenn du lieber zuerst ein Gespräch führen möchtest, buche einen kostenlosen Anruf und wir können gemeinsam ansehen, was du baust.
Andrea Tomasini ist Gründer und Systemarchitekt von my-book.ai, wo er das Engineering und das Prozessdesign hinter dem Service leitet. Er verbrachte zwei Jahre damit, das Konsistenz- und Strukturverfolgungssystem aufzubauen, das hinter jedem Buchprojekt steht — und zwei Jahrzehnte zuvor damit, Organisationen beim Aufbau besserer Engineering-Systeme zu helfen, eine Disziplin, die sich als ebenso anwendbar auf Manuskripte erweist wie auf Software.