Da quando abbiamo iniziato a concentrarci sui semplici siti web e sui prodotti web, sono accaduti una serie di eventi significativi. Grazie a una case history degna di nota e al nostro legame con il network di Talent Garden abbiamo incontrato diversi imprenditori e aziende disposti ad avviare startup digitali che necessitano di conoscenze tecniche in materia di design e coding.
Per quanto complesso possa essere un semplice sito, è molto probabile che rientri nell'ambito dei “requisiti noti”. È sufficiente definire in anticipo l'aspetto e il funzionamento del sito in ogni dettaglio. Non è una scienza missilistica concordare un ambito, un budget e una stima dei tempi.
Per i prodotti digitali vale una regola molto diversa. Il “sito” non è solo una vetrina: è il prodotto stesso, il suo core business. Noi, come facilitatori, cerchiamo di stimolare la fase di avvio di un prodotto con il nostro know-how, comprendendo il business e contribuendo al suo piano di sviluppo.
Quasi tutte le startup oggi abbracciano la metodologia lean:
fissare delle premesse → convalidarle in anticipo attraverso un MVP → iterare.
Minimumn Viable Product
L'esatta portata di un nuovo prodotto digitale è mutevole: i requisiti cambieranno durante la progettazione e la convalida delle ipotesi direttamente con gli utenti.
In questo scenario, le lunghe specifiche dei requisiti sono tossiche: ciò che deve essere intrinsecamente flessibile per avere successo diventerebbe altrimenti rigido e formale.
Ciò si ripercuote inevitabilmente anche sul rapporto cliente-venditore.
Ma allora, come è possibile aiutare i clienti a gestire il budget e la programmazione in cicli snelli? Come possiamo applicare tutto questo a situazioni reali?
Comincia dal perché
Come direbbe Simon Sinek, è fondamentale innanzitutto condividere il perché abbiamo passato le nostre notti a studiare una soluzione migliore al paradigma difettoso cliente-venditore.
- Ragione n.1: Ci piace quello che facciamo, davvero. La nostra missione non è cambiare il mondo. Crediamo di poter creare un posto di lavoro migliore, un luogo in cui crescere personalmente e professionalmente come team facendo le cose che amiamo e aiutando gli altri attraverso le nostre competenze; siamo alla ricerca di un miglioramento continuo e siamo desiderosi di condividere le nostre scoperte e la nostra visione “interna” con il mondo esterno.
- Ragione n. 2: Non crediamo che al giorno d'oggi sia ancora accettabile lavorare senza aiutare realmente il cliente a perseguire i suoi obiettivi di business e a fargli guadagnare denaro. Non va bene essere “solo un fornitore”, vogliamo essere parte di qualcosa di grande. Inoltre, le case history degne di nota portano a una maggiore visibilità (e quindi a più lavoro).
Ecco perché stiamo cambiando il modo di lavorare con i nostri clienti.
Ora concentriamoci su come lo stiamo facendo.
La "big picture"
Siamo onesti: non siamo l'unico studio là fuori, ci sono molti ottimi fornitori agili. Tuttavia, credo che la scelta di un partner sia una scelta molto emotiva.
Nell'ultimo anno ho osservato un modello comune nei nostri clienti: capiscono e condividono profondamente il nostro stile, il nostro atteggiamento e le nostre motivazioni.
Ai nostri clienti piace la nostra storia e il nostro modo di fare le cose, si riconoscono nel nostro atteggiamento e noi instauriamo con loro un profondo rapporto di fiducia.
Come funziona?
Il primo passo consiste nell'ascoltare molto. Cominciamo a scomporre un'idea nei suoi piccoli elementi fondamentali; ci aiutiamo con una tecnica visiva che abbiamo scoperto mentre stavamo formando il nostro metodo di progettazione, uno strumento d'argento: La Mappatura delle storie degli utenti.
Così ci mettiamo nei panni degli utenti reali. Lo Story Mapping cerca di descrivere l'intero percorso più lungo che un utente può compiere all'interno dell'applicazione scrivendo dei post-it su un muro in un flusso di lavoro da sinistra a destra per ogni funzione.
Lo Story Mapping consiste nel descrivere il percorso dell'utente passo dopo passo (da sinistra a destra, carte blu nella foto) con un elenco dettagliato di ogni fase (dall'alto verso il basso, carte gialle nella foto).
Lo Story Mapping è fondamentalmente una sessione di workshop svolta direttamente con il cliente. Preferiamo una lavagna fisica per le sessioni di story mapping e poi spostiamo la mappa su uno strumento virtuale (storiesonboard.com fa questo lavoro molto bene).
Comsa abbiamo scoperto nel mentre
- Il risultato più prezioso dello Story Mapping non è la mappatura dei post-it in sé, ma il brainstorming, la risoluzione dei dubbi che emergono e le decisioni prese durante le sessioni di workshop.
- Lo Story Mapping è uno strumento “aperto” e “facilmente leggibile”. È stato progettato in modo che chiunque possa contribuire attivamente e partecipare in qualsiasi momento: I progettisti e gli sviluppatori dell'interfaccia utente possono dare suggerimenti per valutare la complessità delle funzionalità, gli addetti al marketing possono raccontare le loro caratteristiche irrinunciabili, i responsabili delle vendite possono condividere il loro punto di vista basato sul consumatore. Tutti possono e devono essere coinvolti nel processo.
La parte migliore del viaggio è la sorpresa e la meraviglia lungo il percorso.
(una persona a caso sullo User Story Mapping - senza saperne molto)
La roadmap
Quindi, il prodotto ha senso. Abbiamo fatto un quadro generale del prodotto con dettagli sufficienti, abbiamo persino stabilito le priorità di rilascio per ottenere una prima serie di funzionalità testabili senza pretendere di costruire un progetto di dodici mesi tutto in uno.
Cosa succederà dopo?
A questo punto tutti vogliono sapere quanti soldi dovranno investire. Per rispondere a questa domanda traduciamo le epiche e i temi dalla Story Map a una roadmap di esecuzione suddivisa in sprint (una o due settimane), con la prerogativa di progettare e codificare continuamente settimana per settimana (come suggerisce la filosofia agile).
Dato che saranno coinvolte molte persone del nostro team, la Roadmap fornisce due informazioni preziose:
- Quante settimane lavoreremo → dato il costo del singolo sprint, poi moltiplicato per il numero di settimane della roadmap, si può ottenere la stima del budget finale per il progetto.
- Quanto tempo ci servirà prima di poter rilasciare qualcosa di pubblico → quanto prima potremo convalidare il prodotto con utenti reali.
Sebbene questo metodo non sia perfetto, a causa del fattore umano che gioca un ruolo chiave nella previsione degli sforzi futuri (noi esseri umani non siamo molto bravi in questo), non abbiamo ancora osservato tempi effettivi che si siano discostati di oltre il 15% - 30% dalle proiezioni iniziali quando le cose sono cambiate in corso d'opera.
Dopo che tutto è stato stabilito, ci mettiamo tutti al lavoro e una volta alla settimana ci incontriamo con il cliente per mostrargli ciò che è stato fatto durante lo sprint precedente e per pianificare quello successivo.
Cosa sta cambiando.
Da quando abbiamo scelto il nostro modo personale di aiutare i clienti con lo User Story Mapping e gli Sprint iterativi, siamo riusciti a raggiungere alcuni obiettivi che ci hanno dimostrato che stiamo lavorando nella giusta direzione.
Concentrati sulla costruzione del prodotto giusto
Introducendo revisioni periodiche dello sprint sia con i membri del team che con il cliente, abbiamo assistito a un cambiamento radicale nella percezione del lavoro nel suo complesso. Abbiamo iniziato a parlare tutti come un team di persone che lavorano per un obiettivo comune, invece di inseguire la volontà di un cliente sconosciuto. Solo parlando direttamente con i designer e gli sviluppatori coinvolti nel progetto, valutando insieme fili e opportunità, è stato possibile fare un vero lavoro di squadra con i clienti.
Non ci sono più scaricabarile su specifiche o tempistiche: da quando abbiamo condiviso la visione di costruire insieme qualcosa che “funzionasse efficacemente”, abbiamo smesso di discutere con i clienti su cosa costruire e se le cose fossero o meno incluse in un contratto a prezzo fisso. Anche la tempistica è diventata una responsabilità condivisa, e ora viene trasmessa una pressione “positiva” per costruire piani migliori con le risorse disponibili, senza colpevolizzare nessuno.
Alla fine questo porta a team più felici, a un prodotto migliore e, si spera, a utenti più felici.
I membri del team possono percepire che l'azienda ha un rapporto di fiducia con il cliente: possono parlare liberamente durante le riunioni, sono nella posizione di esprimersi come professionisti al meglio e di fare ciò che è necessario per portare a termine le cose.
