Idea principale

Un libro scritto su un metodo di lavoro può essere scritto dentro quel metodo: le fonti, i capitoli, le decisioni di scrittura, i passaggi tagliati e il motivo del taglio restano nello spazio di lavoro che il libro descrive. Riprendere un capitolo dopo tre settimane di interruzione non richiede allora di rileggerlo — si chiede a che punto si era e cosa si era deciso di non metterci. Le traduzioni e le diverse edizioni escono dallo stesso posto, senza rimettere mano al testo.

Il deliverable ottenuto non illustra il metodo: lo attesta. Una descrizione dice cosa il sistema dovrebbe permettere; un libro di diverse centinaia di pagine, tradotto e ripreso nell'arco di mesi, dice cosa ha realmente permesso, anche là dove la descrizione resta vaga.

Perché è importante

Questo sposta ciò che si chiede all'autore di un metodo. La domanda non è più «è coerente?» ma «cosa ci hai prodotto?» — e la risposta è verificabile da un lettore che non deve credere a nulla sulla parola.

Cambia anche il modo di annunciare un metodo. Un articolo che descrive il sistema convince meno di un deliverable che non sarebbe potuto esistere senza di esso: il secondo contiene la propria prova d'uso, e rende visibili gli oneri che la descrizione tace — la durata, le interruzioni, il volume, le riprese.

Sfumature e limiti

Un deliverable prodotto dal suo autore prova solo la praticabilità per quell'autore. Non dice nulla di quanto il metodo costi a chi non l'ha costruito, né di cosa regge quando passa in più mani.

E un deliverable riuscito può esserlo nonostante il metodo, per ostinazione più che per sistema: la prova riguarda ciò che è stato prodotto, non l'attribuzione del merito.

Domande aperte

• Cosa, in un deliverable, permetterebbe a un lettore esterno di distinguere ciò che il metodo ha reso possibile da ciò che l'autore avrebbe prodotto senza di esso?