Czasami inżynier wsparcia technicznego stoi przed trudnym wyborem: zastosować model dialogu „Jesteśmy za wysoką kulturą obsługi!” czy „Naciśnij przycisk — otrzymasz wynik”?
…Złamałem skrzydło z waty,
Położymy się w chmurach, jak w grobach.
My, poeci, rzadko jesteśmy świętymi,
My, poeci, często jesteśmy ślepymi.
(Oleg Ladyżenko)
Praca w wsparciu technicznym to nie tylko zabawne anegdoty o samonadających się czasach i GPS-jednorożcach, a nawet nie tylko detektywistyczne zagadki w stylu Hercule'a Poirota.
Wsparcie techniczne to przede wszystkim komunikacja, a komunikacja oznacza ludzi, a wśród naszych klientów są bardzo różne osobowości:
- Niemiec, pracujący w kawiarni naprzeciw swojego biura w Berlinie, posiadający naprawdę nordycką wytrzymałość, idealny spokój, starannie dopasowaną sieć, rozległy park serwerów i kognitywne zdolności, aby to wszystko ustawić i utrzymać na A+. Prośby od niego zwykle wywołują taką samą reakcję, jak ostatni pierożek na talerzu w dużym towarzystwie i nieodpowiednio zgaszone światło.
- Brytyjczyk, który w ciągu ostatnich 5 lat zmienił dwie firmy, ale nie styl pracy z pomocą techniczną. Od jego przypadków albo uciekają jak od dżumy, albo biorą, przewidując całą „przyjemność” pracy z tą osobą, ponieważ może nagle przejąć kontrolę podczas sesji zdalnej (by sprawdzić swoją pocztę, czasem osobistą), naciskać na inżynierów i zarząd w najdrobniejszych sprawach, a w końcu, tak samo niespodziewanie, zamykać zgłoszenia z komentarzem „DUPLIKAT”.
- Indyjski klient z wielosylabowym i nie do wymówienia nazwiskiem, obalający wszystkie mity o indyjskim IT: uprzejmy, spokojny, kompetentny, czytający dokumentację, słuchający rad inżyniera i zawsze wszystko robiący sam, noszący wspaniałego turbanu (tak, znaleźliśmy go na Facebooku) i mający idealną angielską wymowę.
Tych „imiennych” klientów każdy inżynier może zapamiętać pięciu, nawet się zbytnio nie zastanawiając. Niektórymi przerażamy naszych nowicjuszy („jeżeli będziesz źle się zachowywał w labie – przyjdzie baba i!..”), z niektórymi się chwalimy („a ja już zamknąłem 5 przypadków z N.”). A najczęściej nawet pamiętamy i rozumiemy, że pozytywne i negatywne przykłady to tylko nasze postrzeganie, które wynika z komunikacji, naszej z klientami i klientów z nami.
A ta komunikacja bywa bardzo różna.
Pewnego razu pisaliśmy już o , a teraz chcę pokazać, jak to wygląda w praktyce.
Oto dobry przykład sprzed dwóch lat: reakcja klienta na „tradycyjne” kroki rozwiązywania problemów ze strony inżyniera i reakcja inżyniera na styl komunikacji klienta.
Przykład fragmentacji
Otóż, przypadek: bardzo doświadczony i technicznie biegły klient otwiera zgłoszenie do pomocy technicznej i zadaje konkretne pytanie, dostarczając wiele szczegółów, aby opisać sytuację.
Zająłem się tym śmiałym krokiem, przekształcając korespondencję w dialog, zachowując cechy stylistyczne.
Klient (K): — Dzień dobry, panie. Nazywam się Marco Santino, skorzystaliśmy z Państwa najlepszych praktyk i zainstalowaliśmy u siebie nową, zalecaną przez Was technologię, ale widzimy, że wydajność systemu staje się krytycznie niska z powodu wysokiej fragmentacji. Czy to normalne?
Inżynier (I): — Cześć, Marco! Mam na imię Ignat i pomogę Ci. Czy to zawsze się objawia? Próbowałeś defragmentacji?
(K): — Szanowny Ignacie! Tak, to objawia się zawsze. Próbowaliśmy defragmentacji, ale niestety zajmuje to zbyt dużo czasu przy pełnym bezruchu systemu, więc jest to niemożliwe.
(I): — Słuchaj, coś nie mogę znaleźć tych najlepszych praktyk. Gdzie je znalazłeś? Może jednak spróbujemy defragmentacji?
(K): — Szanowny Ignacie! Rozumiejąc, że nie traktujesz naszego problemu poważnie i z trudem powstrzymując się od bezpośredniej, a nie politycznie poprawnej odpowiedzi, postaramy się odpowiedzieć. Nie mamy twojego doświadczenia (w IT od 1960 roku), i jesteśmy bardzo wdzięczni za twoje wysiłki w naszej edukacji. Najlepsze praktyki przekazali nam Wasi menedżerowie produktów podczas kolacji w Barcelonie, a wysłałem Ci link do nich. Pytamy cię, Iwanie, bezpośrednio: czy ta sytuacja jest normalna? Jeśli nie chcesz rozmawiać z nami, proszę, znajdź kogoś, kto może nam pomóc.
(I): — Marco, coś nie mogłem znaleźć tych najlepszych praktyk. Potrzebuję logów, przekażę problem innemu inżynierowi. Powiem ci to: jeśli widzisz fragmentację i nie defragmentujesz — to głupota i niewłaściwe postępowanie. A w ogóle, jak udało ci się pomylić szlachetne imię „Ignat” i nazwać mnie Iwanem?
(K): — Dość! Ignat, nie jesteś mi ani bratem, ani powinowatym, więc proszę, zwracaj się do mnie panie Santino! Jeśli nie możesz znaleźć dokumentu i nie radzisz sobie z tak prostym zadaniem, to albo odejdź z firmy, albo zapytaj jego autora, który przekazał nam ten dokument! Jeśli chodzi o logi, nie możemy ich przekazać bez specjalnego uzgodnienia, ponieważ pracujemy z tajnymi dokumentami. Twoje oburzenie z powodu mojego błędu pokazuje twoją ignorancję i brak wychowania. Bardzo mi ciebie żal. I na koniec: jeśli mówimy, że 'próbowaliśmy defragmentować’ i to ‘jest niemożliwe’, to znaczy, że próbowaliśmy i to jest niemożliwe. Ignat, proszę, przestań bredzić i zajmij się swoją pracą — albo daj nam odpowiedź, albo znajdź kogoś, kto ją nam da!
Po tym zgłoszenie zostało przekazane na wyższy poziom, gdzie po prostu umarło – klient nie dostarczył logów, pełne testy nic nie dały i problemu po prostu nie udało się potwierdzić.
Pytanie: co inżynier mógłby zrobić, aby uniknąć zaognienia sytuacji i eskalacji konfliktu?
(Spróbuj odpowiedzieć na to pytanie samemu, zanim będziesz czytać dalej).
Liryczne techniczne odwrócenie
Dla miłośników rozwiązywania zagadek i odpowiedzi na pytanie „kto jest mordercą?”: 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 CPU i RAM aż do dziesięciu razy, i nie tylko u klientów Veeam – cierpieć mogli wszyscy użytkownicy ReFS.
Microsoft potrzebował ponad roku przy wsparciu wielu dostawców, aby w końcu naprawić ten błąd (w czym widzimy również swoją zasługę – wiele kopii złamano o wsparcie tego giganta na wszystkich poziomach).
Ja, odpowiadając na pytanie 'co można było zrobić?', chcę zadać inne, odwieczne pytanie: 'A kto jest winny?'
Z zawodowej solidarności bardzo chcę powiedzieć: 'Wina leży po stronie klienta', — i zacząć bronić inżyniera. Jako kierownik, który stale ocenia pracę swoich inżynierów, widzę błędy, które Ignat popełnił. Kto zatem ma rację?
Rozbieramy wszystko krok po kroku
Ten przypadek jest bardzo trudny, pytań jest więcej niż odpowiedzi.
Formalnie Ignat wszystko robił dobrze:
- przestrzegał jednej z podstawowych wartości Veeam: Conversacja z serca;
- zwracał się do klienta po imieniu;
- wyjaśniał sytuację, zanim zaproponował rozwiązanie.
Czy mógł uniknąć takiego zaostrzenia emocji?
Mógł: zauważyć, jak pan Santino się komunikuje (tylko na „Pan” i po nazwisku), zrezygnować z „podstawowych pytań”, pokazać swój interes w problemie i obiecać wyjaśnić, czy takie zachowanie jest normalne.
Minimalne kroki, bez części technicznej – i one już pomogłyby „ugasić” sytuację. Ale nawet jeśli to zostało pominięte – po prostu „nie działać” też by trochę pomogło.
Brzmi oczywiście: nie brać literówki do siebie, nie obrażać się na zgryźliwego klienta (nawet jeśli wszystko wskazuje na jego wysokie mniemanie o sobie), nie wciągać rozmowy w sferę osobistą, nie ulegać prowokacjom… Oto ile jest tych „nie”, wszystkie ważne i wszystkie dotyczące komunikacji.
A co z klientem? Listy napisane „wysokim stylem”, ciągłe odniesienia do swoich znajomości na samym szczycie, zakamuflowane obelgi i uraza z powodu rzekomego braku szacunku? Tak, możemy to przeczytać w ten sposób. A z drugiej strony – czy pan Santino naprawdę jest niewłaściwy w swoim gniewie?
A jednak, co można byłoby zrobić z obu stron? Widzę to tak:
Ze strony inżyniera:
- ocenić stopień formalizmu klienta;
- mniej podążać za „podstawową izolacją”;
- (teraz będzie subiektywnie) uważniej czytać listy;
- odpowiedzieć na pytania, a nie unikać ich;
- i w końcu, nie ulegać prowokacjom i nie przechodzić na osobiste ataki.
Klientowi natomiast:
- wyraźnie określić pytanie w pierwszym liście, nie ukrywając go w technicznych szczegółach (z dialogu to nie wynika bezpośrednio, ale uwierzcie mi, szczegółowość była zdumiewająca);
- nieco bardziej tolerancyjnie podchodzić do pytań – nie wszyscy myślą w ten sam sposób i czasem trzeba pytać o wiele, aby zrozumieć istotę problemu;
- może powstrzymać chęć pokazania swojej ważności i znajomości „na najwyższym poziomie”;
- i, jak w przypadku Ignata – unikać przechodzenia na osobiste ataki.
Powtórzę – to tylko moja wizja, moja ocena, która w żaden sposób nie jest rekomendacją ani przewodnikiem „jak żyć i pracować”. To jeden z wariantów spojrzenia na sytuację i będę wdzięczny, jeśli zaproponujecie swoje.
Nie bronię inżyniera – sam jest sobie złośliwym Pinokiem. Nie obwiniam klienta – ma prawo komunikować się według własnego uznania, nawet jeśli ta komunikacja skrywa się w wyrafinowanej koronkowej formie niemalże subtelnego obrażenia (dobry obraz współczesnego idalga, który nie trudni się najmem czy wojną, lecz IT – cóż…)
„Znalazła kosa na kamień” – tak mogę podsumować tę korespondencję, a nawet wyrazić się innymi słowami, w prawdę których szczerze wierzę: „w każdym konflikcie zazwyczaj winni są obaj”.
Można to powiedzieć słowami naszego trenera biznesowego: „udana komunikacja jest zakłócana przez przeszłe doświadczenia, nawyki komunikacyjne i różne obrazy świata”. Można przypomnieć złotą zasadę moralności: „traktuj innych tak, jak chcesz, aby oni traktowali Ciebie”.
A można po prostu powiedzieć: w każdym komunikacie zawsze uczestniczą dwie strony, a po drugiej stronie słuchawki lub monitora znajduje się żywy człowiek, który również odczuwa strach, radość, smutek lub coś innego. Tak, uważa się, że emocje i biznes są niezgodne, ale jak możemy uciec od emocji? One były, są i będą, a nawet jeśli my – dział wsparcia technicznego – rozwiązujemy konkretne zadania, nasza główna praca definiowana jest przez drugie słowo: „wsparcie”.
Wsparcie – to jest o ludziach.
***
Pamiętacie, że już dwa razy napisałem, że winni są obaj? Tak więc, w rzeczywistości w tej sytuacji winni są wszyscy troje. Dlaczego? Po prostu dlatego, że inżynier nie jest rzeczą samą w sobie, ale częścią wsparcia technicznego, a to nasza praca i nasza odpowiedzialność – nauczyć pracownika przechodzić przez podobne sytuacje. Staramy się uczyć na własnych błędach – i pomagać naszym pracownikom ich unikać.
Czy zawsze da się uniknąć takich sytuacji? Nie zawsze. Jakkolwiek dobrym inżynierem byłby hipotetyczny Ignat, „po drugiej stronie” może być osoba, która zrobi wszystko, aby zaognić sytuację.
Ale piękno pracy w wsparciu technicznym Veeam, jedna z wartości, z których jesteśmy dumni – to praca zespołowa. Bardzo ważne jest, aby pamiętać: „Nie jesteś sam” – i robimy wszystko, aby tak było.
Czy można nauczyć się żyć i pracować w takich sytuacjach? Można.
Umiemy, kochamy, praktykujemy – dlatego stworzyliśmy nasze wewnętrzne szkolenia i wciąż je doskonalimy. Przez dwa i pół roku, które minęły od opisanej sytuacji, poważnie pracowaliśmy nad naszym programem szkoleniowym – teraz aktywnie korzystamy z przypadków, modelujemy sytuacje, gromadzimy i ciągle wracamy do naszych błędów, analizując niuanse komunikacji.
Wierzymy, że nasi ludzie teraz wychodzą „w pole” znacznie lepiej przygotowani do wszelkich sytuacji, a jeśli pojawi się coś, na co nie są gotowi – jesteśmy blisko i gotowi pomóc, a później uzupełnić nasze kursy nowymi przykładami.
I to się opłaca. Oto przykład opinii jednego z naszych klientów na temat naszej pracy:
„Pracujemy w branży IT od ponad 20 lat i wszyscy zgadzamy się, że żaden dostawca nie oferuje takiego poziomu wsparcia technicznego, jak Veeam. Rozmowa z pracownikami technicznymi Veeam to przyjemność, ponieważ są kompetentni i szybko rozwiązują problemy. Wsparcie nigdy nie powinno być niedoceniane. To miara zaangażowania i sukcesu firmy. Veeam to numer 1 w zakresie wsparcia.”
„Pracujemy w IT od ponad 20 lat i twierdzimy, że żaden inny dostawca nie oferuje takiego poziomu wsparcia technicznego, jak Veeam. Bardzo miło pracować z inżynierami Veeam, ponieważ znają się na rzeczy i potrafią szybko rozwiązywać problemy. Wsparcie techniczne nigdy nie powinno być niedoceniane. To wskaźnik odpowiedzialności i sukcesu firmy. Veeam ma najlepsze wsparcie.”
***
Każda komunikacja to pole do eksperymentów, błędów, czy tego chcemy, czy nie. Moim zdaniem popełnianie błędów jest normalne, więcej, zachęcam do tego: popełniajcie błędy! Chodzi nie o to, czy się potknęliście, ale o to, czy nauczyliście się stawiać krok pewnie.
Czasami trudno jest złapać się na tym i pamiętać wszystkie instrukcje i przepisy, którymi hojnie dzielą się „guru” komunikacji z klientami czy doświadczeni koledzy. O wiele łatwiej czasami przypomnieć sobie: „rozmawiam z człowiekiem.”
***
Nie roszczę sobie prawa do najwyższej wiedzy czy szczególnego standardu jakości w komunikacji z klientami. Wystarczyłoby na pełnoprawny podręcznik lista tylko moich błędów.
Cel, który sobie postawiłem: pokazać, jak może wyglądać wsparcie techniczne i rozpocząć dyskusję, co może być uznawane za akceptowalne w takich przypadkach, a co nie.
Co myślicie?
Źródło: habr.com
