Честно признаюсь, я давно держал в голове эту мысль и понимал, что рано или поздно она все-таки прорвется наружу. При этом я прекрасно понимаю суть "боли техподдержки", поскольку проработал там 3 года на заре своей ИТ-шной карьеры. Потом начал развиваться дальше и взглянул на техподдержку со стороны менеджера проектов, руководителя разработки и заместителя ИТ-директора. И вот, спустя 20 лет, понимая, что мой взгляд стал беспристрастным, эта мысль все-таки прорвалась наружу в виде желания написать статью.
Но давайте сначала отвлечемся и попробуем взглянуть на ИТ в целом "глазами Пользователя". Итак, что представляет себе Пользователь бизнесовой направленности, когда слышит или произносит слово "АйТи-шник"?
Некоторые, услышав это слово, до сих пор представляют себе парня в свитере, или в очках с лохматой головой и "немного того", разговаривающего на непонятном для нормальных людей языке и т.д. Другие, напротив, представляют парня в рубашке с галстуком или костюме. И на самом деле под словом "АйТи-шник" сейчас кроется целая куча узконаправленных специальностей:
менеджеры продуктов,
менеджеры проектов,
менеджеры по инфраструктуре,
ИТ-архитекторы,
тим-лиды,
системные инженеры,
сетевые инженеры,
бизнес-аналитики,
дизайнеры интерфейсов,
менеджеры релизов,
инженеры по средам и сервисам,
тестировщики (тут целая градация: альфа, бета, нагрузочное, интеграционное, регрессионное),
разработчики (и они тоже делятся на направления: фронт-енда, бэк-енда, интеграции и API, мобильных приложений, WEB-сервисов и т.д. и т.п.).
И это я еще пока не дошел до узконаправленных специальностей типа Bid Data, AI, SaaS, где есть Data-scientists, AI-инженеры и т.д. и т.п.
В общем набор ИТ-специальностей - это прямо как титры в конце фильма, где мы видим, что оказывается за 2 главными героями этого блокбастера (главный разработчик и менеджер проекта) стоит несколько сотен людей, благодаря которым этот фильм (ИТ-продукт) был создан и вышел в свет - почувствовали аналогию?
Так вот, представив себе всю эту кучу благородных людей, участвовавших в создании и запуске программного продукта (весь быстро-пробегающий перед глазами список в титрах после фильма) мы подходит к вопросу технической поддержки запущенного ИТ-продукта и задаемся вопросом:
"А если в продукте вдруг возникнет ошибка или он начнет глючить?"
И тут мы вспоминаем о техподдержке. И надо прямо сказать, что у некоторых пользователей есть устоявшееся отношение к техподдержке как к какому-то низшему сервисному звену. Вроде дворника, или того парня, который ездит на мусорной машине и подкатывает мусорные баки к ней. И если вдруг из этих баков что-то упадет, то он должен проявить "мгновенную реакцию", подобрать и максимально быстро "аннигилировать этот баг", не нарушая "утонченное восприятие мира" у Пользователя.
Ну так ведь, правда?
Наверняка Вы сталкивались с такими людьми. Пусть их мало, но они есть, и они иногда даже сами не понимают как их отношение к техподдержке выглядит со стороны. Часто такие люди руководствуются позицией: "Вы обязаны мне предоставить качественный сервис поддержки". Формально они конечно правы. И именно этот формальный подход и порождает отношение к техподдержке как к сервисной функции, которая обязана быстро решить проблему (и никаких НО).
И со мной сейчас не согласятся только те из вас, кто понимает важность и сложность работы самой техподдержки:
соблюдение SLA (service level agreement), который регламентирует сроки "мгновенной реакции", а также сроки исправления ошибок "для анигилирования бага";
обеспечение позитивного восприятия пользователем продукта и команды в целом, т.е. ни в коем случае ни при каких условиях не нарушать "утонченное восприятие мира у пользователя" и быть почти психологом, не позволяя "праведному гневу Пользователя" разжечь третью мировую войну;
правильно организовать исправление найденных багов, т.е. разобраться в их причинах, пробежаться по FAQ, проверить версию возможной ошибки со стороны пользователя, иногда даже разобраться в логах. Поставить задачи разработчикам, тестировщикам, релиз менеджерам и т.д. и потом неустанно контролировать сроки, чтобы исправления не ушли в "релиз следующего года";
и самое главное - внутренняя мотивация и постоянное решение внутреннего конфликта "кто Я, и куда Я хочу развиваться?"
Другими словами, хороший специалист техподдержки почти всегда будет втайне завидовать и сравнивать себя с теми бравыми благородными ребятами из разработки\проектирования, которые создают и внедряют новые фичи и модули, в то время как ему приходится "разбирать грязное белье".
Тут конечно можно начать рассуждать о разделении техподдержки на 1-ю, 2-ю, 3-ю линии, каждая из которых закрывается специалистами разного уровня и позволяет "размазать зону ответственности", распределив ее по разным специалистам.
Но ответьте себе честно: неужели у Вас никогда не возникало раздражения, когда вы обращаетесь к одному специалисту для решения Вашей проблемы, а он переводит ее второму, а потом третьему? Как человек Вы все равно будете ждать конкретного ответственного - именно того, кто сейчас занимается Вашей проблемой. И "передача эстафетной палочки" на следующую линию поддержки как правило вызывает увеличение раздражения и негатива, который выливается на нового ответственного за решение Вашего бага.
Согласитесь, что в такой ситуации сотрудникам техподдержки приходится очень часто думать о самомотивации и находить внутри себя стержень, чтобы не сломаться (не бросить эту неблагодарную позицию и не уйти, например, в аналитики или разработчики). И продолжать работать "с огоньком", разбирать бесконечные баги и решать проблемы Пользователей, периодически сталкиваясь с их негативом.
Если в вашей команде есть классная команда поддержки, которая умеет общаться с Пользователями "как команда психологов" и очень хорошо разбирается в особенностях ИТ-продукта, вплоть до грамотного анализа деталей, логов и наполнения FAQ, то Вам повезло.
Ведь хороший специалист техподдержки может запросто стать тем спасителем вашего продукта (фильма). Тем, кто в сложный момент "возникновения непростительного бага" (который 100% был пропущен всеми этими бравыми ребятами из титров) предотвратит Мировую Войну с Пользователем просто потому, что это его призвание - быть "Бойцом невидимого фронта" и спасать Родину в трудные моменты.
Именно таких мотивированных и технически подкованных специалистов ИТ-поддержки, способных не просто регистрировать заявки и переключать звонки, но еще снизить "накал страстей", параллельно разобраться в проблеме и решить ее, крайне важно найти и удержать.
Я понимаю, что мои взгляды не претендуют на "истину последней инстанции". Но я также искренне надеюсь на то, что они позволят немного качнуть маятник восприятия работы техподдержки в другую сторону и взглянуть на этих (часто недооцененных) ребят с другой стороны.
Подумайте над этим - ведь без них мир ИТ не был бы таким чистым и прекрасным!
