Come stimare un progetto software senza sorprese

Un preventivo software sbagliato raramente nasce da un errore di calcolo. Più spesso nasce da una domanda formulata male: “quanto costa fare un gestionale?”, “quanto tempo serve per rifare l’e-commerce?”. Capire come stimare progetto software significa prima trasformare un'esigenza aziendale in un perimetro tecnico verificabile. Senza questo passaggio, un numero in offerta è solo un'ipotesi commerciale.

Per una PMI, la stima non serve a ottenere il prezzo più basso. Serve a decidere con quali priorità intervenire, quali rischi accettare e quali risultati attendersi. Una stima seria mette in relazione funzioni, integrazioni, dati, infrastruttura, sicurezza e responsabilità operative. Non si limita a sommare schermate e ore di sviluppo.

Come stimare un progetto software partendo dal perimetro

Il punto di partenza è il problema operativo, non la tecnologia. “Serve un CRM” è una direzione, non un requisito. Occorre capire quali utenti lo utilizzeranno, quali informazioni gestiranno, quali attività devono essere automatizzate e cosa accade quando un dato è incompleto o non coerente.

Un progetto di gestione ordini, per esempio, può sembrare semplice finché non emergono listini personalizzati, approvazioni interne, resi, documenti fiscali, ruoli con permessi diversi e sincronizzazioni con ERP o corrieri. Ogni eccezione di processo può diventare codice, test, supporto e manutenzione futura.

La fase iniziale deve quindi produrre un perimetro leggibile anche da chi prende decisioni non tecniche. In pratica, vanno definiti obiettivi misurabili, utenti coinvolti, flussi principali, vincoli normativi, sistemi da integrare e criteri di accettazione. Un requisito è stimabile quando è possibile dire come verificarne il completamento.

Dalla richiesta alla scomposizione del lavoro

Dopo aver chiarito il perimetro, il progetto va diviso in componenti abbastanza piccole da poter essere analizzate. Non basta indicare “area amministrativa” o “integrazione con gestionale”. Bisogna distinguere analisi del flusso, modello dati, interfacce, API, gestione degli errori, importazione iniziale, autorizzazioni, test e rilascio.

Una work breakdown structure efficace non aumenta la burocrazia: rende visibile il lavoro che altrimenti rimarrebbe implicito. È qui che emergono voci spesso trascurate:

• migrazione e bonifica dei dati esistenti;
• integrazioni con servizi esterni e loro limiti tecnici;
• ruoli, permessi, tracciabilità e requisiti di sicurezza;
• ambienti di test, deploy, monitoraggio e procedure di rollback.

Se queste attività non compaiono nella stima, non smettono di esistere. Verranno affrontate più avanti, quando tempi e budget sono già sotto pressione.

I fattori che cambiano davvero costi e tempi

Le funzionalità visibili all'utente sono solo una parte dell'impegno. Due applicazioni con lo stesso numero di schermate possono avere costi molto diversi perché differiscono per complessità dei dati, affidabilità richiesta e dipendenze esterne.

Le integrazioni sono un esempio concreto. Collegare un e-commerce a un ERP non significa soltanto inviare un ordine. Bisogna definire chi è il sistema sorgente per prodotti, disponibilità e prezzi; come gestire gli aggiornamenti falliti; come evitare duplicazioni; cosa fare se l'ERP è indisponibile. La documentazione dell'API, la qualità dei dati e la disponibilità di un ambiente di collaudo influenzano direttamente la stima.

Anche l'architettura pesa. Un'applicazione interna per pochi utenti ha requisiti diversi da una piattaforma accessibile a clienti, agenti e fornitori. Carico previsto, picchi stagionali, continuità operativa, backup, segregazione degli accessi e conservazione dei dati definiscono il livello di progettazione necessario. Progettare troppo poco espone a interruzioni e debito tecnico; progettare troppo rispetto al bisogno iniziale immobilizza budget senza un ritorno proporzionato.

La scelta corretta dipende dal contesto. Un MVP può essere sensato per validare un nuovo servizio, purché siano dichiarati i limiti: funzioni escluse, dati gestiti manualmente, performance attese e passaggi necessari per evolvere il prodotto. Non è sensato usare l'etichetta MVP per giustificare l'assenza di sicurezza, backup o controllo degli accessi.

Stimare l'incertezza, non nasconderla

Una stima precisa non è quella che promette una cifra immutabile prima di aver studiato il progetto. È quella che separa ciò che è noto da ciò che deve essere verificato. Nei progetti software l'incertezza è normale, soprattutto quando coinvolge sistemi legacy, dati storici o fornitori terzi.

Per questo è utile indicare intervalli e assunzioni. Ad esempio, una funzionalità può essere stimata sulla base dell'accesso alle API, di un campione di dati validato e della disponibilità di un referente interno in tempi definiti. Se una di queste condizioni cambia, cambia anche l'impegno necessario. Scriverlo nell'offerta evita che una dipendenza esterna venga interpretata come inefficienza del team di sviluppo.

Il margine di rischio non è una voce arbitraria. Va collegato a elementi specifici: documentazione assente, migrazione non analizzata, regole di business non consolidate, integrazioni proprietarie o requisiti normativi da validare. Un margine non motivato riduce la fiducia. Un rischio esplicitato consente invece di decidere se approfondirlo prima o gestirlo durante il progetto.

Quando serve una fase di analisi separata

Per un sito istituzionale o un'estensione circoscritta di un sistema esistente può bastare una raccolta requisiti rapida. Per un gestionale su misura, un portale B2B, una migrazione e-commerce o un'applicazione con molte integrazioni, l'analisi preliminare merita una fase dedicata e quotata.

In questa fase si definiscono processi, priorità, modello dati, architettura di massima, vincoli di sicurezza e piano di rilascio. Il risultato non è un documento teorico: è la base per una stima più affidabile e per una roadmap che consenta di rilasciare valore prima della fine dell'intero progetto.

Separare l'analisi riduce anche un equivoco frequente: confondere una demo con un prodotto pronto per l'operatività. Un prototipo può confermare l'esperienza utente, ma non dimostra che sincronizzazioni, autorizzazioni, audit trail, carichi e recovery siano stati progettati correttamente.

Il costo totale include il dopo-rilascio

Stimare un progetto software solo fino alla pubblicazione porta a sottovalutare il costo reale. Dopo il go-live iniziano monitoraggio, correzione degli errori emersi in produzione, aggiornamenti di sicurezza, gestione degli accessi, rinnovi tecnici, backup verificati e supporto agli utenti.

Questo non significa che ogni progetto richieda una struttura complessa. Significa definire fin dall'inizio il livello di presidio richiesto. Un e-commerce che genera fatturato ogni giorno necessita di tempi di intervento, monitoraggio e procedure di ripristino diversi da un'applicazione interna usata da un reparto ristretto.

Anche l'infrastruttura va inclusa nel ragionamento. Server, database, container, configurazioni Nginx, logging e controllo delle vulnerabilità non sono dettagli separati dal software. Se codice e ambiente non vengono gestiti come un sistema unico, i problemi di produzione diventano più lenti e costosi da risolvere. Un partner tecnico che segue sviluppo, server e sicurezza può stimare queste dipendenze in modo più coerente, evitando passaggi di responsabilità tra fornitori.

Come leggere e confrontare due preventivi

Confrontare solo il totale è il modo più rapido per scegliere una soluzione apparentemente economica e scoprire dopo cosa non era incluso. Un preventivo utile chiarisce perimetro, esclusioni, assunzioni, modalità di gestione delle variazioni, deliverable e condizioni di collaudo.

La domanda corretta non è “perché questo costa di più?”, ma “quale lavoro è compreso qui e assente altrove?”. Una proposta più economica può essere valida se il perimetro è realmente più ridotto. Diventa rischiosa quando mantiene promesse equivalenti omettendo attività essenziali come migrazione, test, formazione, sicurezza o assistenza post-rilascio.

È utile verificare anche come vengono gestite le richieste che emergono durante il lavoro. Le modifiche sono inevitabili, ma devono essere valutate per impatto su tempi, costi e priorità. Un processo di change request chiaro protegge sia il cliente sia il fornitore: impedisce che nuove esigenze entrino silenziosamente nel perimetro iniziale e rende le decisioni tracciabili.

Una buona stima non vende certezze inesistenti. Costruisce un percorso decisionale: chiarisce cosa si realizza ora, cosa può attendere, quali condizioni devono essere rispettate e come controllare avanzamento e risultati. È da questa trasparenza, non da una cifra rassicurante ma fragile, che nasce un progetto software sostenibile.