Per ogni azienda, vendere online significa chiedersi continuamente come migliorare i processi di acquisto, come semplificarli e snellire tutti i passaggi fondamentali per presentare al cliente un percorso più chiaro e lineare possibile. Un flusso che nel caso delle nostre ADSL e FIBRA prevede anche il passaggio di sottoscrizione del contratto di fornitura.
Negli anni ci siamo chiesti più volte come migliorare questo processo e quest’anno lo abbiamo fatto riprogettando dalle basi il “carrello”, parola che nel commercio elettronico indica tutta la fase di acquisto di un prodotto. In questo post condivideremo l’approccio a un lavoro complesso come quello di ridefinizione del carrello di acquisto delle linee ADSL e FIBRA, da due punti di vista: quello commerciale e legato all’esperienza dell’utente, e quello metodologico che per il nostro team di sviluppo ha significato adottare nuovi metodi di lavoro e in particolare Scrum, un sistema nato per governare in modo efficace e creativo lo sviluppo e il rilascio di un prodotto.
Perché rifare tutto il carrello di acquisto
Presenteremo nel dettaglio il nuovo carrello di acquisto delle linee ADSL e FIBRA in un prossimo post, per il momento vogliamo sottolineare alcune delle esigenze fondamentali che ci hanno spinti a riprogettarlo.
Ehiweb negli anni ha aggiunto alle connessioni ADSL un’offerta più articolata che ha integrato la FIBRA FTTC e la FTTH, anche Open Fiber. Quando si cresce bisogna ripensare l’esperienza di un potenziale cliente sul nostro sito, è necessario rivedere l’usabilità del percorso di acquisto, progettando ogni passo per poi svilupparlo sia nella parte di back end, sia di front end.
Oltre al nostro team di sviluppo interno per la parte di back end, con il coinvolgimento diretto di Matteo Sgalaberni, il nostro Direttore Tecnico, e degli sviluppatori Stefano Dalbagno ed Emiliano Grilli, per studiare e riprogettare questo percorso abbiamo coinvolto anche consulenti esterni come Commonground, azienda che si occupa proprio di disegnare e definire l’esperienza delle persone quando interagiscono con un sito o qualsiasi ambiente digitale, Tatiana Schirinzi e Simone Montanari per la SEO e il design dell’interfaccia.
Meno burocrazia, acquisti più semplici e più veloci
Al centro del processo di acquisto di una ADSL o FIBRA c’è la sottoscrizione del contratto: desideravamo eliminare la parte cartacea di questo processo – stampa, firma e restituzione del contratto – per renderla completamente digitale. Ci siamo riusciti dal punto di vista tecnico e legale, con la consulenza degli Avvocati Massimiliano Nicotra e Giulio Brunelli, anche grazie all’uso degli SMS come mezzo per certificare la volontà del cliente di acquistare il nostro prodotto sottoscrivendo l’accordo e aderendo alla nostra offerta.
Eliminare la parte offline, cioè la carta, rende la procedura di acquisto più veloce perché il contratto viene sottoscritto durante l’acquisto e di conseguenza migliorano i tempi di attivazione delle linee.
Il contratto digitalizzato libera il tempo necessario per verificare la ricezione dei documenti firmati, il tempo risparmiato diventa diventa utilizzabile per altre attività al servizio dei nostri clienti.
Il metodo di lavoro del team di sviluppo
Abbiamo chiesto al nostro direttore tecnico Matteo Sgalaberni di raccontarci l’esperienza di sviluppo del carrello dal punto di vista del metodo utilizzato: lo sviluppo del nuovo carrello è iniziato a gennaio, proprio prima del lockdown, e il nuovo approccio – inteso anche come nuova modalità di collaborazione tra le persone del team – ha avuto effetti positivi anche durante un periodo nel quale non è stato possibile vedersi di persona, dimostrando ancora di più la sua efficacia.
Matteo, come avete deciso di cambiare modello di sviluppo di un progetto come quello del carrello di acquisto?
Nel 2019 abbiamo seguito una serie di eventi formativi organizzati da Coders51, azienda di Altedo che progetta e sviluppa applicazioni: li avevo già incontrati ed ero curioso di capire meglio il loro metodo, per portare nella nostra azienda un metodo diverso per incrementare la qualità del lavoro e dei prodotti che sviluppiamo.
Visto che eravamo all’inizio del “progetto carrello”, ho chiesto a Gianluca Padovani di Coders51 di passare qualche giorno con noi per analizzare e organizzare il progetto. Durante l’analisi abbiamo iniziato a familiarizzare con Scrum, il framework per gestire lo sviluppo di prodotti complessi che loro utilizzano in azienda: in quel momento, quindi, non c’è stata una vera e propria fase teorica di apprendimento di Scrum ma un vero “imparare facendo” che ci ha permesso di imparare e introdurre subito Scrum per organizzare i lavori, decidere quali passi fare e in che sequenza, come calendarizzare le attività, controllare e garantire un rilascio continuo di risultati, fase dopo fase.
È stato un momento molto interessante per tutti anche dal punto di vista organizzativo: abbiamo messo in discussione le nostre abitudini e le nostre giornate lavorative adottando un metodo e un ritmo di lavoro per noi nuovo. Cambiare metodo di lavoro in alcuni momenti è stato destabilizzante, ma il risvolto positivo è che i miglioramenti e l’effetto generale dei cambiamenti introdotti sono arrivati dopo pochissimo tempo e ci hanno motivati a continuare sulla strada scelta.
Come vi siete organizzati per cambiare metodo di lavoro e adottare Scrum come framework?
La prima cosa che abbiamo fatto è stata definire e ridefinire i ruoli e abbandonare la figura del project manager, perché in questo approccio tutti partecipano a definire il flusso di lavoro e le attività da fare.
Seguendo il metodo Scrum, abbiamo affidato a Gilberto Di Maccio, il nostro Direttore Commerciale, il ruolo di Product Owner, il responsabile del processo che esprime le esigenze di business dalle quali derivano tutte le operazioni di sviluppo che porteranno al risultato finale.
Le richieste espresse dal Product Owner sono riportare nel Product Backlog, che le contiene come elementi, ne stabilisce le priorità e la definizione – in alto gli elementi prioritari e definiti nei dettagli, a scendere gli altri – e deve rispondere a criteri rigorosi di visibilità, trasparenza e chiarezza per tutte le persone del gruppo di lavoro.
L’altra parte del team – io, Stefano ed Emiliano – deve organizzarsi e decidere come realizzare e soddisfare le richieste del Product Owner e in che tempi farlo, in un processo di confronto continuo e sempre condiviso con tutti, perché tutti abbiano sempre una visione completa del progetto e non si creino colli di bottiglia. Cosa ancora più importante: tutto il team è responsabile del progetto di sviluppo, nessuno escluso e ognuno con le competenze che porta con sé.
In questo progetto io ho assunto il ruolo di Scrum Master dopo essermi certificato: lo Scrum Master è la persona che si incarica di promuovere e far conoscere Scrum all’interno del team e in teoria non è parte attiva del gruppo di lavoro – nel nostro caso, non è uno sviluppatore – anche se io sono stato coinvolto su entrambi i fronti: è stata un esperimento interessante che mi ha dato la possibilità di intervenire solo quando davvero necessario, lasciando agli sviluppatori autonomia, responsabilità e la gestione delle criticità emerse lungo il percorso, così come prevede Scrum che non assegna ruoli all’interno del team.
Il framework di Scrum indica anche come e in che tempi suddividere gli eventi, detti Sprint: tutti gli appuntamenti e riunioni hanno obiettivi, una durata definita (time-boxed) e devono portare a risultati precisi: nel nostro caso li organizzavamo ogni settimana o due, ciclicamente.
Gli Sprint sono sostanzialmente dei contenitori di altri eventi ben definiti (Sprint Planning, Daily Scrum, sviluppo, Sprint Review e Sprint Retrospective): non li spiegherò nei dettagli ma racconterò cosa è avvenuto da noi:
- ogni Sprint corrisponde a un meeting nel quale c’è un momento Demo dedicato alla verifica o dimostrazione di quanto realizzato nello sprint precedente. È un momento al quale partecipano tutti, anche il Product Owner. La partecipazione di tutto il team a tutti gli eventi è un elemento chiave perché permette di condividere le informazioni fondamentali nei momenti giusti: tutti sanno cosa dicono e cosa hanno fatto gli altri, tutti possono intervenire e fare domande.
- la Retrospettiva è il momento in cui tutto il team può fare considerazioni su quanto fatto nello Sprint precedente, indicando quello che ha funzionato e ci ha dato soddisfazione, le criticità e le opportunità per trovare soluzioni ai problemi condivisi. Durante la Retrospettiva si misurano anche le performance dello Sprint precedente, si assegnano punteggi alle attività svolte, si raggruppano gli elementi critici per argomento e in base ai punteggi assegnati il team sceglie tre attività a cui lavorare per individuare una soluzione: la risposta deve essere applicata entro lo sprint successivo.
- lo Sprint Planning è il momento in cui il team decide cosa farà nello Sprint successivo, scegliendo le attività dal Product Backlog che alimenta i vari Sprint. Detto in altre parole: l’attività che entra in Sprint è l’obiettivo da realizzare nella settimana o nelle due settimane previste, prima dello Sprint successivo. Lo Sprint Planning serve anche per lavorare sul Product Backlog stesso, organizzando i task per priorità e definizione: è un processo iterativo ed empirico utile a migliorare, incrementare e, se necessario, modificare le attività da eseguire.
Seguendo questo approccio, si conosce la data del rilascio del prodotto sviluppato?
In pratica il rilascio avviene continuamente, ed è uno dei grandi cambiamenti portati da Scrum. Abbandoniamo l’idea di un progetto con una data di inizio, uno sviluppo e quindi un momento finale in cui si vede il progetto giunto a sviluppo completo o quasi: usando questo framework, i tempi di rilascio vengono definiti dai contenuti del Product Backlog e, soprattutto, il rilascio è continuo.
L’obiettivo di ogni storia, di ogni elemento contenuto in uno Sprint deve essere non solo visibile a tutti, ma il risultato deve essere dimostrabile e utilizzabile, rilasciando nell’ambiente di test continuamente quanto fatto fino a quel momento. Rilasciare e testare continuamente ci rende ancora più sicuri che alla fine tutto funzionerà come previsto, minimizzando il rischio che il prodotto finale non funzioni esattamente come desideravamo. Posso affermare senza dubbio che vedere e testare il prodotto lungo il suo sviluppo è davvero un elemento rivoluzionario.
Aggiungo anche che oltre ai test eseguiti dalle persone – non solo dal team di sviluppo ma anche dal Product Owner e altre persone – abbiamo usato anche il modello di sviluppo TDD (Test-Driven Development), con test automatici che ogni volta hanno ritestato quanto sviluppato e ci hanno assicurato che tutto funzionasse anche in caso di modifiche apportate in corso d’opera.
Se dovessi elencare i risultati di questo nuovo metodo, cosa racconteresti?
Un risultato importante è stato un cambio di passo nell’approccio al lavoro, cambio che si è espresso nell’aumento della condivisione delle responsabilità e della conoscenza, evitando di assegnare piccoli task individuali e isolati: questi incontri collegiali – circa quattro ore ogni settimana – ci hanno dato la possibilità di condividere le informazioni sul progetto e capirne i dettagli a un livello di dettaglio elevatissimo e, come già detto, noto a tutti, aumentando la produttività di ogni elemento del team che è chiamato a mettersi in gioco continuamente. Adottando Scrum come framework abbiamo eliminato le riunioni uno a uno che semplicemente non si sono rese più necessarie perché tutto era già condiviso con tutti: un bel risparmio di tempo e di energie.
Inoltre, essendo partiti proprio prima del lockdown, abbiamo superato più velocemente l’abitudine a usare sala riunioni, lavagna e post-it per relazionarci solo a distanza, modalità che ha funzionato egregiamente.
La piena visibilità sul progetto ci ha permesso di sapere sempre a quale punto di sviluppo eravamo arrivati: è un punto fondamentale perché, nel caso di Ehiweb, abbiamo dovuto lavorare su tanti aspetti o dipendenze che probabilmente, seguendo un altro metodo di lavoro, avrebbero rallentato o ostacolato lo sviluppo del carrello.
Infine, lavorando a distanza abbiamo utilizzato anche strumenti agili per tenere traccia del nostro progetto tra cui Asana, con una board di sviluppo con i backlog (le attività da fare) le attività in Sprint (attività da fare nel corso della settimana), attività in corso e finite, da dimostrare e far vedere in Demo.
Abbiamo usato anche Miro, una lavagna digitale collaborativa molto flessibile e adattabile alle esigenze del momento e di ogni team, per condividere informazioni e raccogliere i dati delle Retrospettive.
Abbiamo scelto la tecnica retrospettiva Mad, Sad, Glad (Arrabbiato, Triste, Felice) per evidenziare tutto quello che nel progetto è stato un elemento critico oppure positivo: abbiamo raccolto e raggruppato tutti questi elementi e procedendo nel lavoro li abbiamo esaminati stabilendo priorità e necessità e condividendo idee per risolvere le criticità.
Abbiamo anche un’area appunti nella quale abbiamo raccolto tanti tipi di informazioni emerse nel corso del progetto.
Ci dici qualcosa sulle tecnologie che avete usato per realizzare il carrello?
Abbiamo introdotto React, la libreria JavaScript per costruire la parte di front end, abbiamo portato online alcune parti di Ehiweb su Nomad per l’orchestrazione dei container e usato GitLab per tutta la parte di Continuous Integration. Il processo di sviluppo del carrello è sempre stato integrato con tutti gli ambienti di sviluppo e produzione, con processi automatici che hanno reso visibili le attività degli sviluppatori in più ambienti quali test, stage, sviluppo e produzione.
Il progetto di front end curato da Tatiana Schirinzi e Simone Montanari ha prodotto un layout in HTML funzionante che abbiamo integrato nel software.
Ultima domanda: il carrello è pronto? Si può usare?
Siamo pronti a presentare il carrello a tutti e lo faremo sul minisito ADSL-FIBRA per poi portarlo anche su Ehiweb.it: come sempre ci sarà un post di questo blog ad annunciare e spiegare nei dettagli la novità.
