Un programmatore dovrebbe "pensare" al cliente?

Nella maggior parte dei casi il cliente non è a conoscenza di cos'altro può essere fatto. 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 al numero 1 va davvero oltre il modo in cui sono abituati a pensare.

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

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

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

Se hai qualcosa che potrebbe contraddire ciò che il cliente ti ha detto esplicitamente, è il momento di spiegarne il motivo. Avrai bisogno di far emergere alcuni problemi a cui il cliente non ha mai pensato, e di come la tua alternativa dà ancora loro ciò che vogliono / hanno bisogno, ma evita anche quei potenziali problemi. È possibile ottenere un po 'di pushback, ma aumenta anche la fiducia dei clienti che si rendono conto che stai cercando di fornire loro un prodotto che possono realmente utilizzare. Se danno qualche respingimento, li costringe a spiegare perché volevano qualcosa in un certo modo. Ciò ti aiuta a capire meglio il tuo cliente e ad adattare i requisiti secondo necessità.

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

Se li stai "facendo incazzare" da troppe domande, prendi un cliente migliore.

I clienti non sanno quello che 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 un pacchetto software.

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

Leggi questo per maggiori informazioni: link

Supponendo che tu sia un dipendente in una sorta di società, sembra che tu abbia bisogno di un buon analista di business per aiutare a mediare quei dettagli tra il cliente e te stesso. Immagino che tu non abbia abbastanza influenza per far sì che ciò accada, quindi il mio migliore consiglio sarebbe quello di saperne di più sul dominio in cui lavorano i tuoi clienti. Comprendendo il business e i processi con cui lavorano, tu Avremo un'idea migliore di ciò che vogliono veramente fare, nonostante il modo sciolto e possibilmente sbagliato che stanno descrivendo. Questo ti consente di analizzare ciò che hanno chiesto, e puoi tornare più tardi in un incontro separato con un'interpretazione di ciò che vogliono, e un possibile suggerimento per dare loro ciò che vogliono veramente. Se lavori in modo coerente con gli stessi clienti, otterrai una migliore e migliore comprensione del dominio e questo dovrebbe diventare più semplice, e alla fine addestrerai il cliente a presentarti le cose in modo coerente.

Se ciò sembra molto difficile, doloroso, estremamente spiacevole o irrealistico, il mio consiglio finale sarebbe quello di iniziare a cercare un nuovo lavoro da qualche parte con gli analisti di business, perché non sarà più facile per voi senza mettere in sforzo.

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

Sì, il cliente potrebbe annoiarsi, ma in tal caso devi spiegare perché stai chiedendo "tutte queste domande". Devi capire la loro attività prima di poter scrivere il codice che automatizzerà quell'attività. Il punto di forza sarebbe che se non lo facessi, spenderebbero un sacco di soldi per sviluppare un sistema che in realtà non fa quello che vuole.

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

Questo vale sia per Big Design Up Front che Agile.

Purtroppo, è compito tuo pensare al cliente se non può o non vuole farlo 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 è seccato perché lo costringi a ripensare alle sue esigenze. Ma poi, questo tipo di cliente si arrabbierà comunque con te, prima o poi. Sarà sicuramente molto seccato se scoprirà troppo tardi che non hai pensato per lui all'inizio. Direi: evita questo tipo di cliente se possibile: -)

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

Inizia "pensando al cliente" creando un'interfaccia utente non funzionale molto approssimativa per il programma basata sulla tua ipotesi migliore su ciò di cui hanno bisogno. Quindi mostralo a loro e lavoralo in modo iterativo finché non soddisfi le loro reali esigenze.

Non è che non sanno quello che vogliono. È che non sanno quello che vogliono fino a quando non lo vedono, ea volte 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 (design Big Up Front) è che isola la colpa dello sviluppatore costringendo il cliente a un contratto che descrive esplicitamente ciò che sta per ottenere. E sfortunatamente ciò avviene nel momento in cui nessuno nel progetto ha una buona idea di ciò che è veramente necessario. Alla fine, questo fa semplicemente accettare al cliente ciò che hai costruito perché hanno firmato, ma a malincuore.

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

Il compito del cliente è di inoltrarti ciò di cui hanno bisogno. Il tuo compito è capire che cosa hanno bisogno di essere abbastanza in grado di programmare ciò di cui hanno bisogno. Una domanda ovvia al problema di cambiare tutti gli input in uno sarebbe dire "Perché vuoi che cambi tutto l'input in 1?" Quindi il cliente può spiegare il ragionamento dietro di esso in modo che capirai 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, allora non penso che tu debba necessariamente "correggere" la loro linea di pensiero. Useranno il prodotto e la cosa "Oh! È perfetto". Ma a meno che tu non abbia la certezza di sapere di cosa hanno bisogno, dovrai quindi spiegare cosa stai pensando e risolverlo con il cliente. Sfortunatamente non c'è modo di eseguire questa parte del processo senza molta comunicazione che implichi un ascolto reale su entrambe le parti. Fai attenzione a essere infastidito dalla situazione e a dire cose che potresti o non vuoi davvero dire.

Onestamente: a meno che non si tratti di una "grande funzionalità", la persona con la maggior conoscenza di dominio può fare la propria ipotesi su ciò che dovrebbe accadere e implementarla. Si approfondirà nei test di accettazione - che è ciò che è per.