Nel post precedente ho parlato di come spesso la raccolta requisiti è svolta in maniera errata, portando poi a problemi in fase di sviluppo e alla classica sindrome di Penelope, in cui si fa e disfa il codice giorno dopo giorno. Quando si ha un problema e si vuole risolverlo, il modo migliore di partire è addossarsi la colpa e cercare di capire come migliorare; dire "il cliente non sa mai cosa vuole" è una scusa banale, e comunque non porta a nessuna soluzione.
Il modo corretto di porsi di fronte ad un problema è analizzarlo e trovare una soluzione. Nel caso del rapporto con il cliente, il problema principale è che il cliente effettivamente è spesso confuso sulle sue effettive necessità e quindi è dovere degli analisti cercare di carpire le informazioni al cliente. I casi d'uso in questo scenario si rivelano uno strumento eccezionale. Un caso d'uso può avere vari formati, ma è solitamente molto semplice da capire anche per una persona non tecnica. Se si seguono le regole base che potete trovare in qualsiasi testo dedicato all'argomento, il caso d'uso scorre bene e può essere letto anche dal nostro cliente che non ha mai visto un caso d'uso in vita sua.
L'analisi con i casi d'uso inoltre porta ad evidenti vantaggi, prima di tutto il cliente ha già da subito la sensazione di come funzionerà a grandi linee il software che si sta andando a costruire, si identificano gli attori e le parti del sistema, ma soprattutto mano a mano che si procede con l'analisi a "braccetto con il cliente", è più facile che le necessità emergano limitando il sintomo delle Macerie Nascoste, ed evitando che al momento della consegna il cliente lamenti funzionalità mancanti. La contrattazione delle funzionalità in questo caso è infatti fatta in maniera completamente trasparente evitando il classico sintomo dell'analista che: parla 1 ora con il cliente, stila un documento word spesso incompleto, lo fa firmare al cliente e da li si inizia la guerra della contrattazione con frasi del tipo "hai firmato il documento delle specifiche, ora ogni cambiamento si paga".
Chiaramente questo richiede, da parte degli analisti e dei project manager, l'essere disponibili a cambiare mentalità, realizzando che una sana contrattazione con uno Stakeholder deve basarsi su requisiti di: Trasparenza, Onestà e Collaborazione da entrambe le parti.
Alk
Technorati Tags:
use cases