Саппорт принято считать тупиком. Местом, куда приходят, чтобы потом уйти куда‑нибудь «поинтереснее» — в разработку, в аналитику, в DevOps. Или вообще из IT.
С этим я не согласен.
За последние годы из моей команды поддержки десять человек ушли в аналитику, тестирование и смежные направления. Большинство остались внутри — просто перешли на другие роли. Кто‑то ушёл наружу, это нормальная часть процесса. При этом SLA реакции вырос с 61% до 79%, SLA решения — с 80% до 88%. Команда выросла с двадцати с небольшим до тридцати пяти человек.
Я руковожу технической поддержкой крупной федеральной розничной сети — как внешний подрядчик. В этой статье — про то, как мы перестали относиться к саппорту как к промежуточной станции и начали использовать его как точку роста. Без курсов, без внешних программ обучения, без масштабных перестроек. Просто по‑другому посмотрели на людей, которые уже работают.
Почему саппорт считают тупиком
Давайте честно. У саппорта плохой имидж по объективным причинам.
Работа однообразная: те же типы инцидентов, те же пользователи, те же эскалации. SLA, KPI, очередь тикетов. Если делать всё хорошо — никто не заметит. Если плохо — заметят сразу. Карьерная лестница часто заканчивается на «старшем специалисте 2 линии», после чего расти некуда. И самое неприятное — большинство сотрудников и руководителей это принимают как данность.
В результате сильные уходят, потому что не видят перспектив. Слабые остаются, потому что их устраивает. И руководство объясняет это рынком — «сложно найти хороших людей». Хотя на самом деле проблема не в найме.
Проблема в том, что хорошие люди уже есть. Просто система устроена так, что они не могут проявиться.
Что было раньше
Когда я только пришёл в команду, всё держалось примерно так, как держится в большинстве IT‑команд: на нескольких ключевых людях, которые «помнят, как оно работает». База знаний была — формально. Существовала в Confluence, но туда заглядывали редко, потому что проще написать в чат «ребят, кто помнит, как настраивать вот это». В чатах знания и жили — фрагментами, в переписках.
Это работало. До определённого момента. Пока ключевой человек не уходил в отпуск или не увольнялся — и тогда оказывалось, что половина процессов существовала только у него в голове. Время решения инцидентов росло, нагрузка на оставшихся увеличивалась, и команда начинала работать в режиме постоянного тушения пожаров.
Метрики при этом могли оставаться нормальными. SLA — закрывается. Тикеты — обрабатываются. Жалоб — не больше обычного. С формальной точки зрения всё в порядке.
С реальной — нет. И главная проблема была не в технологиях и не в нехватке людей. Проблема была в том, что мы не управляли потенциалом, который уже существовал.
Главный сдвиг в мышлении
Если попытаться сформулировать одной фразой, что изменилось — мы перестали относиться к саппорту как к функции обработки инцидентов и начали относиться как к среде, в которой формируются кадры для всей IT‑структуры.
Это звучит как красивая фраза. На практике она означает три конкретные вещи:
Первое. Метрики исполнения (SLA, время решения, повторные обращения) показывают, насколько хорошо команда выполняет инструкции. Они не показывают, кто из людей способен на большее. Чтобы видеть это, нужны другие индикаторы — поведенческие.
Второе. Потенциал не проявляется сам. Он проявляется в среде, где это безопасно и поощряется. Если человек закрыт регламентом и боится отступить от него — он никогда не покажет, что может думать шире.
Третье. Если у сильных сотрудников нет управляемого роста — они уходят. Не обязательно из компании. Они уходят внутренне: становятся стабильными исполнителями без амбиций. Это потеря, которую никто не замечает, потому что метрики не падают.
После того как мы сформулировали это для себя, начали перестраивать систему.
Прежде чем перейти к деталям — отдельный момент, который меняет восприятие всей дальнейшей истории. Мы — внешний подрядчик. Это значит, что работаем не со своей командой, а с командой заказчика. Любые изменения нужно согласовывать, выстраивать через доверие, объяснять бизнес‑результатом.
То, что я описываю ниже, работало в этих условиях — когда у тебя нет полной административной власти и каждая инициатива требует объяснения «зачем это бизнесу». А значит, у руководителей собственных команд возможностей применить это на практике ещё больше.
Не буду расписывать здесь всё — это материал нескольких следующих статей. Здесь — обзор четырёх элементов, которые работают только вместе:
Диагностика. Перестали измерять только операционные метрики. Начали смотреть на поведение: кто задаёт вопрос «почему», а не только «как». Кто помогает коллегам без запроса. Кто смотрит шире своей роли. Без этих наблюдений невозможно понять, на ком держится экспертиза и кто способен расти.
Работа с потенциалом. Начали явно отличать сильного исполнителя от сотрудника с потенциалом. Это разные люди, и работать с ними нужно по‑разному. Стабильному исполнителю — комфорт и стабильность. Потенциалу — задачи на вырост и видимая траектория.
Смежные роли. Ввели практику временного погружения сотрудников в задачи смежных направлений. Без формального перевода. Специалист поддержки подключается к задачам тестирования или аналитики. Разработчик периодически погружается в процессы поддержки. Это решает три задачи одновременно: даёт людям реальное понимание других ролей, снижает напряжение между отделами, и — что важнее всего — становится видно, кто действительно готов к переходу.
База знаний. Перенесли её из Confluence в Telegram. Это отдельная история, я расскажу её в одной из следующих статей. Здесь важно одно: база знаний — не архив документов. Это диагностический инструмент. По тому, кто что туда пишет и как, видно, кто из команды мыслит системно. Именно эти люди потом первыми переходят в аналитику.
Кейс: бот, которого никто не просил.
Чтобы не оставаться на уровне абстракций — один конкретный пример того, что я имею в виду под «потенциалом».
В нашей инфраструктуре периодически падали службы публикации баз 1С. Это влияло на обмены по шине данных между магазинами и центральной системой. Zabbix отправлял уведомления, дежурный специалист заходил на сервер, перезапускал службу руками, отписывался в чат. Алгоритм рабочий, проблем не возникало.
Один из специалистов второй линии в какой‑то момент сказал: мне надоели эти триггеры. И за пару вечеров написал Telegram‑бота, который сам отслеживает статус служб после падения, восстанавливает их и отправляет уведомления в общий чат. Без задания, без поручения, без согласования. Просто потому что не смог иначе.
Когда я узнал — это был один из тех моментов, когда понимаешь: вот оно. Через несколько месяцев этот сотрудник перешёл в аналитику. Потому что человек, который видит системную проблему и устраняет её сам, — это уже не саппорт. Это аналитик, который пока работает на второй линии.
Похожих историй у меня несколько. В одной — сотрудник вызвался разобраться в незнакомой 1С‑конфигурации, которую никто в команде не знал. Сейчас она знает её лучше вендоров, которые её ставили. В другой — специалист самостоятельно начала собирать mind‑карты по типам обращений, чтобы быстрее в них ориентироваться. На 1:1 спокойно показала. Через полгода — переход в тестирование 1С.
Все три истории объединяет одно: я не «развивал» этих людей. Я создал условия, в которых они проявились сами. Моя работа была в том, чтобы это заметить и дать следующий шаг.
Что получилось в цифрах
Конкретные результаты за период системной работы с командой:
— SLA реакции: 61% → 78,%.
— SLA решения: 80% → 87%.
— 10+ внутренних карьерных переходов: из первой и второй линий в тестирование, аналитику, методологию.
— Команда выросла с 20+ до 35+ человек.
— Снизилась зависимость от ключевых людей: ушли из понятия «это только Лёха знает».
Цифры по SLA важны, но они вторичны. Главное — что команда перестала быть аварийной службой и стала источником кадров для других направлений. Это меняет восприятие саппорта внутри компании. Когда руководство видит, что из поддержки регулярно вырастают аналитики и тестировщики, отношение к ней меняется. Бюджет на развитие — тоже.