Tre domande prima di disegnare

Prima di aprire il board, chiarisci risultato, decisioni già prese e potere di veto.

Obiettivo

Partire da tre domande (risultato, già deciso, chi può fermarlo) e non da un board di componenti.

practice

Il board non sostituisce il mandato

Quando ti chiedono un workshop di architettura, la tentazione è preparare subito componenti, flussi e post-it. Fermati prima su tre domande: quale risultato dobbiamo ottenere, che cosa è già stato deciso e chi può fermare o invalidare la decisione? La prima definisce l'esito concreto del lavoro. La seconda separa i veri spazi decisionali dai vincoli già fissati. La terza fa emergere autorità, veto e stakeholderGlossarioStakeholderUna persona o un gruppo che influenza una decisione o ne sperimenta gli effetti.Apri la voce completa mancanti. Per ogni risposta chiedi un owner e una conferma esplicita. Se una domanda resta aperta, registra il debito decisionaleGlossarioDebito decisionaleUn impegno già comunicato senza owner, criterio di fallimento e possibilità di revert.Apri la voce completa e risolvilo prima di trasformare ipotesi fragili in un disegno dettagliato.

trade-offs

Meno velocità apparente, più decisioni utilizzabili

Questa pratica può rallentare l'avvio e rendere visibili conflitti che qualcuno preferirebbe lasciare impliciti. Può anche ridurre la libertà progettuale quando fa emergere decisioni già irreversibili. In cambio evita workshop ricchi di artefatti ma poveri di autorità, riduce il rework e rende chiaro chi deve approvare cosa. Il punto non è aspettare una governance perfetta: per decisioni reversibili puoi procedere dichiarando assunzioni, owner e data di revisione. Per scelte costose o difficili da invertire, come un modello operativo condiviso o un vincoloGlossarioVincoloUna condizione che limita lo spazio delle soluzioni praticabili e non può essere semplicemente ignorata.Apri la voce completa normativo, l'assenza di chi può fermarle è invece un motivo concreto per non chiudere il disegno.

enterprise-example

Il workshop per la nuova piattaforma ordini

Un'impresa retail pianifica due giorni per disegnare una piattaforma ordini omnicanale. La prima domanda chiarisce il risultato: decidere entro venerdì il confine tra gestione ordini e fulfillment, non produrre l'architettura completa. La seconda rivela che il sistema ERP e il provider logistico sono già contrattualmente vincolati. La terza mostra che il responsabile delle operations, titolare degli SLA e in grado di respingere il modello, non è stato invitato. Il Solution Architect rinvia la decisione sul confine, coinvolge operations e usa il primo incontro per validare risultato, vincoli e criteri. Si produce meno diagramma, ma la sessione successiva parte con il mandatoGlossarioMandatoL'autorizzazione esplicita a occuparti di un risultato, con confini su cosa puoi decidere e cosa puoi solo rendere visibile.Apri la voce completa necessario e con decision maker reali nella stanza.

references

Per approfondire

Fonti autorevoli per approfondire decision rightsGlossarioDecision RightsL’assegnazione esplicita di chi decide, chi contribuisce e chi possiede le conseguenze.Apri la voce completa, responsabilità e preparazione delle decisioni architetturali. • Roles, responsibilities, and resources — Project Management Institute — https://www.pmi.org/learning/library/best-practices-managing-people-quality-management-7012 • The RAPID Decision-Making Model - Bain & Company - https://www.bain.com/insights/rapid-tool-to-clarify-decision-accountability/

Da ricordare

Prima di disegnare, rendi espliciti risultato, decisioni già prese e potere di veto. Se manca un owner, il problema non è la facilitazione: è il mandato decisionale.

Per la prossima riunione

Come Solution Architect, quale delle tre domande — risultato, già deciso o chi può fermarlo — è oggi senza una risposta credibile nella tua prossima conversazione architetturale?

Una domanda per te