Un MVP non è un'applicazione fatta male per spendere meno: è la più piccola che risponde alla domanda giusta. Come si sceglie quella domanda, che cosa si può gestire a mano all'inizio, e le tre cose che, se rimandate, costano il doppio dopo.
di Nadia Maar ·
Quasi tutti i progetti di software su misura partono troppo grandi. Non per ingordigia: perché quando si descrive un processo vengono in mente tutti i casi, e ogni caso sembra indispensabile. Il risultato è una prima versione che arriva tardi, costa più del previsto e viene usata a metà, perché nel frattempo il processo è cambiato.
L'alternativa non è costruire meno a caso. È costruire prima la parte che risponde alla domanda che conta — funziona davvero, per chi la userà? — e rimandare con criterio tutto il resto. Qui c'è il criterio.
Una prima versione utile si descrive in una frase: chi la usa, che cosa fa, che cosa ottiene. «Il commerciale inserisce un ordine dal telefono e il magazzino lo vede subito.» Tutto ciò che non serve a quella frase, nella prima versione, non c'è.
Se la descrizione della prima versione contiene la parola «anche» più di due volte — e anche i report, e anche l'esportazione, e anche le notifiche — non state descrivendo una prima versione: state descrivendo l'ultima.
La frase si capisce meglio vedendola applicata. Tre situazioni frequenti, con la prima versione che ha senso costruire e quello che, per ora, resta fuori:
| La frase della prima versione | Che cosa resta fuori, per ora |
|---|---|
| Il cliente B2B riordina dal portale gli articoli del suo ultimo ordine, con il suo listino. | Il catalogo completo, i pagamenti online, la chat con il commerciale. |
| Il magazziniere conferma dal telefono che un ordine è pronto, e l'ufficio lo vede spedibile. | L'inventario, la gestione dei resi, le statistiche di produttività. |
| Il commerciale compone un preventivo standard in pochi minuti, con i prezzi aggiornati. | Le varianti rare, la firma digitale, il collegamento con la contabilità. |
In ognuno dei tre casi la parte che resta fuori non è meno importante: è meno urgente, e si costruisce meglio dopo aver visto come viene usata la prima.
Una prima versione non deve fare tutto da sola. Molte parti possono, per un periodo, essere fatte a mano dietro le quinte — ed è il modo più economico per scoprire se valgono il costo di automatizzarle.
| Si può fare a mano | Perché conviene, all'inizio |
|---|---|
| I report | Un'esportazione e un foglio di calcolo bastano per capire quali numeri servono davvero, prima di costruire un cruscotto. |
| Le integrazioni rare | Un dato che cambia una volta al mese si può caricare a mano; lo si collega quando si sa che serve. |
| Le notifiche | Un'email mandata da una persona rivela quali avvisi contano e quali sono rumore. |
| I casi eccezionali | I pochi casi strani si gestiscono a mano, finché non si capisce quale diventa regola. |
Ci sono tre cose che una prima versione deve avere fatte bene, perché aggiungerle dopo costa molto più che farle subito. Non sono funzioni: sono fondamenta.
Sono le stesse tre cose che separano un sito da un'applicazione: identità, permessi, registro. Una prima versione può essere piccola in tutto, ma non in queste.
Una prima versione si costruisce meglio a piccoli passi visibili che con un unico rilascio finale. Il metodo che usiamo è semplice:
La prima versione ha funzionato se il numero della frase iniziale si è mosso — non se tutte le funzioni sono state consegnate. Da lì le strade sono tre:
Non è il software che consegna: è la decisione che permette di prendere, con pochi soldi ancora spesi. Un progetto che si ferma dopo la prima versione, perché i numeri dicevano di fermarsi, è un progetto riuscito.
Se riuscite a scriverla — chi la usa, che cosa fa, che cosa ottiene — metà del lavoro di progettazione è fatta. Se non ci riuscite, è il primo problema da risolvere, prima di qualunque preventivo.
L'audit gratuito parte proprio da lì: il processo che vi costa di più, la frase che lo descrive, e che cosa servirebbe per costruirne la prima versione. Ne esce una stima di costo e di rientro.
Sviluppo applicazioni web su misura
È la più piccola versione dell'applicazione che risponde alla domanda che conta: funziona davvero, per chi la userà? Una persona, un percorso, un risultato misurabile.
Report, integrazioni rare, notifiche e casi eccezionali si possono gestire a mano all'inizio, per capire quali valgono il costo di automatizzarli.
I permessi — chi vede che cosa —, la struttura dei dati e il registro di chi ha fatto che cosa. Aggiungerli dopo costa molto più che farli subito.
Dal numero che vi eravate dati all'inizio — minuti risparmiati, errori evitati, un passaggio che sparisce — non dal numero di funzioni consegnate.