“In un mondo ideale ci sarebbe davvero un singolo utente esperto e sempre disponibile, seduto accanto agli sviluppatori, pronto a farsi immediatamente portavoce in modo definitivo per tutti gli altri utenti. Nella maggior parte delle situazioni reali, però, è improbabile che ciò accada”, sostiene l’esperto di requisiti Karl Wiegers in The Myth of the On-Site Customer.
Archivi categoria: utente
Requisiti e maieutica
Il filosofo greco Socrate affermava di essere come un’ostetrica, dato che cercava di portare alla luce le conoscenze che i suoi interlocutori portavano già dentro di sé, ma non avevano ancora chiare, non avevano ancora tirato fuori.
Lo faceva attraverso il dialogo, discutendo, come testimoniato dalle opere pubblicate dal suo allievo Platone. Facendo delle domande. Prima generali, poi via via più approfondite. Come deve fare chi vuole chiarire i requisiti per un sistema da sviluppare o fare evolvere.
Chiarire i requisiti è necessario, per chi li deve soddisfare. Li vogliamo precisi. Ma i requisiti non nascono già chiari, precisi, completi nella testa di qualcuno. Sono sempre il risultato di un dialogo, di un processo di interazione. Non potrebbe essere altrimenti.
Chi chiede il sistema, o la nuova versione del sistema (chiamiamolo “cliente”) ha un’esigenza e la manifesta. Ma non è, se non in casi particolari, un esperto di progettazione dei sistemi, non conosce tutti gli aspetti di cui è necessario tener conto per valutare fattibilità e impatto, non sa quanto possano costare le diverse soluzioni possibili per soddisfare la sua esigenza, non ha risorse infinite.
Il suo interlocutore (chiamiamolo “analista”) ha il compito di aiutarlo a chiarirsi le idee. Di aiutare il cliente a capire i costi e i benefici di ciò che sta chiedendo, i contro e i pro, i rischi e le opportunità. Dialogando.
Condurre il dialogo tra “analista” e “cliente” per chiarire i requisiti è un’arte, non una scienza. Un’arte che si apprende, con lo studio e con l’esperienza. Si tratta di fare le domande opportune, di usare un linguaggio comprensibile anche sugli aspetti meno intuitivi per chi non ha competenze tecniche, di stimolare la riflessione, di accompagnare i ragionamenti.
Per fortuna, alcuni decenni di esperienze nello sviluppo dei sistemi hanno messo a disposizione degli analisti delle tecniche valide, come i workshop sui requisiti, l’analisi degli scenari di operatività utente (casi d’uso), la quantificazione dei livelli di servizio sugli aspetti non funzionali (prestazioni, carichi, sicurezza, …), la valutazione di prototipi delle interfacce utente.
Queste tecniche possono aiutare l’analista a svolgere la propria attività maieutica, a guidare il chiarimento dei requisiti in modo non solo efficace, ma anche rapido ed efficiente, perché il tempo e le risorse che abbiamo a disposizione per chiarire i requisiti sono sempre più limitati.
E sono tutte tecniche basate sul dialogo, sulla formulazione di domande, sull’analisi delle risposte (feedback), sul fare emergere velocemente punti di attenzione e sull’aumento progressivo del livello di precisione e di chiarezza.
Utenti favorevoli, utenti costretti
Quando si rilascia un sistema, la reazione degli utenti può essere classificata in diverse categorie.
Chi usa il sistema, e chi no. Chi è favorevole al sistema, e chi no.
Può accadere che alcuni usino il sistema pur essendo contrari a farlo. E che altri non lo usino pur essendo favorevoli.
Inoltre, altri stakeholder, pur non usando il sistema direttamente, sostengono o contrastano la diffusione e l’uso del sistema.
Un caso reale, legato alla diffusione di un software per i medici di base da parte del governo in Olanda, è descritto in un articolo di Dong Back Seo, Albert Boonstra e Marjolein Offenbeek, su Communications of the ACM, novembre 2011.
Il software e il gatto di Schrödinger
Solo quando il software viene effettivamente usato dagli utenti possiamo sapere se a loro va bene o no. Ovvio, no?
Tutte le attività di testing che facciamo prima del rilascio, comprese quelle di far usare il sistema a “utenti proxy” (cioè non agli utenti reali, ma a persone che vorrebbero rappresentare gli interessi degli utenti reali), non ci possono dare la certezza del fatto che il software sarà davvero apprezzato.
Possiamo fare ipotesi, speculazioni, ragionare in termini di probabilità. Ma la realtà verrà fuori solo dopo il rilascio.
Elisabeth Hendrickson ne parla in “What Software Has in Common with Schrödinger’s Cat”.
Il servizio fa vendere
Molte aziende sono abituate a vedere il servizio di supporto post-vendita principalmente come un costo. E’ un errore, secondo Gerry McGovern, esperto di content management.
“Il servizio è il nuovo modo di vendere. Il servizio è il nuovo marketing. Con il progredire dell’automazione, i prodotti diventano sempre più uguali. È il servizio che vi distinguerà sul mercato. È per il servizio che farete la prossima vendita.”
Spam: quanti ci cascano
Non è semplice sapere quanti cadono vittima dello spam. Gli spammer non lo dicono, ma se continuano a mandare messaggi non richiesti evidentemente lo spam funziona.
Un esperimento di simulazione di spamming, finanziato dal governo USA, ha fornito per la prima volta alcune risposte statisticamente significative.
Non tutti i videogame rintronano
“A growing number of researchers – and an expanding body of evidence – indicate that joysticks can go a long way toward building smarter children with better reasoning skills.
Games such as Sim City, Civilization, Railroad Tycoon, and Age of Mythology extend beyond the flat earth of rote memorization and teach decision-making and analytical skills in immersive, virtual environments that resemble the real world.”
Samuel Greengard, “Are We Losing Our Ability to Think Critically?“, in Communications of the ACM, 07/2009.
La partecipazione degli utenti ai progetti
Erica L. Wagner and Gabriele Piccoli:”Moving Beyond User Participation to Achieve Successful IS Design” in Communications of the ACM, december 2007
L’articolo mette in luce con estrema chiarezza uno dei nodi principali dello sviluppo software.
“We suggest that rather than fighting human nature by trying to force the participation of user groups throughout a project, we should broaden our thinking about development and implementation methodologies to reflect what happens in practice. We find that in practice user participation can be most powerful after ‘go live’ when users are truly engaged.
[…] we acknowledge it will be difficult to fully engage users before the software begins to affect their daily lives, which are generally at ‘go live.’ Yet, we are not suggesting there is no value in user involvement via prototyping or phased roll-out techniques. When properly implemented, these techniques can help increase communication, provide some valuable feedback in the design process, and generally improve goodwill on the user side. But it is critical to recognize that trying to force engagement of user groups throughout a project goes against human nature. We should therefore expand our thinking about the stages of the systems development life cycle, and incorporate this broadened perspective into whichever methodology is used.
We need to recognize that implementation extends beyond “flipping the switch.” Legitimizing the post-implementation activities that are often kept as a shameful secret — a sign of project failure — will help to manage expectations and avoid much of the conflict that erodes trust between the user community, project champions, and the development team by more naturally mimicking human behavior.
[…] It is time to speak honestly about the gap between our intentions to build working systems and our ability to do so in practice. This gap is typically not caused by a lack of effort on behalf of developers or users, but rather is the result of misdirected efforts. The systems development and implementation process will continue to be overly challenging if we work against the tide by trying to make users fit our theories of how and when they should participate in development initiatives.”