Greșeli frecvente în comunicarea cu clientul: cum să nu-ți frustrați clientul

Când cineva solicită un proiect, trebuie să presupunem că este foarte important și că îi pasă profund de produsul la care vei lucra. Deci, este sigur să presupunem că un client este obligat să construiască multe așteptări în jurul produsului final și, prin urmare, poate deveni emoțional atunci când vine vorba de livrare.

Pe parcursul proiectului, un client s-ar putea să devină foarte entuziasmat de o funcție livrată și să te iubească, iar a doua zi el sau ea poate descoperi că ceva nu funcționează și că afecțiunea va dispărea. De cele mai multe ori, este doar o chestiune de comunicare cu clientul a mers prost.

Deși nu există rețete pentru succes când vine vorba de dezvoltarea de software la distanță, cred că există câteva lucruri care trebuie evitate pentru a menține o relație sănătoasă și productivă cu clienții care au pus atâta încredere în mâinile tale.

Nu eșua la comunicarea de bază cu clienții

Imaginați-vă comunicarea cu clienții așa cum ați face-o în comunicarea de zi cu zi cu colegii de muncă, prietenii sau orice altă persoană căreia i-ați întinde politețe.

Dacă un vechi prieten este în vizită acasă și ești de acord să te bucuri de o delicatesă locală „la vechiul tău loc” la prânz, câteva săptămâni mai târziu, ai apărea acolo? Ați rămâne în legătură între timp, sunați pentru a confirma cu câteva zile înainte? Sau poate ai presupune că sunt prea ocupați și nu ai vrea să-i deranjezi fără un motiv întemeiat? V-ați aștepta să vă anunțe când vor sosi?

Nu este probabil să continuați să discutați în fiecare zi decât dacă aveți multe despre ce vorbi, dar veți menține o anumită formă de comunicare, ca o chestiune de curtoazie și practic: nu doriți ca cealaltă persoană să creadă că ați uitat de ea , dar cu siguranță nu vrei să conduci la jumătatea orașului fără un motiv întemeiat.

La un moment dat, probabil ați experimentat situații similare și în comunicarea dvs. profesională, chiar și cu parteneri și colegi de muncă de lungă durată. Unele proiecte sunt executate cu o comunicare minimă, la fel ca să spui „obișnuit, la prânz, ne vedem acolo” pentru a confirma un prânz ușor. Chiar dacă apare ceva, cealaltă parte vă va anunța cu siguranță și veți fi de acord să reprogramați.

Cu toate acestea, lucrurile nu sunt atât de simple sau liniare în lumea dezvoltării software.

Dacă începi să lucrezi la un proiect, mai ales când ai de-a face cu un client nou, dacă nu au auzit niciodată de la tine, vor începe să se gândească la munca și angajamentul tău. Chiar dacă apari cu un produs impecabil după câteva săptămâni, clienții pot avea deja o percepție mai puțin decât ideală despre tine.

Deși uneori este neapărat să se simtă incomod, nu strica să vorbești cu clientul chiar dacă nu ai nimic din obișnuit de raportat! Ai îndoieli cu privire la un punct mic al unei povești de utilizator? Dacă crezi că este important, anunță-le. Ați întârziat puțin și nu sunteți sigur dacă veți putea respecta data estimată pe care ați convenit? Sunați la client cât mai curând posibil! Este mai bine să audă despre asta imediat.

Nu aveți îndoieli și proiectul este perfect în termen, dar clientul nu vorbește mult? De ce nu trimiteți un e-mail care descrie progresul dvs. la fiecare câteva zile? Nu va face niciun rău, deoarece e-mailurile nu vor fi o pacoste pentru nimeni, plus că vă veți documenta progresul și veți menține o comunicare regulată cu clientul.

Comunicarea defectuoasă cu clientul stimulează așteptări nerealiste

Deci, la început, am menționat că clientul este obligat să aibă multe așteptări în legătură cu proiectul, nu? Dreapta. Perioadă.

Clientul deja așteaptă multe de la produs. Dacă nu merge așa cum și-au imaginat, clienții vor fi inevitabil frustrați. Deci, de ce ar promite cineva mai mult decât poate oferi, creând astfel așteptări și mai nerealiste?

Iată o paralelă rapidă: ați cumpărat o tabletă online și vi s-a promis livrare în 10 zile. În a 8-a zi, magazinul vă anunță că există o problemă și întârzie livrarea cu o săptămână. Pentru a vă compensa inconvenientul, comerciantul promite să vă acorde un credit de 75 USD în magazin.

Probabil că oricum nu ai avut nevoie de această tabletă în următoarele zile, așa că crezi că este o afacere bună! Acum vă puteți bucura de tabletă, plus folosiți creditul magazinului pentru a le cumpăra copiilor ceva drăguț. Dar magazinul sună a doua zi, spunând că totul a fost rezolvat peste noapte.

Veți primi tableta a doua zi. Fără extra, fără credit în magazin. Acum tu ești frustrat!

"Ce? Chiar ieri mi-ai spus că voi obține o ofertă mai bună! Nu este cinstit! Le-am spus deja copiilor…”

Derulați înapoi câteva zile și tot ceea ce vă așteptați era oricum tableta. Dacă nimeni nu ți-ar fi promis o ofertă mai bună, ai fi fost mulțumit de jucăria ta când a sosit a doua zi. Dar acum, simți că ai ratat fără niciun motiv întemeiat, în afară de decizia magazinului de a te anunța.

Cum pot dezvoltatorii, în special freelancerii, să evite situații similare în comunicarea cu clienții?

Nu înnebuniți și spuneți tot ce vă trece prin minte în primul rând. Sugestiile nu sunt interzise; de fapt, sunt foarte bineveniți dacă credeți că o anumită caracteristică solicitată nu este o opțiune foarte bună pentru a rezolva problema în cauză. Dar cheia este: mai întâi gândește-te.

• Ascultă clientul.

• Analizați problema lor.

• Analizați soluția propusă.

• Asigurați-vă că se încadrează în buget/program.

• În cele din urmă, continuă și prezintă sugestia ta.

Acesta este motivul pentru care abilitățile de comunicare cu clientul pot fi dificile, deoarece eșuarea doar la unul dintre primii patru pași înseamnă că ai putea ajunge să-ți pierzi timpul și, mai rău, timpul clientului tău.

Nu presupuneți că știți de ce are nevoie clientul

Parafrazându-l pe Mary Schmich, Doamnelor și domnilor din clasa lui '17: Ascultați clientul. Dacă aș putea să-ți ofer un singur sfat pentru viitor, ar fi ascultarea clientului.

Dacă ai fost chemat pentru un proiect, este pentru că cineva are nevoie de ceva. Și cine ar ști mai bine despre această necesitate decât clientul tău? Poate părea evident, dar uneori, în lumea reală, oamenii o uită.

Să vă dau un exemplu. Un comerciant cu amănuntul cere un „sistem software” pentru afacerea sa. De îndată ce îl vezi, ajungi la concluzia că ceea ce vor ei este ceva să înregistreze toate produsele disponibile, să înregistreze fiecare achiziție făcută, să genereze chitanțe pentru clienți și să raporteze despre ce s-a vândut periodic și despre ce articole se epuizează. stoc.

Deci, la prima ta întâlnire, vrei să arăți că ești eficient și să le prezinți ceea ce ai pregătit, caracteristicile propuse, un design de bază care să se potrivească cu identitatea vizuală a magazinului și tot. Dar apoi clientul nedumerit spune că, de fapt, ceea ce are nevoie este un algoritm care să calculeze cum să afișeze mai bine produsele pe rafturi, cu scopul de a crește veniturile pentru anumite mărci și produse!

Eroarea de aici a fost pur și simplu de a nu identifica problema pe care trebuia să o rezolvi. Desigur, în acest caz, din moment ce a fost foarte devreme în proiect, ar fi suficient timp pentru a-l corecta, dar uneori, acest tip de greșeală se întâmplă mai departe. Chiar dacă nu poate fi la fel de drastic ca exemplul anterior, tot poate dăuna proiectului și/sau relației dumneavoastră cu clientul.

Sugestia mea este următoarea: discutați cu viitorii dvs. utilizatori, mult dacă este posibil, și consultați diferite părți interesate din proiect. Ei sunt cei care au o bună imagine de ansamblu asupra situației și știu de ce au nevoie. Încercați să vă dați seama ce fac ei în prezent, la fiecare pas și explicați cum ar fi util software-ul. Îmi place să spun că, atunci când încerc să înțeleg ce își dorește un client, scopul meu este aproape să-și pot îndeplini singur treaba. Dacă te apropii de acest punct, atunci ai aflat cu adevărat care sunt nevoile lor.

Nu înțelegeți ce cere clientul

Nu este neobișnuit să primiți un fel de documentație despre problema în cauză. Uneori este doar o descriere de nivel înalt, în timp ce alteori este un document detaliat cu cazuri de utilizare și reguli de afaceri. În orice caz, oricât de clare sunt înregistrările, singurul lucru pe care nu-l poți face este să presupui că tot ce este scris acolo este adevărul absolut.

Ce???

Exact. În primul rând, ceva poate însemna un lucru pentru cineva, într-un anumit context, și un lucru complet diferit pentru oamenii care nu aparțin acelei realități. Și dacă există ceva ce tu și clientul nu aveți în comun, este contextul!

În al doilea rând, nu toată lumea este un scriitor foarte priceput; ei încearcă să spună A, dar ajung să-l descrie pe B.

Deci, după ce ai citit tot ce ai fost trimis, cum vei fi sigur că ceea ce ai citit este cu adevărat ceea ce a vrut să spună? Ei bine, vei digera totul, vei face niște note, vei analiza totul și... vei convoca o întâlnire . (Vedeți? Totul este despre comunicare!) La întâlnire, veți vorbi despre problemă și veți descrie ceea ce ați înțeles cu propriile cuvinte. În această etapă, probabil că veți putea identifica orice neînțelegeri.

„Oh, dar în cazul meu, nu am primit niciun document. Am stat doar cu clientul și mi-au explicat totul în timp ce am luat câteva notițe”.

Ei bine, încă nu există nicio garanție că ați înțeles ce au vrut să spună și sugestia mea rămâne valabilă: luați-vă puțin timp cu notele, gândiți-vă la întreaga problemă, organizați totul, de preferință într-un fel de cronologie de evenimente, apoi sunați/întâlniți din nou cu clientului să prezinte ceea ce ați înțeles. S-ar putea să vă pară repetitiv, dar uneori nici clientul nu are o viziune completă asupra tuturor proceselor implicate pentru a îndeplini o anumită sarcină și va vedea apoi cât de complex va trebui să fie software-ul.

La final, trebuie să fii sigur că nu există ambiguitate sau neînțelegere.

De ce nu ar trebui să livrați tot ceea ce vă cere clientul fără să vă gândiți

OK, acum că știi că ar trebui să asculți clientul și să confirmi ceea ce ai înțeles, poți să faci tot ce ți-a cerut ei, nu?

Gresit!

Acum este momentul în care poți folosi în sfârșit toată experiența pe care o ai și să te întrebi: ceea ce ți-a cerut clientul le va rezolva problema? Ceea ce v-au întrebat e cu adevărat de ce au nevoie?

Ai fi surprins să vezi de câte ori răspunsul este „nu”.

Înainte de a livra doar ceea ce a cerut clientul, trebuie să analizăm problema și, dacă nu sunteți de acord cu ceea ce a propus angajatorul, atunci este treaba și responsabilitatea dumneavoastră profesională să clarificați acest lucru. Desigur, atunci ar trebui să explicați de ce considerați că propunerea lor nu este bună și ce va face abordarea dvs. alternativă pentru a rezolva aceste deficiențe. Încă o dată, comunicarea este cheia.

Dacă dvs. și clientul sunteți rezonabili, atunci fie veți continua cu soluția dvs., fie veți avea o sesiune de brainstorming pentru a găsi una mai bună (în cazul în care ideea dvs. nu a fost acceptabilă pentru client dintr-un motiv oarecare).

Prototip — Nu scrieți documentație extinsă

Am spus deja că tu și clientul tău, în general, nu aveți aceeași perspectivă, nu? Prin urmare, așa cum vă afectează înțelegerea documentației lor, va afecta înțelegerea acestora a ceea ce furnizați în scris. Este și o chestiune de context.

Deci, sunt de acord că cumva (la un nivel superior sau inferior), trebuie să documentăm ceea ce suntem pe cale să dezvoltăm. Dar înmânarea mai multor pagini de text fără niciun element vizual nu vă va face prea mult bine. Clientul se va plictisi citindu-l, nu va mai acorda atenție și, probabil, nu va putea înțelege ce înțelegeți prin acele reguli complexe de afaceri – sau va interpreta ceva complet diferit de ceea ce v-ați imaginat.

Rețineți că aceste neînțelegeri pot fi și mai grave dacă clientul nu are cunoștințe tehnice.

Toți acești factori pot duce la același rezultat problematic: clienții se vor plânge atunci când livrați produsul, deoarece este probabil să nu fie ceea ce au avut în vedere.

Iată ce sugerez: Întotdeauna prototip, chiar dacă este doar o schiță pentru a desena care este planul tău. Și orice definiții trebuie să faci, începe de acolo. Faceți referințe și încercați să păstrați totul simplu.

Nu mai pierdeți timpul convincând clientul că aveți dreptate

Aproape că pot fi sigur că fiecare dezvoltator a trecut prin următoarea situație: La începutul proiectului, clientul spune „Am nevoie ca culoarea de fundal a software-ului să fie galbenă. A fost deja convenit de către consiliu.” Apoi, când software-ul este livrat, ei spun „Oh, dar culoarea de fundal nu poate fi galbenă. Ți-am spus că trebuie să fie verde!” Acum, cum ar trebui să te descurci cu asta?

Cu siguranță, nu va fi de nimic, în orice caz, să insisti că ai dreptate și ei au greșit. În orice caz, îți va face dificultăți atât ție, cât și clientului.

Este întotdeauna bine să ai o evidență bună a comunicării cu clientul, doar pentru a te asigura că ești pe aceeași pagină și lași o urmă scrisă. De cele mai multe ori, dacă este ceva simplu, poți doar e-mail clientului, spunând: „După cum am convenit la acea întâlnire, fundalul sistemului va fi galben.” Și dacă, pe viitor, clientul se răzgândește, poți argumenta că așa ai procedat din cauza acelei întâlniri menționate pe email, dar dacă acea modificare chiar trebuie făcută, o poți executa, pentru un plus de x ore (și uneori, un plus de x dolari).

Dar dacă nu există nimic care să demonstreze că ai avut dreptate, atunci probabil că ai de luat o decizie (precum și o lecție de învățat): Este schimbarea atât de mare care va necesita o schimbare în arhitectura actuală sau va afecta alte caracteristici? Dacă nu, probabil că cel mai bine este să mergi înainte, să o faci și să aduci clientul lângă tine (dar cu ochii larg deschiși, astfel încât să nu se mai repete). Dacă se întâmplă, atunci o discuție cu clientul va fi cea mai bună soluție; nu unul care se concentrează pe „cum ai avut dreptate”, ci pe „cum putem rezolva problema actuală”.

În orice caz, cel mai bun mod de a preveni nevoia de a face modificări mari este de a oferi noi funcții scurte în perioade scurte de timp. Prin urmare, dacă trebuie schimbat ceva, probabil că nu va fi o transformare majoră a ceea ce există deja.

Aflați când să respectați termenele limită

Nu în ultimul rând, una dintre cele mai mari greșeli pe care le puteți face este să acordați clientului dvs. un termen limită pentru a finaliza proiectul. Și te vor ruga să faci acea greșeală!

Desigur, ca client, vrei să știi când vei putea folosi toate acele funcții frumoase despre care ai discutat în ultimele săptămâni (luni?). Dar, din moment ce un proiect nu este un produs definit, se pot întâmpla multe de când începe dezvoltarea până când software-ul este gata de utilizare.

În primul rând, nu se poate prevedea imprevizibilul. Este foarte probabil să aveți de-a face cu ceva la care nu vă așteptați. Ar putea fi o licență pe care clientul a promis că nu a fost achiziționată la timp sau un alt software intern pe care trebuie să îl utilizați, dar care nu a fost lansat când ar fi trebuit să fie, sau mediul a fost diferit de cel cu care sa convenit la început, sau clientul s-a răzgândit cu privire la câteva (câteva) caracteristici și a trebuit să refaceți câteva lucruri.

Nimic din toate acestea nu este cu adevărat vina dezvoltatorului și poate afecta profund termenul limită al unui proiect. Dar dacă tu, dornic să-i mulțumești clientului, ai promis că vei livra totul până la o anumită dată și vei ajunge, din toate motivele întemeiate, să nu faci asta, un lucru pe care îl pot garanta este că clientul va fi, măcar puțin , frustrat. Dacă sunteți freelancer, trebuie să vă gestionați timpul eficient, așa cum explică acest articol Toptal Engineering Blog. Nu uita că managementul relațiilor cu clienții este și treaba ta.

Așadar, fă-ți o favoare ție și celui care depinde de proiect și măcar oferă-le o estimare a cât timp va dura să dezvolte totul, dar întotdeauna să fie clar ca este doar o estimare și nu un termen limită.

De asemenea, vă sugerez cu tărie (mai ales dacă ați dat deja o estimare) să spuneți întotdeauna clientului când ceva durează mai mult decât se aștepta, astfel încât să poată acționa pentru a vă ajuta!