Discovery progetto software: cos'è, come funziona e quanto costa
Aggiornato a giugno 2026
Chiedi un preventivo per un gestionale su misura e ti arrivano offerte tra €5.000 e €80.000. Non è incompetenza del fornitore. È che senza una discovery progetto software strutturata, nessuno sa davvero cosa stai chiedendo di costruire.
La discovery non è una formalità pre-contrattuale. È il lavoro che rende possibile tutto il resto: definisce cosa serve, quanto costa e perché, prima di scrivere una riga di codice.
Cos'è la discovery di un progetto software?
La discovery di un progetto software è la fase strutturata che precede lo sviluppo e trasforma un'esigenza di business in requisiti tecnici documentati e verificabili. Senza questa fase, i progetti software registrano tassi di fallimento superiori al 60%, secondo il Chaos Report del Standish Group.
Definizione e obiettivi della fase di discovery
La discovery di un progetto software è la fase strutturata che precede lo sviluppo e serve a trasformare un'esigenza di business in requisiti tecnici verificabili. Non è una riunione commerciale. È un processo di analisi con input definiti, sessioni di lavoro con gli stakeholder e output documentati che appartengono al cliente.
L'obiettivo è rispondere a tre domande concrete prima di spendere denaro nello sviluppo:
- Cosa deve fare il software, esattamente?
- Con quali sistemi deve integrarsi e con quali vincoli?
- Quanto costerà costruirlo, e perché?
La fase discovery sviluppo serve a ridurre l'incertezza. Un progetto avviato senza discovery parte con assunzioni non verificate. Alcune saranno giuste, molte no. Il costo di scoprirlo durante lo sviluppo è sempre più alto che scoprirlo prima.
Esiste una distinzione fondamentale che vale la pena chiarire subito. La discovery "commerciale" gratuita che molti fornitori offrono non produce nulla di utile: è una call esplorativa, non un'analisi. La discovery professionale a pagamento, invece, produce documenti strutturati, verificabili e di proprietà del cliente. Se decidi di cambiare fornitore dopo la discovery, puoi portare quei documenti con te. Nessuno ti tiene in ostaggio.
Questo è il modo in cui Nesso Digitale intende la discovery: un deliverable autonomo, non un aggancio commerciale.
Le organizzazioni che investono in una fase di discovery strutturata riducono il rischio di rilavorazioni durante lo sviluppo di oltre il 40%, secondo benchmark di settore raccolti da PMI (Project Management Institute) su progetti software tra €10.000 e €500.000.
Discovery vs analisi dei requisiti: differenze
La discovery è più ampia dell'analisi dei requisiti: include la mappatura dei processi as-is e to-be, la valutazione dei rischi tecnici e la stima economica motivata. L'analisi dei requisiti software è uno degli output della discovery, non il punto di partenza.
I due termini si sovrappongono spesso, ma non sono sinonimi.
L'analisi dei requisiti è un'attività tecnica: raccoglie, struttura e formalizza le funzionalità che il software deve avere. È una delle componenti della discovery, non la discovery stessa.
La discovery è più ampia. Include l'analisi dei processi di business esistenti (as-is), la definizione di come dovrebbero funzionare dopo il software (to-be), la mappatura tecnica dei sistemi coinvolti, la valutazione dei rischi e la produzione di una stima economica motivata. L'analisi dei requisiti software è uno degli output della discovery, non il punto di partenza.
In pratica: puoi avere un documento di requisiti scritto benissimo ma basato su processi mal compresi. La discovery serve proprio a evitarlo.
Standard internazionali come l'ISO/IEC 29148 distinguono formalmente la requirements elicitation (analisi dei requisiti) dal processo di system/software requirements engineering, confermando che la discovery agisce a un livello superiore di astrazione rispetto alla sola raccolta dei requisiti.
Come funziona la discovery in un progetto software
La discovery si articola in tre fasi sequenziali: raccolta delle informazioni tramite sessioni strutturate con gli stakeholder, definizione del perimetro e delle regole di business, produzione dei deliverable documentati. Una discovery completa su un progetto di media complessità richiede tra 3 e 4 settimane di lavoro attivo.
Raccolta e analisi delle informazioni
Il primo passo è il kickoff. Non si parla di tecnologia: si parla di business. Chi usa il software? Quali attività fa oggi, con quali strumenti, con quali colli di bottiglia? Quali metriche di successo esistono?
In questa fase si coinvolgono le persone che usano davvero i processi, non solo i manager che li descrivono dall'alto. È la differenza tra capire cosa succede e capire cosa si pensa che succeda.
Le sessioni di raccolta informazioni sono strutturate, non libere. Ogni sessione ha un'agenda, domande preparate e un output atteso. Il referente tecnico che conduce la discovery porta competenze di analisi dei processi, non solo di sviluppo software.
Metodologie consolidate come il Business Process Model and Notation (BPMN) e tecniche di intervista derivate dal framework Design Thinking guidano la struttura delle sessioni di raccolta, garantendo che i flussi emersi siano rappresentabili in forma verificabile e non solo narrativa.
Perimetro e regole di business
La definizione del perimetro è il passaggio più critico dell'intera discovery: stabilisce cosa è dentro al progetto e cosa è fuori, e porta in superficie le regole di business implicite che, se non documentate, vengono replicate in modo inconsistente nel software.
Dopo la raccolta, si definisce il perimetro. Cosa è dentro al progetto e cosa è fuori. Quali regole di business governano i processi: le eccezioni, i casi limite, i flussi di approvazione, le integrazioni con altri sistemi.
Questo è il passaggio più critico. Le regole di business sono spesso implicite: "lo sa tutti" oppure "lo gestiamo a mano". Portarle in superficie e documentarle è il valore principale della discovery.
Caso d'uso reale - Un'azienda di servizi con una ventina di collaboratori gestiva l'import degli ordini ricevuti via email e CSV nel gestionale manualmente, con un operatore dedicato ogni mattina. Durante la discovery è emerso che le regole di validazione degli ordini non erano mai state scritte da nessuna parte: ogni operatore le applicava diversamente. Prima di automatizzare il processo, è stato necessario formalizzare 14 regole di business distinte. Senza la discovery, il software avrebbe automatizzato il caos, non il processo corretto.
Output concreti di una discovery ben fatta
Una discovery professionale produce sei categorie di deliverable strutturati: mappa dei processi as-is e to-be, documento dei requisiti funzionali e non funzionali, architettura tecnica di massima, piano di sviluppo iterativo con milestone, stima economica motivata e registro dei rischi. Tutti i documenti appartengono al cliente.
Una discovery professionale produce documenti strutturati. Non slide commerciali, non email di riepilogo: documenti tecnici che un altro fornitore potrebbe leggere e usare per sviluppare il software.
Ecco cosa include una discovery completa:
Mappa dei processi as-is e to-be Rappresentazione visiva e testuale di come funzionano i processi oggi e come dovranno funzionare dopo il software. Utile per allineare tutti gli stakeholder su una visione condivisa.
Documento dei requisiti funzionali e non funzionali I requisiti funzionali descrivono cosa fa il software (es. "gestisce stati e approvazioni dei preventivi"). I requisiti non funzionali descrivono come lo fa (performance, sicurezza, disponibilità). Entrambi vanno documentati.
Architettura tecnica di massima Stack tecnologico suggerito, modalità di integrazione con i sistemi esistenti (ERP, gestionali, e-commerce), vincoli infrastrutturali. Non è il progetto architetturale definitivo, ma è abbastanza dettagliato da permettere una stima attendibile.
Piano di sviluppo iterativo con milestone Come si articola lo sviluppo in fasi verificabili. Quali funzionalità fanno parte del primo rilascio, quali dell'evoluzione successiva. Un piano di questo tipo permette di controllare il progetto invece di subirlo.
Stima economica motivata con range e assunzioni esplicite Non un numero fisso, ma un range con le assunzioni che lo determinano. Se un'assunzione cambia, la stima cambia di conseguenza. Trasparenza totale su cosa sposta il prezzo verso l'alto o verso il basso.
Registro dei rischi e delle decisioni Quali rischi tecnici o organizzativi sono stati identificati, come si propone di mitigarli, quali decisioni chiave sono state prese durante la discovery e perché.
Tutti questi documenti appartengono al cliente. Puoi portarli a un altro fornitore, usarli per valutare offerte concorrenti, o decidere di sospendere il progetto. La discovery è un investimento autonomo, non una tassa d'accesso allo sviluppo.
Una discovery che produce un registro delle decisioni riduce il rischio di perdita di contesto tra fase di analisi e sviluppo: nei progetti con team distribuiti, la mancanza di decisioni documentate è responsabile del 35% delle rilavorazioni, secondo dati raccolti da McKinsey & Company su programmi di innovazione digitale nelle PMI europee.
Quando serve la discovery e quando si può saltare?
La discovery è necessaria quando il software sostituisce processi manuali con regole implicite, quando sono presenti integrazioni con sistemi ERP o gestionali esistenti, quando ci sono più stakeholder con esigenze diverse, o quando il budget supera €15.000. Per processi standard coperti da SaaS come Salesforce, HubSpot o SAP Business One, la discovery può essere evitata.
Casi in cui un SaaS generico è sufficiente
Non ogni problema richiede un software su misura e, di conseguenza, non ogni situazione richiede una discovery.
Se la tua azienda gestisce processi standard (fatturazione, CRM base, gestione note spese) e questi processi non hanno eccezioni significative, un SaaS generico è spesso la scelta giusta. Costa meno, si avvia in giorni, non in settimane, e il fornitore gestisce manutenzione e aggiornamenti.
La discovery serve quando lo standard non basta. Non quando potresti adattarti allo standard, ma quando l'adattamento costerebbe più della soluzione su misura nel medio periodo.
Piattaforme SaaS come Salesforce, HubSpot, Monday.com o SAP Business One coprono la stragrande maggioranza dei processi aziendali standard. Se il tuo processo rientra nei modelli supportati da queste piattaforme senza personalizzazioni estese, il costo-opportunità di uno sviluppo su misura raramente si giustifica nel breve periodo.
Quando la discovery è necessaria
Ci sono scenari in cui saltare la discovery è un errore costoso:
Il software sostituisce processi manuali consolidati con regole implicite. Come nel caso d'uso sopra: automatizzare senza prima formalizzare le regole produce software che perpetua il disordine.
Sono presenti integrazioni con sistemi ERP o gestionali esistenti. Ogni integrazione ha vincoli tecnici specifici che emergono solo durante un'analisi approfondita. Scoprirli durante lo sviluppo ritarda il progetto e fa esplodere i costi.
Ci sono più stakeholder con esigenze diverse. Quando il responsabile commerciale, il responsabile operativo e l'IT hanno visioni diverse di "cosa deve fare il software", la discovery è l'unico modo per convergere prima di costruire qualcosa.
Il budget supera €15.000. Oltre questa soglia, il costo della discovery è marginale rispetto al rischio di costruire la cosa sbagliata.
Per i casi più semplici, come un MVP con scope chiarissimo o un progetto MVP per startup con utenti già definiti, può bastare una mini-discovery di una settimana. Per un sviluppo software su misura con processi complessi, la discovery completa è il punto di partenza obbligatorio.
Come Nesso Digitale gestisce la discovery di un progetto software
Nesso Digitale gestisce la discovery di un progetto software attraverso tre modelli operativi distinti: discovery inclusa nel progetto chiavi in mano (Modello A), discovery a scope chiuso seguita da team dedicato (Modello Ibrido A→B), e discovery autonoma con deliverable di proprietà del cliente in tutti i casi. Il referente tecnico che conduce la discovery è lo stesso che coordina lo sviluppo, eliminando la perdita di contesto tra le fasi.
Il metodo di lavoro di Nesso Digitale prevede tre modalità operative, ognuna adatta a un contesto diverso.
Modello A: discovery inclusa nel progetto su misura chiavi in mano
Nel Modello A - Progetti su misura, la discovery è la prima fase di un percorso end-to-end che porta dalla definizione dei requisiti al go-live, passando per MVP, testing e rilascio.
In questo modello il costo della discovery si detrae dall'investimento totale del progetto. Non si paga due volte: si paga una volta per un percorso completo con scope gestito.
È il modello adatto quando l'azienda ha un'esigenza chiara ma non ha un team tecnico interno, e vuole un unico interlocutore responsabile del risultato dalla prima riunione all'ultimo deploy.
Modello Ibrido A→B: discovery a scope chiuso, poi team dedicato
Il Modello Ibrido A→B riduce il rischio nelle prime fasi con una discovery a perimetro definito, poi scala con un team on-demand dedicato che porta il progetto in produzione e lo evolve nel tempo.
Questo modello è adatto quando l'azienda ha già un backlog di funzionalità e vuole validare le priorità prima di impegnare un team per mesi. La discovery produce il piano di sviluppo, il team lo esegue con governance continua.
Il referente tecnico italiano che coordina il team non è una figura commerciale. È la persona che ha fatto la discovery, conosce le decisioni prese, i vincoli tecnici emersi e le regole di business documentate. Questo riduce il rischio di perdita di contesto tra fase di analisi e fase di sviluppo.
Chi partecipa e quali strumenti si usano
Sul lato Nesso Digitale: un business analyst tecnico e, quando necessario, un architect che valuta i vincoli infrastrutturali e le integrazioni.
Sul lato cliente: il referente operativo che conosce i processi, gli utenti finali che li usano, e il decision maker che approva i requisiti. Senza il coinvolgimento degli utenti finali, la discovery produce documenti di carta.
Gli strumenti variano in base al progetto: diagrammi di flusso per i processi, wireframe a bassa fedeltà per le interfacce principali, backlog strutturato per i requisiti. Niente strumenti proprietari che costringono il cliente a restare nell'ecosistema Nesso Digitale.
Per la gestione dei requisiti e del backlog, Nesso Digitale utilizza strumenti standard di settore come Notion, Confluence o Linear, scelti in base al contesto del cliente. Tutti gli artefatti prodotti vengono consegnati in formati aperti (PDF, Markdown, CSV) per garantire la portabilità completa dei documenti.
Costi, tempi e rischi della discovery: cosa aspettarsi
I costi di una discovery professionale variano da €1.500 a €12.000 in base alla complessità del progetto, al numero di stakeholder coinvolti e alle integrazioni richieste. Il costo si detrae dall'investimento totale del progetto se si prosegue con Nesso Digitale; in caso contrario, tutti i documenti restano di proprietà del cliente.
Range di prezzo e fattori che lo determinano
La tabella sotto mostra tre scenari tipici. I range includono le sessioni di analisi, la produzione dei deliverable e una sessione di revisione finale.
| Scenario | Complessità | Durata | Stakeholder | Deliverable inclusi | Costo indicativo |
|---|---|---|---|---|---|
| Progetto semplice | Processo singolo, nessuna integrazione | 1-2 settimane | 1-2 persone | Mappa processi, requisiti funzionali, stima motivata | €1.500-3.000 |
| Progetto medio | Più processi, 1-2 integrazioni | 3-4 settimane | 3-5 persone | Tutti i deliverable base + architettura tecnica di massima | €3.000-6.000 |
| Progetto complesso | Architettura distribuita, sistemi multipli | 4-8 settimane | Team allargato | Set completo + registro rischi + piano iterativo dettagliato | €6.000-12.000 |
Cosa non è incluso nella discovery: sviluppo del software, testing, deployment, formazione utenti, manutenzione. La discovery produce la mappa, non la costruzione.
Il costo della discovery si detrae dall'investimento totale del progetto se si prosegue con Nesso Digitale. Se si decide di non proseguire, i documenti restano al cliente.
Per capire come questi costi si inseriscono nel quadro complessivo, può essere utile approfondire come si stima il costo di un software su misura prima di avviare qualsiasi conversazione con un fornitore.
Rischi principali e come mitigarli
Requisiti instabili. Se il business cambia rapidamente mentre la discovery è in corso, i documenti prodotti rischiano di essere già parzialmente obsoleti alla consegna. Mitigazione: limitare la durata della discovery e lavorare per iterazioni brevi invece di un'analisi monolitica.
Stakeholder non disponibili. La discovery richiede tempo delle persone che conoscono i processi. Se queste persone non sono disponibili per le sessioni, l'analisi si basa su informazioni di seconda mano. Mitigazione: pianificare le sessioni in anticipo e identificare un referente operativo dedicato.
Scope creep durante la discovery stessa. Mentre si analizzano i processi, emergono nuovi requisiti. È normale, ma va gestito. Ogni nuovo requisito va valutato rispetto al perimetro definito inizialmente. Quello che non rientra nel perimetro va nel backlog, non nella discovery corrente.
Dati sporchi o incompleti. Quando il software deve migrare dati esistenti, la qualità dei dati di partenza è critica. Scoprirlo durante lo sviluppo rallenta tutto. Mitigazione: richiedere campioni di dati reali già durante la discovery e documentare le regole di pulizia necessarie.
Secondo una ricerca del Gartner su progetti IT nelle PMI europee, i costi di correzione degli errori di requisiti aumentano in media di 5-10 volte se identificati durante lo sviluppo rispetto a quando vengono intercettati nella fase di discovery iniziale.
Gestionale su Misura Light: discovery + MVP in 8-10 settimane
Per le PMI che hanno bisogno di un gestionale su misura su un processo delimitato, Nesso Digitale propone il pacchetto Gestionale su Misura Light: discovery completa più sviluppo del primo rilascio in 8-10 settimane, con un range di €5.000-12.000.
Le assunzioni che tengono il progetto in quel range:
- Il processo target è delimitato e non richiede integrazioni complesse con sistemi legacy
- Esiste un referente operativo disponibile per le sessioni di analisi e per le revisioni
- I dati di esempio e le regole di business sono accessibili prima dell'avvio
- Lo scope è stabile: le modifiche sostanziali vengono gestite come change request
Il pacchetto è pensato per situazioni come la gestione di preventivi e ordini con stati e approvazioni, oppure l'import automatico di ordini ricevuti via email o CSV nel gestionale, quando i SaaS generici non coprono le regole di business specifiche dell'azienda.
Due fattori spingono il costo verso il limite superiore: la presenza di integrazioni con sistemi esistenti e la necessità di mappare più processi interdipendenti. Due fattori lo tengono verso il limite inferiore: scope ristretto e stakeholder allineati fin dalla prima sessione.
Come riconoscere una discovery professionale da una commerciale
Quando ricevi una proposta di discovery da qualsiasi fornitore, questi elementi ti aiutano a valutarla.
| Segnali di discovery professionale | Red flag da evitare |
|---|---|
| Deliverable scritti e strutturati, consegnati al cliente | Nessun output documentato, solo verbali o email |
| I documenti sono di proprietà del cliente | I documenti "restano al fornitore" o non vengono menzionati |
| Il referente che conduce le sessioni è tecnico, non commerciale | Le sessioni sono guidate da un account manager |
| Durata e costi dichiarati prima dell'avvio | Discovery "gratuita" senza confini definiti |
| Possibilità esplicita di usare i documenti con altri fornitori | Nessuna clausola di handover |
| Registro delle decisioni prese e delle alternative scartate | Le decisioni non vengono documentate |
| Coinvolgimento degli utenti finali nelle sessioni | Solo il management partecipa all'analisi |
Una discovery gratuita senza output scritti è una call commerciale travestita da analisi. Non produce nulla che tu possa usare per valutare il progetto, confrontare offerte o proseguire con un altro fornitore.
Associazioni di categoria come AIPEM (Associazione Italiana Project & Engineering Management) e standard come il BABOK® Guide (Business Analysis Body of Knowledge) dell'IIBA definiscono criteri precisi per distinguere un'analisi professionale da un'attività puramente commerciale: la presenza di deliverable verificabili e di proprietà del committente è il discrimine principale.
Errori comuni nella fase di discovery e come evitarli
Gli errori si dividono in due categorie: quelli del cliente e quelli del fornitore. Entrambi costano.
Errori del cliente
Non coinvolgere gli utenti finali. I manager descrivono i processi come dovrebbero funzionare. Gli utenti finali li descrivono come funzionano davvero. La differenza è spesso enorme. Una discovery senza gli utenti finali analizza un processo ideale che non esiste.
Chiedere tutto senza prioritizzare. "Vogliamo anche la gestione delle ferie, e il portale clienti, e i report avanzati." Ogni aggiunta sposta la stima verso l'alto. La discovery serve anche a stabilire cosa è nel primo rilascio e cosa va in backlog.
Approvare i requisiti senza leggerli. Il documento dei requisiti viene firmato per liberarsi di una task. Poi, durante lo sviluppo, emerge che "non era quello che intendevo". La lettura attenta dei requisiti prima dell'approvazione è tempo investito, non perso.
Pensare che la discovery sia una perdita di tempo. "Vogliamo iniziare a sviluppare subito." Iniziare a sviluppare senza discovery è come costruire un edificio senza progetto. Si può fare, ma il costo delle correzioni supera di gran lunga quello della progettazione iniziale.
Errori del fornitore (e come riconoscerli)
Fare la discovery come rito commerciale. Sessioni senza agenda, nessun documento prodotto, stima consegnata senza assunzioni esplicite. Il segnale è chiaro: la discovery era un pretesto per arrivare al preventivo, non un'analisi reale.
Non documentare le decisioni prese. Durante la discovery si prendono decisioni importanti: quale stack usare, come gestire un caso limite, quale integrazione escludere. Se queste decisioni non sono scritte da nessuna parte, scompaiono con la persona che le ha prese.
Non dichiarare i rischi. Un fornitore che non identifica rischi nella discovery non li ha trovati o non li vuole dichiarare. In entrambi i casi, li troverai durante lo sviluppo, quando costano di più.
Il PMBOK® Guide del Project Management Institute classifica la mancata identificazione dei rischi nelle fasi iniziali tra le cause primarie di escalation di costo nei progetti software. Un registro dei rischi prodotto durante la discovery è uno degli artefatti più citati dai responsabili IT come indicatore di qualità del fornitore.
Domande frequenti sulla discovery di un progetto software
Cos'è la discovery in un progetto software? La discovery è la fase strutturata che precede lo sviluppo. Trasforma un'esigenza di business in requisiti tecnici documentati, verificabili e di proprietà del cliente. Produce documenti concreti: mappa dei processi, requisiti funzionali, architettura di massima, stima economica motivata e registro dei rischi.
La discovery è sempre a pagamento? Una discovery professionale che produce deliverable autonomi è a pagamento. Le "discovery gratuite" non producono output documentati e non hanno valore autonomo: sono conversazioni commerciali, non analisi. Il costo della discovery professionale si giustifica con la riduzione del rischio sullo sviluppo, che vale multipli dell'investimento iniziale.
Posso usare i documenti della discovery con un altro fornitore? Sì, se la discovery è stata condotta correttamente. I documenti devono essere di proprietà del cliente fin dall'avvio. Questa è una clausola da verificare prima di firmare qualsiasi accordo. Una discovery che non permette il handover dei documenti è un vincolo contrattuale mascherato da analisi.
Quanto dura mediamente una fase di discovery? Dipende dalla complessità del progetto. Per un progetto semplice (processo singolo, nessuna integrazione): 1-2 settimane. Per un progetto medio con integrazioni: 3-4 settimane. Per progetti complessi con architettura distribuita e più sistemi: 4-8 settimane. La durata è determinata principalmente dal numero di processi da mappare e dal numero di stakeholder coinvolti.
Qual è la differenza tra discovery e analisi dei requisiti? L'analisi dei requisiti è una componente della discovery, non un sinonimo. La discovery include anche la mappatura dei processi di business (as-is e to-be), l'architettura tecnica di massima, la valutazione dei rischi e la stima economica. L'analisi dei requisiti software produce il documento dei requisiti funzionali e non funzionali, che è uno degli output della discovery.
Come si prepara un'azienda a una sessione di discovery? Tre cose concrete: identificare il referente operativo che conosce davvero i processi (non solo chi li gestisce formalmente), raccogliere esempi reali di dati (ordini, documenti, flussi) che il software dovrà gestire, e preparare una lista delle eccezioni e dei casi limite più frequenti. Le eccezioni sono spesso la parte più complessa da sviluppare e la più facile da dimenticare durante l'analisi.
La discovery agile è diversa da quella tradizionale? La discovery agile si svolge in sprint brevi con revisioni frequenti invece di produrre un documento monolitico alla fine. È più adatta a contesti dove i requisiti evolvono rapidamente o non sono ancora stabili. La differenza pratica: in una discovery agile, i deliverable vengono rilasciati per iterazioni e ogni sprint può aggiungere o correggere quanto emerso nella sessione precedente. Per progetti con scope più stabile, l'approccio tradizionale a fasi è spesso più efficiente.
Richiedi una valutazione per il tuo progetto software
Se stai valutando uno sviluppo software e non sai ancora da dove partire, una discovery strutturata è il primo passo concreto. Non una call esplorativa, non un preventivo a scatola chiusa: un'analisi con output verificabili condotta da un referente tecnico che capisce i processi prima di proporre una soluzione.
Prima di richiedere la discovery, puoi approfondire come affrontiamo un progetto software personalizzato per capire come si inserisce nel percorso completo dalla definizione dei requisiti al go-live.
Se il tuo caso rientra nello scenario del gestionale su misura su un processo delimitato, il pacchetto Gestionale su Misura Light porta dalla discovery al primo rilascio in 8-10 settimane, con investimento tra €5.000 e €12.000.
Richiedi una valutazione - Gestionale su Misura Light
Parli direttamente con un tecnico. Niente call commerciali, solo analisi concreta di cosa serve al tuo progetto.
Aggiornato a giugno 2026.
Autore: Riccardo Sabatti - Founder, Nesso Digitale
FAQ
Quanto costa una discovery progetto software?
Il costo di una discovery varia in base alla complessità del progetto e al numero di processi da analizzare. Per un progetto come il Gestionale su Misura Light di Nesso Digitale, il range complessivo (discovery inclusa) va da €5.000 a €12.000. I fattori che spostano il prezzo verso l'alto sono: requisiti instabili, processi non documentati e necessità di integrazioni con sistemi esistenti.
Quanto tempo dura una discovery progetto software?
La durata dipende dallo scope del progetto: per un'applicazione con 2 - 3 moduli e un processo operativo delimitato, la discovery e lo sviluppo completo richiedono solitamente 8 - 10 settimane con Nesso Digitale. Il rispetto dei tempi è condizionato dalla disponibilità di un referente operativo interno e dall'accesso ai dati di esempio e alle regole di business fin dall'inizio.
Come funziona concretamente il processo di discovery?
La discovery prevede sessioni strutturate di analisi con il referente operativo del cliente per mappare i processi, identificare i requisiti reali e definire lo scope prima di scrivere una riga di codice. Nesso Digitale utilizza questo lavoro per produrre un backlog prioritizzato e una stima di costi e tempi verificabile. Senza questa fase, qualsiasi preventivo rimane un'approssimazione con margine d'errore elevato.
Quali prerequisiti sono necessari prima di avviare una discovery?
È necessario avere un referente operativo disponibile che conosca il processo da digitalizzare e possa partecipare alle sessioni di analisi. Occorre inoltre fornire accesso a dati di esempio e documentare le regole di business prima dell'implementazione. In assenza di questi elementi, i tempi e i costi tendono ad aumentare in modo significativo.
Quali sono i rischi principali di una discovery mal gestita?
Il rischio più comune è quello di requisiti non stabili: se cambiano durante lo sviluppo, generano costi aggiuntivi e ritardi non preventivabili. Un secondo rischio concreto riguarda i dati sporchi o incompleti, che rallentano la migrazione e possono bloccare il go-live. Nesso Digitale mitiga questi rischi con un backlog strutturato, gestione delle change request e campioni di dati validati prima dell'implementazione.
La discovery è obbligatoria anche per progetti piccoli?
Per progetti con scope ristretto e processo ben definito, la discovery può essere semplificata, ma non eliminata. Anche per il Gestionale su Misura Light di Nesso Digitale (€5.000 - €12.000), una fase di analisi iniziale è necessaria per confermare che lo scope sia effettivamente delimitato e che non emergano complessità nascoste. Saltare questo passaggio è la causa principale degli sforamenti di budget nei progetti software.
Cosa include il Gestionale su Misura Light di Nesso Digitale?
Il Gestionale su Misura Light è un'applicazione web accessibile da PC e mobile, progettata per digitalizzare un singolo processo operativo specifico con 2 - 3 moduli e gestione dei permessi base. Il range di prezzo è €5.000 - €12.000 per un progetto completato in 8 - 10 settimane. È indicato per PMI che hanno un processo con scope ristretto e un referente operativo disponibile fin dall'avvio.
Perché i preventivi per software su misura variano così tanto tra fornitori diversi?
Le offerte divergono perché, senza una discovery strutturata, ogni fornitore fa assunzioni diverse su cosa sia incluso nello scope. Un preventivo a €5.000 e uno a €80.000 per lo stesso progetto non sono necessariamente sbagliati: riflettono interpretazioni diverse dei requisiti. La discovery di Nesso Digitale serve esattamente a questo: allineare le aspettative prima di firmare qualsiasi contratto.
Qual è la differenza tra un progetto su misura e un SaaS generico?
Un SaaS generico è una scelta valida quando i processi aziendali sono allineati alle funzionalità standard del prodotto. Quando i processi divergono da quello standard, si inizia ad accumulare lavoro manuale di compensazione o si adattano i processi al software, con perdita di efficienza. Nesso Digitale propone il software su misura come alternativa concreta per le PMI con processi specifici, essendo onesti sul fatto che comporta costi e tempi di sviluppo superiori rispetto a un abbonamento SaaS.
Come si evolve il progetto dopo la discovery e il go-live?
Al termine del progetto è possibile continuare con iterazioni evolutive sul prodotto oppure passare a un modello con team dedicato, in base alle esigenze di crescita. Nesso Digitale offre sia progetti su misura a scope gestito che team on-demand con governance per chi necessita di sviluppo continuativo. La scelta del modello dipende dalla frequenza dei cambiamenti ai requisiti e dalla complessità tecnica prevista nelle fasi successive.
