Come preparare il brief per un’applicazione su misura senza scrivere una specifica tecnica.

Un brief di sviluppo non ha bisogno di iniziare con un diagramma di database. Deve spiegare un lavoro che qualcuno dovrebbe essere in grado di completare e il risultato che il vostro business ha bisogno da esso.

L'obiettivo del primo brief è quello di rendere il progetto discutibile, lasciando aperte le scelte tecniche, pur essendo precisi sul lavoro che l'applicazione deve sostenere.

Iniziare con un utente e un'attività

“Build a portal” nomina un tipo di software. “Lascia che un cliente approvato presenti una richiesta di servizio e veda i suoi progressi” descrive un utile primo flusso di lavoro.

In questo esempio, un membro del personale deve rivedere la richiesta e aggiornare il suo stato, il che significa che il brief contiene già due ruoli diversi e un record condiviso.

Evitare di iniziare con “un’app per tutti”. Diversi utenti potrebbero aver bisogno di autorizzazioni, schermi e informazioni diverse.

Spiega cosa succede oggi

Forse un cliente invia informazioni, un membro del personale lo copia in un foglio di calcolo e un'altra persona invia un aggiornamento del progresso. Stato dove si verifica confusione o sforzo ripetuto, senza assumere che il software risolverà ogni problema circostante.

Un esempio redatto del modulo o del record corrente può essere più utile di una presentazione lucida.

Descrivi un viaggio completo

Seguire un record rappresentativo dall'inizio alla fine. Che cosa inizia? Quali informazioni sono necessarie? Chi prende la decisione successiva? Che cosa lo segna come completo?

Includi una o due importanti eccezioni. Una richiesta può essere incompleta, un recensore può rifiutarla o un utente può avere bisogno di correggere un errore.Questi casi aiutano a distinguere un'applicazione di lavoro da una dimostrazione del percorso ideale.

Non è necessario inventare ogni raro evento in questa fase. Concentrati sulle eccezioni che impediranno al flusso di lavoro principale di essere utile.

Nome dei dati e dipendenze

Elenca i record importanti: utenti, richieste, prodotti, prenotazioni, file o un altro insieme di informazioni. Spiega da dove vengono e chi è responsabile per il loro mantenimento.

Per un'integrazione, nominare l'altro servizio e fornire la sua documentazione quando disponibile. "Connesso al nostro CRM" lascia aperte le principali domande. Il dettaglio utile è quale record dovrebbe muoversi, in quale direzione e dopo quale evento.

Identificare se i disegni, il contenuto del prodotto, l'accesso del conto o le regole aziendali sono già disponibili. I materiali mancanti non sono automaticamente bloccanti, ma hanno bisogno di un proprietario e un posto nel piano.

Definire la prima versione utile

Separare la consegna principale da idee successive. Un primo portale potrebbe sostenere la creazione di una richiesta, la revisione e la visualizzazione dello stato. Messaging, report avanzato e un'app mobile potrebbe essere in seguito discussioni piuttosto che requisiti insopportati della prima costruzione.

Questo non è un'istruzione per costruire qualcosa di incompleto. Il flusso di lavoro scelto dovrebbe funzionare dall'inizio alla fine. Il confine è tra flussi di lavoro completi, non tra uno schermo attraente e la logica di cui ha ancora bisogno.

Scrivere un esempio di accettazione

Prova una frase che qualcuno potrebbe testare:

Un cliente autorizzato può presentare una richiesta, vedere il suo stato dopo la firma e visualizzare solo le proprie richieste.Un membro del personale autorizzato può aggiornare lo stato, e il cliente vede tale cambiamento.

Questo è un requisito illustrativo, non una descrizione di un progetto client esistente, che rende il comportamento atteso molto più chiaro di “un portale moderno e sicuro”.

Aggiungere vincoli pratici

Dichiara il tuo tempismo desiderato, sia che si tratti di una preferenza o di una data esterna fissa, e l'intervallo di budget dove noto.

Descrivi anche le aspettative di rilascio e di consegna. Chi possiederà l'hosting e i conti? Un altro sviluppatore ha bisogno di ricevere il codice? Queste domande influenzano la consegna anche quando non appaiono su uno schermo.

Un breve che puoi usare

Vogliamo costruire: l'applicazione o il flusso di lavoro. I principali utenti sono: le persone e i ruoli. Devono: il compito principale e il risultato completato. Oggi questo avviene attraverso: il processo corrente. La prima versione deve includere: il flusso di lavoro completo essenziale. Deve connettersi a: i sistemi e la documentazione conosciuti. Abbiamo già: disegni, contenuti, account o dati di esempio. Ancora indeciso: domande da risolvere. Timing, budget e decision maker: i vincoli pratici.

Utilizzare alcune frasi chiare per ogni parte. Il brief è un punto di partenza per definire il progetto, non un test che è necessario passare prima di parlare con uno sviluppatore.

Discutere un'applicazione web personalizzata o Invia il tuo brief.