Czasami inżynier wsparcia technicznego staje przed trudnym wyborem: zastosować model dialogu „Jesteśmy za wysoką kulturą obsługi!”. lub „Naciśnij przycisk, a otrzymasz wynik”?
...Po złamaniu skrzydła z waty,
Połóżmy się w chmurach, jak w kryptach.
My, poeci, rzadko jesteśmy święci,
My, poeci, często jesteśmy ślepi.
(Oleg Ladyżeński)
Praca w dziale pomocy technicznej to nie tylko zabawne historie o samoskaczącym czasie i jednorożcach GPS, ale nie tylko zagadki detektywistyczne w stylu Herkulesa Poirota.
Wsparcie techniczne to przede wszystkim komunikacja, a środki komunikacji to ludzie, a wśród naszych klientów są bardzo różne charaktery:
- Niemiec, który pracuje w kawiarni naprzeciwko swojego biura w Berlinie, charakteryzuje się prawdziwie nordycką samokontrolą, idealnym spokojem, starannie skalibrowaną siecią, rozbudowaną flotą serwerów oraz kognitywną zdolnością do skonfigurowania i utrzymania tego wszystkiego na poziomie A+. Prośby z jego strony zwykle wywołują taką samą reakcję, jak ostatni kluski na talerzu w dużym towarzystwie i wyłączenie światła w nieodpowiednim momencie.
- Brytyjczyk, który przez ostatnie 5 lat zmienił dwie firmy, ale nie swój styl pracy ze wsparciem. Albo uciekają od jego spraw jak dżuma, albo je zabierają, uprzedzając z góry cały „czar” pracy z tą osobą, ponieważ może ona bez ostrzeżenia przejąć kontrolę nad sesją zdalną (aby sprawdzić pocztę, czasem osobiste), wywierać presję na inżynierach i kierownictwie w najmniejszych szczegółach, a na koniec równie nagle zamykać aplikacje z komentarzem „DUPLIKACJA”.
- Hindus o wielozgłoskowym i niemożliwym do wymówienia nazwisku, który obala wszystkie mity na temat indyjskiego IT: uprzejmy, spokojny, kompetentny, czyta dokumentację, słucha rad inżyniera i zawsze wszystko robi sam, właściciel szykownego turbanu (tak, znaleźliśmy go na Facebooku) i doskonałą wymowę oksfordzkią.
Każdy inżynier może pomyśleć o pięciu takich „imiennych” klientach, nawet się nad tym nie zastanawiając. Niektórymi straszymy naszych przybyszów („jak się źle zachowasz w laboratorium, przyjdzie kobieta i!…”), innymi przechwalamy się („a ja już mam 5 aplikacji u N. zamknięte!”). A najczęściej nawet pamiętamy i rozumiemy, że pozytywne i negatywne przykłady to tylko nasza percepcja i wynika ona z komunikacji, naszej z klientami i klientów z nami.
A ta komunikacja może być bardzo różna.
Kiedyś o tym pisaliśmy , a teraz chcę pokazać, jak to się dzieje na żywym przykładzie.
Oto dobry przykład sprzed dwóch lat: reakcja klienta na „tradycyjne” etapy rozwiązywania problemów przez inżyniera i inżyniera na styl komunikacji klienta.
Sprawa fragmentacji
A więc tak jest: bardzo doświadczony i znający się na technologii klient otwiera zgłoszenie do pomocy technicznej i zadaje bezpośrednie pytanie, podając wiele szczegółów opisujących sytuację.
Pozwoliłem sobie przekształcić korespondencję w dialog, zachowując cechy stylistyczne.
Klient (K): - Dzień dobry, proszę pana. Nazywam się Marco Santino, skorzystaliśmy z Twoich najlepszych praktyk i zainstalowaliśmy najnowszą technologię zalecaną przez Ciebie, ale widzimy, że wydajność systemu staje się krytycznie niska z powodu dużej fragmentacji. Proszę mi powiedzieć, czy to normalne?
Inżynier (I): - Witaj, Marco! Mam na imię Ignat i pomogę. Czy to się zawsze zdarza? Próbowałeś defragmentacji?
(K): - Drogi Ignacie! Tak, to zawsze się pojawia. Próbowaliśmy przeprowadzić defragmentację, ale niestety zajmuje to zbyt dużo czasu, gdy system jest całkowicie bezczynny i dlatego nie jest możliwe.
(I): - Słuchaj, z jakiegoś powodu nie mogę znaleźć tych najlepszych praktyk. Gdzie go znalazłeś? A może jednak powinniśmy zrobić defragmentację, co?
(K): - Drogi Ignacie! Rozumiejąc, że nie traktujesz naszego problemu poważnie i mając trudności z powstrzymaniem się od bezpośredniej, a nie politycznie poprawnej odpowiedzi, nadal będziemy próbować Ci odpowiedzieć. Nie mamy Twojego doświadczenia (w IT jesteśmy dopiero od 1960 roku), dlatego jesteśmy Ci bardzo wdzięczni za Twoją pracę i trud włożony w naszą edukację. Najlepszymi Praktykami przekazali nam Twoi Menedżerowie Produktu podczas kolacji w Barcelonie, a ja wysłałem Ci do nich link. Pytamy Cię bezpośrednio, Iwanie: czy ta sytuacja jest normalna? Jeśli nie jesteś zainteresowany rozmową z nami, znajdź kogoś, kto może nam pomóc.
(I): — Marco, z jakiegoś powodu nie znalazłem tych najlepszych praktyk. Potrzebuję dzienników i przekażę problem innemu inżynierowi. Powiem ci coś: jeśli widzisz fragmentację i nie defragmentujesz, jest to głupie i nieodpowiedzialne. A tak w ogóle, jak udało Ci się pomylić szlacheckie imię „Ignat” i nazwać mnie Iwanem?
(K): - No to wystarczy! Nie jestem twoim bratem Ignat, ani twoją swatką, żebyś zwracał się do mnie po imieniu, więc proszę, zwracaj się do mnie Gn. Santino! Jeśli nie możesz znaleźć dokumentu lub nie możesz sobie poradzić z tak prostym zadaniem, to albo odejdź z firmy, albo zapytaj autora, który dał nam ten dokument! Jeśli chodzi o logi, nie możemy ich Ci przekazać bez specjalnej zgody, ponieważ pracujemy z tajnymi dokumentami. Twoje oburzenie moim błędem pokazuje twoją ignorancję i złe maniery. Bardzo mi cię przykro. I na koniec: jeśli powiemy, że „próbowaliśmy defragmentacji” i jest to „niemożliwe”, to znaczy, że próbowaliśmy i jest to niemożliwe. Ignat, proszę Cię, przestań męczyć się z bzdurami i zabierz się do swojej pracy – albo daj nam odpowiedź, albo znajdź kogoś, kto nam ją da!
Po tym aplikacja została przeniesiona na wyższy poziom, gdzie umarła - klient nie dostarczył logów, pełne testy nic nie dały, a problemu po prostu nie udało się potwierdzić.
Pytanie: co inżynier mógłby zrobić, aby uniknąć żaru namiętności i eskalacji konfliktu?
(Spróbuj sam odpowiedzieć na to pytanie, zanim zaczniesz czytać dalej).
Liryczna dygresja techniczna
Dla tych, którzy lubią rozwiązywać zagadki i odpowiadać na pytanie „kto jest zabójcą?”: problem okazał się znacznie poważniejszy: fragmentacja ReFS nie tylko wpływała na operacje dyskowe, ale w niektórych przypadkach zwiększała zużycie procesora i pamięci RAM nawet o dziesięć razy, i to nie tylko dla klientów Veeam – mogą ucierpieć wszyscy użytkownicy ReFS.
Minęło ponad rok, przy wsparciu wielu dostawców, od Microsoftu, aby ostatecznie naprawić ten błąd (co jest naszą zasługą – wiele kopii zostało uszkodzonych ze względu na wsparcie tego giganta na wszystkich poziomach).
Ja odpowiadając na pytanie „co można było zrobić?”, chcę zadać kolejne, odwieczne pytanie: „Kto jest winien?”
W ramach solidarności zawodowej naprawdę chcę powiedzieć: „wina jest klient” i zacząć chronić inżyniera. Jako menedżer, który stale ocenia pracę swoich inżynierów, widzę błędy, jakie popełnił Ignat. Kto ma rację?
Uporządkujmy wszystko po kolei
Sprawa jest bardzo trudna, jest więcej pytań niż odpowiedzi.
Formalnie Ignat zrobił wszystko dobrze:
- kierował się jedną z podstawowych wartości firmy Veeam: rozmową płynącą z serca;
- zwrócił się do klienta po imieniu;
- wyjaśnił sytuację przed zaproponowaniem rozwiązania.
Czy mógł uniknąć tak intensywnych namiętności?
Mógłby: zauważyć, jak Mr. Santino komunikuje się (tylko za pośrednictwem Ciebie i po nazwisku), odmawia „podstawowych pytań”, okazuje zainteresowanie problemem i obiecuje sprawdzić, czy takie zachowanie jest normalne.
Minimalne kroki, bez części technicznej, a już pomogłyby „ugasić” sytuację. Ale nawet jeśli to pominiemy, samo „nierobienie tego” również trochę pomoże.
Brzmi oczywisto: nie bierz literówki do siebie, nie obrażaj się na sarkastycznego klienta (nawet jeśli wszystko mówi o zawyżonym FER), nie nadawaj rozmowie osobistego charakteru, nie poddawaj się prowokacjom... Jest ich tak wiele, tych „nie” i wszystkie są ważne, a wszystkie dotyczą komunikacji.
A co z klientem? Czy listy pisane w „wysokim stylu”, ciągłe odniesienia do znajomych na samej górze, zawoalowane obelgi i urazy z powodu pozornego braku szacunku? Tak, możemy to tak odczytać. Z drugiej strony, czy tak jest p. Czy Santino rzeczywiście myli się ze względu na swój gniew?
A jednak, co można zrobić po obu stronach? Widzę to tak:
Od strony inżyniera:
- ocenić stopień formalizmu klienta;
- stosuj mniej „podstawowej izolacji”;
- (teraz będzie to subiektywne) czytaj uważniej listy;
- odpowiadaj na pytania, zamiast ich unikać;
- i wreszcie nie ulegajcie prowokacjom i nie wdawajcie się w personalizm.
Do klienta:
- jasno określ problem w pierwszym liście, nie ukrywając go w szczegółach technicznych (nie wynika to bezpośrednio z dialogu, ale wierz mi, szczegóły były niesamowite);
- bądź trochę bardziej tolerancyjny w stosunku do pytań – nie wszyscy myślą tak samo, a czasami trzeba zadać dużo, aby zrozumieć samą istotę problemu;
- być może powstrzymaj chęć pokazania swojego znaczenia i znajomości „na najwyższym poziomie”;
- a jeśli chodzi o Ignata, unikaj zbytniego osobistego podejścia.
Powtarzam – to tylko moja wizja, moja ocena, która w żadnym wypadku nie stanowi rekomendacji ani wskazówki, „jak żyć i pracować”. To jeden ze sposobów spojrzenia na sytuację i będę zadowolony, jeśli zaproponujesz swój.
Nie bronię inżyniera – to jego własny, zły Pinokio. Nie winię klienta – ma on prawo komunikować się tak, jak uważa za stosowne, nawet jeśli ta komunikacja jest bardziej ukryta pod elegancką koronką niemal wyrafinowanej grzecznej zniewagi (dobry wizerunek współczesnego hidalgo, który nie handluje najemnikami i wojna, ale w IT - chociaż...).
„Znalazłem kosę na kamieniu” – tak mogę podsumować tę korespondencję, a nawet ująć to innymi słowami, w prawdziwość których szczerze wierzę: „w każdym konflikcie winnych jest zwykle dwóch”.
Możemy powiedzieć słowami naszego trenera biznesu: „na skuteczną komunikację utrudniają przeszłe doświadczenia, nawyki komunikacyjne i odmienne obrazy świata”. Pamiętasz złotą zasadę moralności: „Czyń innym tak, jak chciałbyś, żeby oni tobie czynili”.
Możesz też po prostu powiedzieć: w każdą komunikację zaangażowane są zawsze dwie osoby, a po drugiej stronie słuchawki lub monitora znajduje się żywa osoba, która również jest przestraszona, szczęśliwa, smutna lub coś innego. Tak, uważa się, że emocje i Biznes są nie do pogodzenia, ale gdzie możemy uciec od emocji? Byli, są i będą i nawet jeśli zajmujemy się wsparciem technicznym i rozwiązujemy bardzo specyficzne problemy, to naszą główną pracę definiuje drugie słowo: „wsparcie”.
Wsparcie dotyczy ludzi.
***
Pamiętacie, pisałem już dwa razy, że winne są dwie? Tak naprawdę w tej konkretnej sytuacji winni są wszyscy trzej. Dlaczego? Po prostu dlatego, że inżynier nie jest rzeczą samą w sobie, ale częścią wsparcia technicznego, a naszym zadaniem i obowiązkiem jest nauczenie pracownika, jak przechodzić przez podobne sytuacje. Staramy się uczyć na własnych błędach i pomagać naszym pracownikom ich unikać.
Czy zawsze można uniknąć takich sytuacji? Nie zawsze. Niezależnie od tego, jak dobrym inżynierem jest hipotetyczny Ignat, „z drugiej strony” może pojawić się osoba, która zrobi wszystko, aby zaostrzyć sytuację.
Ale piękno pracy w dziale pomocy technicznej Veeam, jedną z wartości, z których jesteśmy dumni, jest praca zespołowa. Bardzo ważne jest, aby pamiętać: „Nie jesteś sam” i robimy wszystko, aby tak było.
Czy można uczyć, jak żyć i pracować w takich sytuacjach? Móc.
Wiemy jak, kochamy, ćwiczymy - dlatego zbudowaliśmy nasze wewnętrzne szkolenia i wciąż je debugujemy i udoskonalamy. W ciągu dwóch i pół roku, jakie minęły od opisanej sytuacji, poważnie pracowaliśmy nad naszym programem szkoleniowym - i teraz aktywnie wykorzystujemy przypadki, symulujemy sytuacje, oszczędzamy pieniądze i cały czas wracamy do naszych błędów i analizujemy zawiłości komunikacji .
Wierzymy, że nasi chłopcy wychodzą teraz w teren znacznie lepiej przygotowani na każdą sytuację, a jeśli okaże się, że nie są na to gotowi, jesteśmy w pobliżu i gotowi pomóc, a następnie uzupełnić nasze kursy o nowe przykłady.
I to się opłaca. Oto na przykład opinia jednego z naszych klientów na temat naszej pracy:
„Pracujemy w branży IT od ponad 20 lat i wszyscy zgodzimy się, że żaden dostawca nie oferuje takiego poziomu wsparcia technicznego, jaki oferuje Veeam. Rozmowa z personelem technicznym firmy Veeam to przyjemność, ponieważ mają oni wiedzę i szybko rozwiązują problemy. Wsparcie nigdy nie powinno być niedoceniane. Jest miarą zaangażowania i sukcesu firmy. Firma Veeam jest numerem 1 pod względem wsparcia”.
„Jesteśmy w branży IT od ponad 20 lat i twierdzimy, że żaden inny dostawca nie zapewnia takiego poziomu wsparcia technicznego jak Veeam. Współpraca z inżynierami firmy Veeam to przyjemność, ponieważ znają się na rzeczy i potrafią szybko rozwiązywać problemy. Nigdy nie należy lekceważyć wsparcia technicznego. Jest to miara odpowiedzialności i sukcesu firmy. Firma Veeam ma najlepsze wsparcie techniczne”.
***
Każda komunikacja jest polem eksperymentów i błędów, czy tego chcemy, czy nie. A ja jestem zdania, że popełnianie błędów jest w porządku; co więcej, moje wezwanie będzie brzmieć: popełniajcie błędy! Nie chodzi o to, czy się potknąłeś, ale czy wtedy nauczyłeś się mocno stawiać nogę.
Czasami trudno się złapać i zapamiętać wszystkie instrukcje i przepisy, którymi hojnie dzielą się „guru” komunikacji z klientami lub doświadczonymi kolegami. O wiele łatwiej jest czasem sobie przypomnieć: „Rozmawiam z Osobą”.
***
Nie udaję, że mam wyższą wiedzę lub szczególny standard jakości w komunikacji z klientami. Sama lista moich błędów wystarczyłaby na pełnoprawny podręcznik.
Cel jaki sobie postawiłem: pokazać jak może być w dziale wsparcia technicznego i rozpocząć dyskusję na temat tego co w takich przypadkach można uznać za akceptowalne, a co nie.
Co myślisz?
Źródło: www.habr.com