Una Carenza Di Comunicazione:Utente vs Analista-Progettista

Question

Normale pratica in caso di utilizzo di studi, costruire il lavoro di dati e flussi, etc.Ma questo non significa necessariamente creare un vocabolario condiviso tra utente/sponsor e l'analista-progettista:l'uno o l'altro, sia di norma, dovrà acquisire termini e vista la "interni" degli altri area di competenza, e questo di solito porta ad incomprensioni e incontri-per-chiarire (inserire RAD-tecniche di Prototipazione Evolutiva), etc.

L'utente/sponsor è concentrato sul suo/i suoi bisogni/ambiente, e non vuole, né deve essere costretta ad acquistare, dal loro punto di vista, estranei 'terminologia di programmazione'.La responsabilità di imparare un nuovo ambiente si trova con l'analista/progettista/programmatore).

Come si fa a superare la curva di apprendimento?Ciò che funziona per voi quando siete di fronte ad un utente che vuole una soluzione software?

Answer 1

Provare a eliminare tanti passaggi intermedi tra l'utente finale e realizzatore possibile.Ogni fase oscura e perde informazioni.Il più prezioso, i membri del team possono essere persone che possono indossare sia negli abiti che - "interfaccia" con gli utenti, e in realtà implementare la cosa.

Se non è possibile, assicurarsi di aver rapida iterazione e implementare le cose in modo iterativo.E ' facile confonderlo con il modo incrementale.La differenza è che con approccio iterativo si dispone di ampia gamma di funzionalità implementate per un piccolo, ma di livello uniforme.Nell'approccio incrementale di implementare grandi blocchi di funzionalità, uno dopo l'altro.

Nell'approccio iterativo si ha il vantaggio di agilità. Utente ha cambiato idea, o c'è stata qualche incomprensione?Nessun problema, c'è ancora spazio per il cambiamento.Non molto sforzo è stato speso, anche, si spera.

Answer 2

Io uso i commenti

"Se non si riesce a spiegare la fisica di una cameriera, non è molto buona fisica" e "non Hai veramente capito qualcosa se non è in grado di spiegarlo a tua nonna" (Attribuita a Rutherford e Einstein)

come mantra quando sto parlando requisiti con i clienti.

Prendere i due fronti, da un elevato livello, Powerpoint o lavagna presentazione, e se si può permettere agli utenti sciolto in un POC o un mockup.

Quindi fare cartina riga per riga requisiti.Il diavolo è nei dettagli.Ottenere loro di firmare questi dettagli.Etichetta e numero di loro in modo che possano fare una linea con l'analisi.

Se si fanno i requisiti dettagliati prima di alto livello impostato, gli utenti non potrà mai cogliere i concetti nella progettazione e impantanarsi nei minimi dettagli e specifiche.Senza alcuna cornice di lavoro, o concetti, gli utenti si gira intorno al numero di angeli sulla punta di uno spillo.

L'agilità e le iterazioni sono buone, purché il cliente e il team di sviluppo può parlare un linguaggio simile.Garantire le aspettative sono definiti e soddisfatti.

Answer 3

Una buona interazione designer deve essere in grado di descrivere il software di funzionamento in termini profani.Se no, lui non dovrebbe fare frontend, IMHO.

Answer 4

Ci vuole una serie di tecniche, e entrambe le parti hanno bisogno di imparare a capire i suoi affari in qualche misura:cioègli analisti ha per ottenere una comprensione del dominio dell'utente e l'utente deve acquisire familiarità con alcune delle tecniche di analisti.

Trovo Flussi di Processo un buon modo per iniziare, d'accordo, ad un livello alto come il business funziona.Alcuni utenti sono buoni con i modelli dei dati (ERDs per esempio), ma in generale mi sento di dire che non sono:essi spesso rispondono meglio quando le regole sono spiegate nel testo, ad es.

• Un Ordine può consistere in una o più Righe d'Ordine
• Ogni Ordine ha un unico, 10 cifre, il numero di riferimento

Si può leggere e zecca o croce quelli molto più facilmente di quanto si può di controllo di qualità di un disco di RIPRISTINO.

A quel punto, niente batte davvero schizzi di immissione e di rapporti di ottenere agli utenti di concentrarsi sui dettagli di ciò che vogliono.