Lavorare con clienti che non sanno quello che vogliono

Alcuni consigli:

• Ascolta i problemi, non le soluzioni . A molti clienti piace dirti come risolvere i loro problemi. Non ascoltarli. Sei il programmatore e il tuo compito è trovare soluzioni ai problemi. Ascolta invece quali sono i problemi dei clienti e individua il modo migliore per risolverli. come altri hanno già detto, i clienti non sanno veramente cosa vogliono, a volte prima devi mostrarlo loro.

• Fai domande . Quando hai finito di fare domande, chiedi qualcun'altro. I clienti sono raramente disponibili con dettagli, in quanto non ci pensano veramente. L'unico modo per ottenere le informazioni di cui hai bisogno è farle fuori da loro.

• Trova le cose scritte A seconda della situazione con il cliente, questo può essere davvero importante in seguito quando iniziano a lamentarsi di come ciò che hai consegnato "non è quello che hanno chiesto". e se non altro, la stesura di specifiche dettagliate può aiutarti ad assicurarti di avere tutte le informazioni di cui hai bisogno e contribuire a chiarire le ambiguità tra te e il cliente.

• La comunicazione è la chiave . non limitarti a parlare con il cliente, a ottenere informazioni, a mettere fuori codice e a non parlare con loro fino a quando non è finito. Rimani sempre in contatto con il cliente. Fai domande durante il processo. mostra loro i progressi che hai fatto e ottieni feedback. Renderà la vita di tutti più facile a lungo termine.

Praticamente qualsiasi libro di auto-aiuto che raccogli sulla comunicazione ti darà qualche variazione di questo:

• Cerca prima di capire, poi di essere compreso

Questo viene dal libro delle 7 abitudini, ma sono tutte varianti del metodo " ascolto attivo ". L'obiettivo non è solo capire, ma comunicare a loro quello che hai capito.

Una volta penso di avere una buona idea di cosa bisogno (stare lontano da ciò che vogliono in particolare se iniziano a descrivere i dettagli dell'implementazione - questo è il tuo lavoro non loro) , Fornisco loro esempi di storie di varie persone che usano il sistema, e vediamo se quelle coppie con loro.

Quindi lo implemento, aspettandomi completamente che una volta che vedranno la funzione, realizzeranno che non è esattamente quello che vogliono. Mantieni tutto flessibile. L'unica costante è il cambiamento. Di solito, dopo il secondo aggiornamento rapido dopo quello iniziale, ho risolto la maggior parte delle rugosità, ma trovo sempre che mi sto avvicinando asintoticamente a un ideale che non potrò mai raggiungere. Alla fine devi lasciare andare le cose non importanti e passare a obiettivi di valore più elevato.

Sento il tuo dolore ....

Le cattive notizie sono: a seconda esattamente di che tipo di clienti hai a che fare, questo potrebbe essere il solito business.

Un problema generale comune è fondamentalmente che i clienti non sanno cosa vogliono . Di solito sanno cosa vogliono ottenere, in termini di un obiettivo aziendale, ma spesso non hanno idea di come dovrebbe apparire in termini di soluzione software. Quindi in molti casi ti troverai in questo ciclo iterativo in cui un progetto rimbalza avanti e indietro per cinque volte tanto quanto la stima iniziale era, perché il cliente continua a cambiare idea e vuole che la soluzione venga ottimizzata e modificata nuovamente. E sì, non è insolito che il risultato finale si trasformi in qualcosa di completamente diverso rispetto all'obiettivo iniziale.

Ho avuto un esempio epico di ciò che accadde un paio di anni fa - un progetto che inizialmente impiegò 10 settimane per diventare un codice trasformato in un periodo di reiterazione di 15 mesi. In quel caso, era principalmente perché diversi manager e reparti dell'azienda cliente desideravano cose diverse, quindi continuavano a inviare il lavoro, a essere ottimizzati e modificati (il nostro software è basato su abbonamento e questo era un cliente importante, quindi questo non era una pelle finanziaria dalle nostre spalle - solo un grande fastidio tecnico in realtà).

Quindi in fondo il mio consiglio è questo:

Se questo è il modo in cui il tuo particolare settore e questi clienti sono (è un grande IF), allora ti ci abitui. Pensa che sia un lavoro agile, orientato alla manutenzione (questo è il modo in cui il mio attuale concerto è, più o meno). :)

Se questo non è il modo in cui le cose devono essere fatte, e stai prendendo la colpa dei lunghi turnaround, parla ai tuoi capi. Spiega loro che ci sono problemi di comunicazione e che le specifiche che ti arrivano dai clienti non sono abbastanza chiare per poter implementare la soluzione desiderata. Non vuoi trovarti nella situazione in cui stai incolpando di non dare ai clienti ciò che vogliono, se non ottieni tutte le informazioni richieste per dare loro quello che vogliono.

Prima di tutto, dovresti accettare il fatto che i clienti non sanno veramente cosa stanno cercando fino a quando non lo vedono. Potrebbero dirti subito che hanno bisogno della funzione X. Mostragli la funzione X, poi capiranno che ciò di cui hanno veramente bisogno è la funzione Y o un'altra variante della feature X.

Un buon modo per capire che cosa il cliente vuole davvero più rapidamente è abbracciando e seguendo il Agile Manifesto , che si concentra sulla comunicazione e sul cliente collaborazione. Dividere il ciclo di sviluppo in iterazioni e mostrare al cliente un prototipo della funzionalità a ogni fine dell'iterazione. In questo modo, riceverai un feedback immediato e lo cambierai, in base al feedback del cliente, senza dover investire troppe risorse sulla funzionalità. In questo modo, sia tu che il cliente sarete soddisfatti del risultato del prodotto.

Sono abbastanza sicuro che la transizione sarà difficile per il tuo team o la tua azienda, ma è uno dei modi migliori per far fronte a requisiti in rapida evoluzione.

Lotti e molte storie simili possono essere trovate qui . Non ho mai nemmeno lavorato come subappaltatore per un'altra società di sviluppo, ho trovato un cliente che sapeva esattamente cosa volevano.

Sono abbastanza contento di lavorare con qualcuno che ha una buona idea di ciò che NON vogliono o che vogliono evitare. Di solito riesco a lavorare da lì a qualcosa di cui sono felice.

La mia esperienza è principalmente nello sviluppo di applicazioni / piattaforme, però. Per fortuna, raramente ho a che fare con problemi di estetica come fanno i web designer.

Dopo molte riscritture fastidiose, ora gestisco ciò che chiamo full disclosure.

Quindi, dopo aver discusso i requisiti e i desideri dei clienti, scriverò sempre ciò che percepisco che vogliono e come procederò per soddisfare tale requisito. Invierò quindi ciò che ho scritto e aspetterò fino a quando non risponderanno affermativamente prima di iniziare il lavoro.

Se è un progetto di grandi dimensioni (più di 5 giorni di lavoro), farò il prototipo. Questo dà loro la possibilità di cambiare idea senza enormi modifiche al codice alla fine.

Non funziona sempre, ma almeno sono in una posizione in cui il cliente sa che sta cambiando idea e che non sto implementando in modo errato.