Il modo giusto per scegliere la tecnologia, un estratto

Carpire requisiti che non facciano pena#section1

Un’ottima comprensione dei requisiti della vostra organizzazione è fondamentale per il successo del progetto. Ottenere quella comprensione implica una raccolta di informazioni da vari gruppi di stakeholder, potenzialmente utilizzando una serie di tecniche.

Notate che in questa fase, i vostri requisiti dovrebbero essere incentrati sul business e sull’utente, piuttosto che specifiche tecniche dettagliate (Ci arriveremo nel Capitolo 6, “Ask Questions That Really Matter”). Il cruciale step finale qui è analizzare e assegnare una priorità ai vostri requisiti per poter determinare quali enfatizzare nel RFP e nelle demo e nelle gare seguenti.

Come non articolare i requisiti#section2

Qualsiasi cosa facciate, evitate i fogli di requisiti tipo “check box”, in cui chiedete al produttore: “Puoi fare questo? Puoi fare quello?”

In pratica, i produttori hanno già visto tutte queste domande e hanno capito come spuntare tutte le caselle. Ma quel che è peggio è che tali fogli di calcolo convertono la comprensione di quella che dovrebbe essere un’attività human-centered, interattiva, in una serie sterile di attività riga per riga adatte ai robot che ripetono sempre lo stesso task.

Il tranello tipico qui comincia così: una business analyst (BA) va in giro a fare domande agli utenti e ad altri stakeholder e finisce con una lunga “wish list” di features. Excel le permette di assegnare una categoria a queste feature, il che è comodo, ma dal momento che il numero di righe è infinito, il suo spreadsheet tenderà ad enfatizzare la completezza piuttosto che l’impatto sul business.

Per gestire la sfida delle priorità, il processo di impresa tipico chiede agli stakeholder di valutare i propri bisogni, magari su una scala da 1 a 5, o di usare MoSCoW (Must Have/Could Have/Should Have/Won’t Have) o un’altra metodologia. Non sorprende che questo generi una mischia in cui gli utenti competono per identificare quante più righe possibile di “Must Have”.

In fin dei conti, qualcuno chiederà alla BA di ricollegare ciascuna riga dei requisiti al business case (ve lo ricordate?), così passerà diversi giorni a creare nuove tabelle e cross-reference in Excel. Alla fine, i reviewer troveranno delle eccezioni e delle varianti per ogni feature quindi verranno aggiunte nuove colonne. Ora il foglio di calcolo è troppo grosso per rientrare su uno schermo standard, non parliamo nemmeno di stamparlo. È impressionante… E impressionantemente inutile.

L’agenzia governativa con una checklist enorme#section4

Una volta abbiamo fatto consulenza a una delle più grandi agenzie governative federali degli USA per selezionare una nuova piattaforma per un portale come hub per suggerimenti per piccole aziende. Siamo arrivati tardi nel processo dopo che un round iniziale di demo da parte dei fornitori aveva fallito nell’evidenziare le differenze tra gli offerenti.

Il problema era Excel. O meglio, l’intero RFP presentato come un foglio di lavoro con 10 tab, con alcuni fogli di centinaia di righe. La maggior parte dei tab aveva delle richieste di feature, particolarmente categorizzati per dipartimento dell’agenzia piuttosto che come customer persona, con una lunga serie di colonne con l’annotazione di queste feature. (Il nostro preferito: il sempre amato requisito “deve essere facile da usare”). Quasi tutte le feature sono state elencate come “must have”. Sono state rigorosamente cross-tabbed a un lungo, ma vago, insieme di obiettivi di business, ma al di là di questo non c’era alcuna priorità.

I fornitori non sapevano cosa dimostrare, sebbene molti ci abbiano provato. Perlopiù hanno solo parlato delle loro (voluminose) proposte, la maggior parte delle quali consisteva nel dichiarare, per ogni riga, “Possiamo farlo!”.

Alla fine, siamo stati in grado di ricreare un approccio più user-centered, con uno scope più ristretto, per cui i fornitori hanno potuto fare delle ragionevoli dimostrazioni.

Lezione: state lontani dalle checklist lunghe e basate su feature.

Applicare i principi dello UCD#section5

C’è un modo diverso per fare tutto ciò, piuttosto che torturare il vostro BA (e tutti gli altri) con dei lunghi fogli di calcolo e gira attorno al dedicarsi a un approccio di user-centered design (UCD) che enfatizzi le narrazioni, che noi qui chiameremo storie. Qualcuno sarà in disaccordo riguardo alle tattiche dello UCD, ma noi possiamo generalizzare che un approccio user-centered è:

• olistico per comprendere l’intera esperienza digitale (e pertanto non basato sulle feature),
• iterativo, in cui all’inizio si fanno delineano dei requisiti leggeri (e pertanto imperfetti) e li si rifinisce nel tempo mediante iterazioni
• Story-based, con un enfasi sulle “user narrative”, spesso chiamate “journey” o “top tasks”

Lo UCD è molto di più, ma per i nostri scopi, saltano fuori due costrutti chiave:

• Persona: archetipi dell’utente che guidano le decisioni riguardanti l’efficacia della tecnologia. Le persona sono utili nel senso che creano una comprensione comune condivisa dello user group, ma con un’esistenza umana che contribuisce a farle sembrare reali.
• User Stories: una storia “to-be” riguardante la “vita quotidiana di” o una journey intrapresa da delle persona chiave. Le user story sono incredibilmente di valore qui perché offrono dei test case con cui confrontare e contrastare i fornitori che faranno delle offerte.

Raccolta delle informazioni#section6

Potete scegliere fra numerosi metodi ben noti per ottenere informazioni necessarie alla creazione di persona e user story.

• Document review: inclusi diagrammi di sistemi esistenti e potenziali, documenti di pianificazione e statistiche, ma anche informazioni che fluiscono attraverso la tecnologia attesa, come le entry del catalogo per un sito di e-commerce o le form in un document management system
• Questionari: incluse indagini sui clienti e sugli impiegati così come domande specifiche che vorreste porre in anticipo ad ogni riunione di persona
• Workshop: Un modo utile per interrogare gruppi di persone e sperimentare un brainstorming più lungimirante; anche i focus group dei clienti rientrano in questa categoria
• Interviste: chiamare a rapporto i singoli stakeholder uno per uno, così che possano essere più schietti
• Shadowing: seguire gli stakeholder per una durata di tempo tipica. Questo tipo di inchiesta contestuale è spesso la più utile ma potrebbe anche essere la più faticosa
• Potenzialmente altri…

Professionisti diversi useranno approcci diversi e chiaramente qui il livello di impegno dovrebbe essere commisurato ai benefici e ai rischi attesi in merito alla nuova tecnologia.

In Real Story Group quando creiamo persona e scenari, ci piace utilizzare un approccio di inchiesta contestuale modificato. Raccogliamo gli individui con ruoli simili in una sala conferenze e interroghiamo il team come un gruppo. Usando un proiettore possiamo chiedere ad alcuni membri di effettuare il login per mostrare degli esempi specifici di un sistema attualmente in uso al gruppo. Quando raccogliamo i requisiti per un sistema interattivo, rendiamo l’ambiente il più interattivo possibile per ottenere il massimo scambio di informazioni.

Mandiamo cinque domande in anticipo come agenda per il workshop:

1. Mostraci brevemente, sullo schermo, quello che fai.
2. Cosa funziona bene nell’ambiente esistente (solo le prime tre cose)?
3. Cosa non funziona bene o manca nell’ambiente esistente (solo le prime tre cose)?
4. Come sta cambiando il tuo lavoro/mercato/ambiente/clientela?
5. Cos’altro c’è di importante di cui non abbiamo discusso?

Le domande sono volutamente a risposta aperta, per creare quanto più dialogo possibile. Notate l’enfasi su “prime tre”: non vogliamo una lista della spesa di feature, ma piuttosto i problemi e le opportunità più importanti.

A volte, è difficile per gli impiegati identificare le potenziali opportunità future, quindi può essere utile introdurre l’intero processo con dei workshop educativi che descrivano le best practice o gli esempi del settore di quello che altre aziende hanno fatto con la tecnologia. Questo è particolarmente importante quando si seleziona un tipo di tecnologia che l’azienda non ha mai usato prima.

Permane la questione del rimanere allineati con il business plan iniziale. Ci piace prenotare sessioni di mezz’ora con gli executive interessati a capire le correnti e gli obiettivi di business più ampi che sottendono il lavoro di selezione della tecnologia.

A questo punto, è stato raccolto molto materiale grezzo. Il passo successivo consiste nel convertirlo nei due componenti principali del futuro RFP: user story e Q&A avanzato.

Suggerimenti#section7

• Dovete investire nell’analisi sia delle informazioni sia del processo e questo richiederà l’analisi del documento così come le indagini contestuali.
• Evitate elenchi di feature lunghi, indistinti e basati su spreadsheet a cui sono da preferirsi le ricerche sul materiale necessario alla creazione di persona e scenari chiave.
• Cominciate con la user experience e procedete all’indietro verso i sistemi di impresa.
• Evitate la tentazione di allargare lo scope al di là del charter originale.
• Non dovete essere perfetti in questa (o qualunque altra) fase, quindi concentrate la ricerca sui problemi più pressanti degli stakeholder o sui bisogni intensi.