--- title: "Come scrivere un brief software per preventivi confrontabili" description: "Cosa mettere nel brief di un progetto software per avere preventivi accurati: problema, utenti, sistemi, dati, budget, cosa lasciare aperto, errori da evitare." canonical: https://sdk.enterprises/it/insights/writing-a-software-project-brief language: it --- # Come scrivere un brief software per preventivi confrontabili Aggiornato il: 2026-09-26 > Un buon brief per un progetto software descrive il problema, gli utenti, i sistemi coinvolti e che cosa significa successo, e lascia aperta la soluzione alle proposte dei partner. Inviate a ogni partner lo stesso brief, con una forchetta di budget e un elenco chiaro di ciò che è vincolante: le proposte che riceverete saranno abbastanza precise da poterle confrontare. ## Un brief serve a rendere confrontabili le risposte Un brief di progetto ha un solo compito: permettere a più partner di capire il vostro problema abbastanza bene da proporre un modo per risolverlo, con una stima di cui potete fidarvi. Se ogni partner colma le lacune con le proprie ipotesi, le proposte differiscono nel perimetro invece che nella qualità, e la più economica è spesso quella che ha dato per scontato di meno. Il brief deve quindi essere preciso sul problema e modesto sulla soluzione. Descrivete che cosa deve essere vero a progetto concluso, e lasciate che i partner spieghino come ci arriverebbero. Le loro risposte su questa parte aperta sono la cosa più utile che leggerete. ## Partite dal problema di business e da come giudicherete il successo Aprite con il motivo per cui il progetto esiste: che cosa non funziona oggi, chi ne risente e quanto vi costa lasciare le cose come stanno. Dire che il vostro team operativo ribatte a mano nell'ERP ogni ordine ricevuto via email dice a un partner molto più che chiedere un portale di gestione degli ordini. Poi dite come giudicherete il successo. Scegliete alcuni risultati osservabili, come il tempo risparmiato per ordine, gli errori che non arrivano più ai clienti o una data entro cui si potrà spegnere un vecchio sistema. Questi criteri diventeranno in seguito i criteri di collaudo delle milestone, quindi formulateli in termini che qualcuno possa verificare. ## Descrivete utenti, sistemi e dati prima delle funzionalità Il lavoro di integrazione e sui dati è facile da sottovalutare quando un partner non lo vede. Prima di elencare le funzionalità, descrivete chi userà il software, con quali sistemi deve funzionare e quali dati gestisce. Le lacune in questa parte tornano più avanti sotto forma di richieste di modifica. - Utenti: chi sono, quanti sono all'incirca, dove lavorano e con quali dispositivi. - Sistemi esistenti: quali sono, chi ne è responsabile e se offrono un'API documentata o solo un database ed esportazioni di file. - Dati: quali sono personali, riservati o regolamentati, dove si trovano oggi e quanti ne vanno migrati. - Gestione operativa: chi farà funzionare il software dopo il lancio, e quali regole di hosting o di cloud la vostra azienda applica già. - Vincoli: lingue, requisiti di accessibilità, standard di sicurezza e qualsiasi scadenza che non si può spostare, con il relativo motivo. ## Indicate una forchetta di budget e la scadenza che conta davvero Molti acquirenti non dicono il budget per vedere che cosa propongono i partner. Il risultato sono proposte per progetti diversi: un partner progetta per il minimo, un altro per tutto ciò che avete nominato. Una forchetta, anche ampia, permette a ogni partner di proporre il miglior progetto che ci sta dentro, e di dirvi chiaramente se non ci sta. Fate lo stesso con i tempi. Dite quale data è fissa e perché, per esempio un contratto in scadenza o un obbligo normativo, e quali date sono solo preferenze. Un partner può organizzarsi intorno a una data inderogabile solo se sa qual è. ## Indicate che cosa è vincolante e lasciate aperto il resto Classificate ogni requisito come vincolante, preferito o aperto. Vincolante significa che una proposta non è valida senza di esso, come l'hosting nell'UE o l'accesso tramite il vostro identity provider esistente. Preferito significa che avete un motivo, ma prendereste in considerazione un'alternativa. Aperto significa che volete la raccomandazione del partner. Lasciate aperta la tecnologia, a meno che non abbiate un motivo reale per fissarla, come un team interno che manterrà il codice o una piattaforma su cui la vostra azienda si è standardizzata. Quando fissate una scelta, spiegate perché, così i partner non passano la proposta a contestarla. Infine, chiedete a ogni partner di rispondere con la stessa struttura: come ha capito il problema, l'approccio, le fasi e le milestone, le ipotesi, i rischi, il team e il modello commerciale. Una struttura comune è ciò che rende le proposte confrontabili nella pratica. ## Errori che rendono impossibile confrontare le proposte Molte proposte inutilizzabili rispondono a un brief che le ha provocate. Eliminate questi schemi prima di inviare il vostro. - Un elenco di funzionalità senza una descrizione del problema, così ogni partner tira a indovinare le vostre priorità. - Una lunga specifica che fissa la soluzione prima che qualcuno abbia esaminato il problema. - Nessuna menzione dei sistemi esistenti o della migrazione dei dati, che poi tornano come richieste di modifica. - Dettagli in più dati solo ad alcuni partner durante le call, così le loro proposte rispondono a domande diverse. - Parole come «semplice», «standard» o «come un'app famosa», che significano qualcosa di diverso per ogni lettore. - Nessuna scadenza per le domande, o risposte condivise solo con il partner che le ha poste. ## Invitate le domande e leggetele come parte della valutazione Date ai partner un periodo definito per fare domande, rispondete per iscritto e inviate ogni risposta a tutti. Le domande dicono già qualcosa di per sé: un partner che chiede dei vostri dati, dei vostri utenti e dei vostri criteri di collaudo sta già pensando alla consegna. Se il problema è ancora troppo incerto per descriverlo bene, ditelo e chiedete una breve fase di discovery a pagamento invece di una proposta completa. Un preventivo fisso costruito su supposizioni nasconde le incognite nel suo margine di rischio; una fase di discovery sostituisce le supposizioni con i fatti. Se volete che degli ingegneri leggano il vostro brief, o che rispondano, potete inviarlo tramite il nostro modulo «Avviare un progetto». ## Punti chiave - Descrivete il problema, gli utenti e che cosa significa successo, e lasciate aperta la soluzione. - Il lavoro di integrazione e sui dati è facile da sottovalutare, quindi elencate ogni sistema e ogni insieme di dati coinvolto. - Indicate una forchetta di budget e dite quale scadenza è fissa, e perché. - Classificate ogni requisito come vincolante, preferito o aperto, e chiedete proposte con una struttura comune. - Rispondete alle domande per iscritto e condividete ogni risposta con tutti i partner. ## Domande frequenti ### Quanto deve essere lungo il brief di un progetto software? Abbastanza da coprire problema, utenti, sistemi, dati, vincoli, forchetta di budget e tempistiche, cosa che per la maggior parte dei progetti sta in poche pagine. Se si allunga molto di più, probabilmente sta descrivendo la soluzione invece del problema. ### Conviene comunicare il budget ai partner software? Sì, sotto forma di forchetta. Senza, i partner propongono progetti di dimensioni molto diverse e non potete confrontarli. Una forchetta permette a ogni partner di mostrare che cosa farebbe entro quei limiti, e di dirvi onestamente se non bastano. ### Conviene chiedere un prezzo fisso in risposta a un brief? Solo se il brief descrive il lavoro con abbastanza dettagli da poterlo stimare. Se alcune domande chiave sono ancora aperte, chiedete una fase di discovery a prezzo fisso o una forchetta di stima con ipotesi esplicite, e fissate il prezzo della realizzazione quando le incognite sono state risolte. ## Partite dalla vostra esigenza - [Realizzazione di siti web](https://sdk.enterprises/it/website-development) ## Servizi correlati - [Software su misura](https://sdk.enterprises/it/services/product-engineering) - [Audit tecnico e consulenza](https://sdk.enterprises/it/services/consulting) ## Per approfondire - [Cosa deve consegnare una fase di discovery a pagamento](https://sdk.enterprises/it/insights/what-a-paid-discovery-phase-should-deliver) - [Prezzo fisso o time and material: quale contratto scegliere](https://sdk.enterprises/it/insights/fixed-price-or-time-and-materials)