Il costo nascosto delle aspettative disallineate

I progetti possono fallire per ragioni tecniche. Architettura inadeguata, implementazione debole, test insufficienti e infrastruttura fragile hanno tutti la loro importanza. Ma molti progetti che sembrano fallimenti tecnici sono iniziati come fallimenti di allineamento. Stakeholder diversi avevano definizioni diverse di successo, tali differenze non sono mai state esplicitate e il team di delivery ha finito per lavorare verso un obiettivo che continuava a spostarsi.

È uno dei problemi più costosi nella delivery di prodotti e software perché spesso rimane nascosto fino a una fase avanzata del processo. Le prime riunioni sembrano produttive. I requisiti appaiono ragionevoli. I backlog vengono popolati. Si svolge la pianificazione degli sprint. Gli aggiornamenti sullo stato mostrano progressi. Poi il team si avvicina alla delivery e scopre che vendite, operations, compliance, leadership, utenti ed engineering non stavano immaginando tutti lo stesso risultato.

A quel punto, il costo non si misura più in una singola riunione imbarazzante. Si manifesta sotto forma di rilavorazione, scadenze mancate, fiducia compromessa, continui cambiamenti di ambito, pressione sul budget e software che soddisfa tecnicamente il requisito scritto, ma non risponde alle esigenze aziendali.

L'anatomia del disallineamento

Di solito gli stakeholder non hanno torto a preoccuparsi di aspetti diversi. Un responsabile vendite può dare importanza agli impegni presi con il mercato. Un responsabile dello sviluppo può concentrarsi sulla fattibilità tecnica e sulla manutenibilità. Un responsabile della compliance può preoccuparsi della verificabilità e del rischio. Un responsabile operativo può concentrarsi sulle interruzioni del flusso di lavoro. Un responsabile finanziario può dare importanza a budget, tempistiche e rendimento misurabile.

Ogni prospettiva può essere legittima. Il problema inizia quando queste prospettive vengono trattate come se fossero già concordi.

Un product owner o un responsabile di progetto può ascoltare un'approvazione generale durante una sessione di pianificazione e presumere che esista un allineamento. Ma l'accordo a livello generale è facile da ottenere. La maggior parte degli stakeholder può concordare sul fatto che un prodotto debba essere più veloce, più facile da usare, più sicuro, meglio integrato e pronto entro una certa data. La parte difficile è decidere che cosa accade quando questi obiettivi entrano in conflitto.

Il team dovrebbe rilasciare prima con un insieme di funzionalità più limitato? Dovrebbe rimandare il rilascio per ridurre il rischio operativo? Engineering dovrebbe accettare debito tecnico per rispettare una finestra di mercato? I requisiti di compliance dovrebbero modificare l'esperienza utente? Una richiesta di un cliente di grande valore dovrebbe prevalere sulle priorità della roadmap?

Sono questi i momenti in cui la gestione degli stakeholder diventa concreta. L'allineamento non consiste nel raccogliere opinioni. Consiste nel trasformare priorità concorrenti in decisioni che il team di delivery possa effettivamente utilizzare.

Gli strumenti possono monitorare il lavoro, ma non possono creare chiarezza

I moderni team di delivery non hanno certo carenza di strumenti. Bacheche Jira, sistemi di gestione del backlog, cerimonie di sprint, dashboard, roadmap di prodotto, documenti condivisi e piattaforme di collaborazione aiutano tutti a coordinare il lavoro. Sono utili. È anche facile confonderli con l'allineamento.

Un backlog ben organizzato non significa che si stia costruendo il lavoro giusto. Una user story dalla formattazione ordinata non significa che il requisito sia chiaro. Una roadmap non significa che gli stakeholder comprendano i compromessi. Un report settimanale sullo stato non significa che i rischi irrisolti vengano affrontati.

Le indicazioni di Mike Cohn sulle user story evidenziano un punto utile: le user story servono a spostare l'attenzione dalla scrittura dei requisiti alle conversazioni su di essi. La storia scritta è solo una parte del lavoro. Il vero valore deriva dalla discussione che chiarisce di che cosa l'utente ha bisogno, perché è importante e come il team saprà quando il lavoro sarà completato. [oai_citation:1‡Mountain Goat Software](https://www.mountaingoatsoftware.com/agile/user-stories?utm_source=chatgpt.com)

Quando le organizzazioni aumentano la scala della delivery, il problema della conversazione diventa più difficile. Più team, più stakeholder, più dipendenze e più livelli di approvazione creano più opportunità perché le ipotesi divergano. Gli strumenti possono mostrare che cosa è assegnato, in corso o completato. Non possono dimostrare che tutti siano ancora d'accordo sul significato del successo.

I piani di comunicazione richiedono responsabilità, escalation e cadenza

La comunicazione con gli stakeholder viene spesso trattata come un'attività secondaria di project management. In pratica, fa parte dell'architettura della delivery. Se i flussi di comunicazione sono progettati male, la qualità delle decisioni ne risente.

Le indicazioni di ITU Online sui piani di comunicazione con gli stakeholder nei progetti Agile evidenziano diversi componenti pratici che i team devono definire, tra cui obiettivo, gruppi di stakeholder, cadenza, canali, responsabilità ed escalation. Sono proprio questi ultimi tre aspetti a creare problemi in molte organizzazioni. [oai_citation:2‡ITU Online IT Training](https://www.ituonline.com/blogs/creating-an-effective-stakeholder-communication-plan-in-agile-projects/?utm_source=chatgpt.com)

Responsabilità: Chi prepara la comunicazione, la diffonde, registra le decisioni e verifica le azioni successive quando è necessario intervenire?
Escalation: Come vengono portati all'attenzione della leadership i blocchi, i rischi, i disaccordi o le decisioni mancanti non risolti?
Cadenza: Con quale frequenza gli stakeholder dovrebbero ricevere aggiornamenti dal team e come dovrebbe cambiare tale frequenza al variare dell'ambito, del rischio o dell'urgenza?

La questione della responsabilità è importante perché «ne abbiamo discusso» non equivale a «abbiamo preso una decisione». Una decisione che non viene acquisita, assegnata e seguita è solo una conversazione con un abito migliore.

L'escalation è importante perché i blocchi irrisolti non diventano meno costosi con il passare del tempo. I team spesso continuano a lavorare mentre aspettano chiarimenti, ma procedere nella direzione sbagliata non è progresso. È rilavorazione che si accumula silenziosamente.

La cadenza è importante perché le esigenze di comunicazione cambiano insieme al progetto. Un'attività di discovery a basso rischio può richiedere solo aggiornamenti essenziali. Un'implementazione ad alto rischio, con dipendenze esterne, esposizione normativa o visibilità presso i dirigenti, può richiedere un ritmo più serrato. Un calendario di comunicazione fisso che ignora il rischio del progetto non è disciplina. È abitudine.

Il product owner come autorità sull'allineamento

La product ownership viene spesso descritta attraverso la visione, la gestione del backlog, la collaborazione con gli stakeholder e la guida della delivery. Sono tutte componenti reali del ruolo. Ma sotto di esse si cela una responsabilità meno ordinata: il product owner deve creare chiarezza utilizzabile.

Questo non significa che il product owner ottenga tutto ciò che vuole. Né significa che ogni stakeholder abbia la stessa influenza su ogni decisione. Una buona product ownership non consiste nel gestire il consenso. Consiste nel gestire le decisioni.

Un product owner efficace sa tenere presenti input contrastanti e fornire comunque una risposta chiara al team. Che cosa stiamo costruendo ora? Perché è importante? Che cosa non stiamo costruendo? Quale compromesso abbiamo accettato? Quale rischio ci stiamo assumendo? Che cosa ci porterebbe a cambiare direzione?

È qui che la gestione degli stakeholder diventa una funzione di leadership. Il product owner non si limita a trasmettere messaggi tra business ed engineering. Aiuta l'organizzazione a prendere decisioni abbastanza specifiche da poter essere eseguite dal team.

La descrizione del Product Owner Masterclass di Udemy riflette l'ampia gamma di competenze attese dalla moderna product ownership: visione, strategia, collaborazione con gli stakeholder, organizzazione del backlog e leadership in ambienti Agile e Scrum. La sfida pratica consiste nel riunire queste responsabilità quando le priorità sono in conflitto e il tempo è limitato. [oai_citation:3‡Udemy](https://www.udemy.com/course/product-owner-masterclass-vision-backlogs-leadership/?srsltid=AfmBOop78in_QjgRR-5XVf8hD2mt_0LVQ6tetEC0_38ciieaTaYMiMa5&utm_source=chatgpt.com)

I registri delle decisioni sono più utili del teatro dello stato di avanzamento

Molti team di progetto dedicano troppo tempo a comunicare le attività e non abbastanza a registrare le decisioni. Gli aggiornamenti sullo stato hanno la loro utilità, ma raramente risolvono da soli i problemi di allineamento.

Un artefatto adatto a documentare le decisioni è diverso. Registra che cosa è stato deciso, chi ha preso la decisione, quali evidenze o vincoli l'hanno determinata, quali rischi sono stati accettati e quali azioni di follow-up sono necessarie. Offre al team un riferimento da consultare quando i ricordi divergono, gli stakeholder cambiano o riemergono vecchi disaccordi.

Questo non deve diventare burocratico. Può bastare un registro leggero delle decisioni:

Decisione presa
Data
Responsabile della decisione
Stakeholder consultati
Contesto ed evidenze
Rischi o compromessi accettati
Azioni successive

Questa piccola abitudine può prevenire una grande quantità di confusione. Crea inoltre un rapporto più sano tra gli stakeholder e i team di delivery. Invece di ridiscutere ciò che le persone ricordano, il team può tornare a ciò che è stato deciso e al perché.

Il disallineamento più costoso è quello tra priorità e capacità

Alcuni problemi degli stakeholder sono in realtà problemi di leadership. L'esempio più comune è il divario tra la priorità dichiarata e la capacità effettiva.

La leadership può dire che un progetto è la massima priorità, ma lasciare in essere ogni iniziativa concorrente. Uno stakeholder può insistere sul fatto che una funzionalità sia urgente, ma evitare di fare compromessi altrove. Un reparto può volere tempi di consegna più rapidi, ma non fornire le persone necessarie per la fase di discovery, i test, le approvazioni o il rilascio.

Quando accade, la gestione degli stakeholder non può risolvere magicamente il problema. Un product owner può facilitare, chiarire, documentare ed effettuare escalation. Ma non può creare una capacità che la leadership non ha realmente allocato.

Una buona gestione degli stakeholder rende visibile prima la contraddizione. Costringe l'organizzazione a rispondere a domande scomode: È davvero una priorità? A cosa siamo disposti a rinunciare? Chi ha l'autorità per effettuare il compromesso? Cosa succede se non decidiamo?

Queste domande possono sembrare politiche, ma evitarle di solito è più costoso.

Come Ridiculous Engineering considera l'allineamento degli stakeholder

In Ridiculous Engineering, consideriamo l'allineamento degli stakeholder una delle basi fondamentali per il successo della delivery software. Non è separato dall'esecuzione tecnica. Dà forma all'esecuzione tecnica.

Quando gli stakeholder sono allineati, i team di ingegneria possono prendere decisioni architetturali migliori, porre domande più efficaci, sequenziare il lavoro in modo più efficiente ed evitare di costruire sulla base di assunzioni che in seguito verranno superate. Quando gli stakeholder non sono allineati, il team tecnico diventa spesso il luogo in cui si manifesta il conflitto aziendale irrisolto.

Ecco perché attribuiamo importanza alla discovery, alla chiarezza dei requisiti, alla cadenza della comunicazione, ai registri delle decisioni, ai percorsi di escalation e alla titolarità. Possono sembrare dettagli di processo, ma influenzano direttamente la qualità della delivery. Determinano se un progetto entra nell'ingegneria con un problema chiaro, un ambito realistico e una comprensione condivisa del successo.

Per i clienti, il nostro ruolo consiste spesso nel contribuire a rendere visibili gli aspetti invisibili della delivery. Dove si bloccano le decisioni? Quali stakeholder devono essere coinvolti prima? Quali requisiti sono in realtà conflitti ancora irrisolti? Dove il team riferisce i progressi senza risolvere i rischi? Dove la leadership deve fare un compromesso invece di chiedere al team di delivery di farsene carico?

L'allineamento è una disciplina della delivery

La gestione degli stakeholder non consiste soltanto nella gestione delle relazioni. È una disciplina strutturale che determina se l'investimento di un'organizzazione nella delivery produce il risultato previsto.

Le organizzazioni che gestiscono bene questo aspetto non lasciano l'allineamento al caso. Progettano i flussi di comunicazione. Definiscono i diritti decisionali. Creano percorsi di escalation. Registrano le decisioni importanti. Adattano la cadenza al variare del rischio. Trattano la chiarezza degli stakeholder con la stessa serietà che riservano all'architettura tecnica.

Se la tua organizzazione sta affrontando continui cambiamenti di ambito, requisiti poco chiari, decisioni bloccate, conflitti tra stakeholder o progetti software che continuano a non rispondere alla reale esigenza aziendale, Ridiculous Engineering può aiutarti. Collaboriamo con i clienti per migliorare la discovery, chiarire i requisiti, strutturare la comunicazione con gli stakeholder e creare la disciplina decisionale necessaria per una delivery migliore.

Il costo dell'allineamento si paga presto, attraverso conversazioni, decisioni e documentazione. Il costo del disallineamento si paga più tardi, attraverso rilavorazioni, ritardi e perdita di fiducia. Uno dei due è molto più economico dell'altro.

Fonti e ulteriori letture: ITU Online: Creare un piano efficace di comunicazione con gli stakeholder nei progetti Agile, Mountain Goat Software: User story ed esempi di user story, Udemy: Masterclass per Product Owner, PMI: Comunicazione con stakeholder e clienti

Gestione degli stakeholder: il costo nascosto delle aspettative disallineate