Il codice rallentava, ma il problema era un altro

Una startup di circa tre anni mi aveva chiamato per un ingaggio classico: “delivery di codice”. Il brief era aumentare la qualità del prodotto introducendo buone pratiche e portare una mentalità di prodotto nel team di sviluppo. Il punto di partenza era un bagaglio di codice scritto male: non risolveva i problemi del business ed era persino iper-complicato da usare.

Da dove partivamo

Il team di sviluppo lavorava sotto pressione e il clima non era sereno. Release faticose, bug ricorrenti, ogni modifica che sembrava semplice diventava un’impresa. La percezione era che il team di sviluppo fosse il collo di bottiglia principale. La mia entrata era prevista come affiancamento tecnico: pair programming, qualità del codice, un po’ di disciplina.

Cosa non funzionava

Lavorando dentro il team è emerso in fretta che il codice era il sintomo, non la causa. Il nodo vero era l’allineamento: business, prodotto e sviluppo parlavano lingue diverse, comunicavano poco e male, e non condividevano una direzione. Ognuno aveva una visione legittima del prodotto, ma nessuna era quella condivisa e erano tutte parziali.

Si può riscrivere tutto il codice del mondo, ma se il business non sa dove sta andando, il software continuerà a non risolvere i suoi problemi. E in questo caso, continuare a investire in sviluppo senza quella chiarezza avrebbe significato spendere soldi per rincorrere un codice che nessuna riscrittura avrebbe salvato.

Cosa abbiamo fatto

Accanto al lavoro quotidiano nel team — pair programming, buone pratiche, cura della qualità — ho proposto di mettere business e prodotto nella stessa stanza. Non per fare un altro meeting, ma per costruire una visione condivisa partendo dai dati reali.

Il piano iniziale era un altro: Value Proposition Canvas e Impact Mapping. Ci è bastato l’inizio della prima giornata per accorgerci che mancava un livello sopra: l’allineamento non c’era nemmeno dentro il gruppo dei decisori. Siamo partiti da un livello più alto, con una serie di workshop di discovery:

• Revenue Model Canvas: per capire come l’azienda crea valore e dove il software poteva incidere davvero.
• Impact Mapping: per collegare gli obiettivi di business agli impatti attesi e da lì alle attività di sviluppo, senza partire dalle feature.

Il lavoro tecnico nel team è continuato, ma è diventato secondario rispetto a una domanda più grande: stiamo costruendo la cosa giusta?

Parallelamente ai workshop, abbiamo iniziato a sistemare il codice con un approccio opportunistico: non una riscrittura, ma piccoli interventi mirati. Quattro micro-servizi fortemente accoppiati — con import diretti di codice l’uno nell’altro — non si sistemano in un colpo solo. Abbiamo estratto in una libreria comune il codice condiviso solo quando ci lavoravamo sopra, abbiamo introdotto architectural fitness functions per misurare l’accoppiamento cross-micro-servizio e assicurarci di non peggiorare, e abbiamo iniziato a ridurre l’accoppiamento interno applicando l’architettura esagonale.

Sul frontend e sul backend abbiamo introdotto test E2E e API, test unitari sociable e pair programming con rotazione a ogni attività. TypeScript era usato senza i controlli attivati: abbiamo introdotto regole di linting forti, risolto le segnalazioni in modo iterativo e abilitato i controlli del compilatore sui moduli ripuliti.

Cosa è cambiato

• Una visione chiara e condivisa: per la prima volta business e prodotto avevano scritto insieme dove si trovavano, dove volevano andare e quale strada percorrere. Le priorità sono diventate chiare.
• Una mappa degli impatti: gli obiettivi di business erano collegati a impatti concreti e a poche attività prioritarie, invece che a un backlog infinito e senza priorità.
• Maggior consapevolezza nel team di sviluppo: anche chi scriveva codice ha iniziato a capire il perché delle cose che costruiva e il loro scopo.
• Qualità del codice in miglioramento: segnalazioni di linting ridotte del ~30% in 3 mesi, 4 moduli su 10 portati a uno standard soddisfacente con controlli TypeScript abilitati in 6 mesi.
• Accoppiamento sotto controllo: architectural fitness functions hanno evidenziato lo stato reale dei 4 micro-servizi; le violazioni cross-micro-servizio sono diminuite del ~10% nello stesso periodo.
• E2E e API test: copertura parziale ma in crescita, pair programming con rotazione su ogni nuova attività.
• UX semplificata: alcune parti dell’applicazione rese più usabili, rimuovendo attriti evidenti.
• Il risultato di maggior valore: non è stato tecnico. È stato l’allineamento tra business e prodotto costruito insieme nei workshop, che ha dato al team una direzione condivisa per la prima volta.

E poi? La parte che non ti aspetti

La strada individuata era quella giusta, ma era lunga. La situazione finanziaria non permetteva di percorrerla, e le condizioni non hanno retto lo sviluppo di prodotto.

Lo racconto perché è la verità, e perché è la parte più istruttiva: la chiarezza non basta se governance e finanze non la reggono. Ma vale anche il contrario — senza quella chiarezza, ogni euro investito in sviluppo sarebbe stato speso alla cieca e, tendenzialmente sprecato.

Cosa mi ha insegnato

Questo caso non rientra nel modello di partnership di 6 mesi che propongo oggi, ma mi ha lasciato una lezione che riporto in ogni conversazione: a volte il mio lavoro più utile è dire che il problema non è dove sembra. Che spendere in codice senza allineamento è una trappola. E che la verità scomoda, detta prima che i soldi volino via, è parte del contratto che ho con chi mi ingaggia.

Da qui è nato anche il filtro onesto che trovi nelle pagine del sito: se non posso aiutarti, te lo dico. Anche quando significa consigliarti di non investire in quello che mi chiedi.

Approfondimenti

Lo stesso tema, dal lato del prodotto: la roadmap non è una lista di feature. I workshop di discovery con cui abbiamo sostituito la riscrittura partono dal dominio insieme al business: lo stesso principio che racconto in l’Event Storming come punto di partenza. E la verità scomoda, detta prima che i soldi volino via, è il tema di partnership: avere gli stessi obiettivi, anche a costo di perdere il cliente.