Sei al capitolo nove. Stai presentando un framework diagnostico che il tuo cliente — un team di leadership con cui lavori dal capitolo 3 — è ora pronto ad applicare. Ma il framework richiede una configurazione organizzativa specifica che contraddice la descrizione dello stato iniziale che hai scritto quattro capitoli prima. L'azienda che hai descritto nel capitolo 3 non può arrivare al capitolo 9 nel modo in cui l'hai scritta.
Segui il filo. Quattro capitoli fanno riferimento a uno stato iniziale che ora devi rivedere. Il cambiamento non riguarda la scrittura. Riguarda la struttura. Sapere come strutturare un libro non è la stessa cosa che sapere come riempire le sue pagine.
La maggior parte degli autori scopre l'architettura del proprio libro dopo averlo già costruito. Gli ingegneri software hanno imparato a non farlo quarant'anni fa.
Marion ha scritto martedì della paura di iniziare — perché il primo capitolo è più difficile di quanto sembri, e cosa fare a riguardo. Questo post parla di ciò che viene dopo aver iniziato: cosa stai effettivamente costruendo, e cosa serve per costruire qualcosa che regga.
Cos'è davvero un libro
Due discipline hanno capito la stessa cosa molto prima dell'editoria.
Gli architetti sanno che un mucchio di materiali non è un edificio. Ha muri portanti, stanze che si collegano in un ordine specifico, impianti idraulici ed elettrici che si sviluppano da un piano all'altro secondo un progetto. Cambia dove vanno le scale e cambi cosa c'è sopra e sotto di esse. I materiali sono gli stessi; è la struttura a fare di essi un edificio.
Gli ingegneri software sanno che una cartella di file non è un sistema. Un codebase ha moduli, dipendenze, stato condiviso, interfacce. Cambia un modulo e cambi tutto ciò che dipende da esso. Il codice è lo stesso; è l'architettura a farlo funzionare.
Un libro funziona allo stesso modo. Nello specifico, funziona come entrambi.
Un libro di business, una raccolta di casi studio, una guida metodologica: ciascuno contiene framework, storie di clienti e persone profilate. Ogni elemento ha uno stato — una condizione attuale che si accumula nel corso del libro e vincola ciò che può venire dopo. Il framework che introduci nel capitolo 3 deve reggere ancora nel capitolo 8. Il cliente con cui apri nel capitolo 2 deve portare la stessa storia iniziale quando riappare nel capitolo 7. Il leader profilato che ha imparato qualcosa nel capitolo 4 porta quell'apprendimento nel capitolo 6. Nessuno di questi elementi è indipendente.
Un outline è ciò che avevi intenzione di costruire. Il manoscritto è ciò che hai costruito. Queste due cose spesso non coincidono.
Due modalità di fallimento che puoi sentire
Ci sono due problemi strutturali che compaiono in quasi ogni manoscritto che ho visto in fase di revisione avanzata. Sono problemi diversi. Si percepiscono in modo diverso. E hanno cause diverse.
Il primo problema: quando cambi una cosa e tutto si rompe.
Nel libro di un consulente, un caso studio nel capitolo 3 stabilisce lo stato iniziale di un'azienda: la composizione del team di leadership, il loro modello operativo, la loro diagnosi iniziale del problema. Questa impostazione si porta avanti per tutto il resto del libro. L'applicazione del framework nel capitolo 7 dipende da chi era il team del cliente. Il risultato nel capitolo 10 dipende dalla diagnosi dello stato iniziale. Se rivedi l'impostazione del capitolo 3 — anche un dettaglio, anche un titolo professionale — devi inseguire ogni riferimento a valle, perché ogni capitolo successivo è stato scritto sulla base di quella versione originale.
La stessa logica si applica alle persone. Un leader profilato appare nel capitolo 1 con una mentalità e un approccio gestionale specifici — il suo modo di pensare prima dell'inizio del percorso di consulenza. Entro il capitolo 5, dopo il lavoro descritto nei capitoli da 2 a 4, è cambiato. Le sue assunzioni si sono evolute. Il suo linguaggio è cambiato. Se rivedi il ritratto del capitolo 1, l'arco di trasformazione si rompe. Se un dialogo nel capitolo 7 contraddice ciò che il capitolo 5 ha detto del suo nuovo approccio, il lettore se ne accorge — anche se non riesce a dire perché. Anche nella narrativa non fiction, le persone portano uno stato. I personaggi nei libri di business non sono decorativi; sono strutturali.
Questo è ciò che gli architetti software chiamano coupling — il grado in cui un componente dipende da un altro. La domanda che insegna a porsi è semplice: se cambio questo, cos'altro si rompe? Un manoscritto con un accoppiamento stretto rende quella lista molto lunga.
Il secondo problema: quando un singolo capitolo sta svolgendo troppi lavori.
Un capitolo che cerca di introdurre il framework HYBRID, illustrarlo con un caso studio di un cliente e contemporaneamente preparare la metodologia diagnostica del capitolo successivo sta svolgendo tre lavori strutturali in una volta. Il lettore si sente confuso. L'editor dice "questo capitolo è poco focalizzato". Entrambi hanno ragione — il capitolo è poco focalizzato perché nessun elemento ha spazio per sedimentarsi.
Questa è la coesione — quanto bene gli elementi all'interno di una singola unità appartengono insieme. Il test è semplice: riesci a dire in una frase cosa deve fare questo capitolo? Se la risposta richiede più di una clausola principale, il capitolo ha un problema di coesione.
Queste due modalità di fallimento si collegano a ciò che la società di analisi della lettura Jellybooks ha misurato attraverso i test degli editori: il tasso medio di completamento dei libri è tra il 25 e il 50 per cento; meno del 5 per cento dei libri raggiunge il 75 per cento di completamento; il picco di lettura si verifica al capitolo 1 e diminuisce nei capitoli successivi. In fase di revisione avanzata, quei problemi strutturali si manifestano come due cose che l'autore non sempre riesce a nominare: incoerenza (framework, storie di clienti e persone profilate che si sgretolano perché le dipendenze non sono mai state mantenute), e mancanza di coinvolgimento (la sensazione che il libro non stia trascinando il lettore avanti perché l'impostazione strutturale non ha fatto il suo lavoro). Il sintomo visibile al lettore è semplicemente che si ferma.
Cosa dicono i dati sulla struttura
Nel 2016, i ricercatori dell'Università del Vermont (Reagan et al., EPJ Data Science) hanno analizzato computazionalmente 1.327 romanzi della raccolta di narrativa di Project Gutenberg per la forma dell'arco emotivo. Hanno utilizzato l'analisi del sentiment per tracciare come la valenza emotiva di una storia sale e scende nel corso della sua lunghezza, e hanno scoperto che questi archi si raggruppano in sei forme riconoscibili.
La scoperta che conta per gli autori: particolari forme di arco emotivo si correlano con un numero più elevato di download. Lo studio ha misurato i download di ebook gratuiti da Project Gutenberg — un indicatore della preferenza del lettore quando il costo non è un fattore. Non sono dati di vendita, ma è una misurazione di ciò che i lettori scelgono di prendere quando l'unica variabile è l'opera stessa. E il pattern, in linea generale, è che la complessità strutturale supera la semplicità: le storie con forme di arco più complesse — quelle che scendono e salgono in modi che creano molteplici punti di coinvolgimento — tendono ad attrarre più lettori rispetto alle storie costruite su un unico arco lineare.
Il preprint su arXiv è disponibile su arXiv:1606.07772, per chiunque voglia leggere lo studio direttamente.
Cosa significa questo per un autore in attività: la forma strutturale è misurabile, e ha effetti misurabili sul comportamento del lettore. L'arco emotivo che costruisci — che sia pianificato o accumulato — sta facendo un lavoro reale sul tuo lettore. Saperlo è l'inizio della possibilità di modellarlo deliberatamente.
La disciplina di revisione che viene dal software
L'architettura edilizia è dove è iniziata la metafora strutturale. Il software è da dove viene la disciplina di revisione.
Jeremy Hanson-Finger è un autore di narrativa pubblicato da Invisible Publishing, una casa editrice letteraria canadese. Nel 2017, ha documentato l'uso di Git — un sistema di controllo versione usato dagli ingegneri software — per gestire il suo romanzo.
Git non è rilevante qui come software. È rilevante come disciplina. La pratica che Hanson-Finger descrive è questa: ogni modifica al manoscritto doveva essere nominata prima di essere confermata. Non solo salvata, ma nominata. Un messaggio come "Reference Llew's bat in tub" lo costringeva ad articolare cosa stava facendo la modifica e dove avrebbe avuto impatto. Ha scoperto che questa disciplina riduceva gli errori di continuità rispetto ai suoi metodi precedenti. Aveva anche un effetto secondario che non si aspettava: sapere che ogni revisione era nominabile e reversibile lo liberava di fare cambiamenti che altrimenti avrebbe evitato.
L'intuizione strutturale non riguarda il software di controllo versione. Riguarda ciò che ti costringe a fare il fatto di nominare un cambiamento. Questo si applica ugualmente a un romanzo e a un libro di business. Quando scrivi "rivedi lo stato iniziale del cliente nel capitolo 3", stai assumendo un impegno verso un cambiamento a scopo singolo — e stai implicitamente chiedendo dove altro appare quel cliente. Un cambiamento ben nominato ti dice qualcosa sulla sua portata.
La maggior parte degli autori rivede in una modalità diversa: una sessione, una rilettura, una manciata di modifiche, un nuovo salvataggio. Le modifiche si accumulano. Le loro interazioni sono implicite. Nessuno le ha nominate. L'autore che scopre al capitolo nove che quattro capitoli richiedono revisione è stato in quella modalità — e il problema non era che il cambiamento fosse necessario. Era che la portata del cambiamento era invisibile finché non era inevitabile.
La disciplina è apprendibile senza alcun software. Nomina il cambiamento prima di apportarlo. Chiedi cosa tocca. Fai un cambiamento alla volta. Sembra semplice. In un manoscritto di 70.000 parole in fase di revisione avanzata, non è affatto semplice — il che è esattamente il motivo per cui avere un metodo è importante.
Come strutturare un libro: quattro pratiche
Quattro pratiche, trasferibili a qualsiasi manoscritto:
Prima di scrivere un capitolo, nominane il lavoro strutturale. Un lavoro, espresso chiaramente. "Questo capitolo stabilisce lo stato iniziale del cliente." "Questo capitolo chiude l'argomentazione per la metodologia diagnostica." Se il nome ha più di una clausola principale, il capitolo deve essere diviso o l'ambito deve cambiare.
Dopo ogni decisione significativa riguardante un caso studio, un framework o una persona profilata, chiedi cosa tocca. Il ruolo di un cliente cambia. Un framework viene raffinato. L'arco di un leader si modifica. Per ciascuno di questi, scrivi un breve elenco dei capitoli a valle — i capitoli che assumevano la versione precedente. L'elenco non deve essere completo. Deve esistere.
Quando qualcosa si rompe, chiedi prima coupling o coesione. È un problema del tipo "troppe cose si collegano a questa singola cosa", o un problema del tipo "questo capitolo sta cercando di fare troppe cose"? La risposta determina la soluzione. Uno richiede di separare i fili; l'altro richiede di chiarire il focus.
Prima le revisioni strutturali, poi le revisioni della prosa. Non ha senso rifinire un paragrafo che poi taglierai. Sistemare dove si trova un capitolo nella struttura — cosa fa, cosa collega — è un lavoro architettonico. Va fatto prima del passaggio a livello di frase. Gli architetti sistemano il progetto prima che i rifinitori levighino i pavimenti.
Un'ultima cosa da nominare: un editor umano è la revisione strutturale. Quando qualcuno chiede "perché questo cliente appare qui?" o "ho perso il filo dal capitolo tre", sta facendo un'analisi di coupling e coesione senza chiamarla così. Questo è l'equivalente della programmazione in coppia — il controllo strutturale che non riesci a vedere dall'interno di ciò che hai costruito.
Gli autori nella nostra pagina dei libri pubblicati includono persone che sono venute da noi specificamente nella fase di revisione strutturale, quando avevano le parole ma non l'architettura. Il lavoro strutturale è avvenuto in collaborazione, capitolo per capitolo.
Da dove iniziare se la tua struttura è già in discussione
Scrivere un libro è un atto strutturale tanto quanto un atto creativo. Marion ha scritto martedì del coraggio di iniziare. Questo riguarda la disciplina di costruire qualcosa che regga una volta che lo hai fatto.
La maggior parte dei problemi strutturali non vengono scoperti quando sono piccoli. Emergono al capitolo nove, o in una revisione editoriale di sviluppo, o quando un lettore chiude il libro senza sapere perché. Gli autori che evitano quel momento non sono scrittori più talentuosi. Sono architetti più deliberati.
Se sei al punto in cui hai iniziato a scrivere e ti stai chiedendo se ciò che stai costruendo è strutturalmente solido, mi piacerebbe sentire del tuo progetto. Un Book Positioning Report è un modo per ottenere chiarezza strutturale in anticipo — prima che il costo di sistemarlo si cumuli. Oppure, se preferisci prima una conversazione, prenota una chiamata gratuita e possiamo esaminare insieme ciò che stai costruendo.
Andrea Tomasini è fondatore e architetto di sistema di my-book.ai, dove guida l'ingegneria e il design dei processi alla base del servizio. Ha trascorso due anni a costruire il sistema di coerenza e tracciamento strutturale che sta dietro a ogni progetto di libro — e due decenni prima di allora ad aiutare le organizzazioni a costruire sistemi ingegneristici migliori, una disciplina che si rivela applicabile ai manoscritti tanto quanto al software.