Il brief tecnico è il documento più sottovalutato in un progetto software. Si dedica settimane a scegliere il fornitore giusto, si discutono budget e tecnologie, ma poi si descrive ciò che si vuole costruire in un'email di quindici righe — spesso scritta di fretta, tra una riunione e l'altra. E poi ci si stupisce quando il risultato non corrisponde alle aspettative.
La maggior parte dei ritardi, dei costi aggiuntivi e dei malintesi nei progetti software non nasce da problemi tecnici. Nasce da requisiti scritti in modo ambiguo. Un brief chiaro non garantisce un progetto perfetto, ma riduce drasticamente la probabilità di costruire la cosa sbagliata.
Descrivi il problema, non la soluzione
L'errore più frequente è confondere il problema con la soluzione. Chi scrive un brief tende a descrivere l'interfaccia che immagina, non il bisogno che vuole soddisfare. Ma chi sviluppa ha bisogno di capire il problema per proporre la soluzione migliore — non necessariamente quella che hai già in testa.
Esempio concreto: invece di scrivere "voglio un bottone che esporta il report in PDF", scrivi "il mio commerciale perde circa 30 minuti al giorno a preparare manualmente i report da inviare ai clienti, copiando dati da tre fonti diverse". Il secondo descrive un problema reale. Il primo descrive una soluzione specifica che potrebbe essere giusta, ma potrebbe anche non esserlo.
I 5 elementi di un brief tecnico efficace
1. Contesto e utenti. Chi userà il sistema? Con quale frequenza? In quale contesto operativo — ufficio, cantiere, punto vendita, da remoto? Un'applicazione usata da un contabile in ufficio ha requisiti molto diversi da una usata da un tecnico sul campo.
2. Flussi principali step by step. Descrivi i processi che vuoi automatizzare, passo dopo passo. "L'utente inserisce l'ordine" non è sufficiente. "L'operatore riceve una telefonata, cerca il cliente per ragione sociale, verifica la disponibilità di magazzino in tempo reale, e conferma l'ordine generando automaticamente un documento di trasporto" è un flusso utile.
3. Integrazioni esistenti. Quali sistemi usa già la tua azienda? CRM, ERP, gestionali, piattaforme e-commerce, servizi di spedizione? Ogni integrazione ha un costo e una complessità. Elencarle permette di stimare con più precisione.
4. Vincoli tecnici o di compliance. Esistono requisiti normativi da rispettare? Dati sensibili da trattare secondo il GDPR? Infrastrutture già esistenti a cui il sistema deve adattarsi? Questi vincoli influenzano profondamente le scelte architetturali.
5. Definizione di "fatto". Come farai a sapere che il progetto è andato bene? Quali sono i criteri di accettazione? Un sistema che "funziona" è troppo vago. Un sistema che "permette all'operatore di completare un ordine in meno di 3 minuti senza errori di inserimento" è misurabile.
Cosa non mettere nel brief
Evita di includere soluzioni tecniche specifiche a meno che tu non abbia vincoli reali in quel senso. "Voglio che sia fatto in React con un backend Node.js" è una scelta tecnica, non un requisito di business. Se non hai ragioni specifiche per imporla, stai limitando le opzioni di chi deve costruire il sistema.
Allo stesso modo, evita wireframe e UI dettagliate nella fase di brief: definiscono troppo presto come appare il sistema, prima che si capisca bene cosa deve fare. E tralascia i dettagli irrilevanti: colori, font, preferenze estetiche appartengono alla fase di design, non al brief tecnico.
Un template minimo per iniziare: "Contesto: [chi siamo e cosa facciamo]. Problema: [cosa non funziona oggi e quanto ci costa]. Utenti: [chi usa il sistema e come]. Flussi: [i 2-3 processi principali]. Integrazioni: [sistemi esistenti]. Vincoli: [normativi, tecnici, di budget]. Successo: [come misuriamo che funziona]." Anche riempire solo questi campi mette già il progetto su basi molto più solide.
Un buon brief non è un documento lungo. È un documento preciso. E la precisione, in un progetto software, vale più di qualsiasi altra qualità. Una volta pronto, il passo successivo è scegliere il partner giusto a cui affidarlo.