Da MVP a prodotto: cosa si tiene e cosa si riscrive
Il momento in cui l'MVP smette di bastare
Un MVP è costruito per rispondere a una domanda: esiste il problema, e questa soluzione lo risolve abbastanza da far tornare le persone? Per rispondere in fretta si prendono scorciatoie, e prenderle è la scelta corretta — un MVP costruito come se dovesse durare dieci anni è un MVP consegnato tardi, che è il solo modo sicuro di sbagliare in quella fase.
Il problema nasce dopo. La risposta è arrivata ed è sì. Adesso ci sono utenti che pagano, un piano commerciale, forse un round chiuso. E il software sotto è ancora quello costruito per rispondere a una domanda, non per reggere un'azienda.
Il riflesso comune è la riscrittura totale: ripartiamo puliti, adesso che sappiamo cosa serve. È quasi sempre la decisione peggiore. Significa fermare per mesi tutto ciò che porta valore agli utenti, per riottenere alla fine quello che si aveva già — con dentro i bug nuovi che si sono introdotti per strada.
I segnali che il passaggio va fatto
Non è una questione di età del codice. È una questione di attrito, e si riconosce da cose molto concrete.
- Ogni modifica ne rompe un'altra. Il tempo di sviluppo non è più speso a costruire, ma a rimettere in piedi ciò che si era mosso.
- C'è un lavoro che solo una persona può fare. Un pezzo che nessun altro tocca, perché nessun altro sa come funziona.
- Il rilascio fa paura. Se si mette in produzione solo il martedì mattina con tutta la squadra sveglia, il problema non è il calendario.
- Il supporto fa cose a mano. Correggere un dato via database, rilanciare un processo bloccato: gesti quotidiani che nessuno conta come lavoro e che invece consumano una persona.
- Un cliente più grande chiede cose che non ci sono. Autorizzazioni per ruoli, esportazioni, tracciabilità di chi ha fatto cosa. È il segnale più affidabile, perché arriva da fuori.
Quando questi segnali compaiono, il conto lo state già pagando. La domanda non è più se intervenire, è dove.
Cosa si tiene quasi sempre
La conoscenza del dominio dentro il codice. Tutte le regole strane scoperte parlando con gli utenti, i casi limite gestiti dopo una segnalazione. Sono la parte di più valore e la meno visibile: una riscrittura da zero le perde quasi tutte, e le ritrova nei mesi successivi, una segnalazione alla volta.
Le scelte che hanno retto. Se una parte funziona, è veloce e nessuno la teme, va lasciata stare anche se il codice non è elegante. L'obiettivo non è la bellezza, è togliere attrito dove c'è.
I dati. Sono il patrimonio vero. Anche quando lo schema va cambiato, si migra: non si riparte.
Cosa si rifà quasi sempre
Il modello dei dati nei punti che l'uso ha smentito. L'MVP assumeva un utente per azienda e i clienti reali sono squadre; assumeva un prezzo per prodotto e servono listini diversi. Sono cambiamenti strutturali che peggiorano se rimandati, perché ogni settimana in più significa più dati da convertire.
Autenticazione, ruoli e permessi. Nell'MVP tutti vedono tutto. Sistemarlo dopo è possibile, ma va fatto in modo sistematico, non aggiungendo un controllo alla volta.
Il modo in cui si va in produzione. Rilascio ripetibile, possibilità di tornare indietro, backup verificati davvero — cioè provati riportando in vita una copia, non solo attivati. Questa parte da sola cambia il tono delle giornate della squadra.
Il sapere cosa sta succedendo. Un errore che non arriva a nessuno viene scoperto da un cliente. Registri, avvisi, un posto solo dove guardare quando qualcosa non va: giorni di lavoro che si ripagano al primo problema serio.
Come si fa senza fermarsi
Il metodo che funziona è sostituire pezzo per pezzo, mentre il resto continua a girare e a essere sviluppato. Si isola un'area, la si riscrive dietro la stessa interfaccia, si sposta il traffico, si verifica, si passa alla successiva.
Due regole rendono possibile lavorare così. La prima: si comincia dal pezzo che fa più male, non dal più facile o dal più interessante — l'ordine giusto lo dettano le segnalazioni e il tempo perso, che sono dati che avete già. La seconda: ogni intervento deve stare in una manciata di giorni, con qualcosa di visibile alla fine. Un lavoro di risanamento che dura tre mesi senza risultati intermedi viene interrotto a metà dalla prima urgenza commerciale, e a quel punto si è pagato il costo senza incassare il beneficio.
Nella pratica conviene tenere una regola di ritmo: una quota fissa di ogni ciclo di lavoro dedicata a questo, sempre, anche nelle settimane in cui il commerciale spinge. Se diventa un progetto separato da approvare a parte, non parte.
Il debito non è un errore
Vale la pena dirlo perché toglie un senso di colpa che fa prendere decisioni sbagliate: le scorciatoie prese per uscire in otto settimane non sono state un errore. Erano il prezzo giusto per arrivare in fretta a una risposta, e senza quella risposta non ci sarebbe nulla da risanare adesso.
L'errore, semmai, è non aver deciso quando ripagarle. Un debito preso consapevolmente, scritto da qualche parte e rivisto quando il prodotto trova il suo mercato, è uno strumento. Uno preso e dimenticato diventa il motivo per cui due anni dopo consegnare una funzione richiede un mese.
La riscrittura totale è la scelta che sembra coraggiosa e quasi sempre è la più rischiosa. Sostituire un pezzo alla volta, mentre gli utenti continuano a usare il prodotto, è meno emozionante e arriva prima.
