C'è un prototipo, da qualche parte, che ti sta guardando male.
Magari è nato in un hackathon di due giorni, oppure in una settimana morta di agosto, o in quel weekend in cui un paio di sviluppatori avevano voglia di provare un'idea. Funzionava. Faceva esattamente la cosa che doveva fare, almeno nella demo. Qualcuno ha detto "wow", qualcun altro ha scattato uno screenshot per LinkedIn, e poi è successa la cosa che succede sempre: il lunedì è arrivato il lavoro vero, le priorità sono tornate quelle di prima, e il prototipo è finito in un branch che nessuno ha più guardato.
Dieci mesi dopo, qualcuno si ricorda che esisteva.
Questa storia la conosciamo bene, perché ci capita addosso con una regolarità quasi comica. Un'azienda ci scrive dicendo "abbiamo già una cosa che funziona, ci serve solo metterla in produzione". E quel "solo" è il punto di tutto questo articolo. Tra la demo che funziona e il software che usano i clienti veri c'è una distanza che quasi nessuno stima correttamente, perché è una distanza fatta di cose invisibili.
Il momento in cui la demo funziona è il momento più ingannevole
Quando un prototipo gira durante una presentazione, sta facendo una cosa molto precisa: percorre il sentiero felice. Un solo utente, dati puliti, connessione buona, nessuno che prova a romperlo, nessuno che inserisce una data nel campo del nome. È il software nelle condizioni di laboratorio più gentili immaginabili.
Il problema è che il cervello umano, quando vede una demo girare, registra "il prodotto è fatto". Non è colpa di nessuno, è proprio come siamo cablati. Vediamo l'output finale e diamo per scontato tutto quello che dovrebbe esserci sotto. È lo stesso motivo per cui guardiamo un edificio finito e non pensiamo alle fondamenta, agli impianti, ai calcoli strutturali.
Una stima vecchia e un po' brutale del mondo dello sviluppo dice che far funzionare il primo 80% di una funzionalità richiede il 20% del tempo, e l'ultimo 20% richiede l'altro 80%. Si chiama, non a caso, la regola del 90-90: il primo 90% del codice prende il 90% del tempo, il restante 10% prende l'altro 90% del tempo. È una battuta, ma chiunque abbia portato qualcosa in produzione sa che è anche piuttosto vera.
Il prototipo vive in quel primo 80% facile. Il prodotto vive nell'altro.
Cosa c'è davvero in quell'altro 80%
Vale la pena essere concreti, perché "metterlo in produzione" è un'espressione che nasconde una lista lunga. Provo a tirarla fuori, non in ordine di importanza ma di quanto la gente la sottovaluta.
Gli errori, che nella demo non esistono
In un prototipo, quando una chiamata API fallisce, di solito succede una di due cose: o l'app crasha, o non succede niente e lo schermo resta bianco. Nessuna delle due va bene per un cliente che ha pagato.
Il software vero deve sapere cosa fare quando la rete cade a metà di un'operazione, quando il servizio esterno risponde con un errore 500, quando l'utente clicca due volte sul pulsante "paga", quando il file caricato è da 2 GB invece dei 2 MB previsti. Ognuno di questi casi è una decisione di prodotto, non solo tecnica. Cosa mostriamo all'utente? Riproviamo in automatico? Quante volte? Salviamo lo stato a metà o ricominciamo? Gestire gli errori in modo serio può richiedere tanto codice quanto la funzionalità principale, a volte di più.
I dati, che da soli non si salvano
Tanti prototipi tengono tutto in memoria, oppure in un file JSON, oppure in un database SQLite che vive sul portatile di chi ha fatto la demo. Funziona benissimo finché c'è un utente e finché nessuno riavvia il processo.
Il passaggio a un vero database porta con sé un universo di domande che il prototipo non si era mai posto. Come gestiamo le migrazioni quando lo schema cambia? Cosa succede quando due persone modificano lo stesso record nello stesso secondo? Come facciamo i backup, e (domanda più importante e più dimenticata) li abbiamo mai provati a ripristinare? Un backup che non è mai stato testato in ripristino è una speranza, non un backup.
La sicurezza, che nel prototipo semplicemente non c'è
Questo è il capitolo che fa più paura quando si riprende del codice vecchio. Nei prototipi le chiavi API stanno scritte nel codice. Le password, quando esistono, sono in chiaro. Non c'è validazione degli input, quindi qualsiasi campo è una porta aperta. Non c'è controllo su chi può vedere cosa, perché tanto nella demo l'utente è uno solo ed è il capo.
Portare in produzione vuol dire prendersi sul serio l'idea che qualcuno proverà ad attaccare il sistema, o anche solo che un utente normale farà per sbaglio una cosa che non dovrebbe. Significa autenticazione vera, gestione dei permessi, validazione e sanitizzazione di ogni input, segreti tenuti fuori dal codice, log che non scrivono dati sensibili. Non è un di più. È la differenza tra un prodotto e un incidente in attesa di accadere.
Il carico, perché un utente non sono mille
Una demo regge un utente perché un utente è il caso più facile del mondo. Il prodotto deve reggere quello che gli arriva addosso: i picchi, i clienti che usano il sistema tutti alla stessa ora, la query che era istantanea su 50 righe e diventa di 40 secondi su 500.000.
Qui non serve diventare ossessionati dalla scalabilità prima del tempo (sovradimensionare in anticipo è uno spreco classico), ma serve sapere dove sono i colli di bottiglia e avere un'idea di cosa fare quando il primo arriva. A volte basta un indice sul database messo nel punto giusto. A volte serve ripensare un pezzo intero.
Tutto il resto che nessuno include nel preventivo mentale
E poi c'è la lista delle cose che esistono solo nel software vero e mai nei prototipi: il deploy che funziona in modo ripetibile invece che "ah, lo faccio girare dal mio computer", il monitoraggio che ti avvisa quando qualcosa si rompe alle tre di notte, i test che ti dicono se la modifica di oggi ha rotto la funzionalità di tre mesi fa, l'accessibilità per chi naviga con la tastiera o con uno screen reader, i messaggi di errore scritti in modo che un essere umano li capisca, la documentazione, il supporto.
Niente di tutto questo si vede nella demo. Tutto questo è il prodotto.
La storia del prototipo ripreso dopo dieci mesi
Torniamo al cassetto. Cosa succede davvero quando si decide di riprendere in mano una cosa abbandonata da quasi un anno?
La prima sorpresa, di solito, è che il prototipo non parte più. Una dipendenza ha cambiato versione, un servizio esterno ha cambiato API, la chiave che usavano nella demo è scaduta. Il codice è "congelato" ma il mondo intorno è andato avanti. I primi due o tre giorni se ne vanno solo per riportare il progetto a uno stato in cui gira di nuovo, prima ancora di aggiungere una sola riga di valore.
La seconda sorpresa è che nessuno si ricorda perché certe scelte erano state fatte. C'è una funzione con un commento che dice "fix temporaneo, da sistemare", e nessuno sa più cosa stesse aggiustando né cosa si rompe se la tocchi. C'è una parte di codice che sembra inutile ma che probabilmente serviva a qualcosa. Il prototipo è stato scritto in fretta, per definizione, e la fretta non lascia documentazione.
A questo punto arriva la domanda vera, quella da cui dipende tutto il resto: si parte da questo codice o si butta via?
Riscrivere o recuperare
C'è una tentazione fortissima, soprattutto negli sviluppatori, di guardare il codice di qualcun altro (o di sé stessi dieci mesi prima) e dire "è più veloce rifarlo da zero". A volte è vero. Spesso no.
Il prototipo, anche se scritto male, contiene una cosa preziosa che non è il codice: contiene le decisioni. Contiene la prova che una certa cosa funziona, le scoperte fatte sbattendo la testa, i casi limite trovati per caso. Riscrivere da zero significa rischiare di ributtare via tutto quel sapere insieme al codice brutto, e di reinciampare negli stessi problemi.
La regola pratica che usiamo è semplice: il prototipo serve a capire cosa costruire, non a definire come. Si tiene quello che ci ha insegnato (il dominio, i requisiti veri emersi dall'uso, il flusso che ha senso) e si è spietati con l'implementazione. Spesso la risposta non è né "riscrivo tutto" né "tengo tutto", ma "tengo l'architettura dei dati e l'idea, riscrivo i pezzi che toccano gli utenti e la sicurezza". È una decisione che va presa pezzo per pezzo, guardando il codice, non in astratto.
Il salto mentale: smettere di pensare alla demo, iniziare a pensare al prodotto
C'è un cambio di prospettiva che deve avvenire, e non è tecnico. È nel modo di porsi le domande.
Un prototipo risponde a una domanda sola: "questa idea può funzionare?". Un prodotto risponde a domande diverse e molto meno glamour: "cosa succede quando si rompe?", "chi lo aggiusta?", "come fa un cliente nuovo a iniziare a usarlo senza che qualcuno gli stia accanto?", "quanto ci costa tenerlo acceso ogni mese?", "se sparisce la persona che l'ha scritto, qualcun altro ci capisce qualcosa?".
Sono domande noiose. Sono anche quelle che separano un'azienda che ha una demo da un'azienda che ha un prodotto da vendere.
Una cosa che ripetiamo spesso ai clienti è che il prototipo ha fatto il suo lavoro nel momento esatto in cui ha convinto qualcuno che valeva la pena andare avanti. Non deve sopravvivere oltre quel momento. Pretendere che il codice di un esperimento di due giorni regga il peso di un prodotto in produzione è come pretendere che il plastico di una casa ci abiti dentro una famiglia.
Come capire se vale davvero la pena
Non tutti i prototipi meritano di diventare prodotti, e dirlo è una forma di onestà che fa risparmiare un sacco di soldi.
Prima di investire mesi, conviene rispondere onestamente ad alcune domande. C'è qualcuno disposto a pagare per questa cosa, o ci piace solo l'idea? Il problema che risolve è abbastanza grosso e abbastanza frequente da giustificare il costo di mantenimento? Abbiamo le persone per portarlo avanti dopo il lancio, o stiamo solo spostando il problema più in là?
La trappola classica è il costo scommemorativo, quello che gli economisti chiamano sunk cost: "ci abbiamo già messo dentro tre settimane di lavoro l'anno scorso, sarebbe uno spreco non finirlo". Quelle tre settimane sono spese in ogni caso, finiate o no. La domanda giusta non è quanto abbiamo già speso, ma se i prossimi tre mesi di lavoro porteranno più valore di quanto costano. Sono due conti completamente diversi, e confonderli porta a tenere in vita progetti che nessuno vuole davvero.
Quando invece le risposte sono buone, quando c'è un mercato vero e un problema vero, allora il prototipo abbandonato è una delle cose più preziose che un'azienda possa avere in cassetto. È un vantaggio di mesi su chi parte da zero, a patto di trattarlo per quello che è: un punto di partenza, non un punto d'arrivo.
Il percorso, in pratica
Quando recuperiamo un prototipo, il lavoro tende a seguire una progressione abbastanza riconoscibile. Non è una ricetta rigida, ma dà l'idea di dove vanno i mesi.
Si parte dal capire cosa c'è. Una settimana, a volte due, passate a leggere il codice, a rimetterlo in moto, a scrivere nero su bianco cosa fa, cosa manca e dove sono le mine. Sembra tempo perso e invece è il tempo meglio speso di tutto il progetto, perché ogni decisione successiva dipende da questa mappa.
Poi si definisce l'MVP vero, che non è il prototipo. È la versione più piccola possibile che un cliente vero pagherebbe e userebbe senza assistenza. Quasi sempre è più piccola di quanto il team si aspetti, e questa è una buona notizia: tagliare le funzionalità che nella demo facevano scena ma che nessun cliente ha mai chiesto è il modo più veloce di arrivare in produzione.
Da lì si ricostruisce la spina dorsale: dati persistenti seri, autenticazione, gestione degli errori, un deploy ripetibile. È la parte meno visibile e più importante, quella che non aggiunge nessuna funzionalità nuova e su cui si regge tutto il resto.
Solo a questo punto si lavora sulle funzionalità, una alla volta, ognuna portata fino a uno stato in cui regge i casi limite e non solo il sentiero felice. E in parallelo, dall'inizio e non alla fine, si mettono i test e il monitoraggio, perché aggiungerli dopo costa il triplo e si fa sempre peggio.
Quanto dura tutto questo? Dipende, e diffida di chiunque ti dia un numero senza aver visto il codice. Ma un prototipo serio che diventa un prodotto serio raramente è questione di settimane. Più spesso sono mesi, e la parte difficile non sono le funzionalità nuove ma tutto il lavoro invisibile intorno.
Perché questo capita così spesso
Vale la pena chiedersi perché tante aziende si ritrovano con questi prototipi nel cassetto. Non è incompetenza, di solito. È che la fase di prototipazione e la fase di prodotto richiedono due mentalità quasi opposte, e raramente convivono nella stessa settimana.
Il prototipo premia la velocità, il taglio degli angoli, il "facciamolo funzionare e basta". È il modo giusto di lavorare quando l'obiettivo è imparare in fretta. Il prodotto premia esattamente le qualità opposte: la cura, la previsione dei casi che vanno male, la disciplina di scrivere test anche quando sembra che rallentino. Chiedere alle stesse persone, nello stesso slancio, di passare dalla prima mentalità alla seconda è difficile. Spesso il prototipo viene fatto in un momento di entusiasmo e di tempo libero, e il prodotto richiede invece un impegno pianificato che compete con tutto il resto del lavoro.
Ed è qui che ha senso, a volte, far entrare qualcuno da fuori. Non perché il team interno non sia capace, ma perché portare un prototipo in produzione è esattamente il tipo di lavoro che soffre delle interruzioni e delle priorità che cambiano. Un team che ha già attraversato quella distanza diverse volte sa dove sono le mine prima di pestarle, e questo è gran parte di quello che facciamo in bajara.it: prendere idee che hanno già dimostrato di valere e portarle fino al punto in cui un cliente le usa senza accorgersi di tutto il lavoro che c'è sotto. Che poi è il complimento più bello per un software: che nessuno noti quanto era difficile farlo funzionare.
Il prototipo non era un fallimento
Se c'è una cosa da portarsi via, è questa: il prototipo finito nel cassetto non è un progetto fallito. Ha fatto la cosa per cui era nato, ha dimostrato che un'idea poteva reggere. Il fatto che non sia diventato subito un prodotto non toglie niente a quel valore.
Quello che serve, dieci mesi dopo, non è ripartire da zero né sentirsi in colpa per averlo lasciato lì. Serve guardarlo con occhi diversi, separare l'idea (che probabilmente è ancora buona) dal codice (che probabilmente va in gran parte rifatto), e decidere con onestà se il problema che risolveva merita ancora di essere risolto.
Se la risposta è sì, quel cassetto contiene un vantaggio che pochi concorrenti hanno. Basta trattarlo per quello che è.