> ## Content Index > Fetch the complete content index at: https://myagilestories.com/llms.txt > Use this file to discover other available public pages before exploring further. # Una decisione non registrata torna in riunione - URL: https://myagilestories.com/una-decisione-non-registrata-torna-in-riunione/ - Published: 2026-08-31T05:30:00.000Z - Updated: 2026-08-31T05:30:00.000Z - Description: Quello che resta scritto di una riunione è quasi sempre l'esito, non il ragionamento che ci ha portato. Senza quel pezzo, tre mesi dopo, la decisione non si può verificare: si può soltanto riprendere da capo. - Author: Gaetano Frascolla - Tags: Decisioni C'è un modo abbastanza semplice per capire quanto tiene una decisione: contare quante volte torna in agenda dopo essere stata presa. Non i suoi effetti, non gli aggiornamenti su come sta andando. Proprio quella scelta lì, rimessa sul tavolo da capo, con le alternative già valutate una volta e spesso con le persone che c'erano. Accade più di quanto si ammetta, e quasi mai per malafede. Succede perché di quella decisione, fuori dalla stanza in cui è stata presa, non è rimasto niente che qualcun altro possa leggere. Non tutte le riaperture sono un difetto. Una decisione si rivede quando cambia il contesto, e rivederla è un lavoro serio quanto prenderla. La differenza sta nel punto di partenza: chi rivede sa che cosa era stato deciso e su quale ragionamento, e mette in discussione quel ragionamento; chi ha dimenticato riparte dal foglio bianco, e paga una seconda volta un lavoro già fatto. ## Il verbale tiene l'esito e perde la scelta Qualcosa, di solito, viene scritto. Ci sono le note della riunione, una riga su un canale, una card spostata di colonna. Quello che resta scritto, però, è quasi sempre l'esito: si è deciso A. Quello che non resta è come ci si è arrivati. Quali erano le altre strade, quale vincolo le ha escluse, che cosa si dava per vero quel giorno. Sembra informazione superflua nel momento in cui la si scrive, perché lì ce l'hanno in testa tutti. Diventa l'unica che serve tre mesi dopo, quando qualcuno chiede perché non si è fatto B. Senza il ragionamento, a quella domanda non si può rispondere: si può soltanto rifare la discussione. E la discussione rifatta non è mai la copia della prima. Le persone in stanza sono altre, le informazioni disponibili sono cambiate, il tempo per pensarci è meno. Può atterrare in un punto diverso, e ogni tanto è perfino un bene. Il guaio è quando atterra in un punto diverso senza che nessuno se ne accorga: da lì in avanti l'organizzazione ha due decisioni vive sulla stessa cosa, tutte e due prese in buona fede, e nessuno sa quale delle due stia governando il lavoro. ## Ogni conoscenza vuole un posto solo Hunt e Thomas, in *The Pragmatic Programmer*, tengono molto a un principio che dentro il software è quasi ovvio e fuori dal software non si applica quasi mai: ogni pezzo di conoscenza dovrebbe avere un unico posto autorevole dove sta scritto. Il costo della duplicazione non è lo spazio che occupa. È che le copie, andando avanti, divergono. Le decisioni di un'organizzazione vivono di solito nella forma peggiore di duplicazione: parecchie copie, tutte dentro la testa di qualcuno. Divergono anche quelle, con la differenza che nessuno se ne accorge, perché qui non c'è nessun compilatore che si fermi e segnali il conflitto. Il conflitto si vede molto più tardi, quando due persone agiscono in modo incompatibile su una cosa che era stata decisa una volta sola, e ciascuna è convinta di stare eseguendo. > Una decisione che vive solo nella memoria di chi c'era non sta coordinando il lavoro: sta aspettando di essere ridiscussa. ## Una traccia corta, e nessuno strumento nuovo Basta poco, e non serve un tool né un formato buono per tutti. Serve che da qualche parte, in un posto che chi non era in riunione sa raggiungere da solo, restino cinque informazioni: che cosa si è deciso, quale vincolo o quale dato ha determinato la scelta, quale alternativa è stata scartata e per quale motivo, chi ne è owner, cioè chi può dire oggi se quella decisione tiene ancora, e a quali condizioni va rimessa in discussione. Sono cinque righe. Costano meno di dieci minuti in coda a una riunione, e sono i dieci minuti che si tende a non spendere, perché ormai la cosa sembra chiusa e la stanza ha fretta di uscire. È lì, in quei dieci minuti, che si stabilisce se quella decisione verrà pagata una volta o tre. L'ultima delle cinque righe è la meno intuitiva ed è quella che fa più lavoro. Una decisione con scritto a quali condizioni va rivista non chiede fedeltà eterna a nessuno: dichiara la propria data di scadenza, e toglie di mezzo l'idea che riaprirla sia un atto ostile verso chi l'aveva presa. ## La traccia lavora per chi arriva dopo Il valore di un registro non si vede mentre lo si scrive. Si vede quando entra una persona nuova, quando qualcuno rientra da un mese di assenza, quando un gruppo eredita un lavoro deciso da altri. In tutti questi casi la domanda che arriva è quasi sempre questa: perché qui si fa così? Se a quella domanda risponde una persona, quella persona diventa un passaggio obbligato per chiunque, e la conoscenza dell'organizzazione resta privata anche quando tutti sono in buona fede. Se la risposta è un posto, chi arriva ci va da solo, e chi sapeva torna a fare il proprio mestiere invece di fare da memoria di tutti. Un registro non fa prendere decisioni migliori, e chi lo presenta come uno strumento di qualità promette una cosa che non può mantenere. Fa un lavoro più piccolo e più affidabile: fa in modo che una decisione presa una volta si paghi una volta sola, e che chi arriva dopo possa metterla in discussione invece di doverla riscoprire. Poi certo, esistono organizzazioni dove le decisioni non si scrivono perché scriverle le renderebbe verificabili, e quello è un problema diverso, che nessun formato risolve. Ma nella maggior parte dei casi sotto non c'è niente di così sofisticato: c'è solo che alla fine di una riunione si ha fretta. Il conto di quella fretta lo paga qualcun altro, qualche settimana dopo, in una riunione che nessuno aveva messo in calendario. ## Riferimenti - Andrew Hunt, David Thomas, *The Pragmatic Programmer*