Nella gestione del ciclo di vita di un software la figura più importante è il cliente, anche se il termine esatto da usare sarebbe stakeholder. La definizione di wikipedia è
Project stakeholders are those entities within or outside an organization which:
a) Sponsor a project or.
b) Have an interest or a gain upon a successful completion of a project.
c) May have a positive or negative influence in the Project Completion.
In sostanza gli stakeholder sono coloro che sono interessati alla realizzazione del progetto stesso, senza i quali il software non esisterebbe. Formalizzare il concetto di stakeholder è importante, perchè troppo spesso si considera cliente solo chi mette i soldi oppure in generale chi commissiona il software, dimenticando completamente altre figure più importanti. Le categorie di persone che fanno parte degli stakeholder possono essere identificate a grandi linee in:
- Chi paga per il prodotto
- Chi lo ha richiesto
- Chi conosce il dominio del problema
- Chi lo usa
- Chi interagisce con l’output del prodotto stesso.
Purtroppo spesso solo i punti 1 e 2 sono considerati come clienti, provocando problemi nel raccoglimento delle specifiche dato che sono gli unici ad essere contattati dagli analisti. Dal punto di vista della raccolta requisiti infatti ogniuna di queste figure deve essere coinvolta per raccogliere tipologie differenti di requisiti.
Gli stakeholder del punto 1 e 2 forniscono la visione del progetto e sono in grado di dare la direzione principale da seguire cosi come una sommaria descrizione delle regole di business.
Gli stakeholder del punto 3 forniscono invece le specifiche dettagliate sulle regole di business che il software deve implementare. Questa categoria di stakeholder è solitamente quella che realmente preme per realizzare il prodotto stesso, ed è rappresentata da coloro che hanno la necessità di creare il prodotto stesso. In questa categoria risiedono gli “esperti di dominio” ed una figura di questa categoria dovrebbe essere sempre presente o contattabile da tutto il team per dirimere eventuali dubbi durante lo sviluppo.
Gli stakeholder del punto 4 sono invece gli utenti, dai quali vanno ricavati gli use case a livello utente del sistema, ed eventuali mockup. In questa categoria troviamo anche le figure che dovrebbero validare l’usabilità del sistema. Il problema classico è che spesso queste persone non sono contattate per nulla, sebbene siano coloro che utilizzeranno fisicamente il sistema. Il nostro sistema infatti può implementare perfettamente le regole di business, ma essere poco usabile perchè ad esempio per compiere le operazioni più comuni richiede un numero elevato di interazioni con l’interfaccia utente.
Gli stakeholder del punto 5 infine non sono sempre presenti, ma in alcuni casi sono invece molto importanti. Se ad esempio un software deve generare un output da spedire a tutti i fornitori, sarebbe necessario raccogliere da loro alcune specifiche sommarie sui formati attesi, invece di creare una esportazione xml e scoprire che il 90% dei fornitori utilizza un formato CSV. Se un programma deve generare delle informazioni da passare ad un altro dipartimento di un azienda che usa SAP, è doveroso contattare una persona di tale dipartimento per determinare come scambiare i dati.
Queste piccole considerazioni fanno capire come la raccolta requisiti coinvolga molteplici figure, ma spesso gli stakeholder non vogliono spendere tempo con gli analisti, presupponendo che chi realizza il software sia in grado di lavorare da solo sulla base di specifiche vage del tipo: “ci serve un software di gestione magazzino da installare nel palmare dei magazzinieri”.
Tra le regole di Extreme programming vi è infatti un contatto costante con il cliente, e si richiede di avere sempre almeno uno Stakeholder che lavora a fianco con il team. Anche in Scrum e nei processi iterativi gli stakeholder sono sempre necessari, perchè vengono resi partecipi del risultato di ogni iterazione o sprint e della riprioritizzazione dei requisiti ad ogni iterazione/sprint.
Sebbene coinvolgere molti stakeholder nel progetto sia difficile, è fondamentale se si vuole avere una elicitazione dei requisiti completa e non parziale. Dato che in letteratura troviamo molti esempi che mostrano come il 40% o più dei difetti di un software può essere ricondotto ad errori fatti durante la raccolta dei requisiti, viene da se che gli investimenti nel migliorare questo settore porterebbero sicuramente benefici, anche nel breve termine.
alk.