Техподдержка по Достоевскому: «Тварь ли я дрожащая или право имею?»

Честно признаюсь, я давно держал в голове эту мысль и понимал, что рано или поздно она все-таки прорвется наружу. При этом я прекрасно понимаю суть «боли техподдержки», поскольку проработал там 3 года на заре своей ИТ-шной карьеры. Потом начал развиваться дальше и взглянул на техподдержку со стороны менеджера проектов, руководителя разработки и заместителя ИТ-директора. И вот, спустя 20 лет, понимая, что мой взгляд стал беспристрастным, эта мысль все-таки прорвалась наружу в виде желания написать статью.

Но давайте сначала отвлечемся и попробуем взглянуть на ИТ в целом «глазами Пользователя». Итак, что представляет себе Пользователь бизнесовой направленности, когда слышит или произносит слово «АйТи-шник»?

Некоторые, услышав это слово, до сих пор представляют себе парня в свитере, или в очках с лохматой головой и «немного того», разговаривающего на непонятном для нормальных людей языке и т.д. Другие, напротив, представляют парня в рубашке с галстуком или костюме. И на самом деле под словом «АйТи-шник» сейчас кроется целая куча узконаправленных специальностей:

• менеджеры продуктов,

• менеджеры проектов,

• менеджеры по инфраструктуре,

• ИТ-архитекторы,

• тим-лиды,

• системные инженеры,

• сетевые инженеры,

• бизнес-аналитики,

• дизайнеры интерфейсов,

• менеджеры релизов,

• инженеры по средам и сервисам,

• тестировщики (тут целая градация: альфа, бета, нагрузочное, интеграционное, регрессионное),

• разработчики (и они тоже делятся на направления: фронт-енда, бэк-енда, интеграции и API, мобильных приложений, WEB-сервисов и т.д. и т.п.).

И это я еще пока не дошел до узконаправленных специальностей типа Bid Data, AI, SaaS, где есть Data-scientists, AI-инженеры и т.д. и т.п.

В общем набор ИТ-специальностей — это прямо как титры в конце фильма, где мы видим, что оказывается за 2 главными героями этого блокбастера (главный разработчик и менеджер проекта) стоит несколько сотен людей, благодаря которым этот фильм (ИТ-продукт) был создан и вышел в свет — почувствовали аналогию?

Так вот, представив себе всю эту кучу благородных людей, участвовавших в создании и запуске программного продукта (весь быстро-пробегающий перед глазами список в титрах после фильма) мы подходит к вопросу технической поддержки запущенного ИТ-продукта и задаемся вопросом:

«А если в продукте вдруг возникнет ошибка или он начнет глючить?»

И тут мы вспоминаем о техподдержке. И надо прямо сказать, что у некоторых пользователей есть устоявшееся отношение к техподдержке как к какому-то низшему сервисному звену. Вроде дворника, или того парня, который ездит на мусорной машине и подкатывает мусорные баки к ней. И если вдруг из этих баков что-то упадет, то он должен проявить «мгновенную реакцию», подобрать и максимально быстро «аннигилировать этот баг», не нарушая «утонченное восприятие мира» у Пользователя.

Ну так ведь, правда?

Наверняка Вы сталкивались с такими людьми. Пусть их мало, но они есть, и они иногда даже сами не понимают как их отношение к техподдержке выглядит со стороны. Часто такие люди руководствуются позицией: «Вы обязаны мне предоставить качественный сервис поддержки». Формально они конечно правы. И именно этот формальный подход и порождает отношение к техподдержке как к сервисной функции, которая обязана быстро решить проблему (и никаких НО).

И со мной сейчас не согласятся только те из вас, кто понимает важность и сложность работы самой техподдержки:

1. соблюдение SLA (service level agreement), который регламентирует сроки «мгновенной реакции», а также сроки исправления ошибок «для анигилирования бага»;

2. обеспечение позитивного восприятия пользователем продукта и команды в целом, т.е. ни в коем случае ни при каких условиях не нарушать «утонченное восприятие мира у пользователя» и быть почти психологом, не позволяя «праведному гневу Пользователя» разжечь третью мировую войну;

3. правильно организовать исправление найденных багов, т.е. разобраться в их причинах, пробежаться по FAQ, проверить версию возможной ошибки со стороны пользователя, иногда даже разобраться в логах. Поставить задачи разработчикам, тестировщикам, релиз менеджерам и т.д. и потом неустанно контролировать сроки, чтобы исправления не ушли в «релиз следующего года»;

4. и самое главное — внутренняя мотивация и постоянное решение внутреннего конфликта «кто Я, и куда Я хочу развиваться?»

Другими словами, хороший специалист техподдержки почти всегда будет втайне завидовать и сравнивать себя с теми бравыми благородными ребятами из разработки\проектирования, которые создают и внедряют новые фичи и модули, в то время как ему приходится «разбирать грязное белье».

Тут конечно можно начать рассуждать о разделении техподдержки на 1-ю, 2-ю, 3-ю линии, каждая из которых закрывается специалистами разного уровня и позволяет «размазать зону ответственности», распределив ее по разным специалистам.

Но ответьте себе честно: неужели у Вас никогда не возникало раздражения, когда вы обращаетесь к одному специалисту для решения Вашей проблемы, а он переводит ее второму, а потом третьему? Как человек Вы все равно будете ждать конкретного ответственного — именно того, кто сейчас занимается Вашей проблемой. И «передача эстафетной палочки» на следующую линию поддержки как правило вызывает увеличение раздражения и негатива, который выливается на нового ответственного за решение Вашего бага.

Согласитесь, что в такой ситуации сотрудникам техподдержки приходится очень часто думать о самомотивации и находить внутри себя стержень, чтобы не сломаться (не бросить эту неблагодарную позицию и не уйти, например, в аналитики или разработчики). И продолжать работать «с огоньком», разбирать бесконечные баги и решать проблемы Пользователей, периодически сталкиваясь с их негативом.

Если в вашей команде есть классная команда поддержки, которая умеет общаться с Пользователями «как команда психологов» и очень хорошо разбирается в особенностях ИТ-продукта, вплоть до грамотного анализа деталей, логов и наполнения FAQ, то Вам повезло.

Ведь хороший специалист техподдержки может запросто стать тем спасителем вашего продукта (фильма). Тем, кто в сложный момент «возникновения непростительного бага» (который 100% был пропущен всеми этими бравыми ребятами из титров) предотвратит Мировую Войну с Пользователем просто потому, что это его призвание — быть «Бойцом невидимого фронта» и спасать Родину в трудные моменты.

Именно таких мотивированных и технически подкованных специалистов ИТ-поддержки, способных не просто регистрировать заявки и переключать звонки, но еще снизить «накал страстей», параллельно разобраться в проблеме и решить ее, крайне важно найти и удержать.

Я понимаю, что мои взгляды не претендуют на «истину последней инстанции». Но я также искренне надеюсь на то, что они позволят немного качнуть маятник восприятия работы техподдержки в другую сторону и взглянуть на этих (часто недооцененных) ребят с другой стороны.

Подумайте над этим — ведь без них мир ИТ не был бы таким чистым и прекрасным!