Lavoriamo insieme ai nostri clienti nel disegno e sviluppo di progetti digitali calando sul loro contesto varie metodologie e approcci (agile, lean, eXtreme programming, design thinking, …) e mettendo a disposizione team cross-funzionali che possano cogliere complessità e impatto delle problematiche da affrontare.
Questo articolo parla di come la “UX” sia una competenza essenziale dei nostri team e del suo ruolo nel proteggere i progetti da alcuni degli anti-pattern più comuni che abbiamo riscontrato nel tempo.
Premessa
Per nostra esperienza, due aspetti vengono spesso sottovalutati e per questo producono risultati lontani dalle attese:
- La sfida più grande di qualsiasi progetto digitale è “capire”, creare conoscenza condivisa sul contesto e sul problema per poi individuare l’azione giusta (senza dare per scontato che ce ne sia una unica e che sia per forza il software).
Se pensiamo, metaforicamente, a un progetto come un viaggio di esplorazione, il problema principale è individuare la giusta direzione per raggiungere la meta. - Questa conoscenza non può essere completa e perfettamente definita per nessuno (neanche per i nostri clienti) all’inizio del progetto, né mai lo sarà, ma cresce durante il progetto.
Quindi, se torniamo alla metafora, possiamo dire che fare un progetto è come fare un viaggio perché scopriamo sempre qualcosa di più sul territorio che stiamo esplorando mano mano che avanziamo. Il viaggio è fatto sia di attività che ci aiutano a mappare il territorio che ci si staglia di fronte, sia di tappe di avanzamento conseguenti e che ci avvicinano alla meta. La posizione precisa della della nostra destinazione è anche essa un’ipotesi che viene raffinata grazie a quello che apprendiamo durante il viaggio.
Per fare questo “viaggio” in modo sano abbiamo affinato (e lo stiamo ancora facendo!) i migliori strumenti di “navigazione”. I principi e il manifesto agile ci hanno portato a lavorare per tappe brevi, di una settimana. Fare piccole tappe ci permette di ridurre al minimo il rischio di andare nella direzione sbagliata e ci garantisce di poter correggere spesso la rotta.
Tuttavia, questo non basta. Da sole le metodologie agili (che di per sé sono solo uno strumento a supporto) non ci danno abbastanza informazioni rispetto a:
- quanto ci stiamo avvicinando alla meta?
- stiamo andando nella giusta direzione?
- cosa dobbiamo fare ora per avvicinarci il più possibile?
- cosa abbiamo imparato dal viaggio fatto fino ad ora? queste conoscenze impattano sui nostri obiettivi?
Gli anti-pattern più comuni
Ci sono diversi anti-pattern che possono nascere all’interno di un team agile, quasi tutti sono legati al fatto che le metodologie agili vengono spesso scambiate per una garanzia che tutto quello che viene fatto seguendone i principi è giusto “a priori”. Ne raccontiamo alcuni che abbiamo vissuto.
La bulimia da backlog
La bulimia da backlog è quando la kanban e le user story si trasformano da strumento a obiettivo. Si verifica quando si accumulano batch di user story da fare senza nessuna verifica reale del perché quelle funzionalità ci aiutano ad avvicinarci al nostro obiettivo. Oppure quando aver prioritizzato e scritto le user story secondo i riti e i canoni sia di per sé garanzia del fatto che esse portano valore e stiamo facendo la cosa giusta. Come abbiamo detto recentemente nell’episodio di Flowing Radio sulla gestione del backlog lavorare in questo modo significa anche scambiare ipotesi per conoscenza validata.
Focalizzarsi sulla metrica sbagliata
Le metriche come la velocity, il numero di story point settimanali che facciamo, o la test coverage di per sé, non sono minimamente misura del fatto che stiamo facendo un software di valore (come spieghiamo in questo episodio).
Tornando alla metafora del viaggio, il fatto che abbiamo una macchina veloce non significa che la macchina stia andando nella giusta direzione.
Il software, quando non è di valore, non solo non serve a niente, ma è tre volte spreco: la prima volta per produrlo, poi per mantenerlo e infine per scriverlo di nuovo perché non andava bene.
Il cliente “ha sempre ragione”
Dobbiamo farlo “perché è quello che ha detto il cliente”, “il cliente ha sempre ragione”. Questo anti-pattern è uno fra i più comuni. Sia perché è molto “comodo” per nascondere il nostro fallimento dietro a un alibi, sia perché potrebbe essere anche quello che si ricava da un’interpretazione errata del primo principio del manifesto agile:
La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.
Come abbiamo spiegato qui, il vero significato di questo principio non è “dobbiamo eseguire i comandi del cliente”. Piuttosto è “dobbiamo fare la cosa giusta” perché il software sia di valore nel contesto del nostro cliente. Il modo per fare software di valore è capire il problema. Quindi è giusto dedicare tempo per esplorare a fondo “il perché” dietro la sua richiesta e poi proporre la soluzione. Per farlo dovrebbe essere dovere e premura di ogni azienda che realizza progetti software fare challenge con le giuste domande e porre i giusti dubbi al cliente. Alla fine la decisione ultima sull’investimento rimane sua, ma a noi è richiesto di esercitare una sana maieutica.
La User Experience come strumento di apprendimento
Come è evidente dagli anti-pattern citati (non abbiamo la pretesa di essere esaustivi, sono solo alcuni esempi) emerge che fare progetti software di valore è in primis un problema di apprendimento. Non può esistere quindi una ricetta, una checklist di cose che se fatte assicurano in automatico il successo. Ogni progetto deve essere esplorato e appreso.
Le informazioni che il team cross-funzionale (comprensivo di manager, designer, sviluppatori, ops, …) è in grado di maturare (come, ad esempio, vincoli tecnici e obiettivi di business) sono utili e necessarie ma non sufficienti. Non basta fare step piccoli e incrementali se poi rimaniamo avulsi dal mondo in cui il nostro progetto genera valore. Per capire il bisogno e come soddisfarlo è necessario andare nel contesto d’uso, prendere tutti i feedback utili fare il prossimo migliore step e stabilire la meta con precisione. Occorre quindi fare attività di ricerca UX.
Tornando alla metafora del viaggio non basta fare piccole tappe se mentre viaggiamo non ci concentriamo a studiare il territorio e creare delle mappe che ci aiutino nella futura navigazione avendo una meta chiara. Corriamo il rischio di girare a vuoto senza uno scopo, attirati dalla prima cosa che vediamo dal finestrino.
Maturare le conoscenze giuste non significa solo fare attività di UX. Ma la UX è sicuramente una delle cose che di più aiutano.
Agile VS User Experience: uno contro l’altro, praticamente amici
Qualsiasi approccio di sviluppo agile che non tenga conto anche del feedback che la UX ci può dare è un processo fallace, tradisce un altro dei principi del manifesto, ovvero:
La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale.
Il software di valore è quello che usa la UX, insieme a tutte le altre conoscenze che il team matura, come feedback per guidare il progetto al più piccolo set di funzionalità necessario a risolvere il problema, esattamente come un test unitario ci guida a scrivere il minor numero di righe di codice possibile per sviluppare una funzionalità (ne abbiamo già parlato qui).
In questo senso la User Experience non è e non deve essere mai vista come un processo separato da quello di sviluppo, ma come parte di esso.
I diversi livelli di maturità del cliente
Sappiamo quello che molti di voi stanno pensando: “Qui da noi questa cosa non funziona…”, oppure “I miei clienti non lo accetterebbero mai”.
Non dobbiamo nasconderci che ogni cliente può avere diversi livelli di maturità. Non con tutti potremmo parlare lo stesso linguaggio e proporre le medesime attività.
A tutti però possiamo fare, quanto meno, delle domande per far emergere la migliore ipotesi possibile rispetto al tema degli utenti, del contesto, dei requisiti non funzionali. Anche se non sono informazioni validate e non sono emerse da una ricerca, sarà comunque meglio che lavorare al buio.
Partiamo dal presupposto che i primi passi che muoviamo con il nostro cliente sono spesso quelli decisivi per orientare la sua aspettativa nei confronti del percorso che verrà fatto insieme. Una prima azione che riteniamo possa essere fatta quasi sempre per iniziare col piede giusto è una sessione di discovery dove invitiamo tutto il team cross-funzionale insieme al cliente. Il fatto stesso che ci sia un momento dedicato a creare conoscenza condivisa, e che a questo momento partecipino varie professionalità getta tutti i presupposti di un approccio sano al progetto.
Poi, a seconda del livello di maturità del cliente, si potranno immaginare altre attività di learning più avanzate o approfondite, oppure rimanere nell’ambito degli assunti e delle euristiche.
Quasi sempre ci troviamo a spiegare il valore delle attività di learning. Crediamo che questo “sforzo” non sia mai sprecato, noi siamo lì proprio perché ai nostri clienti quelle competenze mancano. Molto spesso sono questi sforzi che poi producono una crescita di consapevolezza e un conseguente ampliamento dei tipi di attività che possiamo proporre. In altri casi, invece, bisogna accettare che non potremmo mai andare oltre a un rapporto fortemente centrato sulla delivery.
Learning & Doing
La UX è quindi parte integrante e necessaria di un processo di sviluppo al pari del codice e del business. Tutti insieme partecipano sia alla fase di learning che a quella di doing .
In un processo ideale ci aspettiamo che nella fase di learning la UX ci fornisca una conoscenza degli utenti, delle loro aspettative, sensibilità e modelli mentali tali per cui sappiamo identificare bene il problema da risolvere. Questo per noi è il feedback più veritiero che abbiamo e che ci guida nella fase di doing.
Ovviamente ci sono anche bisogni “commerciali” che emergono dalla conoscenza di chi tiene le chiavi del business ed è chiamato a monetizzare il valore di un software (come, ad esempio, “se aggiungiamo questa funzionalità vendiamo più facilmente”). Questo non possiamo nasconderlo, ma l’origine di tale necessità deve essere esplicita.
È solo da questa conoscenza condivisa a tutto il team che dovrebbero maturare le decisioni sulla delivery e le sue priorità progettando interfacce, interazioni, design system e implementando tutto attraverso il codice (che quindi ritroveremo nel nostro backlog).
Le attività di UX sono quindi presenti sia nei momenti dedicati al learning che al doing: l’apprendimento che è in grado di generare ci permette di evitare gli anti-pattern che vi abbiamo raccontato, per realizzare software di valore e massimizzarne l’investimento.
Totally agree! Love #crossfunctional team ❤ https://t.co/s1EbrG2K3C
— FLOWING (@flowingis) September 8, 2020
Photo credits: sebastiaan stam on Unsplash
