Come scrivere un brief per una software house (e ricevere preventivi confrontabili)
A cosa serve un brief
Serve a far preventivare a tutti i fornitori la stessa cosa. Se ognuno immagina un progetto diverso, vi arrivano numeri diversi e non avete modo di confrontarli.
Cinquanta pagine di documento tecnico non servono. Basta una descrizione chiara del problema, di chi userà il software e di cosa deve fare, in italiano semplice. Il resto tocca al fornitore capirlo, e dalle domande che vi farà vedrete se l'ha capito.
Partite dal problema
La prima parte del brief racconta il problema che volete risolvere. Il software che avete in testa viene dopo, se viene. Un fornitore che conosce il problema può proporvi una soluzione migliore di quella che avevate immaginato.
"Vogliamo un'app con dieci schermate" dice poco. Provate invece con qualcosa come "oggi i nostri tecnici compilano i rapporti di intervento su carta, li fotografano e li mandano in chat, poi in ufficio qualcuno li ricopia a mano e passano due giorni prima di poter fatturare". Con questa frase il fornitore può chiedersi se l'app serva, se basti un modulo web o se il nodo sia nella fatturazione.
Raccontate anche cosa usate oggi. Fogli Excel, un gestionale vecchio, email, carta. Se vi riconoscete in Quando i fogli Excel sono diventati il tuo gestionale, ditelo, perché è un'informazione che pesa. E se non avete ancora deciso se costruire o comprare, conviene chiarirlo prima di scrivere: ne parliamo in Gestionale su misura o software standard?.
Cosa deve contenere
Sei elementi, nel formato che preferite. L'importante è che ci siano tutti.
- Il contesto. Chi siete, cosa fate, quante persone lavorano nell'area coinvolta.
- Il problema. Cosa non funziona oggi e quanto vi costa, anche solo in ore.
- Gli utenti. Chi userà il software, quanti sono, da dove (ufficio, magazzino, cantiere, clienti da casa) e con quali dispositivi.
- Le cose che deve fare, in un elenco semplice ordinato per importanza. Tenete ben separato quello che è indispensabile da quello che sarebbe bello avere.
- I sistemi con cui deve parlare. Contabilità, e-commerce, CRM, il gestionale che c'è già, con i riferimenti di chi li segue se li avete.
- I vincoli. Una scadenza vera come una fiera, un lancio o la fine di un contratto, eventuali requisiti normativi, e il budget indicativo se volete condividerlo.
Sul budget non avete obblighi. Una fascia indicativa però aiuta il fornitore a proporvi la versione giusta del progetto invece di tirare a indovinare. Se preferite tenerlo per voi, chiedete almeno una versione minima e una completa.
Cosa lasciare fuori
Le scelte tecniche, salvo motivi precisi. Linguaggi, framework e database li decide chi dovrà costruire e mantenere il sistema.
Scrivere "va fatto con la tecnologia X" ha un effetto preciso. I fornitori che lavorerebbero meglio con altro si adeguano oppure non rispondono, e voi perdete proposte che magari erano migliori. Il discorso cambia se il vincolo esiste davvero, per esempio un'infrastruttura aziendale già definita, un team interno che manterrà il codice, una policy di sicurezza. In quel caso scrivete il vincolo e spiegate perché.
Fuori anche i dettagli grafici minuti. Colori e posizione dei bottoni si decidono in progettazione, guardando gli utenti veri.
Chiedete risposte voce per voce
Perché i preventivi siano confrontabili, chiedete a tutti di rispondere seguendo il vostro elenco. Ogni voce deve tornare con scritto "inclusa", "esclusa" oppure "inclusa a queste condizioni".
È il modo più semplice per smontare il classico caso dei preventivi che differiscono del triplo, di cui abbiamo parlato in Come si prezza davvero un software su misura. Due cifre lontane diventano leggibili appena vedete che una comprende la migrazione dei dati e l'altra no.
In fondo al brief aggiungete le domande che volete uguali per tutti:
- Cosa è incluso dopo la consegna, e per quanto tempo?
- Come vedremo l'avanzamento del lavoro durante lo sviluppo?
- Cosa succede se a metà progetto cambiamo una priorità?
- Di chi saranno il codice, il database e gli accessi all'infrastruttura?
Leggete le assunzioni
Della risposta, la parte più utile sono le assunzioni. Più del prezzo. Lì capite chi ha ragionato sul vostro progetto.
Un fornitore che scrive "assumiamo che i dati attuali siano esportabili in un formato leggibile" ha individuato un rischio reale. Chi non scrive nessuna assunzione quel ragionamento non l'ha ancora fatto, e lo farà a progetto avviato. Allo stesso modo, le domande che vi arrivano dopo la lettura del brief valgono più di una presentazione ben confezionata.
Prima di scrivere codice noi facciamo una fase di scope e discovery, proprio per trasformare il brief in un perimetro condiviso. Con qualunque fornitore, comunque, un brief chiaro rende questa fase più corta e più precisa.
Domande frequenti
Quanto deve essere lungo un brief per una software house?
Per la maggior parte dei progetti bastano da due a cinque pagine. Contano la chiarezza del problema e l'elenco delle funzioni in ordine di importanza, molto più del numero di pagine. Un brief troppo dettagliato rischia di imporre soluzioni prima che se ne sia discusso.
Devo indicare il budget nel brief?
Non è obbligatorio, ma una fascia indicativa vi fa arrivare proposte più realistiche. In alternativa chiedete a ogni fornitore una versione essenziale e una completa, così potete confrontare anche le priorità.
Cosa faccio se non so descrivere cosa deve fare il software?
Raccontate come lavorate oggi, un passaggio alla volta, e dove il processo si inceppa. Un buon fornitore saprà ricavarne le funzioni e ve le proporrà da confermare.
