Errori comuni nella comunicazione con il cliente: come non frustrare il cliente

Quando qualcuno richiede un progetto, dobbiamo presumere che sia molto importante e che tengano profondamente al prodotto su cui lavorerai. Quindi, è lecito ritenere che un cliente sia obbligato a costruire molte aspettative sul prodotto finale e quindi possa diventare emotivo quando si tratta di consegna.

Nel corso del progetto, un cliente potrebbe essere super entusiasta di una funzione consegnata e amarti, e il giorno successivo può scoprire che qualcosa non funziona e che l'affetto sarà svanito. Il più delle volte, è solo una questione di comunicazione con il cliente andata storta.

Sebbene non ci siano ricette per il successo quando si tratta di sviluppo software remoto, credo che ci siano alcune cose che devono essere evitate per mantenere una relazione sana e produttiva con clienti che hanno riposto così tanta fiducia nelle tue mani.

Non fallire nella comunicazione di base con i clienti

Immagina la comunicazione con i clienti come faresti con la comunicazione quotidiana con colleghi, amici o qualsiasi altra persona a cui porgeresti cortesia.

Se un vecchio amico viene a casa e accetti di gustare una prelibatezza locale "al tuo vecchio posto" a mezzogiorno, poche settimane dopo, ti faresti semplicemente vedere lì? Rimani in contatto nel frattempo, chiami per confermare con qualche giorno di anticipo? O forse daresti per scontato che siano troppo occupati e non vorresti disturbarli senza una buona ragione? Ti aspetteresti che ti facciano sapere quando arrivano?

Non è probabile che continuerai a chattare tutti i giorni a meno che tu non abbia molto di cui parlare, ma manterrai una qualche forma di comunicazione, per una questione di cortesia e praticità: non vuoi che l'altra persona pensi che ti sei dimenticato di loro , ma sicuramente non vorrai guidare dall'altra parte della città senza una buona ragione.

Ad un certo punto, probabilmente hai vissuto situazioni simili anche nella tua comunicazione professionale, anche con partner e colleghi di lunga data. Alcuni progetti vengono eseguiti con una comunicazione minima, proprio come dire “il solito, a mezzogiorno, ci vediamo lì” per confermare un pranzo leggero. Anche se dovesse succedere qualcosa, l'altra parte te lo farà sicuramente sapere e tu accetterai di riprogrammare.

Tuttavia, le cose non sono così semplici o lineari nel mondo dello sviluppo software.

Se inizi a lavorare su un progetto, soprattutto quando hai a che fare con un nuovo cliente, se non ha mai tue notizie, comincerà ad avere dei ripensamenti sul tuo lavoro e sul tuo impegno. Anche se ti presenti con un prodotto impeccabile dopo poche settimane, i clienti potrebbero già avere una percezione tutt'altro che ideale di te.

Anche se a volte è destinato a sentirsi a disagio, non fa male parlare con il cliente anche se non hai niente fuori dal solito da segnalare! Hai dei dubbi su un piccolo punto di una user story? Se pensi che sia importante, faglielo sapere. Sei un po' in ritardo e non sei sicuro di riuscire a rispettare la data stimata che hai concordato? Chiama il cliente al più presto! È meglio che lo sentano subito.

Non hai dubbi e il progetto è perfettamente nei tempi previsti, ma il cliente parla poco? Perché non inviare un'e-mail descrivendo i tuoi progressi ogni pochi giorni? Non farà alcun male perché le e-mail non saranno un fastidio per nessuno, inoltre documenterai i tuoi progressi e manterrai una comunicazione regolare con il cliente.

La comunicazione difettosa del cliente alimenta aspettative irrealistiche

Quindi, all'inizio, ho detto che il cliente è destinato ad avere molte aspettative sul progetto, giusto? Destra. Periodo.

Il cliente si aspetta già molto dal prodotto. Se non va come immaginavano, i clienti si sentiranno inevitabilmente frustrati. Quindi, perché qualcuno dovrebbe promettere più di quanto può offrire, creando così aspettative ancora più irrealistiche?

Ecco un rapido parallelo: hai acquistato un tablet online e ti è stata promessa la consegna in 10 giorni. L'8° giorno, il negozio ti informa che c'è un problema e ritarda la consegna di una settimana. Per compensare l'inconveniente, il rivenditore promette di darti un credito in negozio di $ 75.

Probabilmente non avevi davvero bisogno di quel tablet per i prossimi giorni, quindi pensi che sia un buon affare! Ora puoi goderti il ​​tablet e utilizzare il credito del negozio per comprare qualcosa di carino ai tuoi figli. Ma il negozio chiama il giorno successivo, dicendo che tutto è stato risolto durante la notte.

Riceverai il tablet il giorno successivo. Nessun extra, nessun credito in negozio. Ora sei tu che sei frustrato!

"Che cosa? Proprio ieri mi avevi detto che avrei fatto un affare migliore! Non è giusto! L'ho già detto ai bambini…”

Riavvolgi un paio di giorni e tutto ciò che ti aspettavi era comunque il tablet. Se nessuno ti avesse promesso un affare migliore, saresti stato contento del tuo giocattolo quando è arrivato il giorno successivo. Ma ora ti senti come se ti stessi perdendo senza una buona ragione, a parte la decisione del negozio di farti sapere.

Come possono gli sviluppatori, in particolare i liberi professionisti, evitare situazioni simili nella loro comunicazione con i clienti?

Non impazzire e dire tutto ciò che ti viene in mente in primo luogo. I suggerimenti non sono vietati; in realtà, sono molto graditi se ritieni che una particolare funzionalità richiesta non sia un'ottima opzione per risolvere il problema in questione. Ma la chiave è: pensa prima.

• Ascolta il cliente.

• Analizza il loro problema.

• Analizza la soluzione proposta.

• Assicurati che rientri nel budget/programma.

• Infine, vai avanti e presenta il tuo suggerimento.

Questo è il motivo per cui le capacità di comunicazione con il cliente possono essere complicate, perché fallire solo in uno dei primi quattro passaggi significa che potresti finire per sprecare il tuo tempo e, peggio, il tempo del tuo cliente.

Non dare per scontato che tu sappia di cosa ha bisogno il cliente

Parafrasando Mary Schmich, Signore e signori della classe '17: Ascoltate il cliente. Se potessi offrirti un solo consiglio per il futuro, l'ascolto del cliente sarebbe quello.

Se sei stato chiamato per un progetto, è perché qualcuno ha bisogno di qualcosa. E chi conoscerebbe meglio questa necessità del tuo cliente? Può sembrare ovvio, ma a volte, nel mondo reale, le persone lo dimenticano.

Lasciate che vi faccia un esempio. Un rivenditore chiede un “sistema software” per la sua attività. Non appena lo vedi, salti alla conclusione che quello che vogliono è qualcosa per registrare tutti i prodotti disponibili, registrare ogni acquisto effettuato, generare ricevute per i clienti e riferire su ciò che è stato venduto periodicamente e su quali articoli stanno finendo scorta.

Quindi, al tuo primo incontro, vuoi dimostrare di essere efficiente e presentare loro ciò che hai preparato, le caratteristiche proposte, un design di base per accompagnare l'identità visiva del negozio e tutto il resto. Ma poi il cliente perplesso dice che, in realtà, ciò di cui ha bisogno è un algoritmo per calcolare come esporre meglio i prodotti sugli scaffali, con l'obiettivo di aumentare le entrate per marchi e prodotti specifici!

L'errore qui era semplicemente non identificare quale problema dovevi risolvere. Naturalmente, in questo caso, dato che era all'inizio del progetto, ci sarebbe stato tutto il tempo per sistemare le cose, ma a volte questo tipo di errore si verifica più avanti. Anche se non può essere così drastico come l'esempio precedente, può comunque danneggiare il progetto e/o il tuo rapporto con il cliente.

Il mio suggerimento è il seguente: parlate con i vostri futuri utenti, molto se possibile, e consultate le varie parti interessate nel progetto. Sono quelli con una buona panoramica della situazione e sanno di cosa hanno bisogno. Cerca di capire cosa fanno attualmente, passo dopo passo, e spiega come il software potrebbe tornare utile. Mi piace dire che, quando cerco di capire cosa desidera un cliente, il mio obiettivo è di riuscire quasi a svolgere il proprio lavoro da solo. Se ti avvicini a questo punto, allora hai veramente scoperto quali sono i loro bisogni.

Non capire cosa sta chiedendo il cliente

Non è raro ricevere una sorta di documentazione sul problema in questione. A volte è solo una descrizione di alto livello, mentre altre volte è un documento dettagliato con casi d'uso e regole aziendali. In ogni caso, non importa quanto siano chiari i registri, l'unica cosa che non puoi fare è presumere che tutto ciò che è scritto lì sia la verità assoluta.

Che cosa???

Esattamente. Primo, qualcosa può significare una cosa per qualcuno, in un certo contesto, e una cosa completamente diversa per le persone che non appartengono a quella realtà. E se c'è qualcosa che tu e il cliente non avete in comune, è il contesto!

In secondo luogo, non tutti sono scrittori molto abili; cercano di dire A ma finiscono per descrivere B.

Quindi, dopo aver letto tutto ciò che ti è stato inviato, come sarai sicuro che ciò che hai letto sia davvero ciò che intendevano? Bene, digerirai tutto, prenderai appunti, analizzerai tutto e... convocherai una riunione . (Vedi? È tutta una questione di comunicazione!) Durante l'incontro, parlerai del problema e descriverai ciò che hai capito con parole tue. A questo punto, probabilmente sarai in grado di identificare eventuali malintesi.

«Oh, ma nel mio caso non ho ricevuto alcun documento. Mi sono appena seduto con il cliente e mi hanno spiegato tutto mentre prendevo appunti”.

Bene, non c'è ancora alcuna garanzia che tu abbia capito cosa intendessero e il mio suggerimento è ancora valido: prenditi un po' di tempo con i tuoi appunti, pensa all'intero problema, organizza tutto, preferibilmente in una sorta di sequenza temporale degli eventi, e poi chiama/incontra di nuovo con il cliente per presentare ciò che hai capito. Potrebbe sembrare ripetitivo per te, ma a volte anche il cliente non ha una visione completa di tutti i processi coinvolti per eseguire un'attività specifica e vedrà quindi quanto complesso dovrà essere il software.

Alla fine, devi essere certo che non ci siano ambiguità o incomprensioni.

Perché non dovresti fornire tutto ciò che il cliente chiede senza pensarci

OK, ora che sai che dovresti ascoltare il cliente e confermare ciò che hai capito, puoi semplicemente andare avanti e fare tutto ciò che ti hanno chiesto, giusto?

Sbagliato!

Ora è il momento in cui puoi finalmente usare tutta l'esperienza che hai e chiederti: ciò che il cliente ti ha chiesto risolverà il suo problema? Quello che ti hanno chiesto è davvero ciò di cui hanno bisogno?

Saresti sorpreso di vedere quante volte la risposta è "no".

Prima di fornire semplicemente ciò che il cliente ha chiesto, dobbiamo analizzare il problema e, se non sei d'accordo con ciò che il datore di lavoro ha proposto, è tuo compito e responsabilità professionale chiarirlo. Ovviamente, dovresti quindi spiegare perché ritieni che la loro proposta non sia buona e cosa farà il tuo approccio alternativo per affrontare queste carenze. Ancora una volta, la comunicazione è la chiave.

Se tu e il cliente siete ragionevoli, allora procederete con la vostra soluzione o farete una sessione di brainstorming per trovarne una migliore (nel caso in cui la vostra idea non fosse accettabile per il cliente per qualche motivo).

Prototipo: non scrivere un'ampia documentazione

Ho già detto che tu e il tuo cliente generalmente non avete la stessa prospettiva, giusto? Quindi, così come influisce sulla tua comprensione della loro documentazione, influirà sulla loro comprensione di ciò che fornisci per iscritto. È anche una questione di contesto.

Quindi, sono d'accordo sul fatto che in qualche modo (a un livello superiore o inferiore), dobbiamo documentare ciò che stiamo per sviluppare. Ma consegnare diverse pagine di testo senza alcun elemento visivo non ti farà molto bene. Il cliente si annoierà leggendolo, smetterà di prestare attenzione e probabilmente non sarà in grado di capire cosa intendi con quelle complesse regole aziendali, oppure interpreterà qualcosa di completamente diverso da quello che avevi immaginato.

Tieni presente che questi malintesi possono essere anche peggiori se il cliente non ha un background tecnico.

Tutti questi fattori possono portare allo stesso risultato problematico: i clienti si lamenteranno quando consegnerai il prodotto perché è probabile che non sarà quello che avevano in mente.

Ecco cosa suggerisco: sempre prototipare, anche se è solo uno schizzo per disegnare qual è il tuo piano. E qualunque definizione tu debba fare, inizia da lì. Fai riferimenti e cerca di mantenerlo semplice.

Smetti di perdere tempo a convincere il cliente che hai ragione

Posso essere quasi certo che ogni sviluppatore ha attraversato la seguente situazione: All'inizio del progetto, il cliente dice “Ho bisogno che il colore di sfondo del software sia giallo. E' già stato concordato dal consiglio di amministrazione". Quindi, quando il software viene consegnato, dicono "Oh, ma il colore di sfondo non può essere giallo. Te l'avevo detto che doveva essere verde! Ora, come dovresti affrontare questo?

Di sicuro, in ogni caso, non servirà a nulla insistere che tu avevi ragione e loro torto. Semmai, creerà problemi a te e al cliente.

È sempre bene avere un buon record di comunicazione con il cliente, solo per essere sicuri di essere sulla stessa pagina e lasciare una traccia scritta. La maggior parte delle volte, se si tratta di qualcosa di semplice, puoi semplicemente inviare un'e-mail al cliente, dicendo: "Come concordato in quella riunione, lo sfondo del sistema sarà giallo". E se, in futuro, il cliente cambia idea, puoi sostenere di averlo fatto a causa di quell'incontro menzionato nell'e-mail, ma se quella modifica deve davvero essere apportata, puoi eseguirla, per x ore extra (e a volte, x dollari in più).

Ma se non c'è nulla per dimostrare che avevi ragione, probabilmente hai una decisione da prendere (oltre a una lezione da imparare): il cambiamento è così grande che richiederà un cambiamento nell'architettura attuale o influenzerà altre funzionalità? In caso contrario, probabilmente è meglio andare avanti, farlo e portare il cliente al tuo fianco (ma con gli occhi ben aperti in modo che non accada di nuovo). In tal caso, un colloquio con il cliente sarà la soluzione migliore; non uno incentrato su "come avevi ragione", ma su "come possiamo risolvere il problema attuale".

In ogni caso, il modo migliore per evitare di dover apportare grandi modifiche è fornire nuove funzionalità brevi in ​​brevi periodi di tempo. Pertanto, se qualcosa deve essere cambiato, probabilmente non sarà una grande trasformazione di ciò che già esiste.

Sapere quando impegnarsi per le scadenze

Ultimo, ma non meno importante, uno dei più grandi errori che puoi fare è dare al tuo cliente una scadenza per completare il progetto. E ti pregheranno di fare quell'errore!

Ovviamente, come cliente, vuoi sapere quando sarai in grado di utilizzare tutte quelle belle funzionalità di cui hai discusso nelle ultime settimane (mesi?). Ma, poiché un progetto non è un prodotto definito, possono succedere molte cose da quando inizia lo sviluppo fino a quando il software è pronto per l'uso.

Prima di tutto, non si può prevedere l'imprevedibile. È molto probabile che dovrai affrontare qualcosa che non ti aspettavi. Potrebbe essere una licenza promessa dal cliente che non è stata acquistata in tempo, o qualche altro software interno che è necessario utilizzare ma non è stato rilasciato quando avrebbe dovuto essere, oppure l'ambiente era diverso da quello concordato all'inizio, oppure il cliente ha cambiato idea su alcune (poche) funzionalità e hai dovuto rifare un paio di cose.

Niente di tutto ciò è davvero colpa di uno sviluppatore e può influenzare profondamente la scadenza di un progetto. Ma se tu, volendo accontentare il cliente, hai promesso che avresti consegnato tutto entro una certa data e alla fine, per tutte le giuste ragioni, non farlo, una cosa che posso garantire è che il cliente sarà, almeno un po' , frustrato. Se sei un libero professionista, devi gestire il tuo tempo in modo efficiente, come spiega questo articolo del blog di Toptal Engineering. Non dimenticare che anche la gestione delle relazioni con i clienti è il tuo lavoro.

Quindi, fai un favore a te stesso e a chi dipende dal progetto e dai loro almeno una stima di quanto tempo ci vorrà per sviluppare tutto, ma chiarisci sempre che si tratta solo di una stima e non di una scadenza.

Inoltre, suggerisco caldamente (soprattutto se hai già fornito un preventivo) di dire sempre al cliente quando qualcosa sta impiegando più tempo del previsto in modo che possa agire per aiutarti!