Vi sarà sicuramente capitato di perdere ore preziose – se non giorni e settimane – aspettando una risposta o impantanandovi in sterili discussioni. Questo era ciò che accadeva regolarmente anche a Jake Knapp, designer in Google Ventures (GV), fino a quando non decise di sviluppare un metodo per concentrare gli sforzi su un progetto nel più breve lasso di tempo possibile. Fu così che si inventò Sprint – how to solve big problems and test new ideas in just five days. Sì, è semplice come sembra: si tratta di un libro, scritto in collaborazione con designers del calibro di John Zeratsky e Braden Kowitz, che struttura il processo dell’innovazione in solo cinque giorni di sei ore ciascuno. In trenta ore di lavoro otterrete un prototipo che vi avrebbe tenuti impegnati almeno trenta giorni – peraltro portando spesso a risultati peggiori.

In questa recensione non miro a riassumere tutto il processo, perché vi toglierei il piacere dell’apprendimento e sono sicuro scriverei fin troppo; voglio invece trasmettervi il senso generale dello sprint, oltre a rimarcare i passaggi più importanti. Per saperne di più, vi invito ad andare sul sito ufficiale https://www.thesprintbook.com/ e a leggere il libro. È particolarmente utile a imprenditori e manager, ma qualsiasi persona che voglia sviluppare un’idea senza perdere tempo può beneficiare dalla lettura – peraltro estremamente piacevole (direi da ombrellone), grazie allo stile semplice, alla mancanza di termini tecnici e alla simpatia contagiosa degli autori. Ergo, lo consiglio senza remore anche a chi lavora in politica, per una ONG o in qualsiasi organizzazione che richieda lo sviluppo e l’implementazione di progetti.

Il libro è diviso in cinque giorni, ciascuno con una scaletta ben precisa – un po’ come la Genesi. Prima di tutto, però, si comincia con un buon team, che deve essere composto dai responsabili di ogni area rilevante ed eventualmente di consulenti esterni. La dimensione ideale è minore di sette persone e i numeri dispari sono più apprezzati dei pari per evitare pareggi nei voti. Ogni gruppo deve sempre avere un decisore (ovvero una persona che si prenda la responsabilità di decidere in caso di stallo), un facilitatore, che modera il lavoro e organizza la giornata, e un rompiscatole, che metta in dubbio le idee discusse (ruolo che mi calza a pennello). La regola di base, valida durante tutto lo sprint, è “no cellulari in aula”: visto il tempo limitato, non è il caso di distrarsi per cause esterne al progetto.

La nostra  storyboard. I post-it gialli sono i principali passaggi della catena del consumo, mentre quelli blu sono gli ” How might we?

Durante il primo giorno bisogna determinare l’obiettivo e comprendere i problemi da affrontare. È fondamentale “partire dalla fine”, ossia avendo ben chiaro lo scopo dello sprint e come il prodotto o servizio che verrà progettato dovrebbe comportarsi. Nel pomeriggio è bene avvalersi della consulenza di alcuni esperti, interni o esterni all’azienda, che rispondano ai dubbi di ciascun membro del team. Durante le interviste il gruppo deve prendere appunti individualmente, magari seguendo il metodo How might we? (che consiste nel formulare ogni suggerimento in una domanda che inizia con “come potremmo”). Questa parte è fondamentale per evitare imbarazzanti errori nello sviluppo, di cui ci si accorge solamente alla fine (vanificando così tutti gli sforzi fatti durante la settimana). Tutti questi punti vanno condensati per creare la vostra storyboard, che vi accompagnerà lungo tutta la settimana.

Il martedì è un giorno di miglioramenti marginali ma importantissimi: ciascuno deve lavorare sulla mappa tracciata il giorno precedente per perfezionare il prodotto o servizio. In questa fase si lavora rigorosamente da soli, senza nemmeno sbirciare ai progressi che stanno facendo gli altri membri, in modo da spremere il meglio da ciascuno e non perdersi in inutili polemiche su cosa funzioni meglio e cosa peggio. È importante essere dettagliati negli eventuali testi: scrivete quello che vorreste vedere parola per parola, virgola per virgola, in modo che la vostra idea sia chiara. La soluzione finale dev’essere chiara a chiunque, perché non sono ammesse spiegazioni del proprio disegno, in modo da non scoprire chi è l’ideatore di quel progetto. In seguito, ognuno deve disegnare le proprie proposte su un pezzo di carta, preparando poi otto bozze (le cosiddette “Crazy 8s”) che modifichino leggermente la propria migliore idea, in appena otto minuti; nessuno si aspetta dei Raffaello, e se i miei scarabocchi erano comprensibili significa che ce la possono fare davvero tutti 😉

Il mercoledì si votano le migliori soluzioni, appiccicando tutti i disegni sulla lavagna o sul muro e dando un certo numero di voti a ciascun membro (eventualmente il decisore potrebbe riceverne due o tre in più, in modo da far valere di più la sua opinione). Il pomeriggio si inizia a sviluppare un piano per il prototipo, che viene costruito il giovedì. Mi raccomando: non pretendete di riprodurre un modello al 100% funzionante e corrispondente a quello che desideravate; l’importante è che svolga le funzioni di base e che si interfacci con l’utente finale in un modo non troppo diverso da quello che farà il risultato finale. Ciascun tipo di prototipo ha diversi strumenti di sviluppo migliori: per un’app o un sito potreste usare PowerPoint o Keynote (con tutti i collegamenti ipertestuali del caso), per un servizio potreste simulare le risposte di un call center (mentre il cliente è in realtà al telefono con voi), mentre per un prodotto dovrete ingegnarvi e costruire qualcosa che somigli a ciò che avete in testa. L’obiettivo di questa fase è di dare un prodotto realistico (non reale) in una giornata.

Il venerdì è la giornata di test. Il facilitatore dovrà aver reclutato alcune persone che si offrano come cavie al vostro prodotto/servizio. Jake consiglia di intervistare solamente cinque utenti, ma di estrarre una grande quantità di informazioni dalle loro azioni, reazioni e domande. In questa fase l’intervistatore svolge un ruolo delicatissimo: deve riuscire a far sentire a proprio agio lo sconosciuto e a non porre delle domande che portino a risposte scontate o, peggio ancora, guidate dalla domanda stessa. Gli autori danno consigli pratici su come evitare errori durante l’intervista. Una volta raccolti i feedback, si tirano le somme della settimana e si decide cosa fare del prodotto/servizio proposto.

Anche nel caso si ottengano reazioni negative, l’esperienza accumulata risulterà fondamentale per le successive mosse del team. Lo sprint ci permette di risparmiare tempo, condensando un processo lungo e incerto in poche ore, e denaro, evitandoci costosissimi errori di progettazione e facendoci continuare il progetto solo se c’è un riscontro positivo dall’utente finale. Queste ragioni dovrebbero essere sufficienti per farci spingerci ad imparare a sprintare meglio di chiunque altro; io non sarò mai abbastanza grato a Marco Mari e Carlotta Borruto, Executive Directors di Italia Innovation, per avermi dato la possibilità di provare l’esperienza sulla mia pelle, sotto la guida esperta di Jake. Non vi resta che sprintare in libreria per aggiudicarvi la vostra copia 😉
Se siete curiosi di sapere di più sullo sprint o su Italia Innovation scrivetemi su Facebook!