MVP o prototipo: cosa sviluppare per primo

Un prototipo serve a mettere alla prova un’idea o un’interazione. Un prodotto minimo funzionante, o MVP (minimum viable product), permette a utenti reali di svolgere un compito utile, così da imparare dall’uso effettivo. Sviluppate un prototipo quando il design è incerto; sviluppate un MVP quando siete pronti a consegnare e a gestire un piccolo prodotto. Se l’incertezza è tecnica, può venire prima un proof of concept mirato.

Sono acquisti diversi. Una dimostrazione curata non comprende necessariamente la gestione dei dati, i permessi, il processo di rilascio o l’assistenza che servono a un prodotto funzionante. Prima di confrontare le proposte di sviluppo, indicate la domanda a cui volete che il lavoro risponda.

Prototipo, proof of concept e MVP a confronto

Le etichette cambiano da un team all’altro. Concordate il risultato atteso, invece di fidarvi del nome usato in una proposta.

Su uno schermo stretto, scorrete la tabella in orizzontale per leggere tutte le colonne.

Cosa si consegna	A quale domanda risponde	Cosa dovreste poter osservare	Cosa non dimostra
Prototipo	Gli utenti capiscono e riescono a completare questa interazione proposta?	Le persone provano un percorso limitato; vedete dove esitano o fraintendono.	Integrazioni affidabili, funzionamento in produzione o disponibilità a pagare.
Proof of concept	Un determinato approccio tecnico può funzionare entro i vincoli rilevanti?	Un esperimento circoscritto dimostra una capacità, come leggere da un fornitore i dati necessari.	Un prodotto completo o un’esperienza utilizzabile dal cliente.
MVP	Un piccolo prodotto funzionante può offrire il valore previsto ai primi utenti?	Utenti reali completano il compito principale; raccogliete feedback e osservate l’uso.	L’adeguatezza al mercato, un’acquisizione clienti redditizia o la prontezza per ogni futuro cliente.

Un prototipo può essere uno schizzo su carta, un design cliccabile o un’interfaccia programmata e limitata. La sua utilità sta in ciò che si impara, non nella quantità di codice. La guida GOV.UK sulla fase alpha (in inglese) fa la stessa distinzione pratica: mettere alla prova le ipotesi rischiose con prototipi, senza trattare il codice sperimentale come software di produzione.

Un MVP può essere offerto a un piccolo gruppo di invitati. Non ha bisogno di tutte le funzionalità, ma chi lo usa deve poter completare il compito promesso e ottenere aiuto quando qualcosa non funziona.

Scegliete il risultato più piccolo che risolve l’incertezza

Chiedetevi che cosa potrebbe rendere sprecato il prossimo impegno di sviluppo.

Il bisogno è incerto: parlate con gli utenti previsti e osservate il loro lavoro attuale. Né un prototipo né un MVP sostituiscono questa fase di ricerca, se il problema conta davvero.
L’interazione è incerta: usate un prototipo per provare i passaggi difficili. Potreste non aver bisogno di progettare l’intero prodotto per capire dove le persone si bloccano.
L’integrazione è incerta: realizzate un proof of concept con dati rappresentativi e accessi realistici. Una richiesta riuscita a un endpoint di prova non dimostra che l’intera integrazione sia pronta.
Il valore nell’uso reale è incerto: valutate un MVP con un percorso piccolo ma completo e un piano per osservare cosa succede dopo il rilascio.

Non siete obbligati ad acquistarli tutti e tre in sequenza. Se il flusso è già chiaro e la tecnologia è consolidata, un prototipo separato può aggiungere poco. Se un’integrazione necessaria non può funzionare, costruire prima il resto del prodotto è l’ordine sbagliato.

Un’idea di prenotazione, tre ambiti di lavoro diversi

Pensate a un ipotetico prodotto di prenotazione. I clienti devono scegliere un appuntamento disponibile, ricevere una conferma e modificare la prenotazione se serve. È un esempio illustrativo, non un risultato ottenuto per un cliente di AL+.

Un prototipo potrebbe mostrare la scelta dell’appuntamento, la schermata di conferma e il percorso di annullamento. Verificate se le persone capiscono le scelte e se il personale riesce a usare la vista amministrativa proposta. Appuntamenti e conferme possono essere simulati, purché lo si spieghi ai partecipanti.

Un proof of concept potrebbe esaminare il fornitore del calendario. L’applicazione può leggere la disponibilità, creare una prenotazione e riconoscere una modifica in conflitto, con gli accessi che l’azienda può ottenere? Documentate cosa ha verificato l’esperimento, l’ambiente usato e cosa resta non verificato.

Un MVP potrebbe permettere a un gruppo limitato di fare prenotazioni reali per un servizio in una sede. Servirebbero anche le regole pertinenti su fusi orari, conflitti, annullamenti, accesso del personale e recupero dopo un guasto. Una grande dashboard di reportistica può aspettare; impedire che due persone prenotino lo stesso orario, no.

La decisione riguarda l’incertezza e il risultato promesso. «Solo cinque schermate» non basta a distinguere questi ambiti.

Un brief da usare prima di chiedere un preventivo

Compilate queste sei righe. Se non riuscite a rispondere a una, registratela come domanda aperta invece che come ipotesi.

Utente e compito: chi deve fare cosa, e cosa fa oggi?
Domanda a cui rispondere: quale incertezza deve risolvere questo lavoro?
Cosa consegnare: prototipo, esperimento tecnico o primo rilascio funzionante; spiegate perché.
Prova di completamento: quale comportamento o osservazione vi permetterebbe di accettare il lavoro?
Ambito di lavoro ed esclusioni: quali utenti, dispositivi, integrazioni e casi di errore sono inclusi; cosa può aspettare?
Prossima decisione: cosa farete se il risultato conferma l’idea, la smentisce o non è conclusivo?

Per l’esempio della prenotazione, una frase di accettazione potrebbe essere: «Un cliente invitato può prenotare un orario davvero disponibile, ricevere la conferma e annullarla; il personale vede la modifica». Descrive il comportamento del prodotto. «L’app ha una schermata di prenotazione» descrive un’interfaccia e lascia irrisolto il lavoro importante.

Usate la guida al costo di sviluppo di un MVP (in inglese) per confrontare le stime della stessa consegna e delle stesse esclusioni.

Di cosa ha ancora bisogno un MVP dopo aver ridotto l’elenco delle funzionalità

Un ambito ridotto non elimina le responsabilità che nascono con utenti e dati reali. Individuate quali valgono per voi prima del lancio:

Regole di accesso e corretta gestione delle informazioni che il prodotto conserva.
Un processo di rilascio ripetibile e il controllo del repository e degli account dei servizi.
Un modo per accorgersi dei guasti e recuperare il lavoro o i dati importanti.
Un contatto per l’assistenza e qualcuno responsabile del rilascio successivo.
Un piano per raccogliere feedback che alimenti una specifica decisione sul prodotto.

Questi requisiti devono corrispondere al rilascio effettivo. Non aggiungete infrastruttura per una scala immaginaria, ma non tralasciate un percorso di recupero per informazioni che non potete permettervi di perdere. La guida GOV.UK sulla fase beta (in inglese) offre un modello utile: invitare un gruppo limitato, imparare dall’uso reale e pianificare la capacità di sostenere quell’apprendimento.

Si può trasformare un prototipo in un MVP?

A volte sì. Prima verificate che cosa contiene davvero il prototipo. L’interfaccia può essere riutilizzabile, mentre dati simulati, autenticazione provvisoria o configurazioni solo locali vanno sostituiti. Il codice scritto per un esperimento può costare meno da scartare che da rendere affidabile.

Chiedete allo sviluppatore di separare il lavoro riutilizzabile, il lavoro di produzione che manca e le ipotesi non risolte. Un prototipo realizzato con l’AI richiede la stessa revisione; una dimostrazione convincente prova che la dimostrazione funziona, non che il prodotto sia pronto per i clienti.

Parliamo del prossimo rilascio utile

AL+ offre lo sviluppo di MVP a chi avvia un’attività e ha bisogno di un primo percorso completo e di una proprietà chiara dopo il lancio. Inviateci il brief di sei righe, l’eventuale prototipo esistente e i vincoli di budget o di tempo.

Scrivete ad AL+ del vostro prototipo o MVP. Potremo discutere quale tipo di consegna risponde alla domanda a cui dovete rispondere.