Cosa produce davvero una fase di discovery (e cosa no)

Una fase di discovery è un blocco breve e circoscritto di analisi all'inizio di un progetto software, quello che porta un'idea grezza a un piano definito, stimato e realizzabile. Precede qualsiasi riga di codice di produzione. Il suo compito è sostituire le supposizioni con decisioni: cosa si costruisce, per chi, in che ordine, in quale fascia di prezzo e cosa resta deliberatamente fuori.

Ci si rivolge a una discovery quando l'idea è chiara in testa ma non sulla carta, quando due fornitori danno numeri molto diversi sullo stesso brief, o quando un team interno ridiscute il perimetro a ogni riunione. Il risultato è un insieme di documenti e un prototipo concreti al punto che un secondo team potrebbe prenderli e costruirci sopra. Ecco cosa produce una discovery, quanto costa e le quattro cose che non dovrebbe mai fingere di essere.

La versione in 30 secondi

Una discovery dura di solito da una a sei settimane e costa tra il 10 e il 15 per cento del budget totale del progetto. Produce un documento di perimetro, le user story, una mappa degli stakeholder, una direzione architetturale, prototipi a bassa fedeltà e una roadmap con una stima di costo. Esiste perché i requisiti poco chiari sono la prima causa di fallimento dei progetti software. Non fissa un prezzo definitivo, non sostituisce la costruzione e smette di dare valore nel momento in cui hai abbastanza chiarezza per partire.

Perché serve la discovery

La maggior parte dei progetti software non fallisce sulla qualità del codice. Fallisce sui requisiti. L'analisi dello Standish Group mette i requisiti poco chiari in cima alle cause, davanti allo scope creep e alla pianificazione inadeguata. Il Project Management Institute riporta la stessa forma: requisiti imprecisi o gestiti male stanno dietro a circa quattro progetti falliti su dieci. Le analisi di settore stimano che metà del rilavoro in un progetto derivi da requisiti raccolti male fin dall'inizio.

La discovery è il posto più economico in cui sbagliare. Cambiare una decisione in un documento costa una email. Cambiare la stessa decisione dopo tre sprint di codice costa settimane. Questa differenza è tutta la ragione economica della fase, ed è il motivo per cui saltarla su qualcosa di non banale di solito costa più che farla.

Come si svolge una discovery

Il lavoro è in parte intervista, in parte workshop, in parte sonda tecnica. Parte da sessioni che tirano fuori l'obiettivo reale dalla testa del fondatore e lo portano su una lavagna condivisa: il problema, gli utenti, il modello di ricavo, i vincoli. Da lì il team esegue poche attività mirate. I workshop sui requisiti trasformano gli obiettivi in funzionalità delimitate. Uno spike tecnico mette alla prova l'integrazione rischiosa o l'ipotesi non verificata prima che venga prezzata. Interviste rapide a utenti o stakeholder verificano che il problema sia quello che vale la pena risolvere. Ogni attività termina in uno dei deliverable qui sotto: è così che distingui una discovery vera da una serie di riunioni. Ogni sessione produce qualcosa su cui qualcuno può agire.

Cosa produce davvero una discovery

Una discovery seria produce artefatti, non slide. L'insieme preciso varia da progetto a progetto, ma sei deliverable compaiono in quasi ogni caso:

• Un documento di perimetro. Il riferimento unico per cosa è dentro, cosa è esplicitamente fuori e perché. Ogni discussione futura su "era compreso?" si chiude qui.
• User story e casi d'uso. Le funzionalità descritte dal punto di vista di chi le usa, con il dettaglio sufficiente per stimarle e poi testarle.
• Una mappa degli stakeholder. Chi decide, chi approva, chi va consultato e come ciascuno vuole essere tenuto aggiornato.
• Una direzione architetturale. Le scelte tecniche principali (stack, modello dati, integrazioni, hosting) con i compromessi messi nero su bianco, non il progetto completo del sistema.
• Prototipi a bassa fedeltà. Cliccabili quanto basta per scovare i problemi di flusso prima che diventino codice, non rifiniti al punto da confonderli con il prodotto.
• Una roadmap con una stima. Un piano a fasi e una fascia di costo legata a ipotesi esplicite, così il numero si muove solo quando si muovono le ipotesi.

Quanto dura e quanto costa

La durata segue la complessità. Uno strumento interno semplice o un MVP essenziale sta in una o due settimane. La maggior parte dei software gestionali si assesta tra due e quattro settimane. Sistemi enterprise, funzioni di AI o requisiti di conformità pesanti la portano tra quattro e otto. Quattro settimane sono il punto di equilibrio più comune tra velocità e profondità.

Il costo di solito è tra il 10 e il 15 per cento del budget di sviluppo. In concreto, un MVP con un budget di 50.000 dollari porta con sé circa 2.500-5.000 dollari di discovery; una piattaforma SaaS completa intorno ai 150.000 dollari va sugli 8.000-15.000. I fornitori che vendono discovery stimano che spendere il 5-10 per cento del budget in questa fase riduca lo sforamento di sviluppo del 40-60 per cento. Vale come indicazione di direzione da parte interessata, non come legge. La direzione, però, coincide con i dati sui fallimenti da requisiti: prima intercetti un'ipotesi sbagliata, meno costa.

Immagina un team di due fondatori che arriva con "un marketplace per X". Quattro settimane di discovery possono trasformarlo in un insieme di user story delimitate, nella decisione di lanciare prima un solo lato del marketplace, in un'integrazione di pagamento segnalata come rischio tecnico principale e in una stima con una banda di oscillazione legata a una domanda aperta: se la messaggistica interna entra al lancio. Quella singola domanda può valere tre settimane di scostamento sui tempi. Trovarla in un documento invece che allo sprint sei è il senso della fase.

Quattro cose che la discovery non dovrebbe fingere di essere

La fase si guadagna fiducia essendo onesta sui propri limiti.

1. Un prezzo definitivo. La discovery produce una fascia e una lista di ipotesi, non un numero da contratto. Chi ti dà un totale preciso per un prodotto non ancora costruito sta prezzando sulla fiducia.
2. Un sostituto della costruzione. Un prototipo cliccabile è uno strumento di comunicazione. Non ha dati veri, né casi limite, né tenuta di produzione. Scambiarlo per il prodotto è il modo in cui i tempi slittano.
3. Il posto dove disegnare ogni schermata. La UI al pixel per tutta l'app e un backlog scritto per intero appartengono alla fase di delivery. Pagarli a tariffa di discovery è costoso e prematuro.
4. Una ricerca di certezza. Oltre le otto settimane circa, la discovery scivola nella paralisi da analisi. L'obiettivo è chiarezza sufficiente per muoversi con sicurezza, non una conoscenza perfetta che non arriverà mai.

Un'ultima, a bassa voce: la discovery non dovrebbe essere una proposta commerciale travestita da ricerca. Una discovery che può concludersi solo con "sì, affidateci l'intero sviluppo" non era ricerca. Una vera può finire con "costruite prima una versione più piccola", o "questo non ha nemmeno bisogno di software su misura".

Quando puoi saltarla

Puoi saltare una discovery formale quando il perimetro è davvero piccolo e ben capito: una landing page, una singola integrazione, una modifica a un sistema che già gestisci. Per qualsiasi cosa multi-tenant, regolamentata o più lunga di poche settimane, saltare la discovery è di solito il punto in cui inizia lo sforamento.

Dove sta la discovery rispetto a costo e scelta del partner

La discovery è la prima voce di un budget di sviluppo, quindi si legge bene insieme a quanto costa sviluppare un SaaS nel 2026. Se stai facendo una discovery per confrontare fornitori, i sei deliverable qui sopra funzionano anche da scheda di valutazione: ogni offerente serio dovrebbe restituirti gli stessi artefatti.