Come posso spostare un client dai modelli dell'interfaccia utente a una serie di requisiti reali?

Supponi di avere un mock-up di 25 schermate degli stati visivi della tua applicazione. L'aspettativa è che questo sia sufficiente per essere sicuri che possiamo svilupparlo e consegnarlo allo stakeholder o al cliente originale come un'applicazione finita, e saranno soddisfatti. Naturalmente, finirai per porre di nuovo agli stakeholder molte domande che sono state utilizzate per elaborare l'interfaccia utente, che è dispendiosa.

Tuttavia, molte volte ho scoperto che questo non è abbastanza, nel corso dello sviluppo dell'applicazione i requisiti vengono offuscati dal fatto che stiamo replicando un'interfaccia e alla fine il cliente non è così felice come sembrava prima quando abbiamo chiesto loro tutte le informazioni per creare l'interfaccia utente.

Non sono sicuro di cos'altro chiedere, ho cercato di essere specifico e chiedere requisiti e una comprensione dell'obiettivo generale, ma non so cosa dovrei chiedere. Se ho appena iniziato ora, si sprecherà molto tempo a rielaborare tutte le informazioni che portano all'interfaccia utente e durante questa fase verranno persi molti motivi importanti che il cliente aveva originariamente perso.

Come posso far capire alle persone che non possiamo bloccare i requisiti basati sui modelli dell'interfaccia utente chiedendo qualcosa che possono essere creati per me?

Che cosa avresti idealmente iniziato per eseguire correttamente l'attività di sviluppo di un'applicazione per gli utenti finali?

Alcune altre cose di cui potresti aver bisogno sono:

• Usecase o descrizioni del flusso di lavoro: solo perché sai come appare una schermata, sai quanto male viene gestito l'input? Sai come passare da una schermata all'altra in TUTTI i casi? Qui puoi includere anche la gestione degli errori.

• Descrizione del sistema di alto livello: qualcosa spiega cosa serve l'intero sistema per cui questi 25 schermi e cosa fanno.

• Modello di dati: è possibile inferire un modello di dati da queste schermate? Esiste un modello di dati che deve essere utilizzato o sei libero di progettare il tuo per fare il lavoro?

• Requisiti tecnici: le specifiche tecnologie che devono essere utilizzate a causa di licenze o per motivi di integrazione?

• Requisiti di prestazione: se c'è una schermata di ricerca, c'è un'aspettativa di cosa si può cercare e quanto velocemente dovrebbe essere la risposta? Che dire delle risposte per altri tipi di azioni? Alcuni di essi possono o dovrebbero essere asincroni (l'utente invia il lavoro e torna più tardi)?

• Requisiti di sicurezza: l'applicazione archivia dati potenzialmente sensibili / personali e, in caso affermativo, quali tipi di dati e cosa bisogna fare per proteggerli? Devi soddisfare un certo livello di conformità (come la conformità PCI per effettuare pagamenti con carta di credito)?

Inoltre, esiste qualche conoscenza specifica del dominio aziendale di cui potresti aver bisogno per assisterti? Alcuni settori come assicurazioni, banche, cartelle cliniche sanitarie, ecc ... hanno una logica aziendale complessa. Tali progetti non dovrebbero essere tentati senza l'aiuto di un analista aziendale che conosce quel dominio. Ma se è solo un carrello / sito di informazioni per widget generici, potrebbe non essere necessario un membro del team.

Come far capire alle persone che le simulazioni dell'interfaccia utente non sono sufficienti per creare un programma di lavoro:

Lo gestirò con un'analogia. Dal momento che sono un po 'un matto, sto andando su quella strada.

"Fai finta di non sapere nulla delle macchine. Mi dai alcune foto di una Ferrari. Una coppia dall'esterno e una dall'interno dell'auto (prese dal sedile del conducente in modo che io possa vedere i comandi per l'auto). Ora mi chiedi per costruirti una Ferrari. Torno con una cosa che assomiglia alle foto e ha tutti i controlli. Sfortunatamente, quei controlli non sono collegati a nulla perché (poiché non so nulla delle macchine) non so cosa i controlli dovrebbero fare. Non posso nemmeno fare un'ipotesi perché non so nemmeno cosa dovrebbero fare le auto. Quindi abbiamo una conversazione come questa:

"Quindi cosa fa una Ferrari?" "Mi permette di spostarmi rapidamente da un punto all'altro." "OK. Allora, cosa fa questa cosa del cerchio?" "Oh, quello è il volante. Ruotandolo, puoi cambiare il modo in cui le ruote all'esterno del punto dell'auto. Questo cambierà il modo in cui l'auto si muove." "OK, e questa cosa del pedale?" "Questo è il pedale dell'acceleratore. Rende il motore più veloce, il che rende l'auto più veloce." ... pochi minuti dopo ... "Ok, quindi di che tipo di motore ha bisogno? Ho fatto qualche ricerca e ho trovato motori per golf cart e alcuni per auto sportive. Quale dovrei usare?" ... eccetera. ..."

Quindi puoi spiegare l'analogia. Consegnare agli sviluppatori beffe di schermi dice loro solo che aspetto ha, non cosa fa. Gli sviluppatori hanno bisogno di sapere quale problema risolve il programma o come verrà utilizzato (come sapere cosa fa un'auto rende più semplice progettare l'auto e fare congetture istruite su cosa dovrebbe fare). Devono sapere quali tipi di cose dovrebbero usare (ad esempio il motore del carrello da golf rispetto al motore di un'auto sportiva) e quali altri requisiti non UI ci sono (l'auto dovrebbe andare veloce).

Cose che vorrei chiedere:

Descrizione del problema generale / di alto livello

Usa casi / storie utente

Requisiti di prestazione

Tecnologie / piattaforma richieste (Windows, Linux, Web)

Tutto ciò che ha frustrato con i moduli ha nella sua risposta

Qualcosa per l'effetto dell'80% dello sforzo di sviluppo va verso il 20% dei casi d'uso marginale. Gli screenshot non ti parleranno dei casi d'uso, quindi sarai al buio per l'80% del tuo sviluppo attivo.

È positivo che tu stia cercando di capire di più e cerchi di comunicare quanto sia importante per il cliente essere più coinvolto nei requisiti del progetto, tuttavia se non lo fanno allora stanno configurando il progetto per il fallimento, e non è colpa tua.

La maggior parte dei progetti software fallisce perché il client non è abbastanza coinvolto nel processo di sviluppo del software. Questo non è un nuovo problema e certamente non è un mistero il motivo per cui i progetti software falliscono ma succede continuamente nel settore a causa di situazioni come questa.

Non puoi semplicemente lanciare un rivolo di informazioni su un muro e aspettarti di recuperare tutte le tue speranze e sogni sotto forma di un pacchetto software. Lo sviluppo del software non funziona in questo modo. Che tu sia un negozio Agile o Waterfall, è necessaria una solida direzione del cliente per il successo o il fallimento di un progetto.

Una cosa che le persone sembrano dimenticare di chiedersi, a cosa servono i dati dopo che sono stati inseriti? Hai bisogno di rapporti? È necessario generare un documento di trasporto e inviarlo al magazzino per la spedizione, ecc. Se i dati vengono utilizzati per prendere decisioni di gestione e reportistica, ciò può modificare la progettazione del database. Può anche aggiungere molto tempo allo sviluppo a seconda della complessità dei report.

È inoltre necessario assicurarsi che esista un percorso per ogni possibile decisione. Quindi, se qualcosa richiede l'approvazione della gestione, quindi cosa fai se non viene approvato e cosa fai se viene approvato. Se non viene approvato o disapprovato per un periodo di tempo X, cosa succede? Se selezionano un prodotto ed è esaurito, cosa succede all'ordine? Questo tipo di domande.

È inoltre necessario sapere se esistono limiti specifici su quali dati devono essere inseriti in ciascun campo. Ci sono valori richiesti. Da dove vai per prenderli? Come verranno aggiornati? Devi sapere come gestire gli errori. È necessario sapere se il database deve avere il controllo o se è necessario essere in grado di ricreare i dati da una prospettiva storica (tornando a quei fastidiosi report).

Un'altra cosa che vedo accadere è che le applicazioni possono essere progettate solo per arrivare al rilascio senza considerare il modo in cui i dati verranno conservati in seguito. Hai bisogno di una pagina di amministrazione per assicurarti che possano aggiornare i loro elenchi di valori richiesti? Hai bisogno di inviare dati avanti e indietro ad altri sistemi. Come hai intenzione di ottenere i dati iniziali nel database?

Personalmente, chiederei un incontro di mezza giornata o di una giornata con il cliente per illustrare la progettazione dell'interfaccia utente e i suoi obiettivi e assicurarsi che tutto sia allineato.

Inizia semplice. Fagli capire che con le informazioni che ti sono state fornite, nessuna di quelle schermate farebbe nulla . Nessun dettaglio su casi d'uso, comportamento di input errato e così via. Semplicemente non funzionerà. Spiegare una generalizzazione schietta è più facile che spiegare i dettagli, perché il punto non può perdersi. Cercare di fornire loro una giustificazione più complicata del perché i modelli di schermate non sono sufficienti offre loro l'opportunità di cavillare le tue definizioni invece di riconoscere il problema. Chiedi loro di immaginare che lo sviluppatore di back-end non parlava inglese (o in qualsiasi lingua in cui sono presentati gli schermi). Quindi chiedi quanto è diversa questa situazione rispetto a uno sviluppatore che non ha alcuna conoscenzadei loro processi aziendali. Quindi costruisci l'esempio più realistico di te stesso, che ha una certa conoscenza, ma è giustificato nel ritenere che non sia appropriato decidere la propria logica aziendale per lui.

Le persone che non hanno sviluppato software non sanno cosa devono sapere gli sviluppatori di software. Non ci si può aspettare che producano specifiche dei requisiti e casi d'uso da soli. È necessario applicare le tecniche di elicitazione dei requisiti per ottenere le informazioni che è necessario conoscere. Lavora con il cliente (e, si spera, un campione di utenti di vari ruoli) per determinare ciò di cui hanno bisogno o che desiderano. Tecniche comuni per questo sono interviste e / o osservazioni dell'utente, identificazione di casi d'uso e storie utente e prototipazione.

Consiglio vivamente di applicare tecniche di sviluppo iterativo e incrementale in questo caso, poiché hai requisiti vaghi, incompleti o poco compresi. Guarda le varie metodologie agili insieme al modello a spirale per affrontare la pianificazione del ciclo di vita.

Inizia ottenendo l'obiettivo aziendale che guida lo sviluppo di questo software. Intervista al client e agli utenti e, se possibile, guardali al lavoro. Prova a determinare quale problema stanno cercando di risolvere. Scopri quali strumenti stanno attualmente utilizzando e come li usano in modo da poter migliorare il loro modo attuale di fare le cose. Sfrutta questa opportunità per apprendere il dominio e la sua lingua: diventerà infinitamente più semplice comunicare se gli sviluppatori software e il client / gli utenti parlano tutti la stessa lingua (e non si aspettano che il client / gli utenti parlino in termini di software).

Una volta capito quali sono gli obiettivi, puoi iniziare a lavorare con i modelli di progettazione dell'interfaccia utente che hai e "retroingegnerizzare" i casi d'uso e le storie degli utenti da essi in base al modo in cui i vari schermi si adattano insieme. Il formato della storia dell'utente probabilmente funzionerebbe bene per trattare un pubblico non tecnico. Il formato di As a <user type>, I want to <action> so that <reason>funziona in termini di far parlare sviluppatori e clienti / utenti nella stessa lingua. Una volta che puoi iniziare con le storie degli utenti, adotterò un approccio di prototipazione allo sviluppo.

Penso che mi avvicinerei a questo con l'uso della prototipazione. Potresti affrontarlo da una prospettiva di prototipazione evolutiva o prototipazione usa e getta , ma considererei prima un approccio di prototipazione evolutiva. Inizia con le storie utente con cui ti senti più a tuo agio e che hai convalidato e inizia a implementarle. Man mano che li implementate, ottenete feedback dal cliente e sviluppate nuovi user story, casi d'uso e risolvete incomprensioni.

Inoltre, non pensare a questo come a "implementare un'interfaccia utente con funzionalità sottostanti". Invece, pensalo come sottili fette verticali. Non implementare tutte le interfacce utente contemporaneamente e preoccupati delle funzionalità. Utilizzare invece i mockup dell'interfaccia utente per identificare funzionalità e altri requisiti, quindi implementare una sezione verticale dall'interfaccia utente fino alla logica aziendale e all'archiviazione dei dati. Ripeti l'operazione per ogni fetta verticale. Dovresti anche sentirti libero di dare suggerimenti per migliorare l'interfaccia utente in base ai requisiti e ai principi di usabilità.

Consiglierei di leggere due libri di Karl Wiegers - Requisiti software e altro sui requisiti software . Penso che questi ti aiuteranno con l'ingegneria dei requisiti e le migliori pratiche in questo settore.

Bene, questo è un riferimento iniziale imbarazzantemente ovvio, ma Wikipedia potrebbe essere un posto per te e gli utenti per iniziare. Il fatto che ci sia una voce su questa roba potrebbe aiutare a convincerli che questo è un vero problema, non che tu sia un dolore.

Più specificamente, sei solo confuso su ciò che l'applicazione fa, anche dopo aver esaminato i modelli? In tal caso, ammettilo e prova a spiegare che non hai idea di quali dati dovrebbero essere visualizzati in ciascun modulo o da dove provengono, provengono da altri schermi o dati esterni?

Se hai qualche idea, prova a trovare esempi di cose che non sai come fare ("l'elenco dei modelli da selezionare sarà un elenco globale o sono uno di essi per Utente o qualcos'altro? Se è non per utente dovrei consentire a due persone di modificarlo contemporaneamente? Cosa dovrebbe mostrare l'interfaccia utente se qualcun altro lo sta modificando? C'è una schermata per quello? Una volta che qualcuno ha usato un modello per qualunque modello sia usato e poi il modello viene modificato quel cambiamento dovrebbe essere propagato alla cosa che hanno fatto con il modello? ").

Metti in chiaro che con il tuo attuale livello di conoscenza dovrai avere una risposta alle domande circa ogni 90 secondi per il resto del ciclo di sviluppo e che per la maggior parte del tempo non sarai in grado di continuare a lavorare fino a quando non otterrai una risposta. L'obiettivo dovrebbe essere quello di chiarire perché avere un qualche tipo di processo renderà tutto più semplice. Ricorda anche che il QA avrà bisogno delle stesse informazioni che fai, quindi sarà più facile scriverle tutte in modo che siano disponibili per tutti e nessuno dimentica nulla.

Potrebbe essere utile ricordare che parte del codice che scrivi influenza più di una schermata alla volta, quindi se hai il maggior numero di risposte possibile, potrebbe essere più semplice scrivere quel codice in modo appropriato e non doverlo cambiare in seguito.

Se non riesci ancora a ottenere i requisiti e non sai davvero come procedere, invia e-mail ogni volta che hai bisogno di ulteriori informazioni (ad esempio, requisiti) e se non puoi continuare a lavorare senza tali informazioni, indica chiaramente che purtroppo non sono in grado di continuare a funzionare, perché il codice che devi scrivere sarà molto diverso a seconda della risposta o delle risposte alle tue domande. Non lamentarti, fai solo sapere in modo molto professionale che non puoi scrivere il programma finché non sai cosa dovrebbe fare.

È necessario conoscere i limiti e gli intervalli per ciascun campo nell'applicazione. Ad esempio, se il campo è il numero di telefono, si aspettano che tu gestisca +1? Quali campi sono richiesti? Cosa vogliono che faccia l'applicazione se l'utente digita "abc" nel campo del telefono #? Tutte e 25 le schermate sono nell'ordine in cui tutti gli utenti devono procedere?

Altrimenti, basta creare tutto come campi di testo e il gioco è fatto! Vuoi scommettere che andrà oltre come un pallone di piombo?