--- title: "Cosa deve consegnare una fase di discovery a pagamento" description: "Cosa deve produrre una fase di discovery a pagamento prima dello sviluppo: decisioni, rischi testati, stime in forchetta, una prima milestone, un'uscita pulita." canonical: https://sdk.enterprises/it/insights/what-a-paid-discovery-phase-should-deliver language: it --- # Cosa deve consegnare una fase di discovery a pagamento Aggiornato il: 2026-09-26 > Una fase di discovery a pagamento deve chiudersi con delle decisioni, non solo con dei documenti: che cosa costruire per primo e che cosa lasciare fuori, i rischi principali e come sono stati testati, una stima espressa come forchetta con le sue ipotesi, e una prima milestone pronta a partire. Giudicatela con un solo test: potreste portare i risultati a un altro team e iniziare a sviluppare senza ricominciare da capo? ## La discovery serve a prendere le grandi decisioni finché costano poco La discovery, chiamata anche analisi preliminare, scoping o inception, è una breve fase a pagamento che precede lo sviluppo di un software. Il suo compito è eliminare l'incertezza che rende inaffidabili le stime e fissare le grandi decisioni finché cambiarle costa ancora poco. Cambiare una decisione sulla carta costa una conversazione; cambiarla dopo che il codice è stato scritto costa lavoro da rifare. Le prime stime di un software sono ampie, e si restringono solo man mano che le decisioni eliminano l'incertezza, un effetto spesso chiamato cono dell'incertezza. Le riunioni da sole non le restringono. Vale la pena pagare la discovery quando costringe a prendere quelle decisioni: che cosa deve fare per prima cosa il prodotto, quali vincoli sono fissi e quali rischi tecnici sono reali. ## Concordate che cosa riceverete prima che la discovery inizi Acquistate la discovery come qualsiasi altro deliverable: una durata fissa, un prezzo fisso, persone indicate per nome e un elenco scritto dei risultati. Se un partner non sa dirvi che cosa avrete in mano alla fine, la fase rischia di trasformarsi in workshop senza fine. Un insieme completo di risultati di solito comprende quanto segue. - Una definizione del problema: chi sono gli utenti, di che cosa hanno bisogno e come si misurerà il successo - Il perimetro della prima release: che cosa c'è, che cosa resta fuori e che cosa viene rimandato - I principali percorsi utente, abbozzati o prototipati dove sono incerti - Uno schema dell'architettura: componenti principali, integrazioni, dati e hosting, con le opzioni valutate - Un registro dei rischi che ordina ciò che potrebbe far fallire il progetto, e come verrà gestito ciascun rischio - Una stima in forchetta con le sue ipotesi, e una prima milestone con i criteri di collaudo - Un registro delle decisioni che annota che cosa è stato deciso, da chi e perché ## Cercate decisioni, non una pila di documenti Un report di discovery può essere lungo e non decidere nulla. Leggetelo cercando gli impegni presi: quali funzionalità entrano nella prima release e quali no, quali scelte di tecnologia e di hosting sono state fatte, quali integrazioni servono, e quali domande restano aperte, ciascuna con un responsabile e una data. Un segnale utile è ciò che il partner vi ha sconsigliato. Se alla fine il perimetro è più ampio che all'inizio e non è stato tagliato nulla, probabilmente la discovery ha registrato la vostra lista dei desideri invece di metterla alla prova. A volte la conclusione giusta è acquistare un prodotto esistente, costruire di meno o non costruire affatto, e una buona fase di discovery lo dice. ## Le ipotesi più rischiose vanno testate, non solo elencate Ogni progetto si basa su alcune ipotesi che, se fossero sbagliate, cambierebbero tutto: un'API esterna che non supporta l'operazione che vi serve, dati più disordinati del previsto, un obiettivo di prestazioni che la soluzione scelta non può raggiungere, o utenti che non cambieranno il loro modo di lavorare. Chiedete al partner di indicare presto queste ipotesi e di testare le peggiori durante la discovery, con uno spike tecnico, un prototipo cliccabile o una sessione di lavoro con le persone che gestiscono il sistema in questione. Un rischio testato è un'informazione. Un rischio soltanto messo per iscritto resta un'ipotesi. ## Una stima onesta è una forchetta accompagnata dalle sue ipotesi Un numero unico alla fine della discovery nasconde l'incertezza che rimane. Chiedete una forchetta per la prima release, suddivisa per componente principale, con le ipotesi che la farebbero salire o scendere. Per esempio: la stima presuppone che l'API del fornitore dei pagamenti supporti già i rimborsi parziali; in caso contrario, va aggiunto il lavoro di integrazione indicato a parte. Chiedete quali parti della stima sono solide e quali restano incerte, e come il modello commerciale tratterà ciascuna di esse. Le parti solide possono essere quotate a prezzo fisso; quelle incerte hanno bisogno di un budget e di un momento in cui decidere di nuovo. La prima milestone deve essere specificata abbastanza bene da poter essere consegnata a prezzo fisso. ## Tenete una via d'uscita a ogni passo La discovery è anche il momento meno costoso per andarsene. Assicuratevi che tutto ciò che produce sia vostro, dai documenti e dai diagrammi ai prototipi e al codice, e che i risultati siano scritti per qualsiasi team competente, non solo per il partner che li ha redatti. Dovete restare liberi di sviluppare con quel partner, affidare i risultati a un altro team, sviluppare internamente o fermarvi. Applicate la stessa idea al piano che segue: una prima milestone con criteri di collaudo, poi un punto di decisione in cui potete proseguire, cambiare rotta o chiudere la collaborazione. È così che avviamo i progetti in SDK Enterprises: un perimetro scritto, una prima milestone definita e gli ingegneri indicati per nome, così vedete il piano prima di impegnarvi su un budget più grande. Quando vi serve solo un consiglio, ricevete una risposta scritta su cui il vostro team può agire, che poi sviluppiate con noi o no. ## Sei domande per capire se la discovery valeva il prezzo pagato Alla fine della fase, confrontate i risultati con queste domande. Se la maggior parte delle risposte è sì, quel denaro ha comprato chiarezza. Se la maggior parte è no, avete pagato dei workshop. - Un altro team potrebbe iniziare a sviluppare partendo da questi risultati senza ripetere la discovery? - Il partner ha parlato con gli utenti e con le persone che gestiscono i sistemi coinvolti, non solo con lo sponsor? - Le ipotesi più rischiose sono state testate, con i risultati messi per iscritto? - La stima è una forchetta con ipotesi chiare invece di un numero unico? - Qualcosa è stato tagliato, rimandato o messo in discussione? - La prima milestone è specificata abbastanza bene da poter essere accettata o respinta? ## Punti chiave - Acquistate la discovery con una durata fissa, un prezzo fisso, persone indicate per nome e un elenco scritto dei risultati. - Giudicate i risultati dalle decisioni che contengono, compreso ciò che è stato tagliato o sconsigliato. - Le ipotesi più rischiose vanno testate durante la discovery, non solo elencate in un registro dei rischi. - Aspettatevi una stima in forchetta con le sue ipotesi, e una prima milestone specificata abbastanza bene da poter essere quotata. - Siate titolari di ogni risultato, così potete sviluppare con quel partner, con un altro team o non sviluppare affatto. ## Domande frequenti ### La discovery va pagata, o un partner può farla gratis? Un'analisi gratuita fa parte della vendita, quindi si ferma a ciò che entra in una proposta commerciale. Pagare la discovery compra il tempo per leggere il vostro codice, parlare con i vostri utenti e testare i rischi, oltre a risultati che vi appartengono. Tenete la fase breve e a prezzo fisso, così l'impegno resta contenuto. ### Quanto deve durare una fase di discovery? Il tempo necessario a rispondere alle domande che impediscono una stima affidabile, e non di più. Concordate la durata in anticipo in base alle dimensioni del prodotto e al numero di sistemi coinvolti, e chiudete con una decisione sulla prima milestone invece che con un prolungamento della discovery. ### E se la discovery dimostra che non vale la pena sviluppare il progetto? Allora ha fatto il suo lavoro al costo più basso possibile. Una buona fase di discovery può concludere che conviene acquistare un prodotto esistente, costruire una prima versione più piccola o fermarsi, e in ogni caso le conclusioni restano a voi. ## Partite dalla vostra esigenza - [Sviluppo di app mobile](https://sdk.enterprises/it/mobile-app-development) ## Servizi correlati - [Audit tecnico e consulenza](https://sdk.enterprises/it/services/consulting) - [Software su misura](https://sdk.enterprises/it/services/product-engineering) ## Per approfondire - [Domande da fare prima di scegliere un partner software](https://sdk.enterprises/it/insights/choosing-a-software-partner) - [Come scrivere un brief software per preventivi confrontabili](https://sdk.enterprises/it/insights/writing-a-software-project-brief)