Issue 10081
La review non è un rito: è una decisione
Opzioni esplicite, Decision Rights visibili e un esito scritto trasformano una presentazione affollata in una scelta governabile.
· 5 min
Obiettivo
Usare la review come decisione (opzioni, owner, revert), non come teatro di slide.
Progetta la review a partire dalla decisione
Prima di convocare la riunione, scrivi la decisione da prendere in una frase e rendi espliciti i Decision RightsGlossarioDecision RightsL’assegnazione esplicita di chi decide, chi contribuisce e chi possiede le conseguenze.Apri la voce completa: chi decide, chi fornisce input e chi deve essere informato. Porta poche opzioni realmente praticabili, inclusa quella di non intervenire, e confrontale con gli stessi criteri: qualità di sistema, costo, rischio, tempi e impatto operativo. Per ciascuna opzione chiarisci assunzioni e conseguenze. Chiudi la review registrando decisione, owner, motivazioni, condizioni di validità e modalità di revert. Se manca uno di questi elementi, la riunione può aver creato allineamento, ma non ha ancora prodotto una scelta governabile.
Più decidibilità, meno inclusività apparente
Rendere esplicito chi decide riduce l'ambiguità e accelera l'esecuzione, ma può sembrare meno inclusivo rispetto a una stanza in cui tutti hanno uguale voce formale. Limitare le opzioni migliora il confronto, ma richiede lavoro preparatorio e può escludere alternative immature. Documentare motivazioni e criteri aumenta tracciabilità e responsabilità, al prezzo di una disciplina che rallenta leggermente la chiusura. Definire un revert rende accettabili le decisioni sotto incertezza, ma non tutte le scelte sono facilmente reversibili: migrazioni dati, contratti e cambiamenti organizzativi possono imporre costi di ritorno elevati. Il punto non è decidere sempre più velocemente, ma distinguere le decisioni reversibili da quelle che richiedono più evidenze.
Dalla discussione sul database a una scelta verificabile
Un'azienda deve scegliere se separare il database di un servizio ordini dal monolite. Alla review partecipano architetti, sviluppo, operations, sicurezza, finanza e responsabili di prodotto. Invece di presentare quaranta slide, il Solution Architect propone tre opzioni: mantenere il database condiviso, separare subito lo storage oppure introdurre prima un confine logico con replica degli eventi. I criteri sono autonomia dei team, consistenza, rischio di migrazione, costo operativo e tempo di rilascio. Il responsabile della piattaforma è indicato come decision owner; sicurezza e operations forniscono vincoli, mentre i team applicativi sono consultati. Si sceglie il confine logico per novanta giorni, con metriche su incidenti, latenza e frequenza di rilascio. L'esito viene registrato con owner, assunzioni e soglie che attivano conferma, revisione o revert. La review non elimina il dissenso: lo converte in criteri osservabili.
Un controllo rapido prima di chiudere
Negli ultimi cinque minuti verifica ad alta voce cinque punti: quale opzione è stata scelta, chi ne è owner, quali motivazioni hanno prevalso, quali condizioni potrebbero invalidarla e dove sarà conservata la decisione. Assegna una data di revisione soltanto se esiste un'incertezza da verificare; una scadenza rituale senza nuove evidenze genera un'altra riunione, non migliore governance.
Per approfondire
Fonti autorevoli per strutturare diritti decisionali e registrare le decisioni architetturali. • Documenting Architecture Decisions — Michael Nygard, Cognitect — https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions • RAPID Decision-Making — Bain & Company — https://www.bain.com/insights/rapid-tool-to-clarify-decision-accountability/