# Il nostro metodo in 4 fasi (e perché la prima è la più importante)

> Diagnosi, architettura, sviluppo a sprint, go-live: come trasformiamo un problema aziendale in software che funziona.

- **URL**: https://www.spsproject.net/il-nostro-metodo-in-4-fasi-e-perche-la-prima-e-la-piu-importante/
- **Autore**: Anna De Carolis
- **Pubblicato**: 17/09/2026
- **Categorie**: Sviluppo Software

---

Quasi tutti i progetti software che vanno storti hanno una cosa in comune: sono partiti dalla soluzione. Qualcuno aveva già deciso che serviva un’app, un portale o un gestionale nuovo, e da lì in poi si è solo costruito. Il nostro metodo parte un passo prima, dal problema. Le **fasi di sviluppo di un software su misura**, per come le facciamo noi, sono quattro: diagnosi, architettura, sviluppo a sprint e go-live. Te le raccontiamo una per una, con quello che succede davvero e con quello che resta in mano a te alla fine di ciascuna.

Non è un metodo inventato per sembrare ordinati. È il modo che abbiamo trovato per togliere le sorprese dove costano di più.

## Le 4 fasi di sviluppo di un software su misura, in breve

- **Diagnosi.** Capire il problema con abbastanza precisione da riconoscerlo quando sarà risolto. Qui si decide cosa fare, e sopratutto cosa non fare.
- **Architettura.** Scegliere dove vivono i dati, come si parla con i sistemi che hai già, con quali tecnologie e in che ordine si costruisce.
- **Sviluppo a sprint.** Blocchi di lavoro di due settimane, con una demo ogni settimana sul software vero, non su una presentazione.
- **Go-live.** Il passaggio in produzione: dati migrati, collaudo, formazione, e la consegna di codice sorgente e documentazione.

Detta così sembra la sequenza che trovi in qualsiasi manuale. La differenza sta nel peso che diamo a ciascuna fase, e nella prima ci passiamo più tempo di quanto la maggior parte dei clienti si aspetti.

## Fase 1: la diagnosi, e perché è la più importante

Nella diagnosi non si parla di tecnologie. Si guarda come lavora l’azienda oggi, con le persone che il problema lo vivono ogni giorno: chi ricopia i dati da un programma all’altro, chi tiene il file Excel che nessun altro sa aggiornare, chi risponde al telefono quando un ordine si perde per strada.

Da queste conversazioni tiriamo fuori tre cose, scritte nero su bianco:

- **Qual è il problema**, descritto in modo che tutti in azienda lo riconoscano allo stesso modo.
- **Chi lo subisce**, con ruoli precisi e non con uffici generici.
- **Quanto costa lasciarlo com’è**, in ore, errori, clienti scontenti o opportunità perse.

Poi mettiamo in dubbio l’idea di partenza. Ogni funzione richiesta passa da una domanda semplice: cosa succede se non la facciamo? Quelle che reggono entrano nel progetto, le altre aspettano. Abbiamo raccontato questo passaggio nel dettaglio in [perché spendiamo i primi giorni a mettere in dubbio il tuo progetto](https://www.spsproject.net/perche-spendiamo-i-primi-giorni-a-mettere-in-dubbio-il-tuo-progetto/).

Il motivo per cui la diagnosi pesa più delle altre fasi è quasi aritmetico. Un errore di comprensione scoperto qui si corregge con una riunione. Lo stesso errore scoperto durante lo sviluppo costa settimane di codice da rifare. Scoperto dopo il go-live, costa anche la fiducia delle persone che dovevano usare il software e hanno smesso.

> Tutto quello che decidiamo male nella diagnosi lo paghiamo in ogni fase successiva. Tutto quello che decidiamo bene lo ritroviamo gratis.

Ogni tanto la diagnosi arriva a una conclusione scomoda: il software nuovo non serve, basta sistemare un processo o collegare due strumenti che hai già. Succede, e lo diciamo. È lo stesso ragionamento di [quando non ti serve un’app](https://www.spsproject.net/quando-non-ti-serve-unapp-e-cosa-ti-serve-davvero/): meglio un progetto più piccolo che funziona di uno grande che nessuno usa.

**Cosa ti resta in mano:** un documento con il problema, le priorità, i vincoli e la soluzione consigliata, più una roadmap con un preventivo diviso per fasi. È lo stesso lavoro che facciamo nella [consulenza e analisi dei progetti software](https://www.spsproject.net/consulenza-e-analisi-progetti/), e resta tuo anche se decidi di non andare avanti con noi.

## Fase 2: l’architettura, le decisioni che non si vedono

L’architettura è la fase che il cliente vede meno e che condiziona di più la vita del software nei prossimi anni. Qui si prendono decisioni come queste:

- **Dove vive ogni dato.** Se un’anagrafica esiste sia nel gestionale sia nel nuovo software, uno dei due deve avere l’ultima parola. Deciderlo adesso evita anni di dati che non tornano.
- **Come ci si collega a quello che c’è già.** Gestionale, e-commerce, CRM, macchinari: cosa si integra, in che direzione passano le informazioni, cosa succede quando uno dei sistemi non risponde.
- **Con quali tecnologie.** Scegliamo strumenti diffusi e supportati nel lungo periodo, non linguaggi esotici o framework fatti in casa. Il criterio è semplice: domani un altro professionista deve poterci mettere le mani senza ricominciare da zero.
- **In che ordine si costruisce.** Prima le parti che sbloccano valore o che nascondono più rischio, poi il resto. Ogni blocco diventa una milestone con un risultato verificabile.

È anche il momento in cui si prepara l’ambiente di staging: una copia del software separata da quella di produzione, dove vedrai e proverai ogni avanzamento senza toccare il lavoro quotidiano dell’azienda.

**Cosa ti resta in mano:** lo schema dell’architettura con le scelte motivate, l’elenco delle integrazioni e un piano di milestone con tempi e costi collegati a ciascuna.

![Demo settimanale durante lo sviluppo a sprint di un software su misura](https://www.spsproject.net/wp-content/uploads/2026/09/corpo-fasi-sviluppo-software-su-misura.jpg)

## Fase 3: sviluppo a sprint, con una demo ogni settimana

Lo sviluppo procede a sprint di due settimane. Ogni sprint ha un obiettivo concordato prima di iniziare, e dentro ogni sprint ci vediamo una volta a settimana per una demo.

La demo settimanale non è un aggiornamento a voce e non sono slide. È il software vero, aperto in staging, con le funzioni costruite in quei giorni. Chiediamo che ci sia anche chi lo userà tutti i giorni, non solo chi ha firmato il preventivo, perché sono quelle persone ad accorgersi subito che un campo è nel posto sbagliato o che manca un passaggio che in ufficio si fa da sempre.

Una settimana è abbastanza lunga per mostrare qualcosa di concreto e abbastanza corta perché un fraintendimento costi pochi giorni di lavoro, non un mese. Se qualcosa non va nella direzione giusta, te ne accorgi mentre è ancora facile correggerla.

> Una demo a settimana vuol dire che il progetto non può allontanarsi da quello che ti serve per più di sette giorni senza che tu lo veda.

Durante le demo nascono inevitabilmente idee nuove. Le accogliamo, ma non le infiliamo nello sprint in corso «già che ci siamo». Ogni richiesta nuova viene scritta, valutata per impatto su tempi e costi, e decidi tu se e quando farla entrare. È così che il perimetro resta sotto controllo senza diventare rigido.

**Cosa ti resta in mano:** un software che puoi provare in qualsiasi momento, un elenco aggiornato di cosa è fatto e cosa manca, e nessuna scoperta rimandata alla fine del progetto.

## Fase 4: il go-live, cioè il giorno in cui il software diventa tuo

Il passaggio in produzione è un lavoro a sé, non un clic. Comprende:

- **La migrazione dei dati** dal sistema precedente, aggiornati fino all’ultimo momento utile.
- **Il collaudo con dati reali**, fatto insieme alle persone che useranno il software, sui casi di tutti i giorni e su quelli che capitano una volta al mese.
- **La formazione** di chi lo userà, e l’affiancamento nei primi giorni, quelli in cui le domande arrivano tutte insieme.
- **La consegna** del codice sorgente completo, della documentazione tecnica e degli accessi.

Dopo il go-live il software ha bisogno di manutenzione, come qualsiasi strumento di lavoro. La concordiamo in modo flessibile, sulla base di quanto il sistema è critico per l’azienda. Se ti interessa capire come ogni fase pesa sul costo finale, lo abbiamo scomposto in [cosa c’è davvero dentro il prezzo di un software su misura](https://www.spsproject.net/cosa-ce-davvero-dentro-il-prezzo-di-un-software-su-misura/).

## Trasparenza e controllo: cosa resta sempre a te

Un metodo ordinato serve a poco se il cliente resta fuori dalla stanza. Per questo, lungo tutte le fasi di sviluppo del software su misura, alcune cose non sono in discussione:

- **Il codice sorgente è tuo.** Nessun canone di licenza e nessun vendor lock-in: puoi farlo evolvere con noi o con chi preferisci.
- **La documentazione esiste.** Scritta per chi verrà dopo di noi, con il perché delle scelte e non solo il come.
- **Gli accessi e i dati sono tuoi.** Server, domini, servizi esterni: intestati all’azienda, non a noi.
- **Vedi il lavoro mentre avanza.** Staging sempre disponibile, demo ogni settimana, milestone con risultati verificabili.
- **I costi sono legati alle fasi.** Sai in anticipo quanto costa ogni blocco, e le richieste nuove passano da una tua decisione.

Sul tema della proprietà del codice abbiamo scritto un articolo intero, perché è la domanda che conta di più quando si sceglie un fornitore: [ma poi ci sarete ancora?](https://www.spsproject.net/ma-poi-ci-sarete-ancora-la-domanda-piu-importante/)

## Perché lavoriamo così

Lavoriamo da Castelnuovo del Garda con aziende del Veneto e del Nord Italia, e il metodo è sempre lo stesso anche quando il progetto cambia completamente: un gestionale, un’integrazione fra sistemi, un’app per chi lavora in produzione. Le quattro fasi si adattano alla dimensione del lavoro, ma l’ordine no.

Il senso è tutto qui: spostare le decisioni difficili all’inizio, quando costano poco, e rendere visibile tutto il resto mentre succede. Il software che funziona non nasce da una grande idea scritta bene. Nasce da un problema capito bene, e da tante piccole verifiche fatte presto. Se vuoi vedere come il metodo si applica ai diversi tipi di progetto, trovi tutto nella pagina dei nostri [servizi di sviluppo software su misura](https://www.spsproject.net/servizi/).

## Domande frequenti

### Quali sono le fasi di sviluppo di un software su misura?

Nel nostro metodo sono quattro: diagnosi del problema, architettura, sviluppo a sprint e go-live. La diagnosi decide cosa costruire e cosa lasciare fuori, l'architettura stabilisce dove vivono i dati e come ci si collega ai sistemi esistenti. Lo sviluppo procede a blocchi di due settimane con una demo ogni settimana, e il go-live chiude con migrazione dei dati, collaudo, formazione e consegna di codice e documentazione.

### Perché la fase di analisi iniziale è così importante in un progetto software?

Perché ogni errore di comprensione costa di più man mano che il progetto avanza. Scoperto durante la diagnosi si corregge con una riunione, scoperto durante lo sviluppo richiede settimane di codice da rifare, scoperto dopo il rilascio fa perdere anche la fiducia di chi doveva usare il software. Spostare le decisioni difficili all'inizio è il modo più economico per proteggere il budget.

### Cosa si vede durante una demo settimanale di sviluppo software?

Si vede il software vero, aperto in un ambiente di staging separato dalla produzione, con le funzioni costruite in quella settimana. Non sono slide né aggiornamenti a voce. È utile che partecipino anche le persone che lo useranno ogni giorno, perché sono loro ad accorgersi subito di un campo fuori posto o di un passaggio mancante.

### Cosa succede se durante lo sviluppo emergono nuove richieste?

Vengono accolte ma non inserite automaticamente nello sprint in corso. Ogni richiesta nuova viene scritta e valutata per impatto su tempi e costi, poi è il cliente a decidere se e quando farla entrare nel progetto. Così il perimetro resta sotto controllo senza diventare rigido.

### Alla fine del progetto il codice sorgente è del cliente?

Sì. Alla consegna ricevi il codice sorgente completo, la documentazione tecnica e gli accessi a server, domini e servizi esterni, intestati all'azienda. Non ci sono canoni di licenza né vincoli con il fornitore: puoi far evolvere il software con noi o con un altro professionista.

---

Fonte: https://www.spsproject.net/il-nostro-metodo-in-4-fasi-e-perche-la-prima-e-la-piu-importante/ — SpsProject