Часам перад інжынерам тэхнічнай падтрымкі стаіць нялёгкі выбар: прымяніць мадэль дыялогу "Мы - за высокую культуру абслугоўвання!" або "Націсні на кнопку - атрымаеш вынік"?
...Надламаўшы крыло з ваты,
Ляжам у аблокі, як у скляпы.
Мы, паэты, рэдка святыя,
Мы, паэты, часта сляпыя.
(Алег Ладыжэнскі)
Праца ў Тэхпадтрымцы – гэта не толькі смешныя байкі пра самаскача час і GPS-адзінарогаў, і нават не толькі дэтэктыўныя задачкі ў стылі Эркюля Пуаро.
Тэхнічная Падтрымка - гэта, у першую чаргу, зносіны, а зносіны мае на ўвазе людзей, і сярод нашых кліентаў ёсць вельмі розныя персанажы:
- Немец, які працуе з кафэ насупраць свайго офіса ў Берліне, уладальнік сапраўды нардычнай вытрымкі, ідэальнага спакою, старанна выверанай сеткі, шырокага парка сервераў і кагнітыўных здольнасцяў усё гэта наладзіць і падтрымліваць на А+. Заяўкі ад яго звычайна выклікаюць такую ж рэакцыю, як апошняя пельмешка на талерцы ў вялікай кампаніі і не своечасова пагашанае святло.
- Брытанец, за апошнія 5 гадоў які змяніў дзве кампаніі, але не стыль працы з сапартам. Ад яго кейсаў або бягуць, як ад бубоны чумы, або бяруць, загадзя прадчуваючы ўсю "хараство" працы з гэтым чалавекам, бо ён можа без папярэджання адабраць кіраванне на выдаленай сесіі (каб праверыць сваю пошту, часам асабістую), ціснуць на інжынераў і мэнэджмент па драбнюткіх дробязях і, нарэшце, гэтак жа раптам зачыняць заяўкі з каментаром «Дублікат».
- Індыец са шматскладовым і невымоўным прозвішчам, які абвяргае ўсе міфы аб індыйскім ІТ: ветлівы, спакойны, кампетэнтны, які чытае дакументацыю, які слухае парады інжынера і ўсё заўсёды што робіць сам, уладальнік шыкоўнага цюрбану (так, мы знайшлі яго на Фэйсбуку) і ідэальнага офор.
Такіх «імянных» кліентаў кожны інжынер можа ўзгадаць чалавек пяць, нават асоба не разважаючы. Некаторымі мы палохаем нашых пачаткоўцаў («будзеш дрэнна сябе паводзіць у лабе – прыйдзе бабайка і!..»), некаторымі выхваляемся («а ў мяне ўжо 5 заявак з N. зачынена!»). А часцей за ўсё мы нават памятаем і разумеем, што станоўчы і адмоўныя прыклады - усяго толькі наша ўспрыманне, а яно вынікае з зносін, нашага з кліентамі і кліентаў з намі.
І зносіны гэтыя бываюць вельмі рознымі.
Аднойчы мы ўжо пісалі аб , А зараз я хачу паказаць, як гэта бывае, на жывым прыкладзе.
Вось добры прыклад двухгадовай даўнасці: рэакцыя кліента на «традыцыйныя» крокі траблшутинга са боку інжынера і інжынера на стыль зносін кліента.
Кейс аб фрагментацыі
Такім чынам, кейс: вельмі дасведчаны і тэхнічна падкаваны кліент адчыняе заяўку з тэхпадтрымкай і задае прамое пытанне, падаючы мноства дэталяў, каб апісаць сітуацыю.
Я ўзяў на сябе смеласць перарабіць перапіску ў дыялог, захоўваючы стылістычныя асаблівасці.
Кліент (К): - Добры дзень, васпане. Мяне клічуць Марка Санціна, мы скарысталіся Вашымі best practices і ўсталявалі ў сябе найноўшую, рэкамендуемую Вамі тэхналогію, але бачым, што працаздольнасць сістэмы становіцца крытычна нізкай з-за высокай фрагментацыі. Скажыце, калі ласка, гэта нармальна?
Інжынер (І): - Прывітанне, Марка! Мяне клічуць Ігнат, і я дапамагу. А гэта заўсёды праяўляецца? Дэфрагментаваць спрабавалі?
(К): - Паважаны Ігнат! Так, гэта праяўляецца заўсёды. Дэфрагментаваць мы спрабавалі, але, нажаль, гэта займае занадта шмат часу пры поўным простае сістэмы, а таму не ўяўляецца магчымым.
(І): - Слухайце, а я нешта не магу знайсці гэты best practices. Вы яго дзе знайшлі? І, можа, усё ж зрабіць дэфрагментацыю, га?
(К): - Паважаны Ігнат! Разумеючы, што Вы не ўспрымаеце нашу праблему сур'ёзна і з цяжкасцю стрымліваючыся ад прамога, а не паліткарэктнага адказу, мы ўсё ж такі паспрабуем адказаць Вам. У нас няма Вашага досведу (мы ў ІТ усяго толькі з 1960 гады), і мы вельмі ўдзячныя Вам за Вашу працу і высілкі па нашай асвете. Best Practices нам перадалі Вашыя Product Managers за вячэрай у Барселоне, і я выслаў Вам спасылку на іх. Вас жа, Іван, мы пытаемся прама: гэтая сітуацыя нармальная? Калі Вам не цікава размаўляць з намі, калі ласка, знайдзіце таго, хто можа нам дапамагчы.
(І): - Марка, я вось нешта не знайшоў гэтых best practices. Мне патрэбны логі, і я перадам праблему іншаму інжынеру. Я вам вось што скажу: калі вы бачыце фрагментацыю і не дэфрагментуеце - гэта глупства і безадказна. І наогул, як вам удалося пераблытаць высакароднае імя "Ігнат" і назваць мяне Іванам?
(К): - Так, хопіць! Я Вам, Ігнат, не брат, не сват, каб Вы мяне па імені называлі, таму дазвольце звяртацца да мяне Гн. Санціна! Калі не можаце знайсці дакумент, не спраўляецеся з такой простай задачай, то або звальняйцеся з кампаніі, або спытаеце яго аўтара, які і перадаў нам гэты дакумент! Што тычыцца логаў, мы не можам Вам іх перадаць без асаблівага ўзгаднення, бо працуем з сакрэтнымі дакументамі. Ваша абурэнне наконт маёй памылкі паказвае ваша невуцтва і вашу нявыхаванасць. Мне вельмі шкада вас. І апошняе: калі мы кажам, што мы "спрабавалі дэфрагментаваць" і гэта "немагчыма", значыць, мы спрабавалі і гэта немагчыма. Ігнат, прашу Вас, перастаньце пакутаваць глупствам і займіцеся Вашай працай - альбо дайце нам адказ, альбо знайдзіце таго, хто яго нам дасць!
Пасля гэтага заяўка была перададзена на ўзровень вышэй, дзе так і памерла - логі кліент так і не падаў, поўнамаштабнае тэсціраванне нічога не дало і праблему проста не змаглі пацвердзіць.
Пытанне: што мог зрабіць інжынер, каб пазбегнуць напалу страсцей і эскалацыі канфлікту?
(Паспрабуйце адказаць на гэтае пытанне самі перад тым, як чытаць далей).
Лірыч тэхнічны адступ
Для аматараў рашэння загадак і адказаў на пытанне "хто ж забойца?": праблема апынулася куды як сур'ёзней: фрагментацыя ReFS не толькі ўплывала на дыскавыя аперацыі, але ў некаторых выпадках павялічвала спажыванне ЦПУ і АЗП аж да дзесяці разоў, і не толькі ў кліентаў Veeam - Пакутаваць маглі ўсе карыстачы ReFS.
Microsoft спатрэбілася больш за год пры падтрымцы шматлікіх вендараў каб, нарэшце, выправіць гэтую памылку (у чым мы бачым і сваю заслугу – нямала дзід было зламанае аб падтрымку гэтага гіганта на ўсіх узроўнях).
Я ж, адказваючы на пытанне "што можна было зрабіць?", хачу задаць іншае, адвечнае пытанне: "А хто вінаваты?"
З прафесійнай салідарнасці мне вельмі хочацца сказаць: «Вінаваты кліент», - і пачаць выгароджваць інжынера. Як кіраўнік, які пастаянна ацэньвае працу сваіх інжынераў, я бачу памылкі, якія Ігнат здзейсніў. Хто ж мае рацыю?
Разбіраны ўсё па парадку
Кейс гэты вельмі жорсткі, пытаньняў больш, чым адказаў.
Фармальна Ігнат усё рабіў нядрэнна:
- прытрымліваўся адной з базавых каштоўнасцяў Veeam: Conversation from the heart;
- звяртаўся да кліента па імені;
- удакладняў сітуацыю, перш чым прапаноўваць рашэнне.
Ці мог ён пазбегнуць такога напалу страсцей?
Мог: заўважыць, як гн. Санціна мае зносіны (толькі на Вы і па прозвішчы), адмовіцца ад «базавых пытанняў», паказаць сваю цікавасць да праблемы і паабяцаць высветліць, ці нармальныя гэтыя паводзіны.
Мінімальныя крокі, без тэхнічнай часткі - і яны ўжо б дапамаглі "патушыць" сітуацыю. Але нават калі гэта прапушчана - проста "не рабіць" таксама б крыху дапамагло.
Гучыць відавочна: не прымаць памылку друку на свой рахунак, не крыўдзіцца на з'едлівага кліента (нават калі ўсё кажа аб завышаным АУВ), не перакладаць гутарку на асобы, не паддавацца на правакацыі… Вось колькі іх, гэтых «не», і ўсё важныя, і усё пра зносіны.
А што ж кліент? Лісты напісаны «высокім штылем», сталыя дасылкі да сваіх знаёмстваў на самым версе, завуаляваныя абразы і крыўда ад уяўнай непавагі? Так, мы можам прачытаць гэта менавіта так. А з іншага боку - ці так гн. Санціна на самой справе не мае рацыю ў сваім гневе?
І ўсё ж, што ж можна было зрабіць абапал? Я бачу гэта так:
З боку інжынера:
- ацаніць ступень фармалізму кліента;
- менш прытрымлівацца "базавай ізаляцыі";
- (цяпер будзе суб'ектыўна) больш уважліва чытаць лісты;
- адказаць на пытанні, а не ўхіляцца ад іх;
- і, нарэшце, не паддавацца на правакацыі і не пераходзіць на асобы.
Кліенту ж:
- выразна пазначыць пытанне ў першым жа лісце, не хаваючы яго ў тэхнічных падрабязнасцях (з дыялогу гэта не вынікае наўпрост, але паверце мне, дэталізацыя была надзвычайнай);
- крыху больш памяркоўна ставіцца да пытанняў - не ўсе мысляць аднолькава, і часам даводзіцца пытацца вельмі шмат, каб зразумець саму сутнасць праблемы;
- магчыма, стрымаць жаданне паказаць сваю значнасць і знаёмствы "на самым высокім узроўні";
- і, як і для Ігната - пазбегнуць пераходу на асобы.
Паўтаруся - гэта ўсяго толькі маё бачанне, мая ацэнка, якая ніякім чынам не з'яўляецца рэкамендацыямі або кіраўніцтвам "як трэба жыць і працаваць". Гэта адзін з варыянтаў, як можна паглядзець на сітуацыю, і буду рады, калі вы прапануеце свае.
Я не абараняю інжынера - ён сам сабе злосны Бураціна. Я не абвінавачваю кліента - ён у сваім праве мець зносіны так, як лічыць гэта патрэбным, хай нават гэтыя зносіны больш схавана ў хупавым карунках амаль-вытанчана-ветлівай абразы (добрая выява сучаснай ідальга, які зарабляе не наймітнасцю і вайной, а ІТ - хоць…). .
«Знайшла каса на камень» - менавіта так я магу падсумаваць гэтую перапіску, ці нават выказацца іншымі словамі, у ісціну якіх я шчыра веру: «у любым канфлікце звычайна вінаватыя двое».
Можна сказаць словамі нашага бізнес-трэнера: "паспяховай камунікацыі перашкаджае мінулы вопыт, звычкі зносін і розныя карціны свету". Можна ўспомніць залатое правіла маральнасці: "Паступай у адносінах да іншых людзей так, як ты хочаш, каб яны паступалі ў адносінах да цябе".
А можна проста сказаць: у любых зносінах заўсёды ўдзельнічаюць двое, і з іншага боку тэлефоннай трубкі або манітора ад цябе - жывы чалавек, якому таксама страшна, радасна, сумна ці нешта яшчэ. Так, лічыцца, што эмоцыі і бізнэс несумяшчальныя, але куды нам падзецца ад эмоцый? Яны былі, ёсць, і будуць, і нават калі мы - Тэхнічная Падтрымка і вырашаем суцэль вызначаныя задачы, наша асноўная праца вызначаецца менавіта другім словам: "падтрымка".
Падтрымка - гэта пра людзей.
***
Памятайце, я ўжо двойчы пісаў, што вінаватыя двое? Дык вось, на справе больш за тое - менавіта ў гэтай сітуацыі вінаватыя ўсе трое. Чаму? Проста таму, што інжынер не рэч у сабе, а частка тэхпадтрымкі, і гэта наша праца і наша адказнасць - навучыць супрацоўніка праходзіць праз падобныя сітуацыі. На сваіх памылках мы імкнемся вучыцца - і дапамагаць нашым супрацоўнікам іх пазбягаць.
Ці заўсёды можна такіх сітуацый пазбегнуць? Не заўсёды. Якім бы добрым інжынерам не быў гіпатэтычны Ігнат, "з іншага боку" можа быць чалавек, які зробіць усё, каб напаліць абстаноўку.
Але хараство працы ў Тэхпадтрымцы Veeam, адна з каштоўнасцяў, якімі мы ганарымся праца ў камандзе. Вельмі важна памятаць: "Ты не адзін", - і мы робім усё, каб так яно і было.
Ці можна навучыць жыць і працаваць у такіх сітуацыях? Можна.
Умеем, кахаем, практыкуем - для гэтага мы і выбудоўвалі сваё ўнутранае навучанне і працягваем яго адладжваць і паліраваць. За два з паловай гады, якія прайшлі з апісанай сітуацыі мы сур'ёзна папрацавалі над нашай праграмай навучання — і зараз актыўна выкарыстоўваем кейсы, мадэлюем сітуацыі, збіраем і ўвесь час вяртаемся да нашых памылак і разбіраем тонкасці зносін.
Мы верым, што нашы хлопцы цяпер выходзяць "у палі" значна больш падрыхтаванымі да любых сітуацый, а калі з'явіцца нешта, да чаго яны не гатовы — мы побач і гатовы дапамагчы, а пасля дапоўніць нашы курсы новымі прыкладамі.
І гэта акупляецца. Вось, напрыклад, водгук аднаго з нашых кліентаў аб нашай працы:
“Вы працавалі ў ІТ-індустрыі для больш за 20 гадоў, і мы ўсе акрэслілі не vendor offers узровень technical support that Veeam offers. Гэта добра, каб выказаць здароўе тэхнічнае стаўленне, таму што яны з'яўляюцца здольнымі і рэагуюць на fast. Support павінен не быць underrated. Гэта мера гаспадара Commitment and success. Veeam is #1 for support.”
“Мы працуем у ІТ-індустрыі больш за 20 гадоў, і мы сцвярджаем, што ні адзін іншы вендар не дае такі ўзровень тэхнічнай падтрымкі, як Veeam. Вельмі прыемна працаваць з інжынерамі Veeam, бо яны ведаюць сваю справу і могуць вырашаць праблемы хутка. Тэхнічная падтрымка ніколі не павінна быць недаацэнены. Гэта мерка таго, наколькі кампанія адказная і паспяховая. У Veeam — найлепшая тэхпадтрымка.”
***
Любая камунікацыя - гэта поле для досведаў, памылак, хочам мы гэтага ці не. І маё меркаванне памыляцца - гэта нармальна, больш за тое, мой заклік будзе: памыляйцеся! Справа не ў тым, ці спатыкнуліся вы, а ў тым, ці навучыліся вы потым ставіць нагу цвёрда.
Часам цяжка злавіць сябе і памятаць усе інструкцыі і рэцэпты, якімі шчодра дзеляцца "гуру" зносін з кліентамі ці дасведчаныя калегі. Значна прасцей часам нагадваць сабе: "я размаўляю з Чалавекам".
***
Я не прэтэндую на вышэйшую веданне ці асаблівы стандарт якасці ў зносінах з кліентам. Пераліку толькі маіх памылак хапіла б на паўнавартасны падручнік.
Мэта, якую я ставіў перад сабой: паказаць, як можа быць у Тэхпадтрымцы і запусціць дыскусію, што можа лічыцца прымальным у падобных выпадках, а што не.
Што думаеце?
Крыніца: habr.com