По данным ДОУ, среднему украинскому инженеру техподдержки 26 лет, он имеет зарплату $300-700 и опыт работы 2 года.
Задачи и обязанности
После окончания разработки продукта или его обновленной версии продукт попадает к пользователю. В ходе его использования клиенты могут сталкиваться с определенными проблемами, так как во время тестирования невозможно покрыть все вариации использования продукта и все изменения сред. Проблемы могут быть, как из-за дефектов в продукте, так и из-за проблем с аппаратной частью среды, где установлен продукт. Когда эти проблемы возникают и клиенту не удается самостоятельно их решить, то он обращается в службу технической поддержки.
Профессия Support Engineer разбита на 5 уровней (Levels), по номеру которого можно сразу с большой точностью определить, что из себя представляет конкретная позиция. Эта структура не имеет ничего общего с карьерной лестницей, а только с расположением работника поддержки на линии «Клиент — ядро продукта». Чем ниже уровень, тем ближе к клиенту и тем дальше от ядра. Поэтому из первого уровня практически невозможно дорасти до третьего-четвертого из-за разницы в специфике задач и требований к кандидатам, так как каждый уровень — это совершенно другая сфера деятельности.
Level 0 (Колл-центр). Основная задача — первичная обработка запроса пользователя: уточнение учетной информации пользователя, краткое описание проблемы. Иногда — выдача пользователю заранее согласованной информации (ответов на часто задаваемые вопросы). В особо сложных случаях — вызов дежурного инженера.
Технические знания там не требуются, только грамотная речь и отсутствие боязни телефона. Большой плюс — знание иностранных языков. Карьерно продвинуться из колл-центра особенно никуда нельзя, разве что внутри непосредственно колл-центра.
Level 1. Сотрудники первого уровня поддержки сортируют запросы, поступающие в почту, отделяют явный мусор (в корзину) от простых вопросов (отвечают сами) и профильных вопросов (отправляют коллегам уровнем выше или в соответствующий отдел), отвечают на телефонные звонки.
Требования к сотрудникам обычно такие же, как и для колл-центра, но крайне желательна общая компьютерная грамотность (например, пользователь MS Excel). Поскольку для поддержки продукта нужно главным образом знать продукт компании, то все равно кандидата придется обучать с нуля.
Карьерно продвинуться можно отсюда либо во второй уровень (техническая экспертиза), либо в менеджмент поддержки (управление), либо в отдел продаж.
Level 2. Это последний уровень техподдержки, который имеет дело непосредственно с конечным пользователям. Здесь же сотрудники имеют наиболее полную картину о продукте в целом, как с точки зрения пользователя, так и с точки зрения внутренних особенностей. Сюда перенаправляются запросы, с которыми не справился первый уровень, здесь заказываются тренинги для клиентов о продукте фирмы. У сотрудников второго уровня есть доступы и к клиентским системам, и к внутренним баг-трекерам и бэклогам.
«Мне всегда нравилось помогать людям, я с детства помогал своим друзьям решить проблемы с установкой разных игр и настройкой ПК. Мне это приносило удовольствие. Кроме этого, я имею неплохие софтскиллы и достаточно стрессоустойчив. Привлекала меня загруженность на 100%. Из-за большой загруженности я всегда был в тонусе и быстро впитывал информацию, мне кажется на начальном этапе это то, что нужно, для молодого специалиста».
Текучка здесь ниже, чем в в первом уровне, но требования к кандидату выше: дополнительно нужны как минимум базовые навыки программирования, базовые знания баз данных, умение быстро сопоставлять факты, навыки trouble shooting. Для тренингов нужны навыки презентаций. В зависимости от компании, второй уровень может также выполнять функции первого, что может несколько снизить технические требования к кандидату.
«Я работаю в техподдержке хостинг-компании.Мой круг обязанностей — решение вопросов клиентов компании через чат и систему тикетов, в большей степени это администрирование виртуальных и выделенных серверов, помощь со скриптами и CMS, мониторинг сервисов инфраструктуры, консультирование клиентов по предпродажным вопросам, по вопросам безопасности, восстановление работоспособности серверов в случае каких-либо ошибок».
Из инженеров поддержки второго уровня получаются отличные Technical Pre-Sales Engineers и Product Trainers (если есть хорошие социальные навыки), SLA-менеджеры (если есть склонность к формализации процессов) и изредка — инженеры поддержки третьего уровня (если склонность к поддержке инфраструктуры больше, чем к поддержке непосредственно продукта).
Level 3. Инженеры техподдержки третьего уровня имеют гораздо больше общего с сисадминами/devops, чем с коллегами из второго уровня. С клиентами они уже не общаются, поэтому социальные навыки и знания языков уходят на второй план. Поддержка третьего уровня поддерживает не столько сам продукт, сколько инфраструктуру продукта, поэтому продукт в целом они, как правило, не знают. В их задачи входит конфигурация, починка, поддержка и развитие продуктовой среды, а также разруливание проблем в нерабочее время.
Рабочий процесс третьей линии техподдержки начинается с того, что поступает заявка от второй линии. Типичный вид одного такого кейса — это описание проблемы, в который входит текстовое описание, скриншоты, информация об аппаратной среде, файл с логами работы продукта.
Инженер техподдержки изучает присланную информацию и, как правило, реагирует по одному из трех сценариев:
- Дает рекомендации по решению проблемы, если проблема известна и уже есть готовое решение или продукт работает должным образом, просто необходимо разъяснение, или нужны изменения в конфигурации аппаратного среды, где установлен продукт;
- Запрашивает дополнительные данные (диагностические приложения, новые логи продукта с заданными параметрами, дополнительные снимки экрана), если информации недостаточно, после чего дает рекомендации по решению проблемы;
- Идентифицирует, что проблема в недостатке продукта, и переводит заявку на команду разработчиков, после чего они изготавливают патч, который тестирует инженер техподдержки и передает пользователю.
«Приходит новая заявка — ставишь ее себе в график. Приходит критический инцидент — приостанавливаешь все, разбираешься с ним. Бывает по несколько раз в день приходится менять приоритеты задач. Так что нужно уметь быстро переключаться между задачами и правильно расставлять приоритеты».
Общий процесс работы имеет много общего с методологией Канбан, так как невозможно детально спланировать количество заявок. По опыту можно только ориентировочно знать, когда их будет больше, а когда меньше.
Текучка на этой позиции средняя, требования к кандидатам отражают инфраструктурные особенности компании. Как правило, нужны хорошие знания Unix Based OS, навыки скриптования, знание баз данных, знание мониторинговых систем.
«Куда они растут карьерно — доподлинно неизвестно. По-моему, они просто приходят из таких же позиций и уходят на такие же позиции, наращивая технические знания и гонорары».
Level 4. Встречается гораздо реже первых трех. Фактически, это девелоперы, которые в компании давно и досконально знают внутренности продукта или его части, потому что сами его программировали. С клиентами они не контактируют, инциденты не разруливают. В их задачи входит быстро починить критическую проблему в системе, которая уже ушла к пользователям. Их основные источники задач — багтрекеры.
Со стороны их не берут, а взращивают в компании. Карьерно развиваются они так же, как и программисты: могут стать, например, архитектором проекта или вроде того.
Дальше речь пойдет непосредственно о L2/L3/L4 Support Engineers.
Рабочий день инженера техподдержки — это обработка инцидентов, которых, в зависимости от качества софта, бывает больше или меньше. Как правило, день начинается с проверки всех тикет-трекеров, системы мониторинга, а также, возможно, критически важных сред.
«Работа состоит из разгребания тонн логов разных приложений, копание в базах данных, настройках приложений, аналитика найденного, поиск решения, имплементация, всё это сопровождается контролем признаков активности из мониторинг систем (чтобы ничего не пропустить) и перепиской с коллегами из разных локаций для консультаций по какому-либо вопросу».
От других членов команды разработки ПО Support Engineers отличаются тем, что они как никто другой знают о проблемах юзабилити, а также понимают всю картину воркфлоу от начала до конца.
Преимущества и недостатки
В своей должности инженеров техподдержки привлекаетразнообразие задач, насыщенный ритм работы:
«Нравится общение с людьми из различных стран и культурой, решение технических задач различной сложности. То чувство, когда решил какую-то сложную, на первый взгляд не решаемую задачу, непередаваемо :)»
«Знания ценятся не столько глубокие, сколько разнообразные, и очень важны определенные личностные качества — дружелюбие, выдержка, настойчивость».
«При работе на этой должности опыт приобретается очень быстро. Причем, если сначала этот опыт касается решения проблем, то уже на поздних стадиях это больше отходит к автоматизации решения этих проблем и органично приводит к профессиональному росту, который обогащен множеством низкоуровневых, базовых мелочей, которые потом смогут пригодиться когда угодно в карьере».
«Позиция Support Engineer довольна интересна, так как необходимо много коммуницировать не только с клиентами но и с инженерами своей компании — разработчиками, тестировщиками, техрайтерами, менеджментом. Так ты можешь развиваться в любом направлении, да и друзей много можно завести».
Также отмечают, что эта должность — один из вариантов относительно легкого входа в отрасль:
«Для меня Support Engineering — это переходной этап от работы системным администратором до разработки ПО. Впрочем, работа достаточно разноплановая, нескучная, задачи могут быть достаточно сложными и интересными. Есть возможность проявить себя».
«Мне кажется люди приходят в техподдержку тогда, когда у них не хватает глубоких технических знаний, но при этом хочется быть в ИТ и получать айтишную зарплату без особых напрягов, ведь общение по телефону, email и sql запросы — это проще , чем разработка такой же системы. Единственное сильное требование — хороший разговорный английский».
Из недостатков — обилие стрессовых ситуаций, сложности непосредственного карьерного роста:
«Приходит новый инцидент — ставишь его себе в график. Приходит критический инцидент — бросаешь всё, разбираешься с ним. Бывает, по несколько раз в день меняешь приоритеты задач. Получается рванная работа, ты должен уметь быстро переключаться между тасками. Со временем начала от этого болеть голова, был вымотан».
«У других команд есть цель, которую они видят, к которой движутся. У нас же — такой себе День сурка, ведь письма будут всегда и пользователи будут всегда, и вот когда мы поможем вот этой
«Есть проблема профессионального роста. Когда ты- человек-оркестр, ты знаешь что-то обо всем, но ничего глубинно о чем-то одном. И это тебе не прибавляет цены на рынке, цены как специалисту. Или же наоборот, если у тебя очень узкая специализация по конкретной технологии/продукту, то тоже могут быть сложности с поиском следующей работы».
Упоминают и проблемы в отношениях с коллегами из других отделов:
«Самое очевидное — у саппорта зарплаты меньше, чем у девелоперов ;) В остальном все недостатки — мелкие, больше связанные с рабочим процессом. Например, часто нужно обосновать вышестоящим, зачем тебе необходим доступ на этот сервер или зачем админскими роль в этой базе данных, ты ведь не девелопер — обходись тем, что есть».
«Большое кол-во девелоперов, QA и т.п. не являются людьми высокой культуры общения, что нередко бывает серьезным препятствием при обсуждении/эскалации инцидентов или попытках выудить у них информацию, которая саппорту крайне необходима для анализа риквеста. Девелоперы «всегда очень заняты». Нередко люди в других отделах считают саппорт самой низкой ступенью в компании с вытекающим отношением. Если объяснить более детально, люди не всегда понимают важность саппорта и не оказывают треюбущейся саппорту поддержки. Например, приложение может быть описано довольно слабо техническим писателем (и это не редкость), и информацию можно получить только у тех, кто имеет непосредственное отношение к созданию архитектуры или определению функционала. Задача для саппорта часто бывает сложной, и ты чувствуешь себя в качестве «попрошайки».
Как стать и куда двигаться дальше
Для L2 Support Engineers нужны базовые знания Windows/Linux OS, баз данных, общие знания в области системного администрирования, сетей, архитектуры системы. Для L3 — более глубокие знания по вышеупомянутым темам, а также хорошие знания Unix Based OS, навыки скриптования, знание мониторинговых систем.
Для работы в компаниях, направленных на иностранные рынки, обязателен английский не ниже среднего уровня.
«Работа в саппорте, на мой взгляд, чем-то похожа на „передовую“ на войне. Здесь нужна стойкость, быстрая реакция, конечно же знание своего дела и стрессоустойчивость».
Из личных качеств:
- стрессоустойчивость;
- усидчивость;
- хорошая память;
- обучаемость, умение быстро находить информацию для решения проблем.
«Саппорт должен быть гибким, уметь быстро реагировать и адаптироваться под ситуацию. Важны коммуникационные навыки — не бояться говорить что-то, инициативность — не бояться звонить и уведомлять бизнес и менеджеров высшего звена».
Возможные карьерные путиинженера техподдержки:
- Дорасти до Support Lead — заниматься более сложными задачами, расширять или же, наоборот, углублять свой опыт, координировать работу отдела;
- Стать проектным менеджером, если хочется развиваться не по техническому, а по управленческому пути. Этому поможет баланс софтскиллов и технического бэкграунда, умение решать конфликты. Если же интересно работать с клиентами, можно рассмотреть позицию Technical Account Manager или бизнес-аналитика;
- Стать системным администратором, если нравится работать с инфраструктурой, занимается настройкой и обеспечением стабильной работы техники;
- Стать DevOps, если интересно писать сценарии и хочется самостоятельно создавать инфраструктуру, поднимать проекты, автоматизировать развертывание;
- Стать DBA, если нравится администрировать и проектировать базы данных, писать SQL запросы;
- Стать QA или разработчиком.
P. S. Благодарю за помощь в написании статьи Елену Логодскую и еще 28 украинских инженеров техподдержки, которые рассказали DOU о своей профессии. Приведенные в статье цитаты взяты из их рассказов.
См. также: