"Facciamo prima un MVP" è una frase che si sente in ogni riunione sul software, e che ognuno interpreta a modo suo. Per qualcuno significa "una versione economica, poi vediamo". Per qualcun altro "il prodotto completo, ma più in fretta". Entrambe le letture portano a delusioni: la prima produce un software che nessuno riesce a usare, la seconda un progetto che costa e dura come uno normale.
Questa guida spiega cos'è davvero un MVP, quanto costa con numeri e ipotesi dichiarate, come si decide il perimetro, cosa si può rimandare senza rischi e cosa invece non va mai tagliato. È scritta per chi decide e paga: nessun gergo non spiegato.
Cos'è un MVP (e cosa non è)
MVP sta per Minimum Viable Product, in italiano "prodotto minimo funzionante". L'idea è semplice: invece di costruire tutto, si costruisce la parte più piccola che risolve davvero un problema reale, la si mette in mano a utenti veri e si impara da come la usano.
Un MVP non è:
- un prototipo. Il prototipo serve a mostrare un'idea: schermate che sembrano funzionare ma non salvano niente. Un MVP funziona davvero, con dati reali.
- una versione scadente. Il perimetro è piccolo, la qualità no. Un MVP con dati che si perdono non è minimo: è inutilizzabile.
- un prodotto completo, solo più veloce. Se il progetto contiene tutto, non è un MVP.
- una scorciatoia per saltare l'analisi. Anzi, richiede un'analisi più rigorosa, perché ogni funzione inclusa deve meritarsi il posto.
I tre livelli, a confronto:
| Livello | A cosa serve | Funziona davvero? | Dati reali | Durata tipica |
|---|---|---|---|---|
| Prototipo | Mostrare un'idea, raccogliere reazioni | No: schermate simulate | No | Giorni o poche settimane |
| MVP | Risolvere un problema reale per pochi utenti, imparare | Sì, per una cosa sola | Sì | Da uno a tre mesi |
| Prodotto completo | Coprire tutti i processi, per tutti gli utenti | Sì | Sì | Da quattro mesi in su |
Perché conviene partire da un MVP
I vantaggi sono concreti e non riguardano solo il costo iniziale.
Si impara prima. Le idee su come lavoreranno gli utenti sono quasi sempre sbagliate in qualche punto. Scoprirlo dopo due mesi costa molto meno che dopo un anno.
Si riduce il rischio. Se il progetto non funziona (perché il processo è diverso dal previsto, perché gli utenti lo aggirano, perché il problema vero era un altro), si perde poco.
Si ottengono risultati prima. Anche una versione ristretta, usata già dopo tre mesi, può far risparmiare ore ogni settimana.
Si decide con dati veri. La seconda fase si progetta guardando cosa gli utenti hanno usato davvero, non cosa si immaginava che avrebbero usato.
C'è un rovescio: partire da un MVP non è sempre la scelta giusta. Se i requisiti sono chiari, stabili e non negoziabili (per esempio un software che deve sostituire un sistema esistente in modo esatto, per obblighi di legge), procedere per fasi riduce meno il rischio di quanto sembri.
Come si decide il perimetro: un problema, un utente, un flusso
La parte più difficile di un MVP non è costruirlo, è decidere cosa lasciare fuori. Un metodo semplice, in tre vincoli:
- Un problema. Quale problema, se risolto, farebbe una differenza tangibile? Non "migliorare la logistica": "evitare che gli ordini si perdano tra l'ufficio e il magazzino".
- Un tipo di utente principale. Chi userà il software ogni giorno? Il resto (direzione, clienti, fornitori) può aspettare.
- Un flusso completo. Da dove inizia a dove finisce il processo che vuoi coprire. Non mille funzioni a metà: un percorso intero, dall'inizio alla fine.
Poi, per ogni funzione che vorresti, una domanda secca: senza questa, il flusso funziona? Se sì, va rimandata. Se no, è dentro.
L'esempio nella figura è quello di un gestionale per ordini e magazzino. Dentro: anagrafiche, ordini, movimenti di magazzino, due ruoli, esportazione per la contabilità, accessi protetti e copie di sicurezza. Fuori: portale clienti, integrazione con il corriere, statistiche avanzate, app per il palmare, acquisti, notifiche automatiche. Tutte queste funzioni potrebbero servire, ma il flusso principale funziona senza.
Quanto costa: ordini di grandezza con ipotesi dichiarate
Come per ogni stima, i numeri vanno letti con le ipotesi. Qui ipotizziamo una tariffa media di circa 450 euro per giornata di lavoro, mediata tra i ruoli coinvolti (analisi, sviluppo, collaudo, coordinamento), come in Quanto costa sviluppare un gestionale su misura. Se la tua tariffa di riferimento è diversa, moltiplica le giornate per il tuo valore.
| Tipo di MVP | Esempio | Giornate complessive | Ordine di grandezza |
|---|---|---|---|
| Molto piccolo | Un modulo per raccogliere richieste interne con elenco e stato, un solo ruolo | 15–30 | 6.750–13.500 € |
| Piccolo | Gestione di ordini e giacenze per un ufficio, due ruoli, esportazione dei dati | 35–70 | 15.750–31.500 € |
| Medio | Ordini, magazzino e un'integrazione con un sistema esistente, import dei dati storici | 70–120 | 31.500–54.000 € |
Come leggere queste cifre:
- Sono ordini di grandezza, non preventivi. Servono a collocare un progetto: "da poche migliaia", "da qualche decina di migliaia", "da centinaia di migliaia".
- Non includono i costi ricorrenti (hosting, licenze, manutenzione), di cui parliamo più avanti.
- Il costo non scala in modo lineare. Un MVP "metà del progetto" non costa metà. Una parte del lavoro (struttura del progetto, accessi, copie di sicurezza, ambiente di rilascio) è fissa e va fatta comunque.
Come rifare il calcolo con i tuoi numeri
- Scrivi l'elenco delle funzioni del flusso principale.
- Per ciascuna, chiedi al fornitore una stima in giornate, divisa in analisi, sviluppo e collaudo.
- Aggiungi il lavoro fisso: impostazione del progetto, accessi, rilascio, formazione, copie di sicurezza (spesso 8–15 giornate).
- Somma e aggiungi un 15–20% di margine per imprevisti.
- Moltiplica per la tariffa.
Cosa non tagliare mai (anche in un MVP)
Quando il budget è stretto, la tentazione è risparmiare su ciò che non si vede. Alcune voci, però, non sono "opzioni": sono ciò che rende utilizzabile un software minimo.
- Sicurezza di base. Accessi con credenziali, permessi essenziali, protezione dei dati personali. Un MVP con dati di clienti non può essere esposto.
- Copie di sicurezza e ripristino. Se i dati si perdono, il progetto è finito. Il costo è piccolo, il danno enorme.
- Un disegno dei dati ragionevole. È la parte più costosa da correggere dopo. Un'ora di progettazione in più oggi evita di rifare l'archivio tra sei mesi.
- Test sulle regole critiche. Non serve una copertura totale, ma i calcoli che riguardano denaro, quantità o scadenze devono essere verificati.
- Collaudo con utenti reali. Anche breve, anche con pochi utenti: è lì che emergono i problemi che nessuno aveva previsto.
- Documentazione minima. Cosa fa il sistema, come si installa, dove stanno i dati. Una pagina può salvare mesi di lavoro.
Cosa si può rimandare senza conseguenze: grafica rifinita, funzioni di comodo, statistiche avanzate, integrazioni non essenziali, ruoli secondari, app mobili, notifiche automatiche, personalizzazioni.
Come evitare di dover rifare tutto
Il timore più comune sull'MVP è "poi dovremo buttare via tutto". Non deve accadere, se si mantengono tre accortezze.
Un'architettura che può crescere. Il sistema va pensato in parti separate (dati, regole, interfaccia) in modo che aggiungere funzioni non richieda di riscrivere quelle esistenti. Un progettista esperto sa farlo anche in un progetto piccolo, senza renderlo complicato.
Un disegno dei dati con uno sguardo in avanti. Non serve prevedere tutto, ma evitare scelte che bloccano le evoluzioni probabili (per esempio un solo magazzino, quando è prevedibile che ce ne saranno due).
Tecnologie diffuse e mantenibili. Una scelta standard (come lo stack .NET per applicazioni aziendali) garantisce che altri professionisti possano proseguire il lavoro. Il codice scritto bene è una risorsa dell'azienda, non del singolo sviluppatore.
Al contrario, i modi più sicuri per dover rifare tutto sono: partire da un prototipo "che funziona quasi" e metterlo in produzione, tagliare analisi e progettazione, affidarsi a una sola persona senza documentazione.
I costi che arrivano dopo il rilascio
Anche un MVP ha un costo di esercizio:
- Hosting e infrastruttura. Per un'applicazione piccola può bastare qualche decina di euro al mese; con requisiti di disponibilità più alti, di più.
- Manutenzione correttiva. I difetti emersi con l'uso reale. Nei primi mesi sono più frequenti: è normale e va previsto.
- Evoluzioni. Se l'MVP funziona, le richieste di modifica arriveranno: è un buon segno, ma si pagano.
- Aggiornamenti tecnici. Le piattaforme su cui gira il software ricevono aggiornamenti di sicurezza.
Come regola indicativa, metti a budget, per il primo anno, tra il 15% e il 25% del costo di sviluppo. Un MVP "gratuito dopo la consegna" non esiste.
Come capire se l'MVP funziona
Un MVP serve a imparare, quindi serve sapere cosa misurare. Tre indicatori semplici, senza strumenti complicati:
- Viene usato? Quanti utenti lo aprono ogni giorno, quanti completano il flusso principale.
- Fa risparmiare qualcosa di concreto? Ore a settimana, errori evitati, tempi di risposta ai clienti. Meglio se confrontati con la situazione di partenza.
- Cosa chiedono gli utenti? Le richieste ricorrenti sono la mappa della seconda fase. Quelle che nessuno fa, non vanno costruite.
Fissa questi criteri prima del rilascio, non dopo: è il solo modo di non giudicare a sensazione.
Un esempio: l'MVP di un ufficio acquisti
Un'azienda manifatturiera gestisce gli ordini ai fornitori con un foglio di calcolo (la situazione descritta in Dall'Excel al software). Il problema principale: ordini duplicati e solleciti dimenticati. Il perimetro dell'MVP:
- Un problema: evitare ordini duplicati e dimenticati.
- Un utente: i tre addetti dell'ufficio acquisti.
- Un flusso: dalla richiesta d'acquisto alla conferma di consegna.
Dentro: richieste d'acquisto, ordini ai fornitori con stato, promemoria di scadenza, storico delle modifiche, accesso protetto, copie di sicurezza, esportazione per la contabilità. Fuori: integrazione con il magazzino, approvazioni a più livelli, portale per i fornitori, statistiche.
Stima: circa 45 giornate (analisi 6, progettazione 5, sviluppo 20, collaudo 8, coordinamento 4, rilascio e formazione 2). Con l'ipotesi di 450 euro: circa 20.000 euro, più 4.000–5.000 euro per il primo anno di esercizio e manutenzione. Dopo tre mesi di uso, si decide con dati veri se estendere al magazzino o ai fornitori.
È un esempio costruito per illustrare il ragionamento. Il tuo progetto avrà numeri diversi, ma le domande restano le stesse.
Il ruolo dell'intelligenza artificiale in un MVP
Gli assistenti di IA sono particolarmente utili nelle fasi iniziali: generare un prototipo per discutere con gli utenti, scrivere il codice ripetitivo, produrre una prima documentazione. Questo può accorciare i tempi e abbassare una parte dei costi di sviluppo.
Il rischio è la tentazione di usare il prototipo generato come se fosse l'MVP: funziona nella dimostrazione, ma mancano sicurezza, gestione degli errori, test e un disegno dei dati pensato. Il lavoro da fare per portare un prototipo a un MVP affidabile coincide, in larga parte, con il lavoro di un progetto normale. Ne parliamo in L'intelligenza artificiale non scrive il software al posto tuo.
Il punto: l'IA può rendere più economico arrivare al prototipo. Per trasformarlo in un sistema su cui un'azienda lavora, servono ancora le persone che analizzano, progettano, verificano e rispondono del risultato, come descritto in I ruoli di un progetto software.
Errori frequenti
Un MVP che cerca di servire tutti. Più utenti, più ruoli, più eccezioni: il perimetro cresce e non è più minimo. Meglio un gruppo ristretto che lo usa bene.
Nessuna data di verifica. Un MVP senza un momento in cui si decide "andiamo avanti, cambiamo o ci fermiamo" diventa un progetto che si trascina.
Chiamare "MVP" un progetto già deciso. Se si sa già tutto e si vuole tutto, è un progetto completo, e va preventivato come tale.
Scegliere il fornitore solo per il prezzo. Su un MVP il rischio di un fornitore poco esperto è alto: pochi mesi, poche persone, nessuna rete di sicurezza. Usa la checklist di valutazione.
Domande frequenti
Un MVP si può fare con un budget molto piccolo? Dipende da cosa significa "molto piccolo". Con poche migliaia di euro si fa un prototipo o uno strumento molto semplice. Un software che gestisce dati reali di un'azienda ha un costo minimo, dovuto al lavoro fisso (accessi, copie di sicurezza, rilascio), sotto il quale la qualità non è garantita.
Il codice dell'MVP si può riutilizzare per il prodotto completo? Sì, se è stato scritto con una struttura adeguata. È l'obiettivo di un buon MVP: la seconda fase aggiunge, non riscrive. Chiedi al fornitore di spiegarti come ha previsto la crescita.
Quanto tempo ci vuole? Un MVP piccolo richiede di norma da sei a dodici settimane dal via al rilascio, a patto che il referente risponda con rapidità. I tempi lunghi dipendono più dalle decisioni che dal codice.
Meglio un MVP o direttamente il progetto completo? Se il processo è incerto, gli utenti sono pochi o il budget va protetto, un MVP riduce il rischio. Se i requisiti sono chiari e stabili, procedere direttamente può essere più efficiente.
Come trovo un professionista adatto? Cerca chi ha già portato in produzione software simili e sa spiegare cosa metterebbe fuori. Per lo stack .NET, su LancerJob trovi sviluppatori freelance con profili che indicano stack ed esperienza. Per richiedere le offerte, usa il modello in Come scrivere una richiesta di progetto efficace.
In sintesi
- Un MVP è la parte più piccola di un software che risolve davvero un problema reale: funziona, usa dati veri, ed è fatto bene. Non è un prototipo né una versione scadente.
- Il perimetro si decide con tre vincoli: un problema, un tipo di utente, un flusso completo. Ogni funzione si giustifica con la domanda "senza questa, il flusso funziona?".
- Con 450 euro a giornata, un MVP piccolo ha un ordine di grandezza di 15.000–30.000 euro: molto più basso di un progetto completo, ma non gratuito, perché una parte del lavoro è fissa.
- Non si tagliano sicurezza, copie di sicurezza, disegno dei dati, test sulle regole critiche, collaudo e documentazione minima.
- Per non dover rifare tutto servono un'architettura che cresce, un disegno dei dati con uno sguardo in avanti e tecnologie diffuse.
- Metti a budget il primo anno di esercizio (15–25% dello sviluppo) e decidi in anticipo come misurare se l'MVP funziona.
- L'IA accorcia la strada verso il prototipo; per trasformarlo in un sistema affidabile servono ancora persone del mestiere.