INNOVATIABLE

"Le banche mondiali tradizionali non sono altro che dinosauri in via distinzione" disse Bill Gates
e come non credergli dopo aver visto quello che è successo nel 2015 quando da un palco Ted annunciava, in qualche modo, una pandemia globale. Oggi siamo qua appunto per parlare di Fintech:
questo termine, questa crasi tra la parola Finanza e Tecnologia che indica appunto quel settore dell'industria finanziaria che usa le tecnologie digitali per poter offrire i propri servizi.
Oggi cercheremo di capire come, ad esempio, il dato possa essere qualcosa di davvero importante
per andare a creare valore all'interno di questo settore.

Io sono Lorenzo Beliusse, direttore marketing di Reti S.p.A e vi do il benvenuto a INNOVATIABLE, il podcast di Reti che parla di temi di tecnologia, sicuramente, e di sostenibilità.
Oggi per il tema che andremo ad affrontare c'è qui con me Marco Santoni, Head of Data di Flowe.
Ciao Marco!
Ciao Lorenzo e buongiorno a tutti gli ascoltatori.
Bene, e cosa fa Flowe? Partirei subito da questa domanda e perché non dovrebbe fare la fine del dinosauro?
Allora, Flowe è una spin off di Banca Mediolanum è un'app mobile, quindi Android e iOS, e offre ai propri utenti un conto di pagamento con i servizi più tradizionali di un conto come bonifici, carte di pagamento, bollettini ma in più anche una componente innovativa quindi ha funzionalità più smart con cui puoi, per esempio, condividere le spese con amici se fai un viaggio, puoi fare delle collette per dei regali e, oltre a questo, siamo anche una società Benefit e B Corp quindi vogliamo avere un impatto positivo non solo a livello aziendale ma anche su chi ci sta intorno e in app questo si manifesta con due obiettivi principali: il primo è quello dell'educazione finanziaria, quindi vogliamo educare i nostri utenti al risparmio consapevole e in app gli utenti, per esempio, possono aprire di salvadanai digitali che chiamiamo dei Drop di Risparmio accantonando piccole cifre con delle regole automatiche;
la seconda, quella che un po' più mi sta a cuore, è quella che chiamiamo Echo Balance che è una funzionalità in ambito sostenibilità.
Noi, insieme ad altri partner, stimiamo qual è il footprint quindi qual è la tua impronta di CO2 sulla base delle tue transazioni sulle tue abitudini di spesa e sulla base di questa stima, tu puoi come utente compensare e azzerare il tuo Foot, quindi CO2, attivando questo servizio in cui noi piantiamo tanti alberi quanto sono necessarie ad azzerare il tuo Foot, quindi CO2; e abbiamo anche fatto un paio di mesi fa una campagna che avevamo chiamato "T-rex" per raccontare perché non fare la fine dei dinosauri e passare a Flowe per passare una app un po' moderna, ecco.
Ok quindi l'intro diciamo che ti è piaciuto.
Sì!
Pensando un po' a un target, andando a segmentare la clientela, quindi diciamo che anche per i servizi che offrite, per le modalità, per quello che raccontato ma forse non vi rivolgete proprio ai boomer?
Abbiamo sicuramente il target principale di cui siamo partiti è quello dei giovani studenti o prima esperienza lavorativa quindi quella è un po' una grossa fetta del nostro il nostro target.
- Il vostro target principale. -
Però abbiamo visto, anche guardando i dati che possiamo vedere, abbiamo un po' una sorta di curva bimodale tra virgolette abbiamo anche un picco su di utenti 50-60 anni che forse sono i genitori di queste persone e quindi si è creato un po' una doppia popolazione di utenti ecco.
Bene quindi siamo arrivati a sensibilizzarli sui temi di sostenibilità grazie, magari, anche ai figli e sicuramente grazie a voi.
Ecco parliamo del tema di di oggi: i dati per generare il valore nel Fintech e in generale in questo settore. Cosa vuol dire? Come si fa?
Allora noi ci siamo, in questi due-tre anni, posti un po' questa domanda che "come genera valore?" e soprattutto "Chi è il destinatario di questo valore?"
Per semplificare noi abbiamo identificato due destinatari principali: uno interno, quindi i nostri stakeholder interni che possono essere i team per esempio di Flowe; team di marketing, team di user experience o il team di caring quindi dare al loro un valore tramite degli insight per poter prendere decisioni consapevoli; il secondo destinatario principale sono i nostri utenti, quindi poter offrire un'esperienza in app più personalizzata efficace per l'utente perché non vogliamo un'app che parli allo
stesso modo con un utente che che appena entrato, un utente di cui sappiamo di più e quindi vogliamo offrirgli un servizio più utile per lui.
Quindi questi due sono poi i nostri destinatari principali, per esempio, con i nostri colleghi di marketing proviamo a dare valore rispetto a tante domande che ci fanno, per esempio ci chiedono: qual è l'utente tipico Flowe? ma soprattutto quelli più attivi, come sono arrivati? Sono arrivati tramite un campagna
organica oppure sono arrivate tramite alcune campagne specifiche e quindi sappiamo che lì possiamo portare a casa un lifetime value più significativo?". Oppure ci possono chiedere: "ma se degli utenti abbandonano l'utilizzo dell'app, perché l'hanno fatto? ci possono essere stati dei problemi?" e quindi il primo destinatario del valore sono rispondere in modo puntuale a delle domande che arrivano dai colleghi.
Per gli utenti invece possiamo voler dire Guarda, non voglio farti una comunicazione generica ma voglio darti una comunicazione sia più puntuale, che ti arrivi a dire quello che ti serve nel momento in cui ti serve.
Chiaro. Quindi lato Marketing diciamo che i tuoi colleghi avevano bisogno di capire come indirizzare al meglio i fondi, le iniziative, dove andare a spingere e magari per fare però e per prendere alcune scelte appunto, ancora una volta, devono essere scelte data-driven, come si dice.
Cioè, fammi capire, al di là del percepito che io posso avere dell'idea che possa avere, Marco aiuti a capire: dov'è la verità? e quindi qui entra il gioco il dato.
Esatto ti posso fare se vuoi un esempio, una storia che abbiamo su cui abbiamo lavorato tanto.
Diciamo che un esempio è quello che noi chiamiamo "Onboarding", cioè far salire a bordo di Flowe un utente nuovo, che non è un onboarding di un app più semplice in cui devi mettere nome, cognome e email, mastai aprendo un conto di pagamento quindi ci sono delle degli obblighi contrattuali
normativi di identificazione dell'utente, di firma del contratto, di dichiarazione di
stati patrimoniali, antiriciclaggio.
Quindi comunque è un onboarding in più complesso e quindi chiaramente quando siamo partiti come succede in tanti processi di acquisto anche in e-commerce più tradizionali, tu hai un tot di utenti che iniziano un processo poi c'è un funnel che si stringe per gli utenti che interrompe quindi abbandonano il
processo a metà.
E quindi noi abbiamo iniziato banalmente misurando dei 100 che iniziano quanti sono quelli che arrivano al termine. E quando vedi che quel numero non è quello che hai in mente, che ovviamente vuoi sempre che siano 700, allora inizia a fare delle ipotesi, allora inizia ad essere magari un utente non ha capito bene un certo step, oppure abbiamo dei problemi tecnici per esempio sul face recognition,
sul document recognition oppure il processo di firma digitale ogni tanto può dare de KO.
Il problema è che quando hai tante ipotesi devi per forza focalizzarti su qualcosa per dare una priorità ai tuoi interventi e lì come fai a focalizzarti? O vai sull'istinto che a volte può indovinare a volte no, oppure usi dati per misurare dove sta il problema principale.
Quindi all'interno proprio del Buyer Journey, quando sono all'interno di quel funnel dove ci sono diversi momenti in cui l'utente sta interagendo, lì voi riuscite a tracciare il fatto che "Ok ha abbandonato esattamente in questo step del processo" oppure "Qui è arrivato fino a questo punto, abbiamo visto
che ha fatto qualcos'altro, e poi è tornato avanti" e quindi un conto analizzare il comportamento
di un utente o di un campione e invece un conto avere l'intera mole di dati di quello che è successo e a quel punto come insegna il buon Pareto sempre col 20-80% possiamo magari dire che l'80% del problema arriva da quel 20% di cause.
E quindi voi aiutate appunto a identificare qual è l'aspetto più importante su cui focalizzarsi e magari poi andare a trovare delle soluzioni, che magari al primo tentativo possono non essere quelle giuste, ma si è sulla strada buona.
Sì qui raccontarle è facile no? cioè tu ti immagini - soprattutto a posteriori - A posteriori sì!
In realtà poi quando siamo partiti è stato complesso perché tu hai tanti dati che arrivano da diverse sorgenti: quindi hai la telemetria dell'app che come si dice i Tap che fa l'utente, ai dati suoi anagrafici e hai diverse informazioni e anche nell'analisi dati devi focalizzarti su qualcosa.
Quindi noi all'inizio siamo partiti un approccio che era proviamo a fare delle statistiche macro e i nostri colleghi ci chiedevano di sviluppare per esempio un report per monitorare quanti utenti arrivavano in quale fase e dove si fermava principalmente.
Quindi siamo andati un approccio un po' più tradizionale quindi ci sono arrivati dei requisiti, al team data di cui faccio parte, e abbiamo provato a raccogliere i requisiti a sviluppare la parte data processing e la reportistica.
Fatto questo però vedevamo che poi comunque quel report, perché noi monitoriamo anche i dati di utilizzo dei nostri report, aveva dei momenti di utilizzo però non aveva tutto quell'utilizzo che ci aspettavamo e ci siamo chiesti "ma perché?".
Parlando con i nostri colleghi abbiamo scoperto che non è facile capire a fondo un fenomeno semplicemente analizzando dei dati su dei requisiti che ti ho dato prima, a posteriore, no? perché spesso ti trovi di fronte un grafico che ti fa sorgere altre due domande e allora vuoi andare più nel dettaglio, per esempio: vedo che questa è la pagina, per esempio, di identificazione - face recognition - devo riconoscere che effettivamente quell'utente la persona che il documento dichiara
e se io, per esempio, lì una caduta di abbandono degli utenti però lì io voglio a quel punto quando un
indizio voglio saperne di più: ho avuto de KO delle SDK che usa la mia app? Ho problemi più legati magari a certi tipi di utenti che usano certi tipi di documento? E quindi avere solo un report statico spesso non riesce a dare tutte le domande che il business può avere. E quindi poi abbiamo cercato di cambiare un po' approccio ci siamo detti "Forse non dobbiamo più andare con un approccio di: ti do requisiti mi sviluppi" - più tradizionale diciamo, un classico waterfall -Esatto; abbiamo detto, proviamo a darci un obiettivo che è quello di far aumentare quel KPI di percentuali di conversione degli utenti e non ragiona in ottica di requisiti ma mettiamo i membri dei vari team a un tavolo quindi abbiamo preso i dev di app quindi conoscono bene la parte tecnologica, il team user experience che quindi è quello che progetta e si deve fare in modo che gli utenti capiscono le facciamo e anche colleghi del Caring che quindi loro raccolgono le segnalazioni di utenti quindi hanno anche un altro orecchio su quello che gli utenti dicono e chiaramente il team Data con i data engineer e data scientist. E quindi avevo detto piuttosto che lavorare sui requisiti andiamo in modo iterativo e quindi con sprint due settimane, diamoci un obiettivo e scopriamo qualcosa, anche in modo più artigianale facendo analisi offline, però intanto scopriamo qualcosa e cerchiamo di renderlo subito actionable. E quindi in questo modo siamo riusciti a dare molto più valore, perché in pochi sprint abbiamo identificato quali sono le cadute principali che ce n'erano diverse magari un'area era più critica di un'altra, però poi abbiamo identificato su quali erano i punti di caduta, qual erano le azioni più efficaci e poi da mettere a termine; quindi, per esempio, possiamo cambiare alcuni wording per spiegare all'utente in modo più chiaro alcune frasi che poi abbiamo scoperto dei dati essere complesse, che a noi sembrano chiare magari per gli utenti non era così, oppure se degli utenti si fermavano in una fase altrettanto complessa allora perché non fare una campagna di "carrello abbandonato", di provare a spingere l'utente a completare quello step che sappiamo essere complesso, e quindi abbiamo messo in piedi una marketing automation che ci ha dato risultati interessanti abbiamo aumentato un po' i nostri KPI anche 5 punti percentuali rispetto all'as is.
Quindi io che sono registrato, che ho avviato quindi il processo, tu mi conosci, c'è già stata una prima conversione, abbandonato il processo a metà vengo poi sollecitato in un secondo momento attraverso una serie di comunicazioni di email immagino, di semessi.
Sì esattamente! E il bello è che quando metti insieme le persone di diversi team nascono fuori molte idee quindi per esempio il team di marketing automation ti può dire riguarda perché non facciamo anche degli esperimenti per capire qual è la comunicazione più efficace?
Perchè è importante, esatto, il copy, i classici a/b test che siamo abituati a fare magari nelle campagne anche sui Social per capire quale messaggio funziona meglio, lo fa anche Netflix quando propone la copertina del film capisce che non converte si vi da diversi minuti a guardare non selezioni un
film, quindi sono logiche oggi che vengono applicate addirittura con l'artificial intelligence e credo che sì il problema sia un po' di tutti quando si è all'acquisto che noi siamo pigri, non ci entro a fare cioè l'utente è pigro, -anche al primo ostacolo - al primo ostacolo quindi vogliamo le cose facili, quindi mettendo l'utente al centro che quello che avete fatto avete cercato di capire come aiutarlo per arrivare fino alla fine però poi ci siete riusciti oggi i dati sono molto più simpatici di come erano all'inizio si può dire.
Sì poi collaborando con gli altri team come dicevo escono fuori idee che prima non sarebbero venute, no? Per esempio, se vogliamo fare una comunicazione più puntuale per dare un messaggio all'utente che è proprio specifico del punto in cui lo è arrivato allora magari il dev, lo sviluppatore di app ti dice: "guarda, io posso darti anche un'informazione in più, posso dirti che l'errore che ha avuto per
esempio sul riconoscimento del documento di questo tipo e non di quest'altro".
Allora possiamo dire: "Ok ma allora faccio una comunicazione che magari suggerisce di provare un altro
documento o di posizionare con una luce diversa dallo scan del documento".
Quindi tutte queste idee non sarebbero potute uscire fuori semplicemente con un rapporto tra colleghi di "ti passo requisiti e mi fai", ma solo quando hai un tipo di collaborazione più focalizzato sull'interazione delle persone esce fuori questa idea.
Ma certo, direi che una delle cose che abbiamo subito molto in pandemia era questo, che fare anche queste cose da soli o solo in digitale insomma non era lo stesso e io credo fortementeche la creatività sia proprio un lavoro collegiale, quindi ognuno si mette un pezzo e come si dice la somma degli individui è molto di più della mera somma; quindi diventa un prodotto molto importante.
Bene quindi a livello di marketing è una delle strutture interne e poi cos'altro c'è stato? C'è qualche altra struttura particolare che avete supportato, struttura intesa come stakeholder?
Beh come dicevo quella di user experience è un team con cui lavoriamo molto. Loro sono quello che progettano l'app, le interfacce, i copy, i flussi di navigazione e quindi con loro spesso anche soprattutto dopo l'onboarding una volta che abbiamo degli utenti a bordo spesso vogliamo capire quali sono le sezioni che navigano di più oppure se per una sezione tu hai più entry point, ci può arrivare magari dalla home oppure da altri menu, aiutare a capire gli utenti come navigano cosa funziona cosa non funziona e oltre a queste attività di comprensione con loro abbiamo anche provato a pensare come possiamo personalizzare l'esperienza degli utenti In app.
Quindi una volta che un utente a bordo io magari vorrei che lui conosca l'app in un modo un po' più personalizzato perché non è detto che l'app debba dare le stesse informazioni a tutti gli utenti,
perché ognuno ha diversi abitudini di spesa e diversi comportamenti. Quindi, per esempio, noi abbiamo un paio di sezioni dell'app che sono "analisi spese" o il "budget" e lì con loro abbiamo fatto un po' di brainstorming per capire come possiamo dare degli int o dei suggerimenti agli utenti per dire: "Guarda le tue spese stanno andando come previsto", "stanno andando un po' fuori" e quindi lì abbiamo dovuto fare un lavoro di ingegnerizzazione di modelli che prevedono un pochettino i comportamenti futuri di spesa degli utenti in modo da guidarlo e assisterlo nel conoscere i propri abitudini di spesa.
Ecco questo penso sia anche una parte molto delicata perché è un attimo passare dalla parte opposta e infastidire invece l'utente no? quando magari ci possono essere troppi messaggi, troppe indicazioni, troppo push quindi mi sta invitando per forza a fare di più a spendere di più e è una cosa che magari mi dà fastidio.
Ma è interessante anche questo tema della predittività quindi dove poi dietro ci sono sempre i dati e poi sempre al tuo team si torna, alla fine. E su questo aspetto che cosa ci puoi raccontare sul tema di andare
appunto a predire? Come si fa? Allora diciamo che ormai sono temi che da tanti anni si sente parlare no? da data scientist e engineering ormai si è capito che la costruzione del modello predittivo è solo il primo passo e l'ingegnerizzazione di quel modello e quindi renderlo stabile nel tempo, operativo e affidabile
spesso è un lavoro che all'inizio viene sottovalutato e che ha una complessità che poi si scopre.
E quindi c'è un famoso paper di Google che è "the hidden technical debt of Machine Learning", cioè il debito tecnico nascosto nel Machine Learning che uno spesso fa un piccolo POC e quindi ha un modello che funziona in locale però da lì a industrializzarlo c'è spesso un qualcosa che si sottovaluta.
E quindi noi abbiamo cercato di ridurre un po' questo rischio andando in un approccio anche qui molto incrementale.
Io spesso faccio una battuta con i colleghi il nostro obiettivo è frenare la smania del data scientist di fare un modello troppo sofisticato no e spesso vengo anche preso in giro dai miei colleghi.
Ma l'idea è proprio se tu - di fatto quando costruisci un modello predittivo è una metrica che l'accuratezza che tu puoi migliorare e migliorare.
Arriva un certo punto in cui però prima di spender troppe settimane o mesi a spingere quella accuratezza elevata, a un certo punto è meglio fermarsi prima e dire "ok, come faccio anticipare un pochettino la generazione del valore?" E allora ti devi preoccupare; quello che abbiamo scoperto è che è opportuno cercare di anticipare tutta quella fase di ingegnerizzazione di rilascio, che spesso si sottovaluta, ma è meglio di provare ad anticiparla con un modello che è meno accurato però di iniziare a lavorare prima su come lo integro con la mia app, come lo industrializzo, e quindi se spesso partiamo con un MVP, quindi con un minimum viable product anche un modello più semplice però lavoriamo prima su l'industrializzazione è più facile che degli imprevisti ti sarebbero capitati te ne accorgi prima e quindi riesci prima a risolverli quando magari il modello è ancora semplice da gestire.
Immagino sia appunto un tema, un passaggio, molto delicato perché finché si tratta di uno sviluppo di un nuovo prodotto, di un nuovo mercato fatto da una startup va bene vediamo come va, quando devi integrarlo all'interno di una banca di fatto ovviamente, come dici tu, il tema che - il fatto che sia integrato
che non vada a provocare danni prima che provocare ulteriori benefici è un tema importantissimo.
E quindi sono d'accordo con te nel tenere a bada un po' l'entusiasmo di quando poi meno male ci sono ragazzi, persone, con l'entusiasmo per la tecnologia però a volte, appunto, va ma poi si appassionano anche all'altra fase!
Io quello che ho visto è che Perché vedono che sta per entrare in produzione!
Esatto, perché magari dico: "Ok avrei voluto lavorare di più sul fare un modello più sofisticato" però comunque poi il data scientist si trova a lavorare sull'operalizzazione quel modello comunque impara moltissimo e si entusiasma anche una parte più tecnologica-ingegneristica che ha gran valore anche per il data scientist.
Bene questo quindi grazie anche alle tue doti di leadership e saper indirizzare poi e motivare le persone.
Abbiamo parlato di stakeholder interni ok, quindi il team user experience, il marketing, poi immagino siano tutti sempre molto correlati perché poi il goal finale è sempre unico per l'azienda; ma a livello poi di invece di stakeholder esterni, lato utente, che tipo di attività andate a fare?
Prima dicevi che bisogna ridurre il rischio di inondare l'utente di comunicazioni quindi uno degli obiettivi nostri è proprio quello di ridurre quel rischio cercando di personalizzare il più possibile le comunicazioni che gli mandiamo.
Faccio un esempio; noi - Flowe due tipi di principali di utilizzo: ci sono utenti che lo usano come primo conto, quindi usano principalmente Flowe, e altri che lo usano più come conto di pagamento secondario per le spese quotidiane ma magari non ci versano ancora lo stipendio su Flowe e quindi spesso queste persone abbiamo visto che sono persone molto attive che però a volte non se ne accorgono che hanno esaurito il saldo e quindi devono ricaricare, però se magari sono già al supermercato a pagare hanno un ko, no? perché non c'è il saldo. E quindi abbiamo detto ok, scoperto questo fenomeno come facciamo a aiutare gli utenti a scoprire prima che stanno per rimanere scoperti e quindi a ricaricare prima il conto? E quindi abbiamo lavorato con i team di user experience, ancora, e marketing per aiutare l'utente finale a accorgersi prima di ricaricare il conto personalizzando sulle base delle abitudini spesa di ogni utente quando è secondo me il momento giusto per ricaricare, l'ultimo momento utile per ricaricare prima di rischiare di rimanere scoperto. Perché tu chiaramente non vuoi dire un utente che di solito un saldo
per esempio di 2.000 euro "ricarica!", così effettivamente non è necessaria in quel momento e non vuoi mandare comunicazioni superflue; però vuoi mandarle magari quando lui di solito un saldo di un certo tipo, sta arrivando un periodo di spesa che sappiamo essere frequente in un certo periodo - per quell'utente - Esattamente per quell'utente e quindi un collegamento prima che la soglia critica raggiunta vogliamo suggerirgli "Guarda non è che vorresti fare una ricarica?". E questo è di nuovo un lavoro corale perché c'è una fase di modellazione dei dati e delle abitudini spesa importante e poi c'è una fase ingegneristica di "Ok come faccio quindi a fare un motore che notifichi l'utente?" e questo è un esperimento che abbiamo fatto proprio recentemente negli ultimi mesi e ci ha dato veramente risultati importanti perché di fatto era un bisogno che gli utenti avevano cioè abbiamo sviluppato una comunicazione che non è una comunicazione di marketing commerciale, almeno può sembrare commerciale ma di fatto per gli utenti era molto utile, e quindi abbiamo visto che i rate di apertura di quelle notifiche e di quelle mail era molto più alti del solito e gli utenti che ricevano quelle comunicazioni, facendo un a/b test, abbiamo visto che avevano dei tassi di ricarica del conto molto superiori rispetto a chi non riceveva quelle comunicazioni.
Quindi questo è un esempio in cui portiamo del valore all'utente finale dandogli un servizio utile che è utile per lui e utile anche per Flowe chiaramente, poi utenti più attivi che è nato da un'analisi da una modellazione dei dati.
Questo è un bellissimo esempio appunto di win-win da una parte e dall'altra.
Per l'utente direi che è assolutamente una cosa utile, rispondeva a un suo bisogno.
Marco, per chi volesse intraprendere questo viaggio, il viaggio dove è possibile - ogni aziendale all'interno ha tantissimi appunto dati e si parla come hai detto tu da tempo di Big Data, data scientist, data engineering è un tema noto e stra noto.
Ma per chi vuole approcciare o per chi sta iniziando a attivarsi. Ecco quali sono in generale delle Lesson Learned che tu ritieni più utile condividere?
Ti diresti "Ok le cose belle che ho fatto, che abbiamo fatto, e quelle che non sono andate molto bene e che se posso proprio suggerirti, ecco, ti suggerisco di non fare così e di fare invece in quest'altro modo".
Allora, sicuramente costruire un team con giusto mix di competenze è importante per fortuna diciamo molti strumenti cloud che noi usiamo abbassano molto l'ostacolo tecnologico che magari anni fa c'era perché molte tecnologie cloud semplificano molto alcuni workflow di data processing e data analysis,
quindi dedicare a inizio un po' di studio a quali sono i tool che ci possono aiutare può ridurre un po' un debito tecnico che altrimenti accumuleresti e una volta avuto il giusto mix di competenze sicuramente
il consiglio principale che abbiamo imparato è quello di andare in modo iterativo, partendo con cose molto semplici, perché spesso c'è il rischio di concentrarci su un qualcosa e costruire un qualcosa di troppo complesso magari quella cosa troppo complessa ci mette molto più del previsto rispetto a quello che avevamo in mente e poi il mercato e le necessità dell'azienda cambiano molto velocemente, quindi
tu vuoi andare per piccoli step e provare a generare subito del valore, e quindi quello che che abbiamo visto noi è importante avere interazione molto frequenti con i nostri stakeholder quindi avere delle collaborazioni frequenti - feedback anche molto più frequente rispetto a feedback finale ma "come stiamo procedendo?" , "Stiamo andando a una direzione giusta?", quindi un approccio assolutamente Agile. -
Esatto, per ridurre anche la pianificazione.
Non facciamo pianificazioni che vanno oltre i prossimi 3-4 mesi perché abbiamo visto che comunque sia il mercato sia di noi aziendali sono molto veloci quindi fare piani di 12, 18 mesi è un po' - Cioè siamo
accorti in questi ultimi due anni. Praticamente impossibile predire cosa accadrà in questo 2023, incrociamo le dita.
Quindi sì, andare per piccoli step, avere feedback molto frequenti, cercare di fare sempre mvp quindi andare per piccoli prodotti che generano valore a stretto giro quindi ritardare la complessità quanto più possibile.
Ok e qualcos'altro legato invece le cose che avete fatto magari bene sin dall'inizio e che vi aspettavate - non vi aspettavate magari che eravate partiti col piede giusto? Mi chiedo anche le modalità di lavoro per esempio oggi è un tema importantissimo. Quando prima parlavi di onboarding, per esempio, la prima cosa che mi è venuta in mente ma perché ho alcuni buyers legati alla mia esperienza è l'onbording
di nuove persone che fanno parte del team quindi di assunzione di nuovi talenti all'interno della propria squadra e quindi le difficoltà anche nel punto dar vita progetti nuovi, c'è sempre un momento di necessità di allineamento tra stakeholder interni, dare la stessa visione, essere tutti comitati per arrivare lì, far capire che c'è una certa politica anche prima quando parlavi di quei feedback veloci penso comunque ai meccanismi di qualità della Toyota in generale, il fatto che ognuno porti proprio piccolo contributo ma sempre perché è chiara la visione e tutto questo oggi come come si fa? E come lo fa anche una banca che non è una banca dinosauro, abbiamo capito? Ah guarda, noi quando siamo partiti non avevamo un, non avevamo un metodo così efficace come in due anni però quello che ci ha aiutato molto è stato, sai, lavorare Agile non significa lavorare in modo destrutturato come magari
alcuni pensano, in realtà al contrario.
Noi abbiamo lavoriamo con un framework che si chiama scrum che è una metodologia che bene o male ti dà delle routine, delle cerimonie molto strutturate attrezzature pure essendo Agile.
E cosa fa questo? Ti dà sostanzialmente un ciclo di lavoro di due settimane in cui ogni due settimane tu ti dai degli obiettivi e provi a girare del valore in cui due settimane e alla fine del due settimane soprattutto è un momento che si chiama retrospective in cui tutto il team si guarda indietro e si dice "come siamo andati?", "come potevo migliorare?" e anche questo processo si fa in modo strutturato
con delle card, si vota, si prioritizza gli spunti di miglioramento. E quindi noi in due anni o tre anni abbiamo sempre provato a migliorare il nostro modo di lavorare sia interno al team sia con gli stakeholder, e quindi abbiamo detto abbiamo, per esempio, messo in discussione come prioritizzavamo le cose prima andavamo con un metodo adesso abbiamo un priority poker strutturato oppure come quanto automatizziamo i nostri rilasci del nostro codice e tutto questo è stato possibile non con una pianificazione ex ante su carta ma con un processo che ogni due settimane ti porta un miglioramento incrementale continuo e in cui soprattutto si raccolgono gli spunti di tutti i membri del team.
Quindi ognuno del team è spinto a by design perché c'è un processo che che spinge a fare dei suggerimenti in modo costruttivo e quindi piano piano si raffina un po' tutti gli aspetti della collaborazione interna sia di team, per esempio si può dire "Guarda io in queste due settimane ho speso molto tempo su questa attività troppo manuale" - Ok se anche gli altri vedono quel problema allora ci lavoriamo e l'automatizziamo; oppure magari "Con questi stakeholder abbiamo fatto un lavoro e però poi ha dato poco valore e quindi mi sembra di aver sprecato un po' del tempo" - Ok allora come facciamo a ridurre...E qui tanti dei suggerimenti condiviso prima sono di fatto emersi dal team grazie a questo framework.
Bene quindi direi possiamo estendere questa questo Leasson Learned allora in generale nell'avere comunque a prescindere poi dall'attività che magari si va a svolgere, ma avere una metodologia che crea indubbiamente anche engagement da parte poi di chi collabora e chi lavora insieme quindi mi sembra una bellissima Leasson Learned che possiamo condividere.
Marco grazie per questa bellissima chiacchierata
Grazie a te Lorenzo!
e invitiamo per tutti gli approfondimenti e andare su reti.it/podcast e ci vediamo al prossimo episodio
di INNOVATIABLE.

Ciao a tutti!