Ci sono un paio di modi diversi per suggerire di avvicinarmi a questo:

1. Job shadowing - > Questo fondamentalmente lo sta osservando mentre fa il suo lavoro in modo da sapere cosa sta facendo e quali connessioni ci sono tra i sistemi e i processi che usa per portare a termine il suo lavoro. Questa è totalmente un'osservazione dalla tua fine, in cui possono essere poste domande, ma solo per avere un'idea generale di cosa sia una cosa.

2. Prototipazione - > Prova a passare attraverso una versione cartacea di come interagirebbe con il sistema. Quali parti fa e cosa si aspetta che il sistema faccia automaticamente?

In entrambi i casi si sta tentando di raccogliere informazioni dal guardare l'esperienza di ciò che accade piuttosto che fargli domande. Ci sono una serie di motivi per cui potrebbe non essere in grado di rispondere alle tue domande:

• Mancanza di autocoscienza - forse non può osservare se stesso così bene e quindi non sa tutto ciò che fa. Ad esempio, alcune persone potrebbero essere in grado di ottenere da A a B ma non sono in grado di darti indicazioni perché non conoscono le strade o le distanze che guidano prima di ogni turno.

• Mancanza di articolazione - forse non è in grado di articolare il processo e quindi mentre sa cosa fa, non riesce a mettere bene le parole.

• Mancanza di struttura - forse non riesce a mettere insieme tutti i pezzi per rispondere alla tua domanda.

Sembra che tu stia cercando di indurlo a descrivere la soluzione piuttosto che il problema. I non programmatori hanno difficoltà a pensare al software in questo modo. Per loro, è un prodotto immutabile piuttosto che una raccolta flessibile di componenti.

Ciò di cui hai bisogno a questo punto è una descrizione approfondita del problema. Non ha idea di come dovrebbe apparire la schermata di apertura fintanto che risolve il problema e non ne introduce di nuovi.

Ad esempio, mia moglie mi ha detto che stava cercando un nuovo software di budget perché con il nostro software attuale non sa mai quanti soldi realmente sono disponibili. Questo mi ha sorpreso perché il nostro software attuale è sempre sincronizzato con la banca e suddivide le cose in categorie piacevoli, notificandoci quando ci avviciniamo troppo all'importo previsto. Ho chiesto perché non fosse abbastanza, e ha detto che è troppo lavoro per tenere il passo con l'inserimento di entrate che non sono ancora state liquidate, che spesso sono per importi significativi, e non c'è modo di prevedere in base alle transazioni pianificate in futuro. Quando le transazioni cancellano la banca è troppo tardi per essere utile nella pianificazione.

Si noti che sta descrivendo il problema, non la soluzione. Parte della soluzione che non sapeva di aver bisogno era un'app per smartphone con un'interfaccia ultra semplice per visualizzare rapidamente il budget disponibile per categoria e inserire gli importi delle ricevute nel punto di vendita e che sincronizza automaticamente le transazioni con un'applicazione più completa per l'uso a casa. Non appena le ho presentato questo, ha detto che si adattava perfettamente alle sue esigenze, ma ha detto che non ci avrebbe mai pensato da sola.

In altre parole, è necessario raccogliere i requisiti dal punto di vista del cliente del problema che deve essere risolto, e lasciare i dettagli del progetto al professionista del software. Nelle occasioni in cui i clienti si preoccupano dei dettagli, di solito hanno nessun problema che ti permette di sapere. Il tuo compito è presentare il progetto in modo incrementale in modo tale da consentire loro di fornire feedback senza causarti troppe potenziali rilavorazioni.

Chiedi loro come fanno il loro lavoro ora. Presumibilmente lo sanno. Dalla loro descrizione del loro lavoro, ascolta gli indizi che raccolgono informazioni da qualcuno. Al momento potrebbero scrivere su post-it notes, ricordarli nella loro testa o se sei fortunato, compilare un modulo cartaceo esistente o, se sei veramente fortunato, in un sistema informatico esistente.

Gran parte di ciò che fanno non ha nulla a che fare con la gestione delle informazioni, ad esempio giudicare quando viene eseguito un taglio di capelli. Ma alcuni di essi riguarderanno le informazioni, come mettere i soldi nella cassa quando il cliente lascia (che è lo stesso che riempire la casella ricevuta e inserire i dati nella tabella delle entrate).

La raccolta dei requisiti è un problema irrisolto in informatica. La maggior parte dei consigli è una finzione, in cui stiamo immaginando che la tipica linea di consumatori di applicazioni aziendali sono in grado di eseguire specifiche di basso livello semplicemente chiedendo loro.

Un'altra idea è presentare una varietà di opzioni basate sulla tua comprensione fuzzy, e poi, una volta che il cliente ha qualcosa da guardare (carta disegnata naturalmente, è troppo presto per scrivere un codice sostanziale) prendi feed back e iterativamente prova ad andare dal loro. Ancora una volta, a seconda del cliente, potrebbero non fare un buon lavoro immaginando di utilizzare l'applicazione, quindi fai attenzione a pensare che anche in questo caso il loro feedback sia definitivo o una rappresentazione accurata di ciò che vogliono.

I bloggato su questa settimana scorsa. Questo può essere molto frustrante a volte.

Inizierei facendo domande come ...

• Che cosa renderebbe più semplice il tuo lavoro?
• Cosa non ti piace del tuo lavoro?
• Compila gli spazi vuoti ... Se potessi vuoto invece di vuoto mi renderebbe lavora molto più facilmente.

Potresti aver bisogno che ti mostri di cosa sta parlando. Se è così, vai a trovarlo nei suoi dintorni (è più comodo per lui). Lascia che ti mostri quello che fa e quello che gli piace fare invece. Ascolta, intendo davvero ascoltare. Cerca di capire tutto ciò che sta facendo senza offrire modifiche o soluzioni o critiche.

Una volta stabilito un rapporto con lui, è più probabile che si apra e discuti ciò di cui ha veramente bisogno.

Quindi puoi farlo lavorare all'indietro da quello che l'output atteso vuole e da come creare quell'output per lui.

È la mia esperienza generale che gli utenti finali non sanno cosa vogliono. Sanno cosa gli piace e cosa non gli piace. Sanno cosa è difficile e cosa è facile, ma in realtà non sanno quello che vogliono e non vogliono.

Inizia chiedendo loro l'attuale modo in cui fanno le cose. Chiedi cosa piace a loro in questo modo e cosa non gli piace. Chiedi qual è la parte più difficile del sistema attuale. Chiedi quali scorciatoie usano attualmente per rendere il sistema attuale più gestibile.

Quindi chiedi cosa devono fare ogni volta che fanno un processo. C'è una forma che devono guardare ogni volta? C'è qualche dato che devono cercare prima di iniziare? Quali sono le metriche più importanti per loro.

Siediti e guardali mentre attraversano il sistema attuale mentre svolgono alcune attività. Fare domande.

Finalmente, siediti e prendi in giro qualcosa. Alcune schermate o se è possibile una pagina fittizia che in realtà non fa nulla, ma consente all'utente di vedere le interazioni e così via. Chiedi all'utente di guardarlo e usarlo. Ti diranno cosa gli piace e cosa non gli piace. Ti faranno domande sul perché le cose siano dove sono. Fai domande per ottenere un feedback migliore.

Riesco davvero a mostrare all'utente qualcosa che dia loro qualcosa di cui parlare. Si assicura che tutti siano per lo più sulla stessa pagina e ti aiuta a sapere che stai facendo qualcosa che possono usare.

Se tenendolo per le caviglie e agitando con fermezza non funziona, puoi provare a scrivere l'intera applicazione, mostrandogliela e dopo averti spiegato perché la maggior parte è sbagliata. Di solito è molto più facile per le persone dire perché non ti piace qualcosa piuttosto che dirti cosa vogliono (il che sarebbe molto più utile per te).

Se ciò richiede troppo tempo, prendilo in giro nel modo più semplice possibile, rispondendo alle tue domande e accettando per iscritto che è tutto ciò che vuole che funzioni. Spero che il tuo mockup sia informato da una comprensione di ciò che sta cercando di realizzare.

Molto probabilmente vorrà fare tutti i tipi di cambiamenti, ma almeno sarai in grado di giustificare che il motivo per cui sta impiegando così tanto tempo è che lui sta provando la sua strada attraverso ciò che vuole e facendoti cambiare mentre lo fa . Mantieni i prototipi il più a lungo possibile per ridurre al minimo lo spreco di tempo.

Puoi cercare uno sviluppo agile (un argomento gigante) per ulteriori idee - è un metodo che presuppone che tutti non sappiano in anticipo tutto ciò che vogliono fare.

Case study

Recentemente ho intrapreso una riscrittura della principale app Web interna della nostra azienda. Per scoprire quali funzionalità della vecchia app sono state utilizzate e quali no, e quali attività correlate erano troppo disconnesse, ho registrato tutte le attività per tre mesi in anticipo e ho analizzato i percorsi eseguiti tramite il software . Poiché lavoro nello stesso ufficio degli utenti, sono anche al corrente dell'esperienza passata di come tendono a operare e di quali sono i processi aziendali più ampi. ( job shadowing menzionato in un'altra risposta, ma fatto passivamente.)

Grazie alla conoscenza di come gli utenti stavano usando il sistema, ho poi condotto interviste sulla user story e prodotto un elenco di requisiti . Ho selezionato una parte dell'applicazione che non aveva dipendenze come punto di partenza e ha iniziato lo sviluppo iterativo utilizzando tali requisiti. Il nuovo software è già più testabile e presenta un grado di separazione delle preoccupazioni che il software precedente non poteva sperare di ottenere.

Puoi sempre fare un primo passaggio veloce, magari con alcuni mockup. Un sacco di volte in cui le persone andranno ... è più facile per loro puntare a qualcosa e dire sì o no.

Sì, ombra del lavoro, tuttavia, alla fine, disegna i diagrammi del flusso di dati. L'ho fatto centinaia di volte. Non ho mai incontrato un uomo d'affari che non riusciva a capire un DFD graficamente chiaro (cioè non spaghetti). Se non riesci a disegnare il DFD, non comprendi il flusso di lavoro. Se il cliente non riesce a capire il DFD, l'hai disegnato erroneamente, quindi lo hai rivisto.