Quando lo stakeholder non decide, il problema non è solo il ritardo

Dalla serie

Obiettivo

Riconoscere quando l'assenza di una decisione deriva da ownership ambigua, rischio personale, criteri incompleti o consenso apparente, e trasformare la situazione in una scelta esplicita e verificabile.

Cosa fare davvero quando la decisione si blocca

La decisione doveva arrivare venerdì. È martedì, il team è fermo e la risposta è ancora: «Devo pensarci». Quando uno stakeholderGlossarioStakeholderUna persona o un gruppo che influenza una decisione o ne sperimenta gli effetti.Apri la voce completa rimanda, la reazione istintiva è chiedere un responso più in fretta. In pratica, però, quasi mai basta. Da Solution Architect ti serve rendere la decisione leggibile: chi ne è owner, quali opzioni sono davvero in gioco, quali criteri distinguono una scelta dall'altra e quale conseguenzaGlossarioConseguenzaUn effetto atteso, positivo o negativo, di una decisione.Apri la voce completa ha il rinvio. Il punto non è forzare la mano, ma capire perché la decisione non arriva. Le cause più comuni sono quattro: ownership poco chiara, rischio personale percepito, criteri incompleti e consensoGlossarioConsensoUn impegno condiviso sufficiente a sostenere una decisione, non necessariamente una preferenza unanime.Apri la voce completa apparente tra più persone. Ogni causa richiede un intervento diverso. Se l'ownership è ambigua, serve esplicitare chi decide. Se il rischio è politico, aiuta separare la scelta tecnica dalla responsabilità di business. Se mancano i criteri, bisogna definire cosa rende un'opzione migliore dell'altra. Se c'è un consenso finto, conviene portare il disaccordo in superficie invece di aspettare un allineamento che non arriva mai. Una buona pratica è riformulare la decisione in modo verificabile: «Entro venerdì scegliamo tra A e B, usando questi tre criteri, e se non decidiamo il delivery slitta di due settimane». Così non stai imponendo la risposta: stai rendendo visibili opzioni, trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa e impatto. • Identifica l'owner della decisione e distinguilo dai semplici contributor. • Riduci le opzioni a quelle realmente praticabili. • Definisci criteri di scelta che il gruppo riconosce come legittimi. • Rendi esplicite le conseguenze del rinvio. • Chiudi con una scadenza che abbia senso per il lavoro, non solo per il meeting.

I trade-off da dichiarare apertamente

Spingere troppo può creare difesa e politiche interne. Aspettare troppo, invece, normalizza lo stallo e rende l'architettura un esercizio di rinvio. Il trade-off vero è tra velocità della decisione e ampiezza del coinvolgimento: se cerchi il consenso di tutti su ogni dettaglio, spesso ottieni immobilità; se cerchi solo rapidità, rischi di lasciare dietro di te resistenze che riemergeranno durante la delivery. C'è anche un altro equilibrio da gestire: proteggere lo stakeholder dal rischio senza togliere chiarezza al processo. Se lo aiuti a decidere, non devi assorbirne l'ownership. Il Solution Architect facilita il frame, non diventa il decisore ombra. Questo è importante perché un aiuto troppo invasivo può trasformarsi in dipendenza, e il problema si ripresenta alla decisione successiva. • Più velocità di decisione significa meno spazio per un coinvolgimento ampio. • Più consenso apparente significa spesso più ritardo e più ambiguità. • Più supporto al decisore può ridurre l'ansia, ma non deve spostare l'ownership. • Una scadenza chiara aiuta il flusso, ma deve essere credibile rispetto al contesto reale.

Un esempio realistico in azienda

In un programma di modernizzazione CRM, il team propone due opzioni per integrare i dati anagrafici: un approccio API sincrono oppure una sincronizzazione event-driven. Il responsabile business dice di voler «ancora pensarci», mentre sicurezza e operations non prendono posizione. Il progetto resta fermo per due sprint. Il Solution Architect non chiede semplicemente una risposta. Riporta la discussione su un frame decisionale: chi approva l'integrazione, quali sono i criteri prioritari, quali rischi sono accettabili e cosa succede se si rimanda. Emergono tre fatti utili: il vero timore non è tecnico ma di responsabilità sul dato errato; i criteri mancanti sono resilienzaGlossarioResilienzaLa capacità di continuare a produrre risultati utili quando componenti falliscono o le condizioni degradano.Apri la voce completa e tempo di attivazione; il rinvio costerebbe la finestra di rilascio concordata con il canaleGlossarioCanaleUn formato o una destinazione attraverso cui una issue raggiunge il lettore.Apri la voce completa vendite. A quel punto la conversazione cambia. Non si tratta più di «scegliere un'architettura perfetta», ma di decidere quale compromesso è più coerente con le priorità del programma. La scelta diventa esplicita, documentata e difendibile anche davanti ad altri stakeholder. • Il blocco non era tecnico: era un rischio percepito non nominato. • La decisione si sblocca quando criteri e conseguenze diventano visibili. • Il documento decisionale aiuta, ma prima serve una conversazione ben strutturata.

Per approfondire

Fonti autorevoli per approfondire decision framing, ownership e decisioni architetturali esplicite. • Documenting Architecture Decisions - Michael Nygard - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions • Architecture Decision Records - adrGlossarioADRUn record durevole di una decisione architetturale e del ragionamento che l’ha guidata.Apri la voce completa.github.io - https://adr.github.io/