MVP: perché la prima versione del tuo software deve essere più piccola di quanto pensi

La prima lista di funzioni è sempre lunga. Prenotazioni, pagamenti, notifiche, statistiche, programma fedeltà, app per iPhone e per Android, magari un assistente intelligente. Ogni voce sembra indispensabile.

Il motivo è semplice: in quel momento le funzioni sono tutte immaginate, nessuna è ancora stata usata. E l'errore più costoso nello sviluppo di un software non è costruire male. È costruire bene qualcosa che poi nessuno usa.

MVP sta per Minimum Viable Product: la versione più piccola del prodotto che risolve davvero il problema principale, per utenti reali. Non è un prototipo da mostrare, non è una demo e soprattutto non è una versione fatta in fretta. È un prodotto completo, con un perimetro stretto.

C'è un'illustrazione molto nota di Henrik Kniberg che lo spiega meglio di qualsiasi definizione. Se l'obiettivo è spostarsi, non si costruisce prima una ruota, poi un telaio, poi una carrozzeria, lasciando l'utente a piedi fino alla fine. Si parte da uno skateboard, poi un monopattino, poi una bicicletta. A ogni passo l'utente ha qualcosa che lo porta da qualche parte, e a ogni passo si impara cosa gli serve davvero.

Scopri presto cosa serve davvero. Le persone usano il software in modi che nessuna riunione riesce a prevedere. Prima glielo metti in mano, prima lo scopri.

Sbagliare costa meno. Se una funzione si rivela inutile, meglio averlo capito su un progetto piccolo che dopo mesi di sviluppo.

Arrivi prima all'uso reale. Settimane invece di trimestri. E un software in uso inizia a restituire valore da subito.

Le decisioni successive si basano sui fatti. Dalla seconda versione in poi non si discute più di ipotesi, ma di come le persone usano davvero lo strumento.

Prendi la lista delle funzioni e dividila in tre gruppi: indispensabile dal primo giorno, utile ma può aspettare, bello da avere. Poi fai a ogni voce del primo gruppo una domanda: se questa funzione mancasse, qualcuno smetterebbe di usare il prodotto? Se la risposta è no, scende di gruppo.

Una seconda domanda aiuta a tagliare ancora: cosa si può fare a mano, all'inizio? Approvare una richiesta, mandare un report, gestire un'eccezione. Farlo a mano per qualche settimana costa poco e ti dice se vale la pena automatizzarlo.

Ecco come potrebbe apparire la divisione per una piattaforma di prenotazioni.

Sull'ultima riga ho scritto un confronto dedicato in PWA o app nativa? Cos'è una Progressive Web App e quando conviene.

Qui sta la differenza tra un MVP e un lavoro fatto al risparmio. Il perimetro è stretto, ma le fondamenta sono quelle di un prodotto destinato a crescere: sicurezza, una struttura dei dati pensata bene, codice che si può estendere senza doverlo riscrivere.

Si tagliano le funzioni, non le fondamenta. Un MVP costruito male non è una prima versione: è un prototipo che dovrai buttare.

Ci sono casi in cui partire piccoli non funziona, ed è giusto dirlo.

Se sostituisci uno strumento che l'azienda usa ogni giorno, le persone non accetteranno di tornare indietro: le funzioni principali del vecchio sistema devono esserci tutte dal primo giorno. Il perimetro si può stringere su tutto il resto, non su quello.

Se lavori in un settore con obblighi precisi — dati sanitari, pagamenti, normative di settore — alcuni requisiti non sono funzioni da rimandare, ma condizioni per poter partire.

È lo stesso ragionamento della terza via di cui ho scritto in Gestionale su misura o software in abbonamento: costruire solo il pezzo che serve, e costruirlo bene.