Un programmatore dovrebbe "pensare" per il cliente?

Sono arrivato al punto in cui odio la raccolta dei requisiti. I clienti sono troppo vaghi per il loro bene. In un ambiente agile, in cui possiamo mostrare al cliente un lavoro fino al completamento, non è poi così male in quanto possiamo apportare piccole correzioni / aggiornamenti regolari alla funzionalità.

In un ambiente "a cascata" (prima i requisiti, poi il prodotto quasi completo) le cose possono diventare brutte. Questo tipo di ambiente mi ha portato a porre costantemente domande sui requisiti. Il cliente EG vuole "convertire automaticamente l'input nel numero 1" (riferendosi a una quantità in un ordine). Ma ciò a cui non pensano è che "input" potrebbe essere un semplice tipo-o. Una "x" in una casella di testo potrebbe essere un "woops", non voglio 1 di quei prodotti "dentifricio". Ma c'è così tanto nell'aria con requisiti che potrei sopportare e correggere per ore e ore distruggendo quello che vogliono. Questo non è salutare.

Lavorando per una società, potrei provare ad adattare la cultura per adattarla al modello agile che ci aiuterebbe (non un piccolo lavoro, al di sopra del mio grado di retribuzione). Oppure, sposta i dettagli brutti sotto il tappeto e spera per il meglio. Forse il mio cliente sta cercando di avvicinarsi troppo al codice?

Come si fa a gestire il problema del "pensare per il cliente" senza far incazzare con troppe domande?

Nella maggior parte dei casi il cliente non è a conoscenza di cos'altro si possa fare. Non hanno mai dovuto descrivere ciò di cui hanno bisogno in un modo che lo rende inequivocabile per noi. Nella loro mente, è chiaro. Anche il fatto che stiano pensando di convertire l'input dell'utente nel numero 1 va davvero oltre il modo in cui sono abituati a pensare.

È proprio come dovrebbe essere. Se fossero davvero nuovi su come descrivere esattamente ciò che volevano, non avrebbero bisogno che noi lo scrivessimo per loro. Di conseguenza, la nostra responsabilità è di aiutarli durante il processo. Il processo richiede decisioni da prendere, quindi hanno anche bisogno delle nostre raccomandazioni per facilitare il processo decisionale.

Quindi lascia che il cliente sia vago e parli ad alto livello. Conoscono i loro affari, ed è quello in cui sono bravi (si spera, o non saranno in grado di pagare le bollette ...). Prendi ciò di cui hanno parlato e riflettici per un po '. Alla fine hai delle idee fantastiche per ottenere ciò che vogliono e di cui hanno bisogno, garantendo al contempo che ciò di cui hai bisogno sia testabile e coerente.

Consiglio vivamente di lavorare a pezzi. Quando incontri un cliente, hai una serie di requisiti correlati tra loro e poi spiega come intendi fare quello che vogliono. Spiega anche perché hai fatto le scelte che hai fatto. Il cliente può quindi guardare ciò che hai fornito e perfezionarlo. Se ricevi una risposta del tipo "Non ci avevo mai pensato, ma sarebbe di grande aiuto" sai che hai un impulso su come pensa il cliente. NOTA: che questa non è featurite, sta selezionando le funzionalità giuste per adattarsi al meglio al problema aziendale che il cliente ha.

Se hai qualcosa che sembra potrebbe contraddire ciò che il cliente ti ha esplicitamente detto, allora è il momento di spiegare il perché. Dovrai mettere in evidenza alcuni problemi che il cliente non ha mai pensato e in che modo la tua alternativa offre loro ciò che desiderano / di cui hanno bisogno, ma evita anche quei potenziali problemi. Potresti ottenere un piccolo respingimento, ma aumenta anche la fiducia dei clienti quando si rendono conto che stai cercando di offrire loro un prodotto che possono davvero utilizzare. Se danno un po 'di respingimento, li costringe a spiegare perché volevano qualcosa in un certo modo. Questo ti aiuta a capire di più il tuo cliente e ad adattare i requisiti secondo necessità.

Il modo più veloce di logorare il tuo cliente è quello di porre tutte le piccole domande una dopo l'altra. Vuoi pianificare e programmare una serie di incontri per rivedere il tuo approccio. Finché possiedi i requisiti tecnici (ciò che il tuo team utilizza per costruire il prodotto) e il tuo cliente possiede i requisiti aziendali e puoi metterli in relazione insieme, hai un modo per colmare il divario.

Se le stai "incazzando" da troppe domande, trova un cliente migliore.

I clienti non sanno cosa vogliono. Non riconosceranno necessariamente la loro soluzione quando la vedranno. Questo è un problema e questo è il lavoro che stai risolvendo: tradurre i loro requisiti in qualcosa che può essere consegnato come pacchetto software.

Per fare ciò devi imparare cosa stai facendo. Non dovresti chiedere "cosa dovrebbe succedere quando inseriscono un numero in una casella di testo", dovresti chiedere "perché questo numero è importante? A cosa serve?" Chiedi loro di insegnarti come svolgono il loro lavoro. E non ascoltare ciò che dicono, perché non sanno cosa vogliono, ma guardano cosa fanno e dove vanno i loro occhi .

Leggi questo per maggiori informazioni: http://www.joelonsoftware.com/articles/fog0000000356.html

Supponendo che tu sia un dipendente in una sorta di azienda, sembra che tu abbia bisogno di un buon analista aziendale per aiutare a mediare quei dettagli tra il cliente e te stesso. Immagino che tu non abbia abbastanza influenza per realizzarlo, quindi il mio prossimo consiglio migliore sarebbe quello di saperne di più sul dominio in cui lavorano i tuoi clienti. Comprendendo il business e i processi con cui lavorano, tu " Avrò un'idea migliore di ciò che vogliono veramente fare, nonostante il modo sciolto e forse sbagliato che lo descrivono. Ciò ti consente di analizzare ciò che hanno chiesto e puoi tornare più tardi in una riunione separata con un'interpretazione di ciò che vogliono e un possibile suggerimento per dare loro ciò che vogliono veramente. Se lavori costantemente con gli stessi clienti,

Se questo sembra molto difficile, doloroso, estremamente spiacevole o non realistico, il mio ultimo consiglio sarebbe quello di iniziare a cercare un nuovo lavoro da qualche parte hanno analisti aziendali, perché non sarà più facile per te senza impegnarti.

Se stai raccogliendo i requisiti, è tuo compito porre queste domande.

Sì, il cliente potrebbe infastidirsi, ma in tal caso è necessario spiegare perché si stanno ponendo "tutte queste domande". Devi capire la loro attività prima di poter scrivere il codice che automatizzerà tale attività. Il clincher sarebbe che se non lo facessero, spenderebbero molti soldi per lo sviluppo di un sistema che in realtà non fa quello che vogliono.

L'effetto collaterale di questo è che dovresti finire per aiutare il cliente a perfezionare i suoi requisiti.

Questo vale sia che tu stia eseguendo Big Design Up Front o Agile.

Purtroppo, il tuo compito è pensare al cliente se non può farlo o non lo farà da solo.

Ho avuto entrambi i risultati possibili:

• il cliente è felice che tu stia effettivamente pensando a quello che ti dice, sente di essere nelle mani giuste, o

• il cliente è infastidito perché lo costringi a ripensare alle sue esigenze. Ma poi, questo tipo di cliente ti infastidirà comunque, prima o poi. Sarà sicuramente molto seccato se scoprirà troppo tardi che all'inizio non hai pensato per lui. Direi: evitare questo tipo di cliente se possibile :-)

Un Rapid Application Development (RAD) affronta bene questo problema.

Inizia a "pensare per il cliente" creando un'interfaccia utente non funzionale molto approssimativa per il programma basata sulla tua migliore ipotesi su ciò di cui hanno bisogno. Quindi mostralo a loro e lavora in modo iterativo fino a quando non soddisfi i loro bisogni reali.

Non è che non sappiano cosa vogliono. È che non sanno cosa vogliono fino a quando non lo vedono, e talvolta puoi determinare ciò che vogliono per esclusione. Cioè, mostrando loro qualcosa che NON vogliono e prestando attenzione a come lo criticano.

Il problema principale con BFUD (Big Up Front design) è che isola lo sviluppatore dalla colpa costringendo il cliente a un contratto che descrive esplicitamente ciò che sta per ottenere. E sfortunatamente questo viene fatto nel momento in cui nessuno nel progetto ha una buona idea di ciò che è veramente necessario. Alla fine, questo fa sì che il cliente accetti ciò che hai costruito perché ha firmato, ma a malincuore.

Se il cliente non è soddisfatto del risultato finale, è solo una vittoria di Pirro.

Il lavoro del cliente è quello di trasmetterti ciò di cui ha bisogno. Il tuo compito è capire di cosa hanno bisogno abbastanza bene da poter programmare ciò di cui hanno bisogno. Una domanda ovvia al problema di cambiare tutti gli input in uno sarebbe dire "Perché vuoi che cambi tutti gli input in 1?" Quindi il cliente può spiegare il ragionamento alla base in modo che tu possa capire la necessità e quindi essere in grado di fornire non necessariamente ciò che chiedono ma ciò di cui hanno bisogno. Se sei sicuro di sapere di cosa hanno bisogno, non penso che devi necessariamente "correggere" la loro linea di pensiero. Useranno il prodotto e la cosa "Oh! È perfetto". Ma a meno che tu non sia sicuro di sapere di cosa hanno bisogno, dovrai spiegare cosa stai pensando e risolverlo con il cliente. Purtroppo c'è Non c'è modo di eseguire questa parte del processo senza molta comunicazione che comporta un ascolto reale su entrambe le parti. Fai attenzione a non seccarti della situazione e a dire cose che potresti o non vorresti davvero dire.

Onestamente: a meno che non sia una "grande funzionalità", fai in modo che la persona con la maggior conoscenza del dominio faccia la sua migliore ipotesi su cosa dovrebbe accadere e implementalo. Verrà rafforzato nei test di accettazione - che è quello che serve.