Da nessun team interno a una squadra che conosce il prodotto

viteSicure è il brand con cui Bridge Insurance Services vende polizze vita e infortuni online. Il primo passo della collaborazione era stato un workshop: a novembre 2022 avevo facilitato un Event Storming strategico con tutta l’azienda. Quando sono entrato stabilmente, a gennaio 2023, il prodotto esisteva ma il team di sviluppo interno no. L’applicazione era stata scritta da consulenti, fatturava circa un milione di euro all’anno, e il business non poteva permettersi di rallentare mentre costruivamo chi se ne sarebbe occupato per davvero.

Da dove partivamo

Non c’era un team interno di sviluppo. C’erano due consulenti che mantenevano l’applicazione e una cultura di lavoro molto consulenziale: lo stakeholder forniva le specifiche, i consulenti sviluppavano in isolamento per mesi, poi consegnavano un batch di feature e iniziava una fase di test e validazione manuali. L’ambizione del founder era chiara: viteSicure doveva diventare un vero broker assicurativo, con più carrier e più linee di prodotto. Per farlo serviva qualcuno dentro l’azienda che non eseguisse solo richieste, ma conoscesse il prodotto e guidasse le scelte tecniche.

Cosa non funzionava

Non bastava assumere sviluppatori. Serviva un team che crescesse in fretta e prendesse ownership del prodotto e delle decisioni, non un gruppo di esecutori. Il contesto non aiutava: dovevamo costruire il team che avrebbe riscritto viteSicure, mentre il prodotto continuava a vendere, con pochi sviluppatori, progetti collaterali da incastrare con lo sviluppo principale, e un business che non poteva rallentare.

La sfida più grande non era tecnica: era far nascere un modo di lavorare in cui il team fosse parte della conversazione con il business, non un fornitore interno.

Cosa abbiamo fatto

1. Una coppia, non un consulente

Ho lavorato a part-time al fianco di Luca Giovenzana, che a gennaio 2023 è entrato come fractional CTO. Lui era focalizzato sul business e sul prodotto, io su tech e codice. Entrambi facevamo da ponte tra le due metà, e imparavamo l’uno dall’altro. Non era una gerarchia con noi che guardavamo dall’alto: eravamo due figure di riferimento nel team, con responsabilità diverse ma con lo stesso obiettivo.

Questa coppia ci ha permesso di coprire più terreno senza sovraccaricare nessuno, e di dare al team un esempio concreto di come si discute una decisione tecnica legata a una scelta di business.

2. Un atto di fondazione condiviso

Il workshop di novembre 2022 è stato l’atto che ha creato le basi su cui fondare il futuro team di prodotto. Erano presenti tutta viteSicure e i due consulenti che allora mantenevano l’applicazione: abbiamo fatto emergere come funziona davvero il prodotto e il flusso di lavoro reale dell’azienda, e da lì sono usciti i bounded context.

Quando a gennaio 2023 abbiamo costruito il team — due giovani sviluppatori interni, due nuovi consulenti esterni in sostituzione ai precedenti, più un UX/UI designer part-time — quell’Event Storming era il terreno comune. La conoscenza del prodotto non era solo nei miei appunti o in quelli di Luca: era qualcosa che il team aveva a portata di mano e che, anche se non l’aveva vista nascere, potevamo far crescere tutti insieme.

3. Assumere per cultura, non solo per competenze

I due sviluppatori interni avevano poca esperienza, ma erano svegli e portati ad apprendere. Con uno avevo già lavorato in passato e sapevo che ce l’aveva. La scelta è stata deliberata: preferire chi poteva crescere intorno al prodotto a chi arrivava già pieno di abitudini da altri contesti. I consulenti esterni erano lì per portare qualità e disciplina tecnica, e per trasferirla al team interno, non per sostituirlo.

Nel 2023, durante la riscrittura della vecchia applicazione, il team è arrivato a 6 persone: 3 sviluppatori interni e 3 consulenti esterni. Una volta superata la fase più intensa, siamo tornati a una squadra più snella.

4. Studio e guida mentre si lavora

Niente corsi frontali o slide. Il mentoring è avvenuto dentro il lavoro quotidiano, sempre in verticale: design, frontend e backend insieme. Lavoravamo a coppie, affrontavamo problemi reali, e la conoscenza del prodotto cresceva mentre risolvevamo problemi concreti.

Questo approccio ha avuto un effetto collaterale importante: il team non imparava solo a scrivere codice, ma a ragionare sul perché di quel codice. Le domande non erano più “come faccio questa feature?”, ma “questa feature ha senso rispetto al prodotto?”.

5. Dare spazio, poi togliere il mio

Man mano che il team diventava indipendente ho ridotto il mio impegno. Non è stato un abbandono: è stata una scelta. Ho iniziato a dedicarmi a side project per viteSicure — come il sito web — lasciando il team concentrato sul prodotto principale. L’obiettivo era che il team prendesse il volante, non che imparasse a guidare con me seduto sempre sul sedile del passeggero.

6. I rilasci nelle mani del team

Il cambiamento di cultura si vede da chi decide cosa esce e quando. Prima il ritmo lo dettava il fornitore: batch mensili seguiti da due mesi di test manuali. Con il nuovo team la responsabilità dei rilasci è passata a chi scrive il codice: test E2E automatici in pipeline voluti e mantenuti dal team, fix rilasciati singolarmente appena pronti. Le piccole feature sono arrivate a un lead time di una o due settimane in circa 6 mesi.

La fiducia del business è arrivata più lentamente del codice: oltre un anno per rilasciare qualcosa di grosso, come un nuovo carrier, senza la lunga fase di validazione finale del passato.

Cosa è cambiato

Team creato da zero: da nessun sviluppatore interno a un team con ownership del prodotto.
Il team ha preso il prodotto: non esegue più specifiche passivamente, ma partecipa alle discussioni con il business con un linguaggio comune costruito intorno al prodotto.
Autonomia reale: il team lavora da solo; la mia presenza è scesa per scelta, non per abbandono.
Qualità nelle mani del team: con i consulenti precedenti oltre l’ 80% dei rilasci erano bug fix; da quando il team interno possiede codice e rilasci siamo scesi sotto il 20%.
Rilasci decisi dal team: i batch mensili del fornitore hanno lasciato il posto a fix rilasciati appena pronti, con 1–2 settimane di lead time sulle piccole feature.
Dimensione del team: da zero sviluppatori interni a 3 sviluppatori interni stabili, senza più consulenti esterni. Nel picco della riscrittura nel 2023 il team era arrivato a 6 persone (3 interni + 3 consulenti esterni).
Accountability sul ciclo completo: i membri del team hanno acquisito conoscenze approfondite del prodotto e sono diventati responsabili di ogni aspetto del ciclo di sviluppo software, incluse le integrazioni verso i sistemi esterni. In una struttura gerarchica piatta non ha senso parlare di promozioni: la crescita è stata in autonomia e competenza, non in titolo.
Conoscenza distribuita dei sistemi esterni: ogni sviluppatore ha una conoscenza di base di tutti i sistemi integrati — pagamenti elettronici (Stripe e altri), firma digitale certificata (YouSign), tracciamento del funnel (HubSpot, Google Tag Manager), piattaforma di messaggistica e ticketing — e su ciascuno c’è un referente più esperto a cui gli altri possono rivolgersi.

Cosa mi ha insegnato

Anche questo caso è stato un tassello dell’evoluzione del mio metodo. L’obiettivo finale — un team autonomo che non ha più bisogno di me — era già chiaro, anche se non ancora formalizzato come oggi.

Da viteSicure ho portato via la conferma che assumere per cultura e capacità di apprendimento vale più che assumere per curriculum pieno. Che il mentoring funziona solo dentro il lavoro reale. E che l’autonomia non si dà alla fine del progetto: si costruisce ogni giorno, riducendo gradualmente la propria presenza.

Approfondimenti

Questa è solo metà della storia: l’altra metà è riscrivere il backend senza fermare il business.