Іноді перед інженером технічної підтримки стоїть нелегкий вибір: застосувати модель діалогу "Ми - за високу культуру обслуговування!" або "Натисні на кнопку - отримаєш результат"?
…Надломивши крило з вати,
Ляжемо у хмари, як у склепи.
Ми, поети, рідко святі,
Ми, поети, часто сліпі.
(Олег Ладиженський)
Робота в Техпідтримці - це не тільки кумедні байки про самострибаючий час і 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 років, і ми всі впевнені, що не працювали на рівні технічної підтримки, що Veeam offers. Це здавалося б, щоб сказати, що старий технічний розмір тому, що вони розуміються і відповідають fast. Support should never be underrated. Це є функцією компанією з комісії і успіху. Veeam is #1 for support.”
“Ми працюємо в ІТ-індустрії понад 20 років, і ми стверджуємо, що жоден інший вендор не надає такого рівня технічної підтримки, як Veeam. Дуже приємно працювати з інженерами Veeam, тому що вони знають свою справу та можуть вирішувати проблеми швидко. Технічна підтримка ніколи не повинна бути недооцінена. Це мірило того, наскільки компанія є відповідальною та успішною. У Veeam – найкраща техпідтримка.”
***
Будь-яка комунікація — це поле дослідів, помилок, хочемо ми цього чи ні. І моя думка помилятися – це нормально, більше того, мій заклик буде: помиляйтесь! Справа не в тому, чи оступилися ви, а в тому, чи навчилися потім ставити ногу твердо.
Іноді важко зловити себе та пам'ятати всі інструкції та рецепти, якими щедро діляться “гуру” спілкування з клієнтами чи досвідчені колеги. Набагато простіше іноді нагадувати собі: "я розмовляю з Людиною".
***
Я не претендую на вищі знання чи особливий стандарт якості у спілкуванні з клієнтами. Переліку лише моїх помилок вистачило б на повноцінний підручник.
Мета, яку я ставив перед собою: показати, як може бути в техпідтримці і запустити дискусію, що може вважатися прийнятним у подібних випадках, а що ні.
Що думаєте?
Джерело: habr.com