Typowe błędy w komunikacji z klientem: jak nie frustrować klienta

Kiedy ktoś prosi o projekt, musimy założyć, że jest to bardzo ważne i że bardzo mu zależy na produkcie, nad którym będziesz pracować. Można więc bezpiecznie założyć, że klient jest zobowiązany do budowania wielu oczekiwań wobec produktu końcowego, a zatem może stać się emocjonalny, jeśli chodzi o dostawę.

Przez cały czas trwania projektu klient może być bardzo podekscytowany dostarczoną funkcją i cię kochać, a następnego dnia może odkryć, że coś nie działa i to uczucie zniknie. Najczęściej jest to tylko kwestia niewłaściwej komunikacji z klientem.

Chociaż nie ma recepty na sukces, jeśli chodzi o zdalne tworzenie oprogramowania, uważam, że jest kilka rzeczy, których należy unikać, aby utrzymać zdrowe i produktywne relacje z klientami, którzy tak bardzo zaufali w Twoje ręce.

Nie zawiedź podstawowej komunikacji z klientami

Wyobraź sobie komunikację z klientami jak codzienną komunikację ze współpracownikami, przyjaciółmi lub jakąkolwiek inną osobą, wobec której okazałbyś uprzejmość.

Jeśli stary przyjaciel odwiedza dom i zgadzasz się zjeść lokalny przysmak „w swoim starym miejscu” w południe, kilka tygodni później, czy po prostu tam się pojawisz? Czy w międzyczasie pozostałbyś w kontakcie, zadzwoń w celu potwierdzenia z kilkudniowym wyprzedzeniem? A może założysz, że są zbyt zajęci i nie chcą im przeszkadzać bez powodu? Czy spodziewałbyś się, że powiadomią Cię, kiedy przybędą?

Prawdopodobnie nie będziesz rozmawiać codziennie, chyba że masz dużo do omówienia, ale zachowasz pewną formę komunikacji, z uprzejmości i praktyczności: nie chcesz, aby druga osoba myślała, że ​​o nich zapomniałeś , ale na pewno nie chcesz jechać przez środek miasta bez powodu.

W pewnym momencie prawdopodobnie doświadczyłeś podobnych sytuacji w swojej komunikacji zawodowej, nawet z wieloletnimi partnerami i współpracownikami. Niektóre projekty są realizowane przy minimalnej komunikacji, tak jak powiedzenie „zwykłe w południe, do zobaczenia” w celu potwierdzenia lekkiego lunchu. Nawet jeśli coś się wydarzy, druga strona na pewno Cię o tym powiadomi, a Ty zgodzisz się na zmianę terminu.

Jednak w świecie tworzenia oprogramowania sprawy nie są takie proste ani liniowe.

Jeśli zaczniesz pracę nad projektem, zwłaszcza gdy masz do czynienia z nowym klientem, jeśli nigdy się od ciebie nie usłyszy, zaczną się zastanawiać nad twoją pracą i zaangażowaniem. Nawet jeśli po kilku tygodniach pojawisz się z nieskazitelnym produktem, klienci mogą już mieć o Tobie mniej niż idealne postrzeganie.

Chociaż czasami może się to wydawać niezręczne, rozmowa z klientem nie zaszkodzi, nawet jeśli nie masz nic niezwykłego do zgłoszenia! Czy masz wątpliwości co do jednego małego punktu w historii użytkownika? Jeśli uważasz, że to ważne, daj im znać. Trochę się spóźniasz i nie jesteś pewien, czy zdążysz dotrzymać ustalonego terminu? Zadzwoń do klienta JAK NAJSZYBCIEJ! Lepiej, żeby od razu o tym usłyszeli.

Nie masz żadnych wątpliwości, projekt przebiega idealnie, ale klient niewiele mówi? Dlaczego nie wysyłać co kilka dni e-maila z opisem swoich postępów? Nie zaszkodzi, ponieważ e-maile nie będą nikomu uciążliwe, a ponadto będziesz dokumentować swoje postępy i utrzymywać regularną komunikację z klientem.

Wadliwa komunikacja z klientem sprzyja nierealistycznym oczekiwaniom

A więc na początku wspomniałem, że klient musi mieć spore oczekiwania co do projektu, prawda? Prawidłowy. Okres.

Klient już teraz wiele oczekuje od produktu. Jeśli nie pójdzie tak, jak sobie wyobrażali, klienci nieuchronnie będą sfrustrowani. Dlaczego więc ktokolwiek miałby obiecywać więcej, niż może dostarczyć, tworząc w ten sposób jeszcze bardziej nierealistyczne oczekiwania?

Oto szybkie porównanie: kupiłeś tablet online i obiecano Ci dostawę w ciągu 10 dni. 8 dnia sklep informuje o problemie i opóźnia dostawę o tydzień. Aby zrekompensować Ci niedogodności, sprzedawca obiecuje Ci 75 USD kredytu w sklepie.

Prawdopodobnie tak naprawdę nie potrzebowałeś tego tabletu przez kilka następnych dni, więc uważasz, że to dobra okazja! Teraz możesz cieszyć się tabletem, a także wykorzystać kredyt w sklepie, aby kupić dzieciom coś ładnego. Ale sklep dzwoni następnego dnia, mówiąc, że wszystko zostało załatwione w ciągu nocy.

Tablet dostaniesz następnego dnia. Bez dodatków, bez kredytu w sklepie. Teraz to ty jesteś sfrustrowany!

"Co? Jeszcze wczoraj powiedziałeś mi, że dostanę lepszą ofertę! To niesprawiedliwe! Powiedziałem już dzieciom…”

Cofnij się o kilka dni, a wszystko, czego oczekiwałeś, to i tak tablet. Gdyby nikt nie obiecał ci lepszej oferty, byłbyś zadowolony ze swojej zabawki, gdy dotarłaby następnego dnia. Ale teraz czujesz, że tracisz coś bez powodu, poza decyzją sklepu o poinformowaniu Cię.

Jak deweloperzy, zwłaszcza freelancerzy, mogą uniknąć podobnych sytuacji w komunikacji z klientami?

Przede wszystkim nie wariując i nie mówiąc wszystkiego, co przychodzi ci do głowy. Sugestie nie są zabronione; w rzeczywistości są one bardzo mile widziane, jeśli uważasz, że dana funkcja, o którą prosisz, nie jest dobrą opcją rozwiązania problemu. Ale kluczem jest: Najpierw myśl.

• Posłuchaj klienta.

• Przeanalizuj ich problem.

• Przeanalizuj proponowane rozwiązanie.

• Upewnij się, że mieści się w budżecie/harmonogramie.

• Na koniec przedstaw swoją sugestię.

Dlatego umiejętności komunikacji z klientem mogą być trudne, ponieważ porażka tylko na jednym z pierwszych czterech kroków oznacza, że ​​możesz stracić czas, a co gorsza, czas swojego klienta.

Nie zakładaj, że wiesz, czego potrzebuje klient

Parafrazując Mary Schmich, Panie i panowie z klasy '17: Posłuchaj klienta. Gdybym mógł zaoferować Ci tylko jedną wskazówkę na przyszłość, wysłuchanie klienta byłoby to.

Jeśli zostałeś wezwany do projektu, to dlatego, że ktoś czegoś potrzebuje. A kto wiedziałby o tej konieczności lepiej niż twój klient? Może wydawać się to oczywiste, ale czasami w prawdziwym świecie ludzie o tym zapominają.

Dam ci przykład. Sprzedawca detaliczny prosi o „system oprogramowania” dla swojej firmy. Jak tylko to widzisz, dochodzisz do wniosku, że chcą czegoś, aby rejestrować wszystkie dostępne produkty, rejestrować każdy dokonany zakup, generować paragony dla klientów i raportować, co okresowo zostało sprzedane i na jakich pozycjach się kończy Zbiory.

Tak więc na pierwszym spotkaniu chcesz pokazać, że jesteś skuteczny i przedstawić im to, co przygotowałeś, proponowane funkcje, podstawowy projekt pasujący do identyfikacji wizualnej sklepu i tak dalej. Ale zdziwiony klient mówi, że tak naprawdę to, czego potrzebuje, to algorytm obliczający, jak lepiej eksponować produkty na półkach, mający na celu zwiększenie przychodów dla określonych marek i produktów!

Błąd tutaj po prostu nie identyfikował problemu, który miałeś rozwiązać. Oczywiście w tym przypadku, ponieważ projekt był na bardzo wczesnym etapie, byłoby dużo czasu, aby to naprawić, ale czasami tego rodzaju błąd zdarza się później. Nawet nie może to być tak drastyczne, jak w poprzednim przykładzie, nadal może zaszkodzić projektowi i/lub twojej relacji z klientem.

Moja sugestia jest następująca: Rozmawiaj z przyszłymi użytkownikami, jeśli to możliwe, dużo i konsultuj się z różnymi interesariuszami projektu. To oni mają dobry obraz sytuacji i wiedzą, czego potrzebują. Spróbuj dowiedzieć się, co obecnie robią, na każdym kroku i wyjaśnij, w jaki sposób oprogramowanie może się przydać. Lubię mówić, że kiedy próbuję zrozumieć, czego życzy sobie klient, moim celem jest prawie możliwość samodzielnego wykonywania swojej pracy. Jeśli zbliżysz się do tego punktu, to naprawdę wiesz, jakie są ich potrzeby.

Nie rozumiem, o co prosi klient

Nierzadko otrzymuje się jakąś dokumentację dotyczącą problemu. Czasami jest to po prostu opis wysokiego poziomu, podczas gdy innym razem jest to szczegółowy dokument z przypadkami użycia i regułami biznesowymi. W każdym razie, bez względu na to, jak jasne są zapisy, jedyną rzeczą, której nie możesz zrobić, jest po prostu założenie, że wszystko, co tam napisano, jest absolutną prawdą.

Co???

Dokładnie tak. Po pierwsze, coś może znaczyć dla kogoś jedno, w pewnym kontekście, a zupełnie co innego dla ludzi, którzy nie należą do tej rzeczywistości. A jeśli jest coś, czego Ty i klient nie macie ze sobą wspólnego, to jest to kontekst!

Po drugie, nie każdy jest bardzo utalentowanym pisarzem; próbują powiedzieć A, ale w końcu opisują B.

Tak więc, po przeczytaniu wszystkiego, co otrzymałeś, jak będziesz mieć pewność, że to, co czytasz, jest naprawdę tym, co miało na myśli? Cóż, wszystko przetrawisz, zrobisz notatki, wszystko przeanalizujesz i… zwołasz spotkanie . (Widzisz? Chodzi o komunikację!) Na spotkaniu porozmawiasz o problemie i własnymi słowami opiszesz, co zrozumiałeś. Na tym etapie prawdopodobnie będziesz w stanie zidentyfikować wszelkie nieporozumienia.

„Och, ale w moim przypadku nie dostałem żadnych dokumentów. Po prostu siedziałem z klientem i wszystko mi wyjaśniali, a ja robiłem notatki”.

Cóż, nadal nie ma gwarancji, że zrozumiałeś, o co im chodziło, a moja sugestia jest nadal aktualna: poświęć trochę czasu na notatki, przemyśl cały problem, zorganizuj wszystko, najlepiej według jakiejś osi czasu wydarzeń, a następnie zadzwoń/spotkaj się ponownie z klient do przedstawienia tego, co zrozumiałeś. Może Ci się to wydawać powtarzalne, ale czasami nawet klient nie ma pełnej wizji wszystkich procesów zaangażowanych w wykonanie określonego zadania i wtedy widzi, jak złożone będzie oprogramowanie.

Na koniec musisz mieć pewność, że nie ma niejasności ani nieporozumień.

Dlaczego nie powinieneś bez zastanowienia dostarczać wszystkiego, o co prosi klient

OK, teraz, kiedy już wiesz, że powinieneś wysłuchać klienta i potwierdzić to, co zrozumiałeś, możesz po prostu zrobić wszystko, o co cię prosi, prawda?

Zło!

Teraz jest moment, w którym możesz w końcu wykorzystać całe swoje doświadczenie i zadać sobie pytanie: Czy to, o co prosił klient, rozwiąże jego problem? Czy to, o co cię pytali, naprawdę jest tym, czego potrzebują?

Zdziwiłbyś się, ile razy odpowiedź brzmi „nie”.

Przed dostarczeniem tego, o co prosił klient, musimy przeanalizować problem, a jeśli nie zgadzasz się z propozycją pracodawcy, to Twoim zadaniem i zawodowym obowiązkiem jest wyjaśnienie tego. Oczywiście powinieneś wtedy wyjaśnić, dlaczego uważasz, że ich propozycja nie jest dobra i co zrobi twoje alternatywne podejście, aby zaradzić tym niedociągnięciom. Po raz kolejny kluczem jest komunikacja.

Jeśli Ty i klient jesteście rozsądni, albo kontynuujesz swoje rozwiązanie, albo przeprowadzasz burzę mózgów, aby wymyślić lepsze (na wypadek, gdyby Twój pomysł z jakiegoś powodu nie był do przyjęcia dla klienta).

Prototyp — nie pisz obszernej dokumentacji

Powiedziałem już, że ty i twój klient generalnie nie macie tej samej perspektywy, prawda? Dlatego tak samo, jak wpływa to na twoje zrozumienie ich dokumentacji, wpłynie to na ich zrozumienie tego, co przekazujesz na piśmie. To także kwestia kontekstu.

Zgadzam się więc, że jakoś (na wyższym lub niższym poziomie) musimy udokumentować to, co będziemy rozwijać. Ale przekazanie kilku stron tekstu bez żadnych elementów wizualnych na niewiele się zda. Klient znudzi się czytaniem tego, przestanie zwracać uwagę i prawdopodobnie nie będzie w stanie zrozumieć, co rozumiesz przez te złożone reguły biznesowe — lub zinterpretuje coś zupełnie innego niż to, co sobie wyobrażałeś.

Pamiętaj, że te nieporozumienia mogą być jeszcze gorsze, jeśli klient nie ma zaplecza technicznego.

Wszystkie te czynniki mogą skutkować tym samym problematycznym wynikiem: Klienci będą narzekać, gdy dostarczysz produkt, ponieważ prawdopodobnie nie będzie to taki, jaki mieli na myśli.

Oto, co sugeruję: Zawsze twórz prototyp, nawet jeśli jest to tylko szkic, aby narysować swój plan. I bez względu na to, jakie masz definicje, zacznij od tego. Zrób referencje i postaraj się, aby było to proste.

Przestań marnować czas na przekonywanie klienta, że ​​masz rację

Jestem prawie pewien, że każdy programista przeszedł następującą sytuację: Na początku projektu klient mówi: „Potrzebuję, aby kolor tła oprogramowania był żółty. Zostało to już uzgodnione przez zarząd”. Następnie, gdy oprogramowanie jest dostarczane, mówią „Och, ale kolor tła nie może być żółty. Mówiłem ci, że musi być zielony!” Jak sobie z tym poradzić?

Na pewno nie ma sensu po prostu upierać się, że masz rację, a oni się mylili. Jeśli już, to po prostu sprawi to, że zarówno Tobie, jak i klientowi będzie ciężko.

Zawsze dobrze jest mieć dobry zapis komunikacji z klientem, aby upewnić się, że jesteś na tej samej stronie i zostawisz pisemny ślad. W większości przypadków, jeśli jest to coś prostego, możesz po prostu wysłać e-maila do klienta, mówiąc: „Jak ustaliliśmy na tym spotkaniu, tło systemu będzie żółte”. A jeśli w przyszłości klient zmieni zdanie, możesz argumentować, że zrobiłeś to w ten sposób z powodu spotkania wspomnianego w e-mailu, ale jeśli ta modyfikacja naprawdę musi zostać dokonana, możesz ją wykonać przez dodatkowe x godzin (a czasami dodatkowe x dolarów).

Ale jeśli nie ma nic do udowodnienia, że ​​miałeś rację, prawdopodobnie masz do podjęcia decyzję (a także lekcję do nauczenia): Czy zmiana jest tak duża, że ​​będzie wymagała zmiany w obecnej architekturze lub wpłynie na inne funkcje? Jeśli nie, prawdopodobnie najlepiej jest po prostu iść dalej, zrobić to i pozyskać klienta po swojej stronie (ale z szeroko otwartymi oczami, aby to się więcej nie powtórzyło). Jeśli tak, to rozmowa z klientem będzie najlepszym rozwiązaniem; nie jeden skupiający się na tym, „jak miałeś rację”, ale na „jak możemy rozwiązać obecny problem”.

W każdym razie najlepszym sposobem na uniknięcie konieczności dokonywania dużych modyfikacji jest dostarczanie krótkich nowych funkcji w krótkich odstępach czasu. Dlatego jeśli trzeba coś zmienić, prawdopodobnie nie będzie to poważna transformacja tego, co już istnieje.

Wiedz, kiedy zobowiązać się do terminów

Wreszcie, jednym z największych błędów, jakie możesz popełnić, jest wyznaczenie klientowi terminu zakończenia projektu. I będą cię błagać o popełnienie tego błędu!

Oczywiście jako klient chcesz wiedzieć, kiedy będziesz mógł korzystać z tych wszystkich fajnych funkcji, o których rozmawiałeś w ciągu ostatnich tygodni (miesięcy?). Ale ponieważ projekt nie jest zdefiniowanym produktem, wiele może się wydarzyć od momentu rozpoczęcia rozwoju do momentu, gdy oprogramowanie jest gotowe do użycia.

Przede wszystkim nie da się przewidzieć nieprzewidywalnego. Jest bardzo prawdopodobne, że będziesz miał do czynienia z czymś, czego się nie spodziewałeś. Może to być licencja obiecana przez klienta, która nie została zakupiona na czas, lub jakieś inne wewnętrzne oprogramowanie, którego musisz użyć, ale nie zostało wydane w odpowiednim czasie, lub środowisko było inne niż to, na które zgodził się na początku, lub klient zmienił zdanie na temat (kilku) funkcji i musiałeś powtórzyć kilka rzeczy.

Nic z tego nie jest tak naprawdę winą dewelopera i może poważnie wpłynąć na termin realizacji projektu. Ale jeśli, chcąc zadowolić klienta, obiecałeś, że dostarczysz wszystko w określonym terminie i skończysz, z właściwych powodów, nie robiąc tego, jedno mogę zagwarantować, że klient będzie przynajmniej trochę , sfrustrowany. Jeśli jesteś freelancerem, musisz efektywnie zarządzać swoim czasem, jak wyjaśnia ten artykuł na blogu Toptal Engineering. Nie zapominaj, że zarządzanie relacjami z klientami to również twoja praca.

Więc wyświadcz sobie i osobie, która zależy od projektu, przysługę i przynajmniej daj im oszacowanie, ile czasu zajmie opracowanie wszystkiego, ale zawsze daj jasno do zrozumienia, że ​​to tylko szacunek, a nie termin.

Ponadto zdecydowanie sugeruję (zwłaszcza jeśli już podałeś oszacowanie), abyś zawsze mówił klientowi, gdy coś trwa dłużej niż oczekiwano, aby mógł ci pomóc!