Lavorare con clienti che non sanno cosa vogliono

Di recente ho iniziato un lavoro che mi fa lavorare su un sistema esistente. Richiede modifiche e aggiornamenti, nonché un nuovo codice. Ho fatto diversi progetti di manutenzione / aggiunta ora e molti di loro sono diventati significativamente diversi da quelli effettivamente richiesti. Quindi, ho dovuto programmare l'oggetto più volte per portarlo dove voleva il richiedente.

Ora, non mi dispiace riprogrammare la funzione se questo è ciò che deve essere fatto. Tuttavia, vorrei ridurre i tempi di consegna dei miei progetti. Il collo di bottiglia sembra essere nella percezione del richiedente di ciò che deve essere fatto. Hai idee su cosa potrei fare per capire di cosa ha bisogno il richiedente più rapidamente?

Alcuni consigli:

• Ascolta i problemi, non le soluzioni . A molti clienti piace dirti come risolvere i loro problemi. Non ascoltarli. Sei il programmatore ed è il tuo lavoro trovare soluzioni ai problemi. Invece, ascolta quali problemi hanno i clienti e trova il modo migliore per risolverli. come altri hanno già detto, i clienti non sanno davvero cosa vogliono, a volte devi prima mostrarglielo.

• Poni domande . Quando hai finito di fare domande, chiedine ancora. I clienti sono raramente disponibili con dettagli, in quanto non ci pensano davvero. L'unico modo per ottenere le informazioni di cui hai bisogno è di estrarle da esse.

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

• La comunicazione è la chiave . non solo parlare con il cliente, ottenere informazioni, eliminare un po 'di codice e non parlare con loro fino a quando non è fatto. Resta sempre in contatto con il cliente. Poni domande durante tutto il processo. mostra loro i progressi che hai fatto e ottieni feedback. A lungo termine renderà la vita di tutti più semplice.

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

• Cerca prima di capire, poi di essere capito

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

Una volta che penso di avere una buona idea di ciò di cui hanno bisogno (state lontani da ciò che vogliono in particolare se iniziano a descrivere i dettagli dell'implementazione - questo è il vostro lavoro non il loro), do loro esempi di storie di varie persone che usano il sistema e vedo se che jives con loro.

Quindi lo implemento, aspettandomi completamente che quando vedranno la funzione, realizzeranno che non è esattamente quello che vogliono. Mantieni tutto flessibile. L'unica costante è il cambiamento. Di solito ottengo la maggior parte dei bordi grezzi dopo il secondo aggiornamento rapido dopo quello iniziale, ma trovo sempre che mi sto avvicinando asintoticamente ad un ideale che non riesco mai a raggiungere. Alla fine è necessario lasciare andare le cose non importanti e passare a obiettivi di valore più elevato.

Condivido il tuo dolore....

La cattiva notizia è che, a seconda del tipo di clienti con cui hai a che fare, potrebbe trattarsi di affari come al solito.

Un problema generale comune è fondamentalmente che i clienti non sanno cosa vogliono . Di solito sanno cosa vogliono raggiungere, 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 ritroverai in questo ciclo iterativo in cui un progetto rimbalza avanti e indietro per cinque volte tanto quanto la stima iniziale è stata, perché il cliente continua a cambiare idea e desidera che la soluzione sia ottimizzata e ri-ottimizzata. E sì, non è insolito che il risultato finale si trasformi in qualcosa di completamente diverso da quello che sembrava l'obiettivo iniziale.

Ho avuto un esempio epico di ciò accadere un paio d'anni fa - un progetto che inizialmente impiegava 10 settimane per codificare, trasformato in una reindirizzamento di 15 mesi. In quel caso, è stato principalmente perché diversi manager e dipartimenti dell'azienda cliente volevano cose diverse, quindi hanno continuato a rispedire il lavoro, per essere ottimizzato e ri-ottimizzato (il nostro software è basato su abbonamento e questo era un cliente importante, quindi questo non è stata una pelle finanziaria sulla nostra schiena - solo un grande fastidio tecnico davvero).

Quindi sostanzialmente il mio consiglio è questo:

Se questo è il modo in cui il tuo settore particolare e questi clienti sono (è un grande IF), allora abituati. Pensalo come un lavoro agile e orientato alla manutenzione (è così che il mio attuale concerto è più o meno). :)

Se questo non è il modo in cui le cose devono essere fatte e stai prendendo la colpa per i lunghi inversione di tendenza, allora parla con i tuoi capi. Spiega loro che ci sono problemi di comunicazione e che le specifiche che ti arrivano dai clienti non sono abbastanza chiare per te per implementare la soluzione desiderata. Non vuoi trovarti nella situazione in cui stai prendendo la colpa per non dare ai clienti ciò che vogliono, se non stai ottenendo tutte le informazioni necessarie per dare loro ciò che vogliono.

Prima di tutto, dovresti accettare il fatto che i clienti non sanno davvero cosa stanno cercando fino a quando non lo vedono. Potrebbero dirti ora che hanno bisogno della funzione X. Mostra loro la funzione X, quindi si renderanno conto che ciò di cui hanno davvero bisogno è la funzione Y o un'altra variante della funzione X.

Un buon modo per capire cosa desidera veramente più rapidamente il cliente è quello di abbracciare e seguire il Manifesto Agile , che si concentra sulla comunicazione e sulla collaborazione con il cliente. Dividi il ciclo di sviluppo in iterazioni e mostra al cliente un prototipo della funzionalità ad ogni estremità dell'iterazione. In questo modo, riceverai un feedback immediato e lo modificherai, in base al feedback del cliente, senza dover investire troppe risorse sulla funzione. In questo modo, sia tu che il cliente sarete contenti 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.

Molte e molte storie simili possono essere trovate qui . Non ho mai, nemmeno lavorando come subappaltatore per un'altra società di sviluppo, trovare un cliente che sapesse esattamente cosa voleva.

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

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 fastidiose riscritture, ora gestisco ciò che chiamo divulgazione completa.

Quindi, dopo aver discusso delle esigenze e dei desideri dei clienti, scriverò sempre ciò che percepisco che desiderano e come procederò a soddisfare tale requisito. Invierò quindi ciò che ho scritto e aspetterò che rispondano affermativamente prima di iniziare a lavorare.

Se è un progetto di grandi dimensioni (più di 5 giorni di lavoro) lo farò anche io. Questo dà loro la possibilità di cambiare idea senza enormi cambiamenti di codice da parte mia.

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