Sto pensando di sedermi con gli utenti finali e osservarli mentre lavorano per un giorno per capire meglio i requisiti del software.
Prima di provare questo, spero che qualcuno possa fornire un elenco di best practice, suggerimenti su quando questo approccio è più / meno adatto rispetto al semplice colloquio con gli utenti, e note delle tue esperienze usando l'osservazione del lavoro / shadowing.
I riferimenti ad altri siti o ricordi della tua esperienza personale sono entrambi benvenuti.
Questo approccio è quasi sempre più adatto di un semplice colloquio con gli utenti.
Perché?
Perché gli utenti mentono. A volte non è malizioso. Non riescono a raccontare una storia appropriata.
Lo fanno in due modi.
Hanno poca visione; in realtà non sanno cosa potrebbe fare una nuova applicazione. Non descrivono cose che includono il valore aziendale reale e complessivo. Al contrario, descrivono i dettagli di come è implementato in questo momento, per quanto negativa sia l'implementazione.
Questo è forse il più comune, dal momento che la maggior parte degli utenti che non sono "proprietari di attività" o "dirigenti" sono stati delegati a un'operazione più ampia.
Hanno una visione eccessivamente grandiosa; immaginano ogni genere di cose, alcune delle quali sono impossibili. Non descrivono cose che includono il valore aziendale reale e complessivo. Invece, fantasticano su un lavoro che esiste solo nella loro immaginazione.
Questo è angosciante perché conduce a requisiti che - a volte - non possono nemmeno essere testati. Oppure, se riescono a inventare casi di test, il dibattito sorge all'interno dell'organizzazione dell'utente. Oppure, se un'organizzazione concorda, altre organizzazioni non possono fornire i dati richiesti.
Molto spesso, tuttavia, questo porta a sistemi che sono inutilmente sovradimensionati. Spesso un "primo sprint" fornisce una soluzione praticabile che fa tutto il necessario ma è molto poco simile alla visione grandiosa.
Perché gli utenti mentono. A volte è dannoso. Rifiutano di raccontare una storia vera e invece evitano semplicemente di fornire dettagli concreti. Gli utenti evasivi sono particolarmente difficili da gestire, dal momento che non esiste una storia. Quando provi a dettagliare la tua comprensione, hai sempre avuto diverse funzioni chiave completamente sbagliate - anche se hai fornito parole testuali dell'intervista .
Best Practices
Raccogli documenti effettivi (file o documenti cartacei) che riflettono il flusso di lavoro reale dell'utente con dati reali. Nulla - niente - batte i dati reali per fornire le complessità sfumate del lavoro quotidiano.
Cerca di distinguere il valore aziendale reale dai workaround a causa del cattivo software creato da persone che non hanno svolto alcuna osservazione sul lavoro. Sembra che il 25% -50% di un'applicazione richieda tweaks e interfacce necessarie per correggere i problemi in altre applicazioni.
Quando osservi qualcuno che risolve un problema (o aggira un problema), devi scoprire la causa principale. Non lo scoprirai attraverso l'osservazione del lavoro o l'intervista. Lo scoprirai attraverso una combinazione di osservazioni, interviste e revisioni del codice.
In alcuni casi, interi reparti sono creati per ovviare alle limitazioni del software. Quel reparto non crea valore - evita il costo del software non valido. L'osservazione del lavoro può portare a una soluzione semplificata. Ma è ancora una soluzione alternativa per un problema di causa root più fondamentale.
Leggi altre domande sui tag requirements