Requisiti e bisogni nei progetti fintech complessi: una lezione dal cambio di core banking

Chi lavora tra tecnologia e prodotto sa che, nei progetti fintech complessi, la difficoltà principale non è costruire soluzioni tecnicamente corrette, ma decidere quali componenti rendere disponibili subito e quali far evolvere nel tempo.
Vincoli di time to market, integrazioni regolatorie e sostenibilità operativa rendono la definizione delle priorità un esercizio continuo di compromesso.

Il percorso di trasformazione di Flowe, e in particolare il cambio della piattaforma di core banking, offre un esempio concreto di come affrontare queste scelte in un contesto B2B ad alta complessità.

Dal B2C al B2B: quando cambiano bisogni e criteri decisionali

Gli ultimi anni di Flowe sono stati caratterizzati da una trasformazione profonda. Dopo una prima fase in cui la missione principale era offrire servizi finanziari al cliente finale secondo un modello B2C, l’azienda ha intrapreso un percorso di evoluzione verso un modello B2B, in cui il cliente diventa un’altra organizzazione.

Un passaggio di questo tipo non è mai neutro. Cambiano i bisogni, cambiano i vincoli e, soprattutto, cambiano i criteri con cui si valuta il valore di una funzionalità. Abitudini consolidate e approcci precedenti devono essere messi in discussione, con un impatto diretto su roadmap di prodotto, priorità di sviluppo e definizione dello scope dei servizi.

Il cambio di core banking come sfida strutturale

All’interno di questo percorso, uno dei passaggi più delicati è stato il cambio della piattaforma di core banking: il sistema che gestisce conti correnti, transazioni e pagamenti, e che rappresenta il cuore operativo di una banca o di un IMEL.

Le motivazioni alla base di una scelta di questo tipo sono molteplici e non tutte approfondibili in questa sede. Ciò che conta è il contesto temporale in cui questa decisione è stata tradotta in progetto: avvio a gennaio 2025 e go live di tutti i servizi core entro il 1° luglio dello stesso anno.

Sei mesi — inclusi collaudi e messa in produzione — per ricostruire ciò che si era stratificato in anni di operatività.

Dal punto di vista tecnico, una sfida di questo tipo impone subito una riflessione sul classico triangolo del project management, spesso riassunto in una formula tanto semplice quanto efficace:
“Veloce, economico o buono: scegline due.”

Sebbene si tratti di un principio ampiamente noto, è utile richiamarlo nel contesto della realizzazione di un prodotto o di un progetto complesso. Spesso, infatti, non si considera con sufficiente attenzione il “prezzo” da accettare per raggiungere il risultato desiderato. In particolare:

• un risultato può essere di buona qualità ed economico, ma difficilmente sarà realizzato in tempi rapidi;
• può essere rapido e di alta qualità, ma avrà costi più elevati;
• può essere economico e veloce, ma non potrà garantire un livello di qualità adeguato.

Quando tempo e costo rappresentano vincoli non negoziabili  - come in questo progetto - il rischio più frequente è quello di compromettere la qualità, spesso perché percepita come l’elemento più “elastico” o come qualcosa che può essere rimandato. È proprio su questo punto che occorre mantenere alta l’attenzione: la qualità è il primo fattore a essere sacrificato quando tempi e budget non lasciano margini di manovra, ma anche quello che incide più profondamente sull’efficacia e sul valore finale del risultato.

Lo scope come leva decisionale nei progetti Agile

Un approccio Agile consente però di spostare il fuoco della decisione su una variabile diversa: lo scope, ovvero la quantità di funzionalità che il sistema deve includere al momento della consegna.

Nel contesto del cambio di core banking di Flowe, è stato proprio questo il driver con cui è stato affrontato il problema. Le tempistiche erano fisse (sei mesi, senza margini) e i costi già definiti (budget allocato e team disponibile). La vera domanda non era quindi se rispettare quei vincoli, ma come decidere cosa portare effettivamente in produzione al go live.

Riuso tecnologico ed exaptation

In questo scenario, il team di sviluppo è stato particolarmente sollecitato. È stato anche il contesto ideale per applicare un principio noto in ambito evolutivo: l’exaptation, ovvero la capacità di riutilizzare strumenti nati per uno scopo in un contesto nuovo.

Metodologie di testing sviluppate per il mondo B2C sono state adattate all’integrazione dei circuiti di pagamento (in particolare SEPA). Processi pensati per l’onboarding dei clienti finali sono stati riutilizzati per orchestrare flussi complessi basati su macchine a stati, alla base della nuova piattaforma.

Più che da una scelta teorica, questo approccio è nato da una necessità concreta: ridurre tempi di implementazione senza rinunciare alla solidità del sistema.

Impatto e frequenza: la base delle priorità

Nel corso del progetto, per ogni funzionalità è stata posta una domanda molto semplice, ma operativa:
per quale motivo riteniamo che questa feature debba essere presente fin dal primo giorno?

Per rispondere in modo strutturato, il confronto si è basato su due metriche:

• l’impatto della mancata realizzazione, in termini economici e operativi;
• la frequenza di utilizzo attesa nelle fasi iniziali.

Un esempio chiarisce il punto. Nel modello B2C, l’addebito diretto SEPA (SDD) era una funzionalità essenziale: la sua assenza avrebbe compromesso la percezione di qualità del prodotto. Nel contesto B2B, lo stesso servizio rimane importante, ma la sua assenza iniziale non impedisce l’operatività quotidiana, che può essere garantita tramite bonifici SEPA.

La matrice di Eisenhower (2×2)

L’incrocio tra impatto e frequenza ha portato alla costruzione di una matrice di priorità 2×2, utilizzata come strumento guida per la gestione del backlog.

Interpretazione operativa delle priorità:

1. Priorità alta – funzionalità core, indispensabili, che non possono essere delegate a processi manuali per frequenza o impatto.
2. Priorità medio-alta – funzionalità non percepite come centrali, ma che generano un carico operativo manuale insostenibile se non automatizzate.
3. Priorità medio-bassa – funzionalità importanti ma poco utilizzate, sostituibili temporaneamente da procedure manuali strutturate.
4. Priorità bassa – funzionalità a basso impatto e bassa frequenza, pianificabili in fasi successive.

Questa matrice non è stata utilizzata come riferimento teorico, ma come criterio vincolante nelle decisioni di sviluppo.

Oltre il go live: evoluzione e sostenibilità

A distanza di alcuni mesi dal go live del nuovo core banking, il percorso evolutivo è ancora in corso, con l’introduzione progressiva di nuovi strumenti e servizi per le aziende. L’approccio nato in un momento di forte pressione si sta dimostrando efficace anche nella gestione ordinaria.

Un ruolo chiave lo ha avuto il confronto tra competenze eterogenee: pagamenti, accounting, compliance, risk e tecnologia hanno contribuito in modo complementare alla definizione delle scelte. È da questa integrazione di esperienze che sono emerse decisioni sostenibili e soluzioni in grado di reggere la complessità del contesto.

In contesti in cui risorse e tempo sono limitati, distinguere tra requisiti teorici e bisogni reali non è solo una strategia di sopravvivenza, ma il modo più solido per costruire piattaforme fintech sostenibili, capaci di evolvere senza perdere qualità e continuità operativa.

Messaggio pubblicitario con finalità promozionale.