Sviluppo Software per Milestone: Come Funziona

Chi commissiona un software per la prima volta spesso vive la stessa esperienza: si firma un preventivo, passano mesi in cui si vede poco e alla fine arriva qualcosa di diverso da quello che si aveva in mente. Di solito nessuno ha lavorato male. In un progetto lungo le idee cambiano, i dettagli emergono strada facendo e manca un momento in cui controllare la direzione.

Lavorare per milestone serve a evitare proprio questo. Il progetto viene diviso in tappe brevi, ognuna con un risultato che puoi provare e approvare prima di andare avanti. In questa guida spieghiamo come funziona, come si scrivono milestone utili e quali segnali indicano che un progetto sta perdendo la strada.

Cos’è una milestone (e cosa non è)

Una milestone è un pezzo di software funzionante, concordato prima di iniziare, con una data di demo e dei criteri per dire se è stato completato. La parola chiave è funzionante: alla fine della milestone c’è qualcosa che si può aprire, usare e verificare.

Una milestone non è una percentuale di avanzamento. «Backend al 60%» non dice nulla a chi dovrà usare il software, e nessuno può controllarlo. Confronta queste due formulazioni:

Poco utile: «Completata la parte database e metà delle API».
Utile: «Un utente dell’ufficio può inserire un ordine, modificarlo e vederlo nell’elenco, e il magazzino vede solo gli ordini confermati».

La seconda si può provare durante una demo in dieci minuti. Se funziona, la milestone è chiusa. Se qualcosa non va, lo si vede subito.

Perché le milestone proteggono chi commissiona il software

Il vantaggio principale è semplice: vedi il software crescere, invece di immaginarlo. Da qui derivano altri benefici molto concreti.

I problemi emergono presto. Un campo mancante o un flusso sbagliato scoperto alla seconda demo costa poco da correggere. Scoperto a fine progetto può costare settimane.
Il budget resta sotto controllo. Sai quanto è stato fatto e quanto manca, misurato in funzioni consegnate e non in ore spese.
Cambiare idea costa meno. Tra una milestone e l’altra si possono spostare le priorità, sulla base di quello che hai visto.
Il rischio si riduce. Se per qualsiasi motivo il progetto si ferma dopo la terza milestone, hai comunque un software funzionante e il relativo codice, invece di un lavoro a metà.
Partecipa chi userà il software. Le demo sono il momento giusto per coinvolgere chi lavora ogni giorno con il processo: spesso nota cose che nessun documento aveva previsto.

Come si definiscono le milestone

Le milestone si definiscono all’inizio, durante l’analisi, insieme a chi commissiona il progetto. Questi sono i criteri che usiamo.

Partire dagli utenti e dai processi. Chi userà il software, per fare cosa, e cosa succede oggi senza di esso.
Arrivare presto a una prima versione utile. La prima milestone dopo il prototipo dovrebbe già risolvere una parte reale del problema, anche piccola.
Affrontare prima le parti rischiose. Un’integrazione con un sistema esterno o un calcolo complicato va verificato all’inizio, quando c’è ancora tempo per cambiare strada.
Tenerle brevi. In genere una milestone corrisponde a poche settimane di lavoro. Se dura molto di più, si torna al problema di partenza: troppo tempo senza vedere nulla.
Scrivere i criteri di accettazione. Per ogni milestone, una lista breve di cose da verificare alla demo. Ne parliamo più avanti.

Un esempio: un gestionale per gli ordini

Ecco come potrebbe essere divisa la realizzazione di un gestionale web per un’azienda che oggi gestisce gli ordini con fogli Excel ed email. È un esempio indicativo: numero e contenuto delle milestone dipendono dal progetto.

Esempio di piano per milestone (indicativo)
Milestone	Cosa vedi alla demo	Come si verifica
1. Prototipo navigabile	Le schermate principali cliccabili, senza dati reali.	Chi userà il sistema percorre i flussi principali e conferma campi e passaggi.
2. Accessi e anagrafiche	Login, ruoli, schede clienti e prodotti, con dati importati da un file di prova.	Ogni ruolo vede solo ciò che gli compete; l’importazione del file non perde righe.
3. Gestione ordini	Creazione, modifica e stati dell’ordine, con email automatiche.	Un ordine di prova passa da «nuovo» a «spedito» e il cliente riceve le email previste.
4. Report e integrazioni	Report mensili, esportazione dei dati e collegamento al programma di contabilità.	I totali del report coincidono con quelli calcolati a mano su un mese campione.
5. Messa in produzione	Il sistema online con i dati reali e le persone formate.	L’ufficio lavora una settimana solo con il nuovo gestionale, senza tornare ai fogli Excel.

Alla fine della milestone 3 l’azienda ha già un sistema che sostituisce l’email per gli ordini. Se a quel punto le priorità cambiano, per esempio perché un cliente importante chiede un portale, si può decidere di anticipare un’altra funzione.

La demo: il momento più importante

A ogni milestone mostriamo il software funzionante in un ambiente di prova, non delle slide o degli screenshot. Chi partecipa prova le funzioni con dati verosimili e annota cosa non torna.

Dopo la demo le strade sono tre:

Approvata: i criteri sono rispettati e si passa alla milestone successiva.
Approvata con correzioni: piccoli difetti da sistemare, che non bloccano il lavoro successivo.
Da rivedere: qualcosa di importante non funziona come concordato e va corretto prima di proseguire.

Un consiglio pratico: alla demo porta chi userà davvero il software. Il responsabile del progetto vede se le funzioni ci sono; chi inserisce cinquanta ordini al giorno vede se il lavoro è più veloce o più lento di prima.

Criteri di accettazione: scriverli prima

I criteri di accettazione sono frasi semplici che descrivono cosa deve succedere perché una milestone sia considerata completa. Si scrivono prima di iniziare la milestone, così entrambe le parti sanno cosa aspettarsi.

Devono essere verificabili. Qualche esempio:

Invece di «la ricerca deve essere veloce»: «con 10.000 ordini, la ricerca per cliente mostra i risultati in meno di due secondi».
Invece di «gestione dei permessi»: «un utente del magazzino non può modificare i prezzi».
Invece di «import dei dati»: «il file clienti di prova viene importato senza errori e i duplicati vengono segnalati».

Criteri scritti così evitano la discussione più frustrante di un progetto software: «pensavo fosse incluso».

Quando le cose cambiano

Durante un progetto i cambiamenti sono normali, e spesso sono un buon segno: vuol dire che il software in uso ha fatto emergere esigenze reali. Il problema nasce quando i cambiamenti entrano senza che nessuno ne valuti l’effetto su tempi e costi.

Per questo ogni nuova richiesta viene annotata e valutata. Di solito le possibilità sono:

inserirla nella milestone in corso, se è piccola e non sposta la data della demo;
spostarla in una milestone successiva;
sostituire un’altra funzione meno importante, per restare nello stesso budget;
aggiungerla al progetto, con una stima di tempo e costo da approvare.

Quello che conta è che la decisione sia presa insieme e messa per iscritto.

Segnali che un progetto sta perdendo la strada

Che il progetto sia seguito da noi o da altri, questi segnali meritano una conversazione:

da settimane non vedi software funzionante, solo aggiornamenti a parole;
l’avanzamento è comunicato in percentuali («siamo all’80%»);
non esistono criteri di accettazione scritti;
le demo mostrano schermate statiche invece del software in esecuzione;
le nuove richieste vengono accettate senza parlare di tempi e costi;
non hai accesso al codice né a un ambiente di prova.

Milestone, pagamenti e contratto

Le milestone si prestano bene anche alla parte economica. Una formula diffusa prevede un acconto all’avvio e un pagamento all’approvazione di ciascuna milestone: chi commissiona paga per risultati verificati, chi sviluppa ha un flusso di lavoro e di pagamenti prevedibile. È un’opzione da concordare nel contratto, insieme a cosa viene consegnato a ogni tappa.

Nel contratto conviene definire anche l’accesso al repository del codice, la proprietà del codice e cosa succede se il progetto si interrompe. Sono dettagli che si spera di non dover usare, ma rendono il rapporto più sereno.

Come lavoriamo in Kineto Soft

Ogni progetto parte da un’analisi dei processi e da un prototipo navigabile. Poi lavoriamo per milestone concordate, con una demo del software funzionante a ogni tappa e aggiornamenti regolari tra una demo e l’altra. Proprietà del codice, accesso al repository e passaggio di consegne sono definiti nel contratto.

Lavori direttamente con lo sviluppatore che scrive il codice, quindi le domande fatte alla demo trovano risposta subito. Questo modo di lavorare vale per i gestionali e le applicazioni web, per le app mobile e per i prodotti SaaS.

Domande frequenti

Quanto dura una milestone?

Dipende dal progetto, ma in genere poche settimane di lavoro. L’obiettivo è non passare mai troppo tempo senza vedere software funzionante.

Cosa succede se una milestone non viene approvata?

Si correggono i punti che non rispettano i criteri di accettazione concordati e si ripete la verifica. Per questo i criteri si scrivono prima: rendono chiaro cosa va sistemato.

Posso fermare il progetto dopo una milestone?

Sì, se il contratto lo prevede. Anche in quel caso hai un software funzionante e il codice delle milestone completate, invece di un lavoro a metà.

Lavorare per milestone costa di più?

Le demo richiedono un po’ di tempo in più rispetto a lavorare senza interruzioni, ma riducono il rischio di dover correggere a fine progetto errori scoperti tardi, che di solito costano molto di più.

Che differenza c’è con un progetto a prezzo fisso?

Le due cose si possono combinare: un prezzo concordato per ogni milestone, con perimetro e criteri definiti. Le richieste nuove si valutano a parte, così il prezzo resta legato a ciò che è stato concordato.

Vuoi pianificare il tuo progetto per milestone?

Raccontaci cosa deve fare il software e chi lo userà. Ti proponiamo una prima divisione in milestone, con cosa vedrai a ogni demo e una stima per ciascuna tappa.

Parliamo del tuo progetto