В одной команде техподдержки больше 10 сотрудников за несколько лет ушли не из IT, а в аналитику, тестирование и смежные роли внутри той же структуры. Параллельно SLA реакции вырос с 61% до 79%, а SLA решения — с 80% до 88%. Для русскоязычного рынка, где карьерный рост в саппорте обычно считают красивой легендой для вакансий, это редкий практический кейс: поддержка может быть не тупиком, а внутренним кадровым лифтом.
Об этом сообщает Habr / Карьера со ссылкой на руководителя технической поддержки крупной федеральной розничной сети, работающего как внешний подрядчик. Его тезис звучит просто и немного неудобно для многих IT-менеджеров: проблема саппорта не только в перегрузке, очередях тикетов и слабом бренде роли, а в том, что компании сами превращают первую и вторую линии в конвейер без траектории роста. В итоге сильные специалисты либо уходят, либо остаются, но внутренне выключаются и становятся просто аккуратными исполнителями.
До изменений команда жила по знакомому сценарию. Формально база знаний была в Confluence, но реальные ответы хранились в чатах и в головах нескольких ключевых людей. Пока такие сотрудники были на месте, система выглядела рабочей: тикеты закрывались, жалоб не становилось больше, SLA не падали критически. Но как только носитель экспертизы уходил в отпуск или увольнялся, процессы начинали рассыпаться, время решения инцидентов росло, а оставшиеся специалисты переходили в режим постоянного тушения пожаров. Внешне это не всегда видно в отчетах, и именно поэтому саппорт так легко недооценить: цифры еще терпимые, а управляемости уже нет.
Ключевой разворот был не в том, чтобы срочно отправить всех учиться на аналитиков или перестроить оргструктуру, а в смене оптики. Руководитель команды перестал смотреть на поддержку только как на функцию обработки инцидентов и начал воспринимать ее как среду, где можно заранее увидеть будущих тестировщиков, аналитиков и методологов. Для этого операционных метрик оказалось недостаточно. SLA, время решения и количество повторных обращений хорошо показывают, насколько аккуратно команда исполняет регламент, но почти ничего не говорят о потенциале людей. Поэтому в работу добавили поведенческие признаки: кто задает вопрос «почему», а не только «как»; кто помогает коллегам без прямого запроса; кто пытается увидеть проблему шире своей роли. На бумаге это звучит как банальная управленческая психология, но в живой поддержке именно такие сигналы отделяют будущего системного специалиста от просто крепкого исполнителя.
Следующий элемент — разный подход к разным типам сотрудников. В кейсе прямо сказано: сильный исполнитель и человек с потенциалом — не одно и то же. Одному нужна стабильная зона ответственности и понятные правила игры, другому — задачи на вырост и видимая следующая ступень. Если всем раздать одинаковую нагрузку и одинаково измерять по KPI, карьерный рост в саппорте останется теорией. Поэтому команда начала практиковать временное погружение в смежные роли без формального перевода. Сотрудники поддержки подключались к задачам тестирования и аналитики, а разработчики периодически погружались в процессы саппорта. Такой обмен, по словам автора, решал сразу три задачи: давал людям реальное представление о соседних ролях, снижал привычное напряжение между отделами и помогал быстро понять, кто действительно готов к переходу, а кто романтизировал чужую работу со стороны.
Отдельно в материале выделена база знаний, и здесь кейс выглядит особенно показательно. Команда перенесла ее из Confluence в Telegram, то есть фактически туда, где и так уже жила ежедневная коммуникация. Ход не универсальный и точно не для каждого контура безопасности, но мысль важна: база знаний — это не архив документов для галочки, а инструмент диагностики. По тому, кто и как описывает решения, кто умеет не просто ответить на частый вопрос, а структурировать опыт так, чтобы им воспользовались другие, видно, у кого в команде системное мышление. Именно таких людей, как утверждает автор, позже чаще всего видно на переходе в аналитику. Для бизнеса здесь сигнал прямой: если знания оседают в личках и чатах без структуры, компания теряет не только скорость реакции, но и внутренний кадровый резерв.
Самый сильный эпизод в статье — не про методологию, а про конкретный поступок. В инфраструктуре компании периодически падали службы публикации баз 1С, что било по обменам между магазинами и центральной системой. Сценарий был стандартным: Zabbix присылал уведомление, дежурный заходил на сервер, перезапускал службу руками и отписывался в чат. Один из специалистов второй линии устал от повторяющегося ритуала и за пару вечеров написал Telegram-бота, который сам отслеживал состояние служб после падения, восстанавливал их и отправлял уведомления в общий чат. Без задачи сверху, без проекта трансформации, без согласований. Через несколько месяцев этот сотрудник ушел в аналитику. Логика руководителя здесь предельно земная: человек, который видит системную поломку и устраняет ее на уровне процесса, уже вырос из роли «просто саппорта», даже если формально еще сидит на второй линии.
Есть и другие примеры: одна сотрудница добровольно взялась разбираться в незнакомой 1С-конфигурации, которую никто в команде толком не знал, и со временем стала ориентироваться в ней лучше вендоров, которые ее внедряли; другая начала самостоятельно собирать mind-map по типам обращений, чтобы быстрее навигироваться в потоке задач, а затем перешла в тестирование 1С. Важная деталь: автор не приписывает себе героическое «я их развил». Наоборот, он подчеркивает более трезвую управленческую роль — создать условия, в которых такие люди проявятся, заметить это вовремя и дать следующий шаг. Для IT-директоров и руководителей сервисных функций это, пожалуй, главный вывод: карьерный рост в саппорте начинается не с курса по аналитике и не с новой карьерной матрицы в HRM-системе, а с того, что менеджер перестает считать поддержку расходным материалом.
В цифрах результат выглядит убедительно даже без громких лозунгов: команда выросла с 20 с небольшим до 35 с лишним человек, SLA реакции поднялся с 61% до 79%, SLA решения — с 80% до 88%, а больше 10 человек перешли из первой и второй линий в тестирование, аналитику и методологию. Для рынка, где саппорт по-прежнему часто продают как «вход в IT» без ответа на вопрос «и что дальше», это неприятный, но полезный сигнал. Похоже, дефицит кадров в ряде IT-функций частично можно закрывать не только наймом снаружи, но и нормальной работой с теми, кто уже сидит ближе всего к реальным инцидентам, процессным сбоям и пользовательской боли. Вопрос теперь не в том, может ли поддержка растить специалистов для остальной IT-структуры, а в том, сколько компаний готовы перестать мерить саппорт только скоростью ответа на тикет.