Perdere il controlloMetodologie agili, user-experience, customer-handling... e tutto quanto fa brodo.

(Ovvero come rinunciare ad avere il controllo sulle cose e vivere felici!)

ATTO I - IoATTO II - UtentiATTO III - ClienteATTO IV - Conclusioni

Commedia in 4 atti

Dramatis personae

gileNon sono un agilista “ortodosso”... anzi, direi quasi di essere per certi versi un “eretico”... un anarchico. Nel senso che io mi occupo principalmente di design, e solo in parte di sviluppo, e quindi ho una visione “da esterno” del mondo agile, un approccio da “appassionato” e non da “professionista”.

Perciò l'idea di questa presentazione è quella di provare a raccontare la mia esperienza di web-designer e contemporaneamente web-developer, a partire dal primo incontro/scontro con i metodi agili all'Italian Agile Day di un paio di anni fa e di come essi abbiano cambiato il mio modo di lavorare, di progettare il design delle interfacce, di studiare la user-experience dei prodotti.

Di come spostare il fulcro del proprio lavoro da "io" a "loro" (gli utenti) e abbia implicato un passaggio logico - e per niente banale - da "prodotto" a "servizio", e quindi un passaggio da "utenza" ad "esperienza", con tutte le difficoltà connesse alla progettazione di qualcosa su cui la nostra possibilità di controllo è assolutamente limitata.

Di come poter coniugare il proprio "essere agili" con l'irrazionalità e l'imprevedibilità dei propri clienti abbia richiesto una rinuncia: quella al controllo nei minimi termini del software/sito fornito, al suo "possesso" assoluto da parte nostra per cederne responsabilità e oneri al legittimo proprietario: il cliente stesso, colui che è responsabile ultimo della qualità del prodotto/servizio - e della relativa esperienza d'uso - che intende offrire ai propri utenti/clienti.

Di come in fondo per essere felici (lavorativamente parlando, ma non solo) non basti "essere agili", ma occorre anche rinunciare all'idea di poter gestire tutti gli attori e tutte le variabili in gioco, per potersi finalmente concentrare su ciò che realmente possiamo controllare: noi stessi e la qualità del nostro lavoro.

(E soprattutto, di come poter raccontare tutte queste cose con un sorriso sulle labbra).

Atto I - Io

Scena prima - “Tempus fugit”

Da cosa derivano tutte queste mie riflessioni: dai miei capelli grigi.

Avere i capelli grigi significa esser maturato, come età ovviamente ma anche come competenze, come modo di lavorare. Se l’hanno scorso il mantra che mi ha portato a cambiare completamente il modo di lavorare è stato “essere agili”, il mantra di quest’anno è stato “perdere il controllo”.

Mi sono cioè reso conto che essere agili e allo stesso tempo pensare di avere il controllo su tutto ciò che faccio non sono un buon binomio.

Vita personale

Né sul lavoro, né nella vita privata.

Come mi sentivo ieri

Se da giovane mi sentivo come “Jeeg Robot d’Acciaio”

Come mi sento oggi

oggi mi sento più come “MacGyver”.

Come ero ieri

Se vogliamo usare una metafora: una volta ero come una freccia, veloce e dritta verso il proprio bersaglio.

Come sono oggi

Oggi mi sono reso conto che sono, ed è sicuramente molto meglio, un coltellino svizzero multiuso.E’ meglio perché se da giovane essere veloci e andare dritti all’obiettivo è un vantaggio, un plus, crescere vuol dire anche affrontare progetti più complessi, progetti professionalmente più complessi, più a lungo termine.

Probabilità

100%Ora, nei progetti a lungo termine sappiamo tutti che la probabilità che il cliente cambi specifiche e requisiti in corso d’opera è pressoché una certezza, quindi se tu sei una freccia e sei stata scoccata, non hai più modo di cambiare direzione.

Scena seconda - “Beeing agile”

Ecco allora che il mio incontro/scontro con le metodologie agili diventa amore a prima vista. Essere agili, ovvero avere la capacità - intesa innanzitutto come attitudine mentale - di adattarsi al cambiamento, nei progetti come nella vita personale, ha significato uno stravolgimento completo del mio modo di lavorare. Mi ha portato ad avere un approccio più agile e iterativo nei miei processi di lavoro, mi ha portato all’adozione di nuove tecniche. Tecniche di “design agile”.

Il contesto

Tecniche che sono andate ad affiancarsi ad un processo, già in corso da tempo, di rielaborazione dei miei modelli mentali e dell’approccio alla progettazione e al design delle interfacce delle applicazioni e dei siti web.

Time management

http://www.pomodorotechnique.com/

24:00

La tecnica che ha dato il “la” è stata sicuramente la “tecnica del pomodoro”, che anche se non è mai stata applicata concretamente nei termini canonici, mi è servita moltissimo per acquisire una diversa percezione del mio tempo di lavoro. I 25 minuti canonici oggi sono diventati per me la mia giornata di lavoro. E’ con quella che misuro le mie offerte, è con quella che misuro il mio tempo lavorativo. E’ con quella che misuro la mia velocità. E’ grazie a quella che da molto tempo non “sforo” nei progetti (almeno, non senza rendermene conto e decidere coscientemente se farlo o meno...)

Paper prototyping

Una prima tecnica utilizzata concretamente è stata l’utilizzo di carta, post-it e pennarelli per la progettazione rapida e l’identificazione dell’architettura generale di un progetto o di un sito web, possibilmente fatta assieme al cliente.

Wireframing

Un’altra tecnica è stata quella di adottare schemi visuali - i cosidetti wireframe - più orientati alla definizione dei flussi logici e dei layout di impaginazione e meno alla presentazione grafica degli elementi e dei contenuti.

Personas

Un’altra tecnica adottata è stata quella delle “personas”, che se anche non direttamente collegata alle metodologie agili, tuttavia costringe il cliente a esplicitare, fin dall’inizio del progetto, i suoi requisiti e permette a noi di focalizzare quali sono i suoi obiettivi.

Prototipi funzionali

In alcuni casi, al posto dei semplici wireframe su carta, vengono realizzati direttamente dei veri e propri prototipi funzionali, con cui il cliente può interagire e che possono essere usati come “piattaforma di confronto” su cui andare a iterare in modo veloce e a basso costo per definire le specifiche finali di progetto.

Other stu!

customer-on-site

iterationindividuals

customercollaboration

documentation-less

retrospective

E molto altro ancora...

Toolbox

Tutte queste tecniche rappresentano oggi la mia “scatola degli attrezzi”, il mio “coltellino svizzero” con cui posso affrontare ogni volta un nuovo progetto senza avere a priori uno schema predefinito, da seguire pedissequamente, ma costruendolo ex-novo ogni volta, decidendo day-by-day quale “tool” adottare per uno specifico scopo, per andare allo step successivo e avvicinarsi così all’obiettivo finale. Certe volte, anche in funzione del tipo di cliente che ho di fronte, del tipo di persona con cui ho a che fare.

In fondo, anche MacGyver costruiva “tool” con pezzi messi assieme con lo scotch per uno scopo ben preciso: funzionare!

Atto II - Utenti

Scena unica - “Homo utentis”

Users

Secondo me non esiste più lo "user", è solo un archetipo che ci si crea ad arte. E' un totem, da adorare e venerare, e al cui altare spesso viene sacrificato il proprio senso critico, la propria creatività.

Bottoni

53 1vs

Il problema è che spesso pensiamo che far "disegnare" un prodotto a un utente (o a un cliente) sia di per sé una buona scelta. Beh, temo che se qualche anno fa qualcuno dentro la Apple avesse chiesto agli "Utenti" quanti bottoni volessero su loro cellulare, la risposta "un solo bottone" non sarebbe nemmeno stata presa in considerazione.

Consumers

All'ExperienceCamp di Milano ho sentito una frase che per me è stata rivelatrice: "Oggi ci sono persone che comprano il Porsche Cayenne e fanno la spesa alla Lidl". Ora: come puoi minimamente comprendere nei tuoi schemi, come puoi pensare di poter disegnare (nel senso di "controllare", di poter avere leve su cui operare) la user-experience altrui, quando non hai alcun modello che possa rappresentare quello che passa nella testa (e nel cuore, soprattutto) delle persone?

Puoi prendere un campione di 10, 100, 1000 persone. Testare una applicazione/prodotto/servizio su di loro. Ma avrai sempre un insieme di 10, 100, 1000 diverse UX, una per ogni testa. E non sarà attraverso interviste, eye-tracking, test A/B o card-sorting che potrai "capire" veramente cosa vorranno i tuoi utenti.

Avrai solo l'informazione media, "qui e ora", di cosa vuole il tuo campione. Ma da domani tutto il lavoro sarebbe da rifare, perché la testa delle persone è già cambiata, i loro desideri sono cambiati, nel frattempo hanno già venduto il Porsche Cayenne e...

Consumers

... si sono comprati la Toyota Prius perché ha il pannello fotovoltaico sul tettuccio!

Complessità

E guardate che non sto parlando di volubilità delle persone, questo è un vecchio discorso. Sto parlando di complessità del mondo, e quindi di impossibilità di comprenderlo sotto un unico cappello "User", su cui poi vado a costruire o progettare una esperienza.

Per questo secondo me oggi chi fa UX, e più in generale realizza prodotti e - nel nostro caso specifico - software dovrebbe dedicare tempo, risorse ed energie a disegnare il "servizio" e quindi l’esperienza (Andrea Resmini ne parla da un po'). Il migliore servizio che riesce a mettere in campo. Deve costruirlo assieme al proprio committente, passo passo, con tanta tanta analisi, togliendo, limando, aggiustando, iterando.

Mattoncini

Deve costruire la "experience" non come un meccanismo predeterminato e preconfezionato (pia illusione!) ma come una serie di "mattoncini". E non mattoncini qualsiasi: ogni mattoncino deve essere il migliore mattoncino che esista sulla terra, il migliore che riusciamo a realizzare con le nostre capacità/risorse/competenze. Sarà poi l'utete a costruire la sua user-experience, sulla base dei sui desideri, delle sue passioni, della sua "voglia del momento".

Connecting the dots

http://www.slideshare.net/frogdesign/brugnoli-system-ux-1061731

All'ultimo IA Summit di Forlì c’è stata una presentazione che mi ha molto colpito, dal titolo "Connecting the dots". Ecco, quello è il punto: non posso più pensare di controllare l'utente, decidere a priori quale sarà il suo percorso, con quali mattoncini costruirà la propria user-experience (il Cayenne e la Lidl sono due mattoncini con cui costruisce la propria UX quotidiana, "iHandy Level" e "Flight Control" sono i mattoncini con cui costruisce la propria UX sull'iPhone).

Mattoncini

Quello che posso (devo, ripeto) fare è invece costruire appunto i mattoncini (e guardate che non è riduzionismo). I mattoncini sono i dettagli: il suono del click quando blocco/sblocco l'iPhone, il distributore di calzini di spugna all'ingresso dello Småland all'IKEA, il modo buffo con cui Pippo firma gli autografi nei parchi Disney.

Il “giardinetto della felicità”

Devo costruire il “giardinetto della felicità”. E per farlo, per farlo davvero bene, devo capire i bisogni veri e profondi delle persone. E non è così ovvio: pensate che ce ne siamo dimenticati a tal punto, dei bisogni e delle motivazioni delle persone, che qualcuno ha dovuto addirittura re-inventare una “teoria del design motivazionale”!

Atto III - Cliente

Scena unica - “Committenza”

Conosci il tuo “nemico”?

Agile Realevs

Fin dal mio primo incontro/scontro con le metodologie agili, ho sempre pensato che il cliente rappresenti un po’ l’anello debole della catena. Non delle metodologie in sé, quanto della loro applicazione reale ed effettiva. Nel senso che spesso il cliente viene rappresentato come una persona ben felice di sedersi attorno a un tavolo con noi a scrivere user-stories, disposta a testare l’applicazione e il software ad ogni rilascio, a calcolare i punti e decidere quali sono le features da implementare prima e quali dopo, a venire presso la nostra azienda, sedersi accanto a noi e vederci sviluppare la sua applicazione; ma soprattutto è una persona che ha sempre ben chiari quali sono i suoi obiettivi di business e come raggiungerli, che ha una cultura sia personale che manageriale in grado di assisterlo nella comprensione e nella valutazione delle opzioni che gli sottoponiamo, e guidarlo nelle scelte conseguenti. Insomma: il cliente “agile” è il cliente perfetto.

Ora, io non so se è un problema tutto italiano, o comune ad ogni continente e latitudine. So solo che “quel cliente lì” io non l’ho mai incontrato. E a detta di molti, non esiste proprio! Il cliente “reale” è ben altra cosa, e tutti sappiamo quello di cui sto parlando.

Questa non è certamente una colpa delle metodologie agili. Però è comunque un difetto di realismo che secondo me va affrontato.

Essere razionale

Noi partiamo dal presupposto che il nostro cliente sia un essere razionale, e su questo basiamo molti dei nostri comportamenti (ed è questo un aspetto delle metodologie agili che mi lascia dubbioso...) mentre in realtà l’esperienza ci insegna esattamente il contrario: il cliente spesso fa scelte illogiche, senza senso, che vanno addirittura contro il proprio interesse.

Pensiamo che poiché è razionale, allora possiamo relazionarci con lui e controllare questa relazione in modo lineare. Una volta che ho capito come ragiona il mio cliente, sono cavallo. Poi però il giorno che si è svegliato male o ha litigato con la moglie/il marito, cosa faccio? Perdo tutto il mio controllo, senza più alcuna possibilità di cambiare strategia.

A ognuno il suo

Quale è il ruolo che i tre “domini” coinvolti nel nostro lavoro, ovvero “io/noi”+cliente+utente, devono avere reciprocamente? Sono giunto alla conclusione che devono essere disgiunti su alcuni aspetti fondamentali. Sono convinto che occorre riportare ognuno ai propri ruoli: il committente disegna/crea/progetta (anche grazie al nostro aiuto) il suo miglior modello di business, il suo miglior prodotto/servizio (e perché abbia successo non possiamo prescindere dagli utenti); poi però dovrò lasciare agli utenti la possibilità di disegnare quella che per loro è la migliore experience, senza illudermi di poterla conoscere a priori, e al cliente la responsabilità del successo di quel progetto: il business è suo. Non devo innamorarmi del prodotto, anche se è “un figlio mio”. Occorre lasciarlo andare, non essere sempre una chioccia. Non pretendere di averne sempre il controllo, avendone la paternità. Ripeto: il business è suo, noi facciamo un altro lavoro, concentriamoci su quello.

Fare design oggi significa ripensare il proprio ruolo: non più "master" (disegno la UX, quindi controllo la UX, quindi sono UX) ma "slave": faccio un servizio nel miglior modo possibile, mi metto "al servizio" dei miei utenti.

Evangelizzazione

Un’altra conclusione a cui sono arrivato (ma in un grosso progetto che sta per partire ci riproverò, e probabilmente ci sbatterò di nuovo la testa, quindi predico bene ma razzolo male) è che il cliente NON vada evangelizzato. Ho regalato libri di AI e usabilità, ho fatto riunioni in cui ho raccontato e provato a spiegare i metodi agili, in modo che diventassero un “terreno comune” di lavoro. Ma non è servito a nulla. E probabilmente in fondo è sbagliato.

Siamo noi che siamo appassionati di metodologie agili, siamo noi che abbiamo (dovremmo avere) fatto nostri i principi alla loro base. Il cliente no. Può anche essere interessato o incuriosito, può anche comprendere che per lui e per la sua attività è un beneficio l’uso di questo approccio. Però resta il fatto che lui fa un altro lavoro. Per quanto tempo e voglia possa avere, deve comunque occuparsi e preoccuparsi di quello, non del nostro. Il suo primo pensiero è al suo lavoro, non al nostro. Anche se magari il nostro gli porterà enormi benefici, anche se è ben felice di stare in riunione con noi a fare user-stories o paper-prototyping, ma resta comunque il fatto che se dedica oggi la sua giornata a queste attività, domani dovrà lavorare il doppio per recuperare.

Dobbiamo essere in grado di lavorare indipendentemente dal grado di agilità del cliente. Tanto meno dobbiamo pretendere che il cliente cambi abitudini e/o mentalità solo perché sappiamo (?!) che per lui sarebbe meglio o conveniente.

Per rimanere sul tema evangelico: non dobbiamo “imporre la parola” come dei crociati, bensì “testimoniarla” con la nostra condotta di vita!

Atto IV - Conclusioni

Scena unica - “Summa”

ipse dixit

“Let it be, let it be, let it be.”

Fin qui abbiamo visto come “perdere una parte del proprio controllo” sugli utenti e sui clienti. Resta un’ultima parte: quella su noi stessi.

La metafora della valigia

http://www.bettersoftware.it/conference/talks/i-metodi-agili-e-laumento-del-roi

Ora, tutti noi abbiamo l’ansia del controllo. Per chi non lo avesse visto, Francesco Cirillo ha fatto una bellissima presentazione, usando appunto la metafora della valigia, in cui spiegava come non abbia senso che quando andiamo in viaggio per lavoro (da un cliente, a un corso, ecc.) ci portiamo dietro 3 libri, 5 ricambi, la cuffia il costume e l’accappatoio per andare forse in piscina, ecc. perché così facendo abbiamo una valigia talmente enorme che poi non siamo più in grado di rispondere agli imprevisti, come il ritardo di un treno o un acquazzone improvviso. Così facendo, abbiamo solo l’illusione di esser pronti a tutto: in realtà abbiamo solo una palla al piede, la valigia si trasforma in una zavorra.

Sinceramente, se aveste pensato voi a progettare l’iPhone, quante volte vi sareste chiesti “Si ma se poi l’utente vuole fare XXX, come fa?” e avreste aggiunto un bottone (una funzione nel vostro software). Ecco, quella è proprio ansia di controllo. Voler controllare e predeterminare tutte le possibili casistiche e scenari. Il nostro software deve poter far tutto. La nostra valigia deve contenere tutti i tipi possibili di abbigliamento: se fa caldo, se fa freddo, se fa tiepido, se piove, se nevica, ecc. ecc.

Invece molto meglio portarsi uno zainetto con poche cose, e agire di conseguenza se necessario. Avere con sé solo uno zainetto, ed è questa la parte più interessante e a mio avviso profonda della metafora di Cirillo, specialmente se traslata sulle metodologie agili, è che essere agili e “leggeri” vuol dire soprattutto saper cogliere al volo le opportunità, le possibilità che mi si aprono davanti nel momento stesso in cui decido, nel luogo in cui vado a fare consulenza, di provare una nuova attività o di andarmene a zonzo per la città senza un percorso prestabilito. (Se non ricordo male, lui diceva di aver deciso, nella città in cui era andato per lavoro, di seguire un corso di djambe, un tamburo africano, e di essersene appassionato moltissimo).

La ricerca della felicità

Questo vuol dire essere pronto ad accettare, senza un controllo preventivo - e ripeto, è un’attitudine mentale - non solo i cambiamenti ma anche le possibilità che ci vengono offerte. Vuol dire essere adattativi, mentre in realtà spesso si tende solo a essere agilmente schematici.

Questo vuol dire sì perdere qualcosa, il controllo, ma guadagnare qualcos’altro: una maggiore serenità nell’affrontare le incertezze, quella che gli anglosassoni chiamano “serendipity” e una migliore consapevolezza delle proprie capacità e dei propri limiti.

Grazie!

Cristiano Rastelliweb: www.didoo.net interaction design

?A voi la parola!

Se avete domande, suggerimenti, idee da condividere, critiche...