Tempi di sviluppo software: fasi, milestone e durata reale

"Quanto tempo ci vuole?" è la seconda domanda più frequente in un kickoff progetto, dopo "quanto costa?". La risposta onesta è "dipende, ma meno di quanto si pensa quando va bene, e molto di più quando va male". Capire da cosa dipende è il primo passo per avere stime realistiche.

In questa guida vediamo i tempi reali delle fasi di un progetto software, basati sui pattern che si ripetono progetto dopo progetto.

Le fasi tipiche di un progetto

Un progetto software custom segue (o dovrebbe seguire) sei fasi distinte:

1. Discovery (1-2 settimane)

Comprensione approfondita del problema, degli obiettivi, dei vincoli, del pubblico.

Output: documento di brief, mappa delle funzionalità, prioritizzazione iniziale, identificazione di rischi.

2. Strategia e architettura (1-2 settimane)

Scelta delle tecnologie, design dell'architettura, pianificazione delle integrazioni, definizione delle milestone.

Output: documento tecnico, schema architetturale, piano dei rilasci.

3. Design (2-4 settimane)

Per progetti con interfaccia: wireframe, prototipi, sistema di design, validazione con utenti.

Output: design system, prototipi navigabili, asset esportabili.

4. Sviluppo (4-12 settimane)

La fase più lunga. Implementazione delle funzionalità, in sprint con review periodiche.

Output: software funzionante, test automatici, documentazione tecnica.

5. Test e hardening (1-3 settimane)

Test funzionali, test di carico, audit di sicurezza, fix di bug emergenti.

Output: software pronto al lancio, documentazione di rilascio.

6. Lancio e stabilizzazione (1-2 settimane)

Deploy, monitoraggio attivo, fix rapidi di issue post-lancio.

Output: sistema in produzione, dashboard di monitoraggio, prime metriche.

Tabella tempi tipici per dimensione progetto

I 5 fattori che davvero spostano i tempi

1. Chiarezza dello scope al kickoff

Effetto: enorme. Uno scope ben definito può ridurre i tempi del 30%; uno scope vago può raddoppiarli.

Se il committente arriva con "ho un'idea ma vediamo strada facendo", aspettarsi 50% in più sui tempi. Se arriva con specifiche dettagliate, i tempi sono prevedibili.

2. Velocità decisionale del committente

Effetto: medio-alto. Un cliente che risponde a domande in 24 ore vs uno che ci impiega 2 settimane: differenza facile di 2-3 settimane su un progetto di 4 mesi.

I momenti chiave dove la decisione blocca tutto: approvazione design, scelta integrazioni, validazione contenuti, decisione configurazioni cloud.

3. Qualità delle integrazioni esterne

Effetto: medio-alto. Un'API esterna ben documentata e stabile aggiunge 1-3 giorni. Un'API mal documentata o instabile può aggiungere settimane.

Pattern critico: integrazioni con sistemi gestionali aziendali interni. Spesso richiedono accesso a documentazione che non esiste e collaborazione di team interni occupati.

4. Cambi di scope durante il progetto

Effetto: alto e crescente nel tempo.

Pertanto: bloccare lo scope al kickoff è la singola decisione che più riduce i tempi totali.

5. Qualità del processo di review

Effetto: medio. Review tempestive e con feedback chiari fanno avanzare; review tardive o ambigue fanno tornare indietro.

Anti-pattern frequente: 5 stakeholder in review che danno feedback contraddittori, nessuno con potere decisionale finale. Risultato: settimane di iterazioni che non risolvono.

Pattern che accelerano

Tre pratiche che applichiamo regolarmente per ridurre i tempi senza compromettere la qualità:

Discovery rigorosa al kickoff

Sembra controintuitivo (allungare l'inizio per accelerare il totale), ma la pratica conferma sistematicamente: ogni settimana ben spesa in discovery ne fa risparmiare 2-3 nelle fasi successive.

Sprint brevi con demo

Sprint da 1-2 settimane con demo funzionante alla fine. Permette di intercettare disallineamenti presto, prima che diventino refactor costosi.

Decisioni tracciate

Ogni decisione importante viene documentata: contesto, alternative considerate, scelta, motivazione. Riduce drasticamente le rinegoziazioni successive.

Errori che allungano i tempi

1. "Fai una bozza e poi vediamo"

Senza brief chiaro, il team produce qualcosa, lo stakeholder non lo riconosce come utile, si ricomincia. Si bruciano 2-3 settimane.

2. Stakeholder multipli senza champion

Nessun decisore finale. Ogni decisione richiede consenso di 5 persone. Tempi raddoppiati.

3. Cambi tecnologici a metà progetto

"Cambiamo framework / database / hosting." Equivalente a riavviare il progetto.

4. Nessun ambiente di staging

Test fatti direttamente in produzione, bug che si scoprono solo dopo il lancio. Stabilizzazione doppia rispetto a quello che sarebbe stato.

5. Dimissioni o cambio team a metà

Il team che non finisce quello che ha iniziato lascia un debito di onboarding al successivo. Tempi +30-50%.

Conclusione

I tempi di sviluppo software non sono un mistero: sono prevedibili, se si conosce il metodo e si rispettano alcune pratiche di base. La difficoltà non è tecnica, è di governance.

Un committente che sa cosa vuole, decide rapidamente, blocca lo scope al kickoff, fornisce review di qualità, riceve un progetto in tempo. Un committente che cambia idea spesso, decide lentamente, espande lo scope strada facendo, riceve un progetto in ritardo.

Il tempo è una risorsa che si gestisce tanto da parte del fornitore quanto da parte del cliente. Le partnership che funzionano riconoscono questa responsabilità condivisa fin dall'inizio.