Sie befinden sich in Kapitel neun. Sie stellen ein Diagnoseframework vor, das Ihr Kunde — ein Führungsteam, mit dem Sie seit Kapitel 3 zusammenarbeiten — nun bereit ist anzuwenden. Doch das Framework erfordert eine spezifische Organisationsstruktur, die dem Ausgangszustand widerspricht, den Sie vier Kapitel zuvor beschrieben haben. Das Unternehmen, das Sie in Kapitel 3 beschrieben haben, kann auf dem von Ihnen beschriebenen Weg nicht in Kapitel 9 ankommen.
Sie verfolgen den Faden zurück. Vier Kapitel beziehen sich auf einen Ausgangszustand, den Sie nun revidieren müssen. 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 Sie eigentlich bauen 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. Es 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. Ändern Sie, wo die Treppe liegt, und Sie ändern, 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. Ändern Sie ein Modul, und Sie ändern 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 Sie in Kapitel 3 einführen, muss in Kapitel 8 noch Bestand haben. Der Kunde, mit dem Sie in Kapitel 2 beginnen, 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 Sie zu bauen beabsichtigt haben. Das Manuskript ist das, was Sie gebaut haben. Diese beiden Dinge sind oft nicht identisch.
Zwei Arten des Scheiterns, die Sie spüren können
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 Sie eine Sache ändern 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 Sie den Aufbau aus Kapitel 3 revidieren — selbst ein Detail, selbst eine Berufsbezeichnung — müssen Sie 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, haben sie sich verändert. Ihre Annahmen haben sich verschoben. Ihre Sprache hat sich verändert. Wenn Sie die Darstellung in Kapitel 1 revidieren, bricht der Transformationsbogen. Wenn ein Dialog in Kapitel 7 dem widerspricht, was Kapitel 5 über ihren neuen Ansatz 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 es Sie lehrt zu stellen, ist einfach: Wenn ich das ändere, was bricht sonst noch? Ein Manuskript mit vielen solcher Abhängigkeiten macht diese Liste sehr lang.
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 einfach: Können Sie 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 Sie aufbauen — ob geplant oder im Laufe der Zeit entstanden — arbeitet real auf Ihren 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. Es 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. Sie 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 Sie zwingt zu tun. Das gilt für einen Roman ebenso wie für ein Wirtschaftsbuch. Wenn Sie schreiben „Ausgangs-Kundenzustand in Kapitel 3 revidieren", verpflichten Sie sich zu einer zweckgebundenen Änderung — und fragen implizit, wo dieser Kunde sonst noch erscheint. Eine gut benannte Änderung sagt Ihnen 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. Es war, dass die Reichweite der Änderung unsichtbar war, bis sie unvermeidbar wurde.
Die Disziplin ist ohne jegliche Software erlernbar. Benennen Sie die Änderung, bevor Sie sie vornehmen. Fragen Sie, was sie berührt. Nehmen Sie jeweils eine Änderung vor. Das klingt einfach. In einem 70.000-Wörter-Manuskript in der Spätrevision ist es überhaupt nicht einfach — 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 Sie ein Kapitel schreiben, benennen Sie 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 fragen Sie, was es berührt. Die Rolle eines Kunden ändert sich. Ein Framework wird verfeinert. Der Bogen einer Führungskraft verschiebt sich. Schreiben Sie 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, fragen Sie 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 Sie später kürzen werden. Zu korrigieren, wo ein Kapitel in der Struktur sitzt — was es tut, womit es verbunden ist — ist architektonische Arbeit. Sie 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 Sie von innen des Gebäudes, das Sie gebaut haben, nicht sehen können.
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 Sie anfangen sollten, wenn Ihre 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 Sie an dem Punkt sind, an dem Sie begonnen haben zu schreiben und sich fragen, ob das, was Sie bauen, strukturell solide ist, würde ich gern von Ihrem 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 Sie lieber zuerst ein Gespräch führen möchten, buchen Sie einen kostenlosen Anruf und wir können gemeinsam ansehen, was Sie bauen.
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.