Come sviluppare un MVP: cosa entra e cosa resta fuori

Un MVP si sviluppa scegliendo un percorso completo che porta un risultato utile a un solo tipo di utente, tagliando tutto ciò che non serve a far funzionare quel percorso una volta, e mettendolo in mano a utenti veri il prima possibile. Prima si scrive l'ipotesi da verificare e il criterio che dirà se è confermata, poi si costruisce: l'ordine inverso produce software corretto che non risponde a nessuna domanda. La decisione difficile non è tecnica, è cosa lasciare fuori.

Se hai un'idea già verificata e ora devi decidere cosa entra nella prima versione, questa guida ti dà il metodo per fissare il perimetro, l'ordine dei passi e la soglia oltre la quale puoi far entrare persone che non conosci.

Cosa serve prima di iniziare

• Un'ipotesi scritta in una riga, con un criterio di successo. Non "voglio un'app per le prenotazioni", ma "i titolari di palestra con meno di trecento iscritti accetteranno di gestire i rinnovi da uno strumento nuovo: sarà confermato se sei su dieci lo usano ancora dopo tre settimane". Se non hai ancora questa riga, il passo che ti manca è a monte: come validare un'idea di software.
• Un tipo di utente solo. Un MVP che serve il titolare, il dipendente e il cliente finale è tre prodotti e nessuna risposta. Scegli quello che ha il problema più caro e ignora gli altri, per ora.
• Una lista di funzioni con un ordine, non con delle priorità. Numerate da 1 a N, senza pari merito e senza la categoria "importante". L'ordine è la decisione: le etichette servono a rimandarla.
• Il nome di chi decide. Una persona, con la facoltà di dire no a una richiesta senza convocare nessuno. Sui progetti piccoli il tempo si perde quasi sempre in approvazioni in attesa.
• Un tetto di spesa dichiarato e una data entro cui la risposta serve. Il tetto definisce quanto puoi sbagliare, la data impedisce che il perimetro cresca di settimana in settimana. Senza nessuno dei due, aspetta: partire senza limiti è il modo più rapido per finire il budget prima del primo utente.

Come si scegliono le funzioni del primo rilascio

Il criterio è uno: un utente deve poter arrivare dall'inizio alla fine di un compito senza che tu intervenga a mano. Tutto ciò che sta su quella linea entra, tutto il resto aspetta. È una regola scomoda, ma è l'unica che produce un prodotto usabile invece di cinque metà.

Provala su un esempio: Marta gestisce uno studio di fisioterapia e vuole che i pazienti prenotino da soli. Il percorso completo è "il paziente apre il link, vede gli orari liberi, prenota, riceve la conferma": tutto ciò che non sta su questa linea non serve.

Le celle vuote sono la parte importante della tabella: sono le funzioni che nella prima versione non esistono e che quasi tutti provano a recuperare "tanto costa poco". Il pannello di amministrazione è la tentazione più forte: nelle prime settimane gli utenti sono dieci e le operazioni straordinarie si fanno a mano in due minuti. Scrivere l'elenco delle esclusioni nero su bianco serve esattamente come nel capitolato di un software su misura: è il documento che tiene fermo il perimetro quando arrivano le richieste in corsa.

I passi dello sviluppo, in ordine

1. Scrivi l'ipotesi e il criterio di successo su una pagina sola. Una riga per l'ipotesi, una per il numero che la conferma, una per la data. Il risultato atteso è un foglio che puoi rileggere fra un mese per sapere se hai vinto o perso, senza reinterpretare nulla.
2. Disegna il percorso schermata per schermata, prima di scrivere codice. Anche a mano: una casella per schermata, una freccia per ogni azione possibile, e le parole esatte che l'utente leggerà. Alla fine devi avere tre o quattro caselle e nessuna freccia che finisce nel vuoto. Qui si tagliano le funzioni gratis, mentre dopo costano.
3. Scegli uno stack noioso e documentato. Un linguaggio e un framework con dieci anni di domande e risposte pubbliche, un database relazionale, un servizio di pubblicazione gestito. Il risultato atteso è che qualsiasi sviluppatore entri nel progetto senza una settimana di studio e che nessun problema sia inedito.
4. Costruisci il percorso completo prima di ogni rifinitura. Il primo obiettivo è che un utente vada da capo a fondo, anche con schermate grezze. Il risultato atteso è una versione brutta ma attraversabile: da lì in poi ogni miglioramento è misurabile, prima è solo opinione.
5. Metti dentro dal primo giorno il minimo di sicurezza e tracciamento. Dati di accesso conservati come si deve, permessi verificati sul server e non solo nel browser, separazione dei dati fra utenti, log degli errori con notifica, backup automatico e provato una volta, e una misura di cosa fanno gli utenti passo per passo. Il risultato atteso è che tu venga a sapere di un problema da un avviso, non da una telefonata.
6. Provalo con 5 o 10 utenti veri, uno alla volta. Non amici: persone del segmento. Dai un compito e stai in silenzio. Il risultato atteso è l'elenco dei punti in cui si fermano, ordinato per frequenza.
7. Decidi sulla base di quello che fanno, non di quello che dicono. Guarda quanti arrivano in fondo, quanti tornano una seconda volta, dove si interrompono. I commenti spiegano i numeri, non li sostituiscono. Il risultato atteso è una decisione scritta: consolidare, cambiare percorso o fermarsi.

Quando un MVP è pronto per utenti veri

Questa lista è la soglia che separa un prototipo da un prodotto. Un prototipo si mostra in una demo guidata, un prodotto si consegna e resta acceso da solo.

• Il percorso completo funziona senza nessun intervento manuale, comprese la creazione dell'utente e la conferma finale.
• I dati sono al sicuro: accessi separati per utente, nessun dato personale visibile a chi non deve vederlo, backup automatico che hai provato a ripristinare almeno una volta.
• Sai misurare se l'utente arriva in fondo, con un conteggio per ogni passo del percorso.
• Esiste un modo per ricevere segnalazioni che non sia il tuo numero di telefono, e qualcuno le legge ogni giorno.
• Sai quanto costa tenerlo acceso ogni mese e come cambia se gli utenti diventano cento.

Se una voce manca, il lavoro non è sbagliato: quello che hai va mostrato, non consegnato. Il passaggio da prototipo a software che regge utenti esterni è un lavoro a sé, con i suoi controlli: lo trovi nella roadmap da MVP a produzione.

Errori comuni

Chiamare MVP la versione 1.0 completa. È l'errore che costa di più: si costruisce per sei mesi tutto quello che il prodotto avrà, si finisce il budget e il primo utente arriva quando non ci sono più soldi per correggere. Rimedio: fissa il tetto di spesa per il primo rilascio a una frazione del totale e considera speso il resto solo dopo il primo dato.

Tagliare la sicurezza o i backup invece delle funzioni. Sono le voci che non si vedono, quindi sono le prime a saltare. Ma un dato di un utente vero perso o esposto chiude la verifica e apre un problema diverso. Rimedio: quando devi rientrare nei tempi, togli una funzione dall'elenco numerato, non una riga della lista di controllo.

Costruire il pannello di amministrazione prima del percorso dell'utente. È comodo perché lo specifichi da solo, senza dipendere da nessuno, e dà la sensazione di avanzare. Rimedio: nelle prime settimane le operazioni interne si fanno a mano, e il pannello si scrive quando il tempo che ti costa supera mezza giornata a settimana.

Quanto tempo serve e il passo successivo

Gli ordini di grandezza, quando l'ipotesi è già scritta: una settimana per il perimetro e il disegno delle schermate, da quattro a otto settimane per costruire il percorso completo con il minimo di sicurezza e misurazione, due o tre settimane per la prova con i primi utenti e la decisione. Quello che allunga i tempi non è quasi mai la parte tecnica: è un perimetro che cresce durante lo sviluppo e un tipo di utente non scelto fino in fondo. Sulle voci che compongono la spesa valgono le stesse regole di qualsiasi sviluppo su misura: contano le persone coinvolte e le settimane.

Il passo successivo, se hai l'ipotesi e la lista ordinata, è scrivere le due pagine del perimetro con l'elenco delle esclusioni e portarle a chi svilupperà: è lì che l'idea diventa stimabile. Se l'ipotesi non c'è ancora, torna alla verifica prima di spendere: chi non ha una domanda da verificare non ha bisogno di un MVP, e lo diciamo volentieri prima di un preventivo. Se la domanda ce l'hai, puoi vedere come lavoriamo sullo sviluppo software su misura.