Сжигаете инженеров технической поддержки быстрее, чем нанимаете новых?

Техническая поддержка сложных программных продуктов отличается от традиционного клиентского сервиса. Если в клиентский сервис найти сотрудников особого труда не составляет - главное, чтобы умели (готовы были научиться) правильно общаться, достаточно грамотны для использования скриптов и/или готовой базы знаний, и готовы работать (как правило) по сменному графику, то что касается технической поддержки, то здесь уже все не так просто.

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

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

Даже если с деньгами и зарплатами все хорошо, то не открою большого секрета, если скажу, что техническая поддержка не самое популярное место работы. Если человек имеет достаточно глубокие технические знания, а еще вдобавок владеет иностранным языком и коммуникативными навыками, то он стремится в лучшем случае занять управленческую позицию, а наиболее частый трек это из технической поддержки пойти в DevOps, QA или R&D. Многие идут в техническую поддержку, изначально рассчитывая на временную работу, чтобы «зацепиться» в компании, а дальше уже строить карьеру внутри.

И вот здесь наступает боль руководителя технической поддержки, и иногда разделяющего с ним HR'а.

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

Если посмотреть на проблематику, то вырисовываются следующие цели:

• Снизить время найма.
• Уменьшить время онбоардинга.
• Уменьшить текучку кадров, даже внутреннюю

Обычно для этого есть традиционные пути решения.

Разграничение команды и входящего потока по линиям/уровням, где первая линия обрабатывает весь поток, пытаясь решить самые простые проблемы с использованием базы знаний и документации, остальное передавая на вторую линию. Вторая линия уже применяет технические знания продукта, операционных систем, смежных продуктов и т.д. Опционально может быть еще и третья линия, которая уже умеет заглядывать в код продукта и возможно выпускать хотфиксы ( но иногда эта задача «сидит» в R&D).

Ну да, ответ в капитанском стиле. Хотя сам в свое время начинал работать инженером технической поддержки в компании, где не было никаких тренингов. Меня просто посадили рядом с опытным сотрудником, который буркнул мне что-то про дистрибутив продукта, который я должен сам развернуть на сервере (типа заодно и разберусь что там как) , а потом он мне показал тикетную систему, и все :)

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

Плюсы

• Активное обучение продукту, по заданной программе, несомненно способствует более быстрому его освоению, чем самостоятельное прощупывание.
• Коачинг/менторинг не дают сотруднику потеряться в «реальном мире» и сделать первые шаги.

Минусы

• Мотивация ментора. Здесь это не совсем минус в прямом смысле, а скорее то, на что надо обратить внимание. Например, если ментор это Тим Лид, то он мотивирован и заинтересован в росте новичка. А бывает, что ментор это просто еще один сотрудник, которому эту задачу дали в нагрузку плюсом к его основной работе. Тогда нужно позаботиться о соответствующем поощрении.

Пожалуй самый сложный пункт над которым бьются HR'ы. Помимо всего того, что присуще всем другим департаментам в техподдержке есть свои особенности:

• Сменный график.
• Низкая зарплата (или вообще или по сравнению с другими отделами).
• Отношение к профессии в IT индустрии в целом. Можно конечно привести много примеров почему это все же не так, или компании, где устроено по другому, но все же «средняя температура по больнице» такова, что техподдержку считают стартовой площадкой для карьеры, после которой обязательно надо пойти дальше.
• Психологическое напряжение. Не всегда клиенты бывают хорошими, и не всегда продукт работает как надо. Отсюда весь негатив на себя принимает поддержка. При тех же самых технических навыках некоторые предпочитают работу системных администраторов, чтобы избежать коммуникаций с клиентом.
• Конвейерный тип работы. Если у разработчиков есть релизы, а например у системных администраторов какие-то проекты – т.е. точки окончания каких-то этапов работ, то заявки всегда идут сплошным и бесконечным потоком. Это тоже ведет в конце концов к выгоранию от рутины.

Если с первыми двумя пунктами можно что-то сделать, то с остальными это что называется «из песни слов не выкинешь», и текучка (и так высокая в IT) в техподдержке может достигать 30%.

Можно ли сделать что-то еще? Короткий ответ – Да.
При этом велосипед изобретать не нужно, а можно воспользоваться уже накопленными знаниями и методами, которые используются в сотнях других компаний.
Методология Knowledge-Centered Service (KCS) – эффективный подход в использовании коллективных знаний в службах технической поддержки.

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

KCS предлагает наиболее эффективный подход к накоплению и поддержанию знаний в постоянном актуальном состоянии. Говоря простым языком – в базе знаний с вероятностью 90%+ можно найти ответ на вопрос по использованию, конфигурации или исправлению ошибки продукта.
При таком подходе минусы, связанные с наймом, онбоардингом и удержанием сотрудников, нивелируются

Давайте посмотрим подробнее:

• Даже при наличии сложного продукта, база знаний, которая содержит широкий охват актуальных и постоянно обновляющихся знаний и кейсов по которым приходят клиенты, позволяет снизить порог входа по техническим требованиям для новых сотрудников. В некотором смысле можно сказать, что вы можете использовать почти такой же профайл сотрудника, как и для клиентского сервиса, где основным навыком должна быть коммуникация. (Конечно же в реальности какой-то технический фундамент у сотрудника должен быть, иначе он не сможет расти дальше). Новички находят ответы на большинство (пусть даже сложных) проблем в базе знаний, используют их для ответа и одновременно изучают внутренности продукта.

• Комбо тренингов и постоянно актуализирующейся базы. Получив тренинги и начальный коачинг, новичок может достаточно быстро начать решать тикеты, пользуясь готовыми решениями с одной стороны, а с другой продолжая обучаться на этих решениях с минимальным вовлечением ментора. Полностью отказываться от менторства не рекомендуется, потому как даже ChatGPT не все еще знает :)

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

Суммаризируя все вышесказанное:

• Техническая поддержка имеет свои особенности, которые негативно влияют на текучку кадров.
• Существуют классические методы по управлению и организации технической поддержки, которые позволяют снизить негативный эффект, но не избавиться от него полностью.
• Если нельзя существенно снизить текучку, то можно существенно улучшить найм и онобоардинг.