Chi commissiona un software per la prima volta si trova di fronte a un'attività che non conosce: non vede cosa succede tra la firma del preventivo e il giorno in cui il programma "è pronto". In mezzo ci sono settimane in cui il fornitore sembra sparire, riunioni in cui gli viene chiesto tempo, schermate che compaiono e cambiano, e un momento, quasi sempre carico di tensione, in cui il software "va provato".
Conoscere le fasi di un progetto serve a due cose. La prima è sapere cosa aspettarsi: cosa deve esserci a ogni punto, cosa viene consegnato, quando si può dire che una fase è finita. La seconda è sapere cosa deve fare l'azienda, perché in ogni fase c'è una parte di lavoro che spetta al cliente, e che nessun fornitore può fare al posto suo.
Questa guida descrive il percorso tipico di un progetto di dimensione media, con le sue variazioni. Non è l'unico modo di lavorare (ne esistono molti, e li confrontiamo più avanti), ma è un buon quadro di riferimento per valutare un preventivo, un piano di lavoro e lo stato di un progetto in corso.
Il quadro generale: sei fasi, non una linea retta
Le fasi sono sei: analisi, progetto, sviluppo, collaudo, rilascio, assistenza. Descritte una dopo l'altra sembrano una catena di montaggio; nella realtà si sovrappongono e si ripetono.
Il diagramma mostra un progetto di circa sei mesi. Tre osservazioni utili:
- Le fasi si sovrappongono. La progettazione comincia prima che l'analisi sia chiusa per le parti già chiare. Il collaudo parte mentre si sviluppano le ultime funzioni.
- Lo sviluppo è la fase più lunga ma non la più rischiosa. Il rischio maggiore sta nelle fasi in cui si decide cosa costruire (analisi e progetto) e in cui si verifica che sia giusto (collaudo).
- L'assistenza non è un "dopo". Comincia al rilascio e dura quanto il software.
Fase 1: l'analisi. Capire cosa serve davvero
Obiettivo. Chiarire il problema da risolvere, i processi da coprire, i casi particolari e i criteri con cui si deciderà che il lavoro è riuscito.
Cosa si fa. Interviste con chi usa i processi, osservazione del lavoro reale, raccolta dei documenti e dei fogli di calcolo in uso, elenco delle eccezioni, definizione delle priorità. Spesso si disegna a mano il flusso: chi fa cosa, in quale ordine, con quali dati.
Cosa viene consegnato. Un documento dei requisiti (anche di poche pagine), un elenco delle funzioni con le priorità, i casi particolari, e un perimetro chiaro: cosa è dentro e cosa è fuori.
Cosa deve fare il cliente. Mettere a disposizione le persone che conoscono i processi, non solo il responsabile. Fornire esempi reali (documenti, file, casi difficili). Decidere le priorità. Leggere e validare il documento: la firma sui requisiti è l'atto più importante di tutto il progetto.
Durata tipica. Da una a quattro settimane, secondo il perimetro.
Errori frequenti. Ridurre l'analisi per "partire subito"; farla con una sola persona che parla a nome di tutti; non documentare le eccezioni; confondere "come lo facciamo oggi" con "come dovrebbe funzionare".
Fase 2: il progetto. Decidere come è fatto
Obiettivo. Trasformare i requisiti in un disegno del sistema: struttura, dati, schermate, tecnologie.
Cosa si fa. Si disegna lo schema dei dati (quali informazioni, collegate come), si decide l'architettura (le parti del sistema e come comunicano), si scelgono le tecnologie, si preparano i disegni delle schermate principali, si definiscono permessi e ruoli, si pianificano gli ambienti di prova e di produzione.
Cosa viene consegnato. Lo schema dei dati, il disegno dell'architettura, i prototipi delle schermate, il piano di sviluppo con le tappe.
Cosa deve fare il cliente. Guardare i disegni delle schermate con gli utenti e dire cosa non va, in questa fase che costa poco. Rispondere alle domande sulle regole (come si calcola un prezzo, chi può approvare cosa). Approvare il piano.
Durata tipica. Da due a quattro settimane, in parte sovrapposte all'analisi.
Errori frequenti. Approvare i disegni senza provarli con chi userà il software; rimandare le decisioni su permessi e ruoli; non chiedere come si prevede la crescita del sistema.
Fase 3: lo sviluppo. Costruire, a pezzi che si possono vedere
Obiettivo. Scrivere il software, in modo che sia funzionante, comprensibile e protetto da test.
Cosa si fa. Lo sviluppo procede per tappe brevi, di solito da una a tre settimane, al termine delle quali esiste una parte funzionante da mostrare. Gli sviluppatori scrivono il codice (oggi spesso con l'aiuto di assistenti basati su intelligenza artificiale per le parti ripetitive), scrivono i test automatici, si scambiano revisioni, integrano i pezzi. Il project manager aggiorna il piano.
Cosa viene consegnato. Versioni intermedie funzionanti, mostrate al cliente a ogni tappa; il codice in un archivio ordinato; i test automatici.
Cosa deve fare il cliente. Partecipare alle dimostrazioni di fine tappa: sono l'occasione di correggere la rotta quando costa poco. Rispondere alle domande dello sviluppatore in tempi brevi. Mantenere il perimetro: ogni funzione nuova passa dalla gestione delle modifiche, descritta più avanti.
Durata tipica. Da uno a quattro mesi nei progetti di dimensione media.
Errori frequenti. Sparire per settimane e riapparire a fine sviluppo; chiedere piccole aggiunte "al volo" senza passare per la procedura; non guardare le versioni intermedie.
Fase 4: il collaudo. Verificare che sia giusto
Obiettivo. Verificare che il software faccia ciò che serve, in tutte le condizioni reali, prima che venga usato davvero.
Cosa si fa. Si collaudano i singoli pezzi (test tecnici) e l'insieme, con scenari di prova scritti in anticipo: i casi normali, i casi limite, gli errori, la sicurezza, il comportamento con molti dati e molti utenti. Poi c'è il collaudo di accettazione: gli utenti dell'azienda provano il sistema con dati e casi reali.
Cosa viene consegnato. L'elenco dei difetti trovati e risolti, il resoconto delle prove, la versione approvata per il rilascio.
Cosa deve fare il cliente. È la fase in cui il suo impegno è più alto. Deve mettere a disposizione utenti reali con il tempo per provare; fornire dati realistici; segnalare i problemi in modo chiaro (cosa stavo facendo, cosa mi aspettavo, cosa è successo); decidere cosa è un difetto da correggere e cosa una richiesta nuova.
Durata tipica. Da due a sei settimane, in parte sovrapposte allo sviluppo.
Errori frequenti. Collaudare con pochi minuti e poche persone; usare dati di prova perfetti; confondere i difetti (il software non fa ciò che era stato concordato) con le richieste nuove (vorrei anche questo).
Un criterio semplice per distinguerli: se la funzione era nei requisiti approvati ed è sbagliata, è un difetto; se non c'era, è una modifica. Questa distinzione, scritta nel contratto, evita molte discussioni.
Fase 5: il rilascio. Mettere in uso senza traumi
Obiettivo. Portare il software in produzione, con i dati reali e gli utenti reali, senza interrompere l'attività dell'azienda.
Cosa si fa. Si prepara l'ambiente di produzione (server, database, accessi, copie di sicurezza), si importano i dati esistenti (la fase più delicata), si formano gli utenti, si pianifica il passaggio. Spesso si affianca il vecchio sistema al nuovo per qualche giorno o settimana. Si definisce un piano per tornare indietro se qualcosa va storto.
Cosa viene consegnato. Il sistema in produzione, la documentazione per gli utenti e per chi lo manterrà, gli accessi, le procedure di copia e ripristino dei dati.
Cosa deve fare il cliente. Verificare i dati importati (solo chi li conosce può dire se sono giusti). Pianificare la formazione. Scegliere un momento adatto: non il giorno della chiusura di bilancio. Designare chi, in azienda, sarà il riferimento per gli utenti nei primi giorni.
Durata tipica. Da una a tre settimane, più il periodo di affiancamento.
Errori frequenti. Importare i dati all'ultimo momento; saltare la formazione; rilasciare di venerdì sera; non avere un piano per tornare indietro.
Fase 6: l'assistenza. Il software vive
Obiettivo. Mantenere il sistema funzionante, correggere i difetti emersi con l'uso e farlo evolvere.
Cosa si fa. Si risponde alle segnalazioni, si correggono i difetti, si applicano gli aggiornamenti di sicurezza, si monitorano le prestazioni, si raccolgono le richieste di evoluzione. Spesso c'è un periodo di garanzia (di solito alcuni mesi) in cui i difetti si correggono senza costi aggiuntivi, seguito da un contratto di manutenzione.
Cosa viene consegnato. Interventi correttivi, aggiornamenti, e a intervalli regolari un resoconto dello stato del sistema.
Cosa deve fare il cliente. Segnalare i problemi in modo ordinato (un solo canale, informazioni chiare), mantenere un referente, valutare le evoluzioni con la stessa attenzione del progetto iniziale.
Durata. Quanto vive il software: anni.
Errori frequenti. Pensare che dopo la consegna non ci siano costi; non fare aggiornamenti per anni e poi doverli fare tutti insieme; non avere un contratto e scoprirlo nel giorno del guasto.
Come lavora il fornitore: cascata e metodi agili, in parole semplici
Descrivere sei fasi in sequenza può far pensare a un processo "a cascata": si finisce una fase, poi si passa alla successiva senza tornare indietro. Esiste davvero, e funziona bene quando i requisiti sono chiari e stabili. Il rischio è di scoprire i problemi tardi.
I metodi agili (di cui si sente parlare spesso) fanno il contrario: dividono il progetto in cicli brevi, ciascuno con un po' di analisi, sviluppo e collaudo, e mostrano il risultato a ogni ciclo. I problemi emergono prima, ma richiedono che il cliente partecipi con continuità e che il perimetro sia gestito con disciplina.
Nella pratica la maggior parte dei progetti seri è una via di mezzo: un'analisi iniziale abbastanza solida da stimare il lavoro, poi uno sviluppo a tappe brevi con dimostrazioni regolari. Per un'azienda cliente, la domanda da fare non è "agile o cascata?", ma "quando vedrò una parte funzionante del software?". Se la risposta è "alla fine", il rischio è alto.
Come si gestiscono le modifiche in corso d'opera
Le modifiche arrivano sempre. Non sono un'anomalia: sono il segno che gli utenti stanno capendo meglio cosa vogliono. Ciò che fa la differenza è come vengono gestite. Una procedura semplice:
- Si scrive la richiesta, in poche righe: cosa serve e perché.
- Il fornitore stima l'impatto: giornate, costo, effetto sui tempi, funzioni che potrebbero essere toccate.
- Il referente decide: accettare, rimandare, rifiutare, o sostituire una funzione meno importante.
- Si aggiorna il piano e si registra la decisione.
La regola d'oro: nessuna modifica "al volo". Ogni richiesta piccola, accettata senza procedura, sposta tempi e costi in modo invisibile. Per le tipologie di contratto e il loro rapporto con le modifiche, vedi Freelancer o agenzia: quando conviene l'uno o l'altra.
Comunicazione: cosa dovrebbe arrivare e con che frequenza
Un buon progetto non richiede riunioni infinite, ma richiede un ritmo prevedibile. Un'impostazione ragionevole:
- Un aggiornamento breve ogni settimana, scritto: cosa è stato fatto, cosa si farà, cosa blocca, cosa serve dal cliente.
- Una dimostrazione a fine tappa, con il software funzionante, non con diapositive.
- Un elenco delle decisioni, che raccolga cosa è stato deciso, quando e da chi.
- Un canale unico per le segnalazioni, per non disperdere le informazioni.
Se non ricevi aggiornamenti, chiedili. Se li ricevi ma non capisci a che punto sei, anche questo è un segnale.
Cosa si dovrebbe ricevere alla fine
Alla consegna di un progetto devono esserci, per iscritto:
- il software funzionante in produzione;
- il codice sorgente, o l'accordo chiaro su dove si trova e di chi è;
- la documentazione per gli utenti e per chi manterrà il sistema;
- gli accessi ai sistemi (server, database, archivio del codice) intestati all'azienda;
- le procedure di copia di sicurezza e ripristino, provate almeno una volta;
- le condizioni di garanzia e assistenza: per quanto tempo, con quali tempi di risposta.
Se un fornitore è restio a consegnare il codice o gli accessi, è un segnale d'allarme: l'azienda deve poter cambiare fornitore senza ripartire da zero.
Il ruolo dell'intelligenza artificiale lungo le fasi
Gli assistenti basati su intelligenza artificiale entrano in quasi tutte le fasi, con pesi diversi:
| Fase | Dove aiuta l'IA | Dove servono le persone |
|---|---|---|
| Analisi | Organizzare appunti, redigere bozze di documenti | Ascoltare gli utenti, capire cosa non viene detto |
| Progetto | Proporre alternative, generare schemi di partenza | Scegliere in base a vincoli, rischi e budget |
| Sviluppo | Scrivere codice ripetitivo, spiegare codice esistente | Garantire coerenza, qualità e sicurezza |
| Collaudo | Generare scenari di prova, prime bozze di test | Decidere cosa conta, interpretare i risultati |
| Rilascio | Preparare checklist e documentazione | Verificare i dati, gestire il passaggio, formare le persone |
| Assistenza | Aiutare a diagnosticare i problemi | Rispondere al cliente, decidere le priorità |
In ogni riga c'è una colonna che l'IA non riempie: il giudizio, la responsabilità, il rapporto con il cliente. Per approfondire, leggi L'intelligenza artificiale non scrive il software al posto tuo e I ruoli di un progetto software.
Checklist per il cliente: cosa preparare per ogni fase
Prima di iniziare
- Un referente con tempo e autorità di decidere.
- Una descrizione scritta del problema e dei processi attuali.
- Esempi reali: documenti, fogli di calcolo, casi difficili.
Durante l'analisi e il progetto
- Le persone che usano i processi, disponibili per le interviste.
- Le regole di business scritte, comprese quelle che "tutti sanno".
- Approvazione scritta dei requisiti e del piano.
Durante lo sviluppo
- Presenza alle dimostrazioni di fine tappa.
- Risposte alle domande in tempi concordati.
- Una procedura per le modifiche, rispettata.
Durante il collaudo
- Utenti reali con il tempo per provare.
- Dati realistici, anche difficili.
- Segnalazioni chiare, distinguendo difetti e richieste nuove.
Al rilascio
- Dati verificati da chi li conosce.
- Formazione pianificata, momento di rilascio adatto.
- Un riferimento interno per i primi giorni.
Dopo il rilascio
- Un canale unico per le segnalazioni.
- Un contratto di assistenza.
- Un budget per manutenzione ed evoluzione (come regola indicativa, il 15–20% annuo del costo iniziale, come visto in Quanto costa sviluppare un gestionale su misura).
Domande frequenti
Quanto dura in tutto un progetto software? Come ordine di grandezza, un progetto piccolo richiede da due a quattro mesi, uno medio da quattro a nove, uno complesso un anno o più. I tempi dipendono molto dalla rapidità con cui il cliente risponde e decide: i ritardi nei progetti nascono più spesso dalle decisioni che dal codice.
Posso saltare una fase per risparmiare? Puoi ridurla, non eliminarla. Se non si fa analisi, i requisiti si scoprono durante lo sviluppo, quando correggerli costa di più. Se non si fa collaudo, i difetti si scoprono con gli utenti reali. Il risparmio apparente si trasforma quasi sempre in rilavorazioni.
Chi decide se il software è "finito"? Il cliente, con i criteri stabiliti nei requisiti. Per questo è importante che i criteri di accettazione siano scritti all'inizio, non negoziati alla fine.
Cosa succede se i requisiti cambiano a metà progetto? Si applica la procedura delle modifiche: stima dell'impatto, decisione del referente, aggiornamento del piano. Cambiare è normale; farlo senza procedura è ciò che manda fuori controllo costi e tempi.
Come faccio a sapere a che punto è davvero il progetto? Dalle dimostrazioni. Una percentuale di avanzamento è un'opinione; una funzione che puoi provare è un fatto. Chiedi di vedere il software funzionante a ogni tappa.
Dove trovo professionisti per le diverse fasi? Per la parte .NET, su LancerJob trovi sviluppatori freelance specializzati nello stack Microsoft, con profili che indicano esperienza e disponibilità. Per presentare il progetto in modo chiaro e ricevere offerte confrontabili, usa il modello in Come scrivere una richiesta di progetto efficace.
In sintesi
- Un progetto software ha sei fasi: analisi, progetto, sviluppo, collaudo, rilascio, assistenza. Si sovrappongono e si ripetono: è un ciclo, non una linea.
- Il rischio maggiore sta nelle fasi in cui si decide cosa costruire e in cui si verifica che sia giusto, più che nella scrittura del codice.
- In ogni fase c'è una parte di lavoro che spetta al cliente: il referente, le persone che conoscono i processi, i dati, il collaudo.
- Il collaudo è la fase in cui l'impegno del cliente è più alto; la distinzione tra difetti e richieste nuove va scritta nel contratto.
- Le modifiche si gestiscono con una procedura (stima, decisione, aggiornamento del piano), mai "al volo".
- Alla fine devi ricevere software, codice, documentazione, accessi, procedure di copia e condizioni di assistenza.
- L'IA accelera alcune attività in quasi tutte le fasi, ma il giudizio, la verifica e la responsabilità restano alle persone.