Il ghost stakeholder non è silenzio: è rischio decisionale

Dalla serie

Obiettivo

Progettare coinvolgimento, evidenze e gate decisionali che riducano il rischio di feedback tardivo da parte di stakeholder intermittenti o assenti.

Cosa fare in pratica

Partecipa al kick-off, poi sparisce. Nessun feedbackGlossarioFeedbackUn segnale del lettore usato per migliorare i contenuti e le scelte editoriali future.Apri la voce completa, nessuna obiezione. Due settimane prima del go-live riappare e rimette in discussione una scelta che il team considerava ormai chiusa. Con uno stakeholderGlossarioStakeholderUna persona o un gruppo che influenza una decisione o ne sperimenta gli effetti.Apri la voce completa intermittente, l’obiettivo non è “ottenere presenza”, ma proteggere le decisioni. In pratica: - definisci finestre di feedback esplicite, legate a un gate del delivery; - porta al gate materiali brevi e decisionali: opzioni, impatti, rischio, raccomandazione; - nomina un owner alternativo con delega chiara quando lo stakeholder non è disponibile; - chiarisci in anticipo quali decisioni potranno essere chiuse secondo un mandatoGlossarioMandatoL'autorizzazione esplicita a occuparti di un risultato, con confini su cosa puoi decidere e cosa puoi solo rendere visibile.Apri la voce completa e un gate concordati, e entro quale data; - documenta sempre se una decisione è stata presa senza il suo input, così il contesto resta tracciabile; - stabilisci il percorso per riaprire la decisione solo se cambia davvero costo, rischio o priorità. Il punto chiave è smettere di interpretare il silenzio come consensoGlossarioConsensoUn impegno condiviso sufficiente a sostenere una decisione, non necessariamente una preferenza unanime.Apri la voce completa. In architettura, il silenzio è solo assenza di evidenza. Se non la governi, ti torna addosso tardi come rework, escalationGlossarioEscalationUna richiesta deliberata a un’autorità superiore o diversa per risolvere un rischio materiale o una decisione bloccata.Apri la voce completa o perdita di credibilità del team.

I trade-off da rendere espliciti

Questo approccio ha un vantaggio evidente: riduce il rischio che un feedback tardivo blocchi il rilascio o riscriva una soluzione già validata. Ma introduce anche alcuni trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa. - Più struttura nei gate significa più disciplina, ma anche più lavoro di preparazione. - Chiudi le decisioni prima, ma accetti di decidere con informazioni incomplete. - Usi un delegato o un owner alternativo, ma devi accettare che non avrà sempre la stessa autorevolezza politica dello stakeholder principale. - Documentare l’assenza protegge il processo, ma può essere percepito come rigido se non spieghi bene il perché. Per un Solution Architect il punto non è evitare questi trade-off: è renderli visibili. Così la scelta diventa una decisione di governance, non una speranza organizzativa.

Esempio realistico in azienda

Immagina un programma di modernizzazione di un portale retail. Il responsabile del canaleGlossarioCanaleUn formato o una destinazione attraverso cui una issue raggiunge il lettore.Apri la voce completa digitale partecipa al kick-off, poi sparisce per settimane perché assorbito da una campagna commerciale. Il team interpreta la sua assenza come assenso implicito sulla scelta di un nuovo flusso di checkout. Due settimane prima del go-live, lo stakeholder riappare e contesta proprio quel flusso: dice che impatta la conversione e che non era stato “formalmente approvato”. Il risultato è una riapertura della decisione, analisi extra, tensioni con il business e rischio di slittamento. Con una finestra di feedback definita, un owner delegato e criteri espliciti per escalation e riapertura, la decisione sarebbe rimasta tracciata. Lo stakeholder avrebbe avuto un momento chiaro per intervenire; in alternativa, il team avrebbe potuto procedere con un mandato esplicito e con il rischio accettato documentato.

Per approfondire

Fonti esterne autorevoli per consolidare il tema delle decisioni tracciabili e delle finestre di feedback. • Documenting Architecture Decisions - Michael Nygard - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions • The Scrum Guide - Ken Schwaber and Jeff Sutherland - https://scrumguides.org/scrum-guide.html