Una buona prima versione contiene solo ciò che serve al processo principale per utenti reali, più protezione dei dati, diritti di accesso, backup e monitoraggio. Tutto il resto finisce in una lista per dopo. Questa decisione si prende prima della prima riga di codice ed è la più efficace dell’intero progetto. Un ambito ristretto le porta prima riscontri reali e protegge il suo budget da funzioni che poi nessuno usa.
Nel settore una versione del genere si chiama spesso MVP, abbreviazione di Minimum Viable Product. Noi diciamo prima versione, perché deve funzionare nell’uso quotidiano e poi continuare a crescere. Un prototipo, invece, serve a fare dimostrazioni e spesso viene scartato.
Parta dal risultato
Formuli in una frase che cosa dovrà essere possibile dopo l’avvio, ad esempio: una cliente può prenotare un appuntamento online e riceve una conferma. Tutto ciò che non serve a questo scopo diventa un candidato per dopo.
Scriva la frase dal punto di vista della persona che usa il prodotto. «Ci serve un portale clienti» descrive una soluzione. «Un cliente vede le sue fatture aperte senza dover telefonare» descrive un risultato, e su questa base si può verificare ogni funzione.
Tre domande per ogni funzione
- Il processo principale funziona anche senza questa funzione?
- Il passaggio si può svolgere a mano per il momento?
- Sappiamo con certezza che qualcuno ne ha bisogno, o lo supponiamo soltanto?
Se il processo principale funziona anche senza la funzione, se il passaggio si può svolgere a mano per il momento o se il bisogno è solo una supposizione, la funzione finisce nella lista per dopo. Questa lista non va persa: diventa la base per la seconda versione.
Un esempio: prenotazione di appuntamenti online
Prendiamo la prenotazione dell’appuntamento citata sopra come caso modello per un’azienda di servizi. Il processo principale ha bisogno di queste quattro funzioni:
- Mostrare gli appuntamenti liberi
- Scegliere l’appuntamento e inserire i dati di contatto
- Inviare la conferma per e-mail
- Mostrare le prenotazioni al suo team in una panoramica
Queste funzioni possono aspettare:
- Conto cliente con accesso, perché per iniziare basta la conferma per e-mail.
- Pagamento online, finché si può pagare sul posto.
- Collegamento al suo calendario, se per il momento il team riporta le prenotazioni a mano.
- Analisi, finché non ci sono abbastanza prenotazioni.
Quanto costa la prima versione e quanto tempo richiede
Una prima versione come applicazione web può partire dal pacchetto Strumento semplice con CHF 9'000 – 13'500. Un portale clienti costa CHF 28'000 – 42'000. Ogni funzione rinviata si vede direttamente sul conto. Un collegamento a ERP o software di settore costa da solo CHF 9'000 – 13'500 e allunga la tempistica di diverse settimane.
Se rinvia questo collegamento alla seconda versione, parte prima di conseguenza. Dovrà comunque pagarlo, ma deciderà con l’esperienza maturata in esercizio se e in quale forma le serve. Per la prenotazione di appuntamenti dell’esempio si può spesso fare ancora più in piccolo: un sito web con uno strumento di prenotazione integrato costa come funzione aggiuntiva CHF 100 – 170.
I valori provengono dalla nostra panoramica prezzi e valori indicativi per il software. L’articolo Quanto costa un’applicazione web in Svizzera? mostra alcuni casi modello. Per il software su misura, i pacchetti sono nell’articolo Quanto costa un software su misura?. È vincolante l’offerta che segue il colloquio.
Dove non tagliare
Anche la versione più piccola deve funzionare in modo sicuro e affidabile. Protezione dei dati, diritti di accesso, backup e monitoraggio in esercizio fanno parte di ogni versione, anche della prima. Aggiungerli in seguito è più costoso e più rischioso. Lo stesso vale per i test e per una breve documentazione, perché la seconda versione si basa su di essi.
Quando la prima versione deve essere più grande
A volte non si può fare più piccola. Se sostituisce un sistema esistente, la nuova versione deve saper fare tutto ciò che è indispensabile nel lavoro quotidiano, altrimenti il suo team lavora due volte. Nemmeno i requisiti legali o contrattuali si possono rinviare. In questi casi è utile una sostituzione a tappe: una parte del processo si trasferisce, il resto rimane per il momento nel vecchio sistema.
Tre trappole nel definire l’ambito
- Tutti dicono la loro e nessuno decide. Designi una persona che abbia l’ultima parola sull’ambito.
- I casi particolari tornano a far parte dell’ambito. Verifichi ogni caso particolare con le stesse tre domande usate per qualsiasi altra funzione.
- Poco prima dell’avvio spunta la frase «Già che ci siamo». Annoti il desiderio nella lista per dopo e mantenga la data di avvio.
Misuri prima di ampliare
Stabilisca prima dell’avvio come riconoscerà il successo: meno telefonate, più contratti conclusi, tempi di elaborazione più brevi. Annoti il valore attuale finché il vecchio processo è ancora in funzione. Così la seconda versione si baserà su osservazioni e non su supposizioni.
Il prossimo passo
Se riesce a formulare il risultato in una frase, ha già l’essenziale per un primo colloquio. Da SIMPLY CODE SOLUTIONS stabiliamo poi insieme che cosa serve per l’avvio e che cosa può aspettare. Può inviarci direttamente la richiesta per il suo progetto. Il nostro modo di procedere è descritto alla pagina sviluppo di applicazioni web. L’articolo Software su misura o software standard? chiarisce se un prodotto su misura conviene davvero.