Secondo la teoria "Win-Win" applicata allo sviluppo software, soddisfare committenti, utenti e altri soggetti interessati alla realizzazione
di un progetto equivale al successo. Identificare gli stakeholder chiave, capendone bisogni e aspettative, è quindi essenziale, così come sanare il prima possibile eventuali conflitti di interesse tra le parti in causa.
Il termine stakeholder deriva da stake, “paletto” o “bastoncino”, e holder, “custode”. Viene da tempi in cui le scommesse venivano raccolte ricevendo da ogni scommettitore un bastoncino che lo rappresentava: il custode dei bastoncini era lo stakeholder. Successivamente il significato del termine cambiò, denotando non più chi riceveva le scommesse, bensì chi le aveva effettuate: la persona coinvolta, il “soggetto interessato” alla scommessa.
È questo secondo significato che è arrivato a noi quando, a partire dagli anni Sessanta del Novecento, il concetto di stakeholder si è diffuso nelle teorie di management e di analisi organizzativa.
Perciò possiamo tradurre stakeholder con “parte in causa, parte interessata”, in quanto può ricevere effetti positivi o negativi dall’andamento e dai risultati di un progetto, di un servizio, di un evento.
Identificare gli stakeholder rilevanti, e comprendere il loro punto di vista e i loro interessi, è quindi essenziale. Barry Boehm, uno tra i principali esperti di ingegneria del software, definì nel 1989 la teoria “Win-Win” dello sviluppo, in base alla quale soddisfare gli stakeholder chiave del sistema è condizione necessaria e sufficiente per il successo di ogni progetto.
Committente
Primo tra gli stakeholder è il committente, cioè il soggetto che richiede l’intervento progettuale, decide cosa vuole ottenere, quanto vuole spendere e per quando è necessario concluderlo. Può trattarsi di un singolo individuo, ma in organizzazioni complesse il ruolo è spesso esercitato da un comitato guida, in particolare nel caso di progetti che coinvolgano diverse aziende, oppure diverse unità della medesima organizzazione. Poiché tiene i “cordoni della borsa”, il committente ha la responsabilità e l’autorità di prendere le decisioni in caso di conflitto tra diversi punti di vista ed è spesso la fonte primaria dei requisiti progettuali.
Utenti
Altri stakeholder fondamentali sono gli utenti, cioè gli utilizzatori effettivi del prodotto da sviluppare. Quando gli utenti appartengono alla stessa organizzazione del committente, la loro identificazione e il loro coinvolgimento nel progetto non è difficile, mentre quando si tratta di soggetti esterni il coinvolgimento può risultare problematico, in particolare quando si vuole sviluppare un prodotto o un servizio da proporre a soggetti non noti a priori (potenziali clienti per un’azienda, cittadini per la pubblica amministrazione).
In ogni caso, il coinvolgimento di rappresentanti degli utenti nei progetti di sviluppo è essenziale, perfino nei casi in cui gli utenti abbiano dubbi o obiezioni rispetto agli obiettivi di un progetto: nel caso in cui il punto di vista degli utenti non sia preso in considerazione, il rischio di non accettazione e di non utilizzo è molto elevato.
Altri stakeholder
Sono stakeholder anche i referenti e gli utenti di altri prodotti collegati in input o in output al sistema. Se ad esempio il prodotto da sviluppare fornisce servizi a sistemi esterni, gli utenti di tali sistemi possono trarre beneficio dalle caratteristiche del servizio e possono avere interesse al formato dei dati e alle modalità e tempistiche di interazione.
Ulteriori stakeholder sono costituiti dai ruoli che possono ricevere effetti positivi o negativi dalle caratteristiche del prodotto, anche se non ne sono utenti diretti. Quando un’azienda propone nuovi servizi ai propri clienti, è spesso indispensabile coinvolgere chi ha la responsabilità degli aspetti legali e della gestione della sicurezza; quando invece si tratta di ripensare e ottimizzare i processi di lavoro interni, chi si occupa dell’organizzazione aziendale e delle risorse umane è tra gli stakeholder più influenti.
Identificati gli stakeholder, sarà necessario che il prodotto riesca a soddisfarli, il che non è sempre facile, in quanto gli interessi dei diversi stakeholder possono essere divergenti, o addirittura contrastanti. Identificare gli stakeholder è quindi una condizione essenziale per il successo di un progetto software. Ma una volta identificati, come possiamo coinvolgerli e cosa possiamo aspettarci da loro?
Vantaggi e svantaggi per ogni stakeholder
Gli stakeholder devono poter esprimere i propri requisiti. Dato che ognuno è un soggetto interessato al prodotto da sviluppare, è possibile (anzi probabile) che il chiarimento dei requisiti dal suo punto di vista faccia emergere aspetti che sono in conflitto con i requisiti di altri stakeholder. Ad esempio, nello sviluppo di prodotti per il mercato, la volontà di fornire un numero elevato di funzioni può entrare in contrasto con l’esigenza di contenere il prezzo che i futuri acquirenti dovrebbero pagare per il prodotto. Può anche succedere che determinate iniziative commerciali siano rischiose sotto il profilo legale, o per la sicurezza.
Il conflitto tra requisiti espressi dagli stakeholder è una caratteristica normale nei progetti che comportano innovazione. Ma è importante che il conflitto, quando c’è, venga portato alla luce il più velocemente possibile, in modo che gli stessi stakeholder possano, in collaborazione con il committente, affrontarlo e risolverlo per tempo: più tardi il conflitto emerge, maggiori sono i rischi e i costi per il progetto.
Naturalmente nessuno stakeholder ha già pronta una lista di requisiti completa; è invece compito di chi sviluppa aiutarlo a fornire il proprio contributo al progetto, facendo domande, scoprendo quali sono i fattori critici di successo e i rischi che possono avere un impatto negativo sui suoi interessi, e proponendo soluzioni, con prototipi e semilavorati. In ogni caso, l’approccio di chi sviluppa deve essere maieutico, come quello del filosofo greco Socrate che aiutava i propri interlocutori a chiarirsi le idee attraverso una serie di stimoli e di domande, e paragonava se stesso ad un’ostetrica che aiuta le donne a partorire. Proprio come è necessario aiutare gli stakeholder a chiarirsi le idee e a fornire i requisiti necessari per un sistema che rispetti nella misura maggiore possibile le loro esigenze.
* Adriano Comai, esperto in metodologie di sviluppo software, www.analisi-disegno.com
