Qual è la migliore pratica per la raccolta dei requisiti quando un cliente non sa cosa vuole? [duplicare]

Il tuo problema sembra passare dal fatto che il "cliente" è probabilmente una persona che non utilizzerà il sistema. Alcune cose che ricordo dalla classe SE:

• Prova a visitare le persone che utilizzeranno effettivamente il sistema e osservali nelle effettive condizioni di lavoro. Questo può essere importante a causa delle differenze di dominio tra utenti e sviluppatori, le ipotesi di differenza possono essere fatte dai due gruppi. Se ciò non è possibile, includi almeno uno degli utenti finali direttamente nel processo dei requisiti.
• Utilizza un qualche tipo di software di progettazione dell'interfaccia utente per mostrare loro gli screenshot dell'interfaccia utente che puoi progettare in base alle tue esigenze attuali. Questo evita il problema dei termini tecnici e la rappresentazione grafica spesso evidenzia problemi che potrebbero altrimenti essere trascurati.

So che questa è una brutta frase nel mondo dello sviluppo, ma è proprio qui che entra in gioco la consulenza aziendale . Se il cliente non sa realmente quali sono i suoi problemi e quali tipi di soluzioni potrebbero desiderare, non è davvero possibile progettare software che li aiuti.

Agile è ottimo e il design funzionale si adatta bene alla revisione durante il processo di sviluppo. L'analisi aziendale - almeno la maggior parte di essa - è gestita meglio in un modo più a cascata (ooh, una parola ancora più brutta oggi), con gli effettivi requisiti aziendali risolti prima dell'inizio di qualsiasi progetto di software funzionale.

Attenzione, questo lavoro non deve essere fatto da un consulente aziendale (sebbene per molti progetti risparmierà molto tempo e dolore), ma lo stesso tipo di sforzo sono obbligatori se lo fai. Dai tuoi commenti non sembra che questo lavoro sia preventivato, ma è davvero importante fare un passo indietro con il cliente e capire come funziona la sua attività, almeno le parti che il software toccherà direttamente. Trascurare di farlo garantisce quasi un progetto fallito.

1. Identifica i tuoi stakeholder. Di solito ce ne sono pochi, non solo un cliente.

2. Chiedi a ciascuno di loro cosa vogliono dal progetto. Ogni progetto dovrebbe fornire una nuova "Qualità". "Sostituire il software esistente" non ha senso senza spiegazione Perché? Il metodo 5-whys potrebbe essere applicabile in questa situazione per capire di cosa ha realmente bisogno il cliente.

3. usare un dizionario come "etichetta", "casella di testo" quando parli agli Stakeholder nella fase iniziale della raccolta dei requisiti è un'idea piuttosto sbagliata. Dovresti mantenere la tua mente e le tue menti delle parti interessate pulite da Idee di progettazione finché non comprendi i requisiti.

I clienti non hanno requisiti. Hanno problemi.

La selezione dei problemi da risolvere e la loro conversione ai requisiti è un ruolo separato che richiede conoscenze nel dominio del cliente e conoscenza di ciò che può essere fatto dalla tecnologia e cosa non può.

A volte questo ruolo può essere preso dal cliente se ha conoscenza della tecnologia - ma è improbabile che sia il caso qui.

Quindi dovresti studiare il dominio del cliente o trovare una persona giusta che si troverà nel mezzo.

Mi piace pensare ai requisiti come decisioni sul futuro. Il futuro è in evoluzione, e lo sono anche le decisioni a riguardo. Quando nuove informazioni verranno alla luce, dovremmo rivedere le nostre decisioni di conseguenza.

Il modo migliore per raccogliere informazioni è rilasciare il software il più spesso possibile in modo che il cliente possa testarlo. Da quel feedback, cambia le tue decisioni.

In altre parole: sperimenta, osserva e adatta.

Mappare le persone come un gruppo su un algoritmo (studi sociali / statistiche) può portare a molto apprendimento .. provare a mappare le persone individuali a un algoritmo (alchimia) può solo portare alla follia.

Supponendo che tu abbia provato quanto sopra, allora l'unica opzione che vedo per te (dato che il progetto deve ancora andare avanti, e tu sei ancora occupato) è di impostare il progetto come uno agile - e costarlo per funzione consegnata.

Fornisci solo le caratteristiche più ovvie ed essenziali e lascia che si sviluppi in modo organico.

Potrebbe benissimo essere che l'intero sistema sia troppo complesso per il tuo cliente da tenere a mente. Quindi quando fai un suggerimento A sembra ragionevole e lui dice "Sì", ma quando torni indietro con una domanda la risposta contraddice la decisione A - semplicemente perché la relazione di questi due non è chiara per lui.

Nota a margine: se gli stai chiedendo delle caselle di testo e delle etichette, gli stai ponendo le domande sbagliate. È probabile che a lui sia interessato solo a lavorare, non a come funziona. Questo è per te decidere (con input dell'utente).

Come Stephan Bailey dice che l'unico modo in cui questo può funzionare è se hai un approccio agile.

Avrei iniziato a prototipare l'interfaccia utente e mostrarli al cliente, che dovrebbe almeno focalizzarli un po ', anche se loro odiano il tuo primo tentativo si spera che questo almeno li porti a dire cosa fa voglio.

C'è un grosso rischio nel mostrare un prototipo di interfaccia utente, e cioè che il cliente vedrà "schermate" e supporrà che il lavoro sia completo perché può vederlo. Ci vuole un sacco di lavoro per persuaderli che alcuni pulsanti non sono un'applicazione. Per questo motivo non rendere il prototipo troppo lucido, mantienilo ruvido e non provare a mettere a punto troppe funzionalità.