Evidence-based stakeholder identification: Managing conflict and its impact on requirements prioritisation

Nel complesso mondo della costruzione di software, le persone che contano di più sono spesso le più difficili da trovare. Questi individui, noti come stakeholder, sono i clienti, i manager e gli utenti le cui necessità plasmano il prodotto finale. Se un team manca una persona chiave, il software potrebbe non riuscire a risolvere i problemi giusti o ignorare rischi critici. Per decenni, trovare queste persone è stato una questione di intuizione umana, basata sull'esperienza dei project manager nel tentare di indovinare chi detenesse la maggiore influenza. Tuttavia, man mano che i progetti diventano più grandi e globali, indovinare non è più sufficiente. La sfida non è solo trovare queste persone, ma capire come pesare le loro opinioni contrastanti. Una persona potrebbe affermare che un determinato utente sia vitale, mentre un'altra insiste sulla sua irrilevanza. Quando queste visioni soggettive si scontrano, i metodi tradizionali spesso faticano a trovare una via chiara, lasciando i team nell'incertezza su chi conti davvero.

Un team di ricercatori dell'Università di Almería ha proposto un nuovo modo per risolvere questo enigma, allontanandosi dalle sensazioni a pelle verso un approccio matematico progettato per gestire il disaccordo. Il loro lavoro si concentra su un concetto chiamato "salienza", che è semplicemente una misura di quanto una persona sia percepita come importante o influente all'interno di un gruppo. Nel loro studio, hanno trattato le opinioni di diverse persone come pezzi di evidenza, proprio come una giuria che valuta una testimonianza. Hanno utilizzato un framework noto come teoria dell'evidenza, un metodo originariamente sviluppato per gestire l'incertezza, per combinare queste valutazioni soggettive in un'unica immagine chiara. I ricercatori non si sono limitati a cercare l'accordo; hanno costruito un sistema specificamente progettato per gestire il conflitto. Analizzando quanto i raccomandatori discordessero tra loro, il loro metodo poteva determinare quali stakeholder fossero genuinamente centrali per il progetto e quali fossero rumore periferico.

Per testare la loro idea, i ricercatori hanno applicato il loro metodo a un dataset reale proveniente da un progetto presso l'University College London chiamato RALIC. Questo progetto prevedeva la fusione dei sistemi di accesso alla biblioteca e al centro fitness, e il team originale aveva già identificato una lista di 18 persone chiave e 28 ruoli. I ricercatori hanno preso una rete di raccomandazioni in cui centinaia di persone avevano valutato l'influenza degli altri su una scala da zero a dieci. Hanno inserito queste valutazioni nel loro sistema, che le ha convertite in una credenza condivisa su chi contasse di più. I risultati sono stati sorprendenti. In una versione della rete, il loro metodo ha ridotto il pool iniziale di potenziali stakeholder di quasi l'85 percento, restringendo la lista a soli 15 o 19 individui chiave a seconda della specifica regola matematica utilizzata. In un'altra versione, la riduzione è stata di circa il 70 percento. Il sistema ha filtrato con successo il rumore, identificando un gruppo centrale che includeva persone che il team originale aveva trascurato, confermando al contempo l'importanza di coloro che avevano già sospettato.

Lo studio ha rivelato una relazione affascinante tra conflitto e chiarezza. I ricercatori hanno scoperto che quando le persone che forniscono raccomandazioni discordavano meno, il sistema riusciva ad accordarsi su un gruppo di stakeholder chiave più piccolo e preciso. Al contrario, quando la rete era piena di alto conflitto, il sistema diventava più cauto, identificando un gruppo leggermente più ampio per garantire che nulla di vitale venisse tralasciato. Questo comportamento suggerisce che il livello di disaccordo all'interno di un team è un segnale utile in sé. I ricercatori hanno anche scoperto che il modo in cui le persone esprimono le loro preferenze conta immensamente. Hanno testato tre modi diversi per raccogliere input: classificare gli elementi in ordine, assegnare un punteggio o distribuire un numero fisso di punti. Hanno scoperto che questi diversi metodi producevano risultati significativamente differenti. Ad esempio, in una rete con alto conflitto, passare da un sistema di classificazione a un sistema di punteggio ha alterato completamente quali requisiti erano considerati più importanti.

Forse il risultato più significativo è stato che il gruppo specifico di persone scelto per fornire input cambiava l'esito delle priorità del progetto. Quando i ricercatori hanno confrontato le priorità stabilite dall'intera folla di stakeholder rispetto a quelle stabilite solo dagli stakeholder "chiave" identificati dal loro metodo, i risultati erano spesso statisticamente differenti. Ciò significa che fare affidamento sulle opinioni di tutti può portare a un insieme di obiettivi diverso rispetto al fare affidamento sulle opinioni delle persone più influenti. In alcuni casi, la "folla" dava priorità a funzionalità che gli stakeholder chiave non consideravano importanti, e viceversa. Lo studio suggerisce che se un team non filtra attentamente chi ascoltare, rischia di costruire un software che soddisfa la massa ma fallisce nel soddisfare i pochi che effettivamente guidano il successo del progetto.

I ricercatori hanno concluso che il loro approccio offre un modo pratico e automatizzato per identificare le persone giuste da ascoltare, trasformando un processo disordinoso e soggettivo in uno strutturato e quantitativo. Non hanno sostenuto di aver risolto ogni problema nello sviluppo del software, ma hanno dimostrato che gestire il conflitto non significa solo cercare di smussare gli angoli; significa usare quel conflitto per raffinare la lista di chi conta. Trattando le opinioni degli stakeholder come dati che possono essere combinati e analizzati, i team possono andare oltre l'intuizione e prendere decisioni basate su un consenso chiaro. Questo lavoro evidenzia che, nella complessa rete dei moderni progetti software, sapere chi ascoltare è altrettanto critico quanto sapere cosa costruire. Lo studio serve da promemoria che il percorso verso un progetto di successo inizia spesso non con una lista di funzionalità, ma con una comprensione precisa della rete umana che lo sostiene.