Come scrivere il brief per un'agenzia di sviluppo software

Alla fine di questo articolo avrai un brief su cui uno studio di sviluppo software può fare un preventivo senza tirare a indovinare. Non una specifica tecnica. Non un elenco di funzionalità. Un documento breve che nomina il problema, traccia il perimetro, indica una fascia di budget e spiega come valuterai le proposte. Scritto bene, trasforma quattro preventivi vaghi e non confrontabili in quattro preventivi precisi che puoi mettere a confronto.

Conta perché la maggior parte dei progetti software fallisce sul brief, non sulla realizzazione. Nei dati sui fallimenti raccolti dai report CHAOS dello Standish Group, i requisiti poco chiari sono la causa più citata di fallimento dei progetti software, davanti allo scope creep e alla pianificazione debole (Gitnux, 2026). Uno studio non può quotare ciò che non vede. Quando il brief è scarno, o gonfia la stima per coprire le incognite o vince il lavoro e ritocca il prezzo dopo. In entrambi i casi paghi tu.

Cosa ti serve prima di iniziare

Non ti serve una specifica tecnica. Ti serve chiarezza su poche cose che già conosci:

• Il problema di business in una frase, con un numero accanto se ce l'hai.
• Una fascia di budget di massima che sei disposto a spendere, anche se è ampia.
• La scadenza reale e cosa la determina.
• Gli strumenti e i sistemi con cui il software deve dialogare.
• Chi in azienda può decidere e approvare il lavoro.

Se non sai rispondere ai primi due punti, non sei pronto per fare il brief a uno studio. Sei pronto, semmai, per una fase di discovery.

Passo 1: descrivi il problema, non la funzionalità

L'errore più comune nel brief è descrivere la soluzione che hai immaginato invece del problema che hai. "Vogliamo un portale clienti" è una funzionalità. "Il team di supporto passa circa il 40% della settimana a rispondere a email di aggiornamento sullo stato" è un problema. La prima frase blocca lo studio sulla tua ipotesi. La seconda gli lascia proporre qualcosa di migliore e quotarlo in modo onesto (Toptal).

Scrivi un paragrafo per ogni problema. Di' chi lo subisce, con quale frequenza e quanto ti costa oggi in tempo o denaro. Uno studio che legge un problema reale sa dimensionare il lavoro. Uno studio che legge un elenco secco di funzionalità indovina tutto quello che ci sta dietro.

Passo 2: spiega perché questo progetto e perché adesso

Il contesto dice allo studio quali sono le priorità. Un brief che dice "perdiamo due trattative enterprise a trimestre perché non abbiamo l'SSO" si legge in modo del tutto diverso da "ci piacerebbe l'SSO prima o poi". Indica l'innesco: un round di finanziamento, una scadenza di compliance, un concorrente, un rinnovo che stai per perdere. L'innesco stabilisce l'urgenza, e l'urgenza dà forma al piano.

Passo 3: traccia il perimetro con il MoSCoW

Il perimetro è dove i preventivi confrontabili vivono o muoiono. Se tre studi assumono ciascuno un perimetro diverso, i prezzi non sono confrontabili e non puoi scegliere. Risolvi assegnando una priorità a ogni requisito con il MoSCoW: Must have, Should have, Could have, Won't have. Il metodo è stato creato nel 1994 da Dai Clegg in Oracle e poi affidato al framework agile DSDM, e resiste perché costringe a una domanda onesta: cosa rende la versione uno un fallimento se manca (metodo MoSCoW)?

Metti ogni funzionalità in uno dei quattro secchi. Sii spietato con i "Must have". Se tutto è indispensabile, niente lo è. La lista dei "Won't have" conta quanto il resto: dice allo studio cosa lasciare fuori dalla stima, ed è così che il numero resta onesto.

Passo 4: dai una fascia di budget e una scadenza reale

I fondatori nascondono il budget per paura di vederselo quotare tutto. Succede il contrario. Senza una fascia, gli studi non capiscono se vuoi un prototipo da 15k o una piattaforma da 150k, quindi o sovradimensionano o si defilano. Basta un intervallo: "abbiamo da 40k a 60k per la versione uno". Specifica se la cifra include il supporto post-lancio e se è al lordo o al netto dell'IVA. Per la scadenza, dai la data che conta davvero e cosa la determina, non un ottimistico "il prima possibile" (Numiko).

Passo 5: elenca lo stack e ogni integrazione

Le integrazioni sono il punto in cui le stime saltano. Pagamenti, autenticazione, CRM, email, analytics e qualsiasi sistema legacy da cui il software deve leggere o scrivere sono tutti rischi che lo studio deve quotare. Elenca cosa usi oggi: Stripe, Supabase, HubSpot, qualunque cosa sia. Se un'integrazione va fatta, nominala. Un solo "deve anche sincronizzarsi con il nostro gestionale" non detto può spostare un preventivo di settimane.

Passo 6: indica chi decide e chi possiede i contenuti

Uno studio va alla velocità della tua approvazione più lenta. Di' chi firma, quante persone sono coinvolte e quanto velocemente riesci a restituire un feedback. Poi definisci i contenuti: chi scrive i testi, chi fornisce i dati, chi consegna gli asset di brand. I progetti si bloccano più spesso per i contenuti mancanti che per il codice mancante.

Passo 7: di' come valuterai le proposte

Spiega agli studi come deciderai. Dai peso al prezzo, ai lavori pertinenti, ai tempi o alla qualità delle domande che ti rimandano? Dichiarare i criteri fa due cose: esclude gli studi poco adatti e ti fa arrivare proposte più affilate da quelli che restano. Se stai gestendo un processo formale, è anche il momento di rimandare al tuo RFP.

Come verificare che il brief sia pronto

Fai tre prove prima di inviarlo:

1. La prova dell'estraneo. Dallo a qualcuno che non era nella stanza. Se sa spiegarti cosa vuoi, è chiaro. Se non ci riesce, riscrivi il punto torbido.
2. La prova del perimetro. Ogni requisito sta in un secchio MoSCoW e la lista dei "Won't have" non è vuota.
3. La prova del confronto. Due studi che lo leggono quoterebbero all'incirca lo stesso perimetro. Se indovinerebbero in modo diverso, c'è una lacuna da chiudere.

Errori comuni nel brief e come rimediare

• La specifica da 40 pagine. Un brief descrive il problema, una specifica descrive la soluzione. Se il tuo sembra un manuale di costruzione, hai tolto allo studio la possibilità di proporre una strada migliore. Riportalo a problema, perimetro e vincoli.
• L'elenco di funzionalità senza contesto. "Auth, dashboard, reportistica" non dice nulla sulla complessità. Aggiungi il perché dietro ogni riga.
• Niente budget, niente scadenza. Produce preventivi che non puoi confrontare e una rosa di cui non ti fidi. Un intervallo e una data reale sistemano tutto in due frasi.
• Tutto è un Must have. Lo scope creep parte da qui. Costringi almeno un terzo della lista sotto il "Must". L'espansione incontrollata del perimetro porta a uno sforamento di budget medio intorno al 27% (Stop Scope Creep, 2026).

Per andare oltre

Una volta uscito il brief, le decisioni successive sono commerciali: com'è fatto un preventivo equo e a chi mandarlo. Trattiamo entrambe in costo della fase di discovery e come ingaggiare uno studio di prodotto e ingegneria.