Definizione del progetto
Definire un software operativo su misura partendo da un processo reale
Un brief utile parte dal lavoro difficile da completare o verificare, non da un elenco di schermate. Un processo concreto dà al team un riferimento condiviso per decidere cosa deve cambiare nella prima release.
Descrivi evento iniziale, persone e prossima azione
Chiedi cosa avvia il processo, chi riceve l'informazione, chi decide e cosa succede quando il lavoro è in ritardo o poco chiaro. Nomina gli strumenti già coinvolti e il punto in cui l'informazione viene copiata o ricostruita.
La descrizione può essere breve. Deve però distinguere un sintomo, come le continue chiamate per chiedere lo stato, dal passaggio sottostante che rende necessarie quelle chiamate.
Trasforma il risultato desiderato in una prova
Scegli pochi scenari prioritari e scrivi cosa deve poter fare una persona in ciascuno. Includi dati rilevanti, ruolo, eccezione e risultato visibile. Gli scenari diventano criteri di accettazione, senza promettere che ogni funzione possibile rientri nella prima versione.
Per uno strumento di passaggio consegne può significare trovare una procedura insieme a registrazione, trascrizione e fonte. Per una vista consegne può significare individuare stato corrente e responsabile della prossima azione. I criteri esatti devono nascere dal processo del cliente.
Dai un prezzo a un perimetro definito e conserva la decisione
La consulenza iniziale è gratuita e senza impegno. Quando requisiti e vincoli sono chiari, un preventivo versionato può dichiarare deliverable, ipotesi, esclusioni e prezzo. Lo sviluppo inizia solo dopo l'approvazione del preventivo applicabile.
Se il perimetro cambia durante il confronto, si crea una nuova versione del preventivo. Decisione e contesto restano accanto alla richiesta, così una conversazione successiva non cancella ciò che è stato concordato.
Usa una preview per verificare i casi concordati
Una preview protetta permette al cliente di provare gli scenari prioritari su un incremento funzionante. Il feedback fa riferimento al caso e al risultato atteso, rendendo la modifica successiva specifica e verificabile.
La scelta nella review non equivale automaticamente ad accettazione contrattuale o autorizzazione al rilascio. Registra la decisione, completa le verifiche concordate e rendi visibile la prossima azione prima di pubblicare una release versionata.
Un brief pronto da discutere
- Cosa avvia il processo e chi possiede la prossima azione?
- Quali sistemi esistenti e vincoli orientano la prima versione?
- Quali tre scenari dimostrerebbero un risultato utile?
- Cosa va deciso prima di approvare un preventivo?