Leggo finalmente le slide di Nicolò Volpato presentate a Better Software 2012 (quest’anno non ci sono andata). Nicolò ha parlato di “Visual design vs Creatività” e mi trovo d’accordo in linea generale con tutto il suo discorso. Avrei voluto parlare con lui dei problemi ricorrenti che sto affrontando io da quando, negli ultimi anni, stiamo approcciando i progetti con questa modalità di lavoro.

Un piccolo inciso: nei team che non adottano queste metodologie, i problemi sono più grandi. Grazie alle iterazioni, abbiamo come minimo l’occasione di farli emergere e possiamo tentare di risolverli.

Queste sono le slide di Nicolò:

1. Non sono previsti grossi bugfix su ux, visual e comunicazione (sulla ui qualcosina sì…)

La realtà dei progetti agili è che il dev guida il progetto più del designer e questo va in contrasto con l’utopia rappresentata dalla slide 47. Sulla quale tra l’altro non mi trovo d’accordo: designer e dev dovrebbero guidare insieme il progetto.
Perché succede? Il lavoro si svolge più o meno così:

• il designer propone un primo tentativo di ux, ui e visual, confrontandosi con il dev. Molto raramente questa proposta riguarda la porzione di design relativa a una sola iterazione, di solito abbraccia gruppi di iterazioni che possono portare anche a un rilascio completo e funzionante. Sì, lo fa anche nella fase di minor conoscenza del progetto, come rappresentato in slide 15. Ma è appunto una fase e le iterazioni future dovrebbero offrirci la possibilità i correggere il tiro.
• la proposta di design viene presentata al cliente, la si corregge e poi passa al dev che la sviluppa.
• la fase di sviluppo può durare qualche settimana. Qui il dev chiede al designer assistenza generica (png, piccoli dubbi di ux ecc.). A volte, alcune soluzioni di ux ipotizzate si rivelano troppo complesse e quindi il dev ne chiede una revisione. A volte questa revisione viene fatta al volo, per consegnare una demo funzionante e testabile con il cliente e la “toppa” viene discussa con lui. Quello che ho visto succedere è che queste toppe siano rimaste tali, pubblicate in una release e gli step successivi non ne prevedono la revisione. Di solito si dice che mancano sempre tempo e budget e poi “Che problema sarà, il cliente ha detto che è ok”. Quest’ultima frase nasconde l’alibi più grosso: il cliente non fa il nostro mestiere, siamo noi che dobbiamo guidarlo. Se non lo facciamo per mancanza di tempo o budget stiamo scendendo a un compromesso sulla qualità.

Derivo una seconda riflessione: durante le settimane in cui il dev sviluppa, investe il suo tempo a far funzionare, revisionare, correggere bug ecc. Ho una piccola sensazione a pelle: che un po’ del tempo che il dev investe a sistemare bug infinitesimali potrebbe essere spostato sul designer, che quindi avrebbe tempo e budget per sistemare i suoi bug (le famose toppe, grandi e piccole). Qui ci vogliono esperienza e buon senso del team, oltre che un po’ di retrospettiva sulle iterazioni.

2. Il cliente vuole un prezzo, ma di cosa?

Continuo a lavorare quasi sempre su progetti in cui vengono previste delle macro release. E le release successive alla prima non tengono conto dei test con gli utenti. Qui non mi riferisco ai piccoli problemi di usabilità che incontro, ma all’identità stessa di un progetto. Servirebbe una collaborazione reale del cliente e una buona dose di coraggio da parte di tutti.
Un esempio: il cliente ha già deciso che vuole una community, perché i numeri che conta di derivarci sono quelli che gli servono per bla bla bla… Per arrivarci costruisce con il team un progetto su misura suddiviso in n step. La prima release ci darebbe l’occasione di condurre degli ottimi test con gli utenti, ma questo non viene fatto. Supponiamo che i test vengano fatti (succede, sì) e magari gli utenti dimostrino di non amare le community ma di apprezzare invece altri aspetti del progetto…  Chi glielo dice ora al cliente? E come facciamo con il nostro budget? E se non vuole più spendere quei soldi con noi?
Il cliente non vuole sentire e persino il team ha paura. Ma non è forse anche questo un compromesso sulla qualità?

Come fare?

Sono due problemi che abbiamo più volte discusso con Jacopo durante le sedute di coaching in e-xtrategy. Ma c’è sempre un divario grosso da colmare tra teoria e pratica: i tempi e i progetti sono lunghi, non tutti i progetti partono con il piede giusto e bisogna “provare… provare… provare, provare, provare…” (cit.)
Portare all’attenzione questi temi alle altre aziende con cui sto collaborando è molto più difficile, perché non adottano le stesse metodologie e, in poche parole, vedono solo la punta dell’iceberg del problema.

Parliamone ancora

Io e Alessandro saremo all’Agile Day 2012, a presentare la versione aggiornata di “Perché non facciamo più quello che ci piace”. Ci si vede là.