Меня спрашивают: «Чем ты занимаешься? Поддержка же — просто отвечать на вопросы».

Раньше бесило. Сейчас улыбаюсь. Человек никогда не руководил техподдержкой. Поддержка и техподдержка — разное. Поддержка — принял, ответил, закрыл. Техподдержка — лезешь в логи, диагностируешь баг, понимаешь архитектуру. Нужны «исследователи», а не «коммуникаторы».

Мои сотрудники не просто обрабатывают тикеты. Они решают операционные задачи, мониторят, пишут базу знаний, онбордят новичков. Это самообслуживающаяся команда. Построить такое — искусство. Одно дело нанять людей под инструкции. Другое — вырастить команду, которая сама их пишет, сама видит проблемы, сама предлагает решения.

Теперь сравним с разработкой. Разработкой управлять проще. Там спринты, бэклог, сторипоинты. Есть «сделано» и «не сделано». Система с обратной связью.

В техподдержке нет «сделано». Тикет закрыт — приходит новый. Бесконечный поток. Нельзя сказать: «Закончили, отдыхайте». Тикеты будут всегда. В три ночи. В воскресенье. В день релиза.

В разработке ты планируешь спринт. В техподдержке не знаешь, что случится через час. Может, ничего. Может, продакшен упадёт на сутки. Команда должна быть готова к обоим сценариям. Всегда.

Теперь про людей. Разработчики могут уйти в задачу на день и молчать. У них почти нет эмоциональной нагрузки.

Сотрудник техподдержки за смену пропускает десятки обращений. Каждое — злой, паникующий клиент. Надо сделать так, чтобы он остался. Даже если орёт. Даже если проблема не в вашей системе. Это эмоциональный труд. Огромный. Не виден в метриках. Но именно он определяет лояльность.

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

Это не «менеджмент по ответам на тикеты». Это управление бесконечным потоком, эмоциональным состоянием и саморазвивающейся системой.

Когда у тебя три сотрудника — управляешь вручную. Когда сорок — строишь систему без себя: эскалации, дежурства, смены, онбординг, метрики, регрессы, мониторинг, ротация. Всё это — перестраивая самолёт в воздухе.

Почему руководитель разработки не поймёт? У него другая реальность. У задачи есть конец. Можно закрыть спринт и выдохнуть. Сказать «я сделал». Он не разгребал двести тикетов, зная, что завтра будет триста. Не слушал, как клиент орёт в трубку. У него есть время думать.

У руководителя техподдержки времени нет. Всегда режим «сначала потушить, потом разбираться». Нет гарантии, что релиз не принесёт нагрузку х10.

И главное — он не понимает, каково управлять командой без чувства завершённости. Где нельзя сказать: «Мы закончили, молодцы». Потому что ничего не закончено. Никогда. Это другой тип нагрузки. Кто не был внутри — не представит. Поэтому когда руководитель разработки говорит: «Поддержка — просто тикеты разгребать», он не высокомерный. Он просто не знает.

Руководитель техподдержки — не тикет-менеджер. Он управляет потоком проблем, состоянием команды и ожиданиями бизнеса. Если работает хорошо — вы не замечаете. Тикеты закрываются, клиенты молчат, люди не увольняются. Как будто само.

Но это не само. Это невидимая работа. Требует тех же компетенций, что и управление разработкой. А где-то больше. В разработке можно спрятаться за спринт. В техподдержке ты всегда на передовой . Если в вашей компании руководитель техподдержки — «менеджер среднего звена», а руководитель разработки — «техлидер» с другой зарплатой — проблема у компании. Она не понимает, что продукт держится не только на коде.

Зачастую, продукт держится не на фичах — их скопируют. Он держится на том, что клиенту ответили в три ночи. Быстро. По-человечески. Решили проблему. И сделали так, чтобы не повторилась.

Это и есть техподдержка. Полноценная дисциплина. Управлять ей — чёртова работа. Не проще разработки. Просто другая. Пора это признавать.