Quando un team raccoglie i requisiti per un software enterprise destinato a utenti esperti, si organizzano workshop con responsabili, stakeholder e utenti, si rileggono procedure aziendali, ci si allinea con il management. Quando il quadro sembra completo si parte con lo sviluppo.
Tempo dopo, quando il prototipo arriva nelle mani degli utenti, emergono richieste, eccezioni, criteri di scelta non dichiarati inizialmente. Si avvia una serie di rilavorazioni il cui costo è difficile da stimare in anticipo.
Questo accade in particolare quando il software coinvolge utenti esperti, e ha a che fare con come funziona la loro mente: una parte importante del lavoro reale resta fuori dal racconto.
Quando le esigenze degli esperti resta inespresso
Pensiamo a un meccanico esperto che, accendendo un motore, individua immediatamente la causa di un rumore anomalo. Se gli chiediamo come ha fatto, risponderà che lo sente. La spiegazione completa difficilmente viene spiegata, perché negli anni la sua mente ha imparato a riconoscere quel suono in modo immediato.
Lo stesso accade ai professionisti che useranno il software che stiamo progettando. Un revisore contabile, un farmacista ospedaliero, un ispettore qualità: ognuno ha imparato negli anni operazioni che svolge in modo automatico. Quando un team di progetto indaga per comprendere procedure o prassi di lavoro, una parte delle informazioni resta fuori dal racconto.
Il filosofo Michael Polanyi, nel libro The Tacit Dimension del 1966, ha definito questo fenomeno conoscenza tacita, riassumendolo nella frase “sappiamo più di quanto possiamo dire”.
Quattro pratiche per portare alla luce le esigenze
Quando ci occupiamo di progettazione con utenti esperti, integriamo nella raccolta requisiti pratiche specifiche, dedicate a far emergere la parte di lavoro che l’esperto compie senza più rendersene conto. Si combinano fra loro a seconda del contesto del progetto.
1. Lavorare a fianco dell’esperto, come un apprendista
Un nostro analista passa una giornata, o più, accanto al professionista, facendogli domande durante il lavoro reale, come farebbe un apprendista. In questo ruolo l’esperto verbalizza scelte e criteri che, in altri contesti, applicherebbe in automatico.
2. Commentare con l’esperto la registrazione di quello che ha fatto
Registriamo il professionista, con il suo permesso, mentre svolge un compito reale. Subito dopo riguardiamo insieme la registrazione e gli chiediamo cosa stava pensando in punti specifici. Vedendo le proprie azioni, racconta il ragionamento che durante il lavoro restava implicito.
3. Esaminare gli appunti, i file e gli oggetti che l’esperto usa ogni giorno
Ogni professionista esperto costruisce nel tempo artefatti personali: fogli Excel parametrizzati, post-it sul monitor, quaderni operativi, scorciatoie sul desktop. Una sessione dedicata a guardarli insieme, con domande precise sul perché siano fatti così, porta alla luce regole pratiche che difficilmente emergono in sala riunioni.
4. Ricostruire una decisione difficile, passo dopo passo
Anziché chiedere come funziona il lavoro in generale, partiamo da un caso concreto: una decisione difficile, un errore evitato. Guidiamo l’esperto a ricostruire passo dopo passo cosa ha visto, cosa ha pensato, cosa ha escluso. La memoria di un caso preciso conserva molti più dettagli rispetto al racconto astratto del proprio metodo..
Cosa cambia per gli sponsor di progetto
L’effetto di queste pratiche si misura, in un’analisi in ambito software, su quattro piani:
- I requisiti raccolti sono più completi e meno soggetti a rilavorazioni.
Le eccezioni e i casi limite emergono in fase di analisi, e non in fase di test, riducendo i cambi di requisito e accorciando il tempo complessivo di sviluppo e lancio. - I costi nascosti si riducono.
Requisiti più completi e corretti significano meno ambiguità per il team di sviluppo, meno rilavorazioni su funzionalità che non rispecchiano il lavoro reale, meno ticket di supporto post-lancio. - La fiducia nell’iniziativa e nella soluzione migliora. Gli stakeholder incontrano un team che entra nel suo lavoro e gli pone domande coerenti con la sua pratica, la sua fiducia e la sua disponibilità a partecipare ad altre iniziative cresce.
- Il prodotto rende più efficiente il lavoro perché è più allineato al lavoro reale.
In produzione, l’utente esperto riconosce il software come strumento utile e lo integra nel proprio flusso quotidiano.
Conclusione
Una larga parte del sapere di un professionista esperto vive in azioni automatiche, criteri impliciti, segnali percettivi che fatica a raccontare a mente fredda.
Affrontare questo fenomeno durante la raccolta requisiti richiede pratiche dedicate, che si possono integrare nel processo di analisi per arrivare in breve tempo a un prodotto che supporti il lavoro reale.
Un team di Product Design incentrato su pratiche user-centered è in grado di supportare il processo di raccolta di queste informazioni per fare la differenza fra un investimento riuscito e uno da ripetere, evitando successive rilavorazioni e revisioni.
Nel design per domini verticali, sanitario, finanziario, industriale o legale, la differenza fra un investimento riuscito e uno da ripetere passa da qui.
Stai progettando un software per professionisti in ambito industriale, sanitario, finanziario o legale? Raccontaci il tuo progetto.
Scopri come affrontiamo la raccolta requisiti con utenti esperti
Autore: Gabriella Moro, UX Manger @ Bitrock