Как мы выращиваем экспертов из техподдержки при текучести ключевых кадров
В двух компаниях мы столкнулись с одной и той же болью: архитектор работает в среднем 30 месяцев, а потом уходит. После этого решения принимали вслепую, ошибки повторялись, проекты тормозили. Доля эскалаций на L3 достигала 10%. Но главная проблема не в цифрах – знания уходили вместе с человеком.
Мы не пытались удержать архитекторов дольше. Это бессмысленно в условиях рынка, где их активно переманивают. Вместо этого мы поставили цель: создать систему, которая воспроизводит компетенции быстрее, чем они теряются.
Задачи:
- отобрать и подготовить кадровый резерв из специалистов первой линии;
- выстроить передачу знаний от внешних подрядчиков;
- превратить базу знаний в рабочий инструмент, а не архив.
Бизнес-триггером стало не ЧП, а осознание: мы не контролируем рынок труда, зато можем контролировать процессы передачи знаний. Риск потерять ключевого эксперта стал лучшим аргументом для HR и руководства.
Управленческая и операционная модель
Мы сразу отмели принудительное обучение. Нам нужны люди, которые сами хотят развиваться – их не надо контролировать. Мы разослали запрос: «Хочешь развиваться в администрировании?». Участвовали только те, кто поднял руку. Мы нацелили проект на подготовку архитекторов (в нашей структуре это L3 – проектирование, выбор технологий, стандарты).
Отбор проходил в два этапа.
Этап 1 – тестовое задание. Архитекторы сами разработали 10 задач на основе реальных случаев с первой линии. Сложность росла с каждым шагом. Никто не освобождал от текущей работы. Дедлайн – неделя. Так мы проверяли не только знания, но и умение расставлять приоритеты.
Примеры задач:
1. Написать скрипт для создания папки.
2. Скопировать файлы в неё.
3. Сделать общую сетевую папку (шару) с доступом на чтение для группы...
…
6. Напиши скрипт, который по IP-адресу компьютера подключает нужный сетевой принтер и делает его принтером по умолчанию. Драйверы принтеров находятся в сетевой папке на файловом сервере
Первые пять задач были итеративными (каждая зависела от предыдущей), остальные – самостоятельные. Требовалось выполнить минимум 40% (4 из 10). Главное – логика, а не количество. Мы просили присылать даже нерабочие варианты.
80% участников присылали прогресс каждый день, 5% тянули до последних дней и пропадали, 15% вылетали сами. Так мы проверяли не технику, а самоорганизацию.
Этап 2 – решение нестандартных инцидентов на L1. Кандидат пробовал выдвигать гипотезы и действовать. Удалось – сразу документируй и расскажи коллегам. Не вышло – чётко опиши шаги и передавай на L2.
В резерв попадали те, кто готов не только расти сам, но и тянуть за собой команду.
Оценка тестовых заданий
Архитекторы оценивали по простой шкале:
- +1 балл – решение работает в штатном и нештатном режимах;
- +0,5 балла – логика верна, реализация сырая;
- 0 баллов – нет понимания предметной области.
Случай из практики. Один претендент формально выполнил задание, но нашёл дыру в формулировке: сделал ровно то, что написано, а не то, что нужно. Архитектор зарубил задачу. Руководитель выступил арбитром: засчитали 0,5 балла и объяснили, что в реальной работе сервисный подход важнее буквоедства.
Отобранные кандидаты получали задачи L2. Распределение – по кругу: следующий запрос следующему в списке. Два архитектора-наставника давали обратную связь напрямую руководителю. Ежемесячные встречи один на один и контроль по индивидуальным планам развития. Через 3–6 месяцев начинали формировать ИПР для перехода на L3.
Из 10–15 претендентов в резерв попадало 2–4 человека. Реальный разброс – от 13% (2 из 15) до 40% (4 из 10), в зависимости от исходного уровня группы.
Передача компетенций от подрядчиков
Помимо внутреннего центра компетенций, мы задействовали и подрядчиков. Мы вписали в договоры обязательное условие: «Подрядчик проводит официальное обучение двух инженеров с последующей аттестацией в учебном центре. По итогу – практический экзамен: решение кейсов в тестовой среде. Аттестацию проводит независимый эксперт вендора и руководитель направления».
Подрядчики соглашались без восторга, но мы настояли.
Работа по пусконаладочным и внедренческим договорам шла по пятиэтапному циклу:
- Подрядчик настраивает систему.
- Наш инженер повторяет действия «руками» под присмотром.
- Инженер пишет пошаговую инструкцию с фото и скриншотами.
- Подрядчик рецензирует статью – указывает на неточности.
- Финальное ревью – руководитель и два дублёра из смежных направлений.
Пример: при модернизации ЦОД первый сервер настраивали вместе, второй – инженер под контролем, третий – самостоятельно, четвёртый и пятый – дублёры по инструкции. Так мы проверяли, насколько инструкция воспроизводима.
Через 3–4 таких цикла обращения к подрядчику прекращались.
База знаний
Для накопления знаний мы завели внутреннюю wiki с версионированием и фиксацией автора. Доступ на редактирование – по направлениям, чтение – для всех.
Критерий качества – воспроизводимость. Если дублёр может повторить настройку без вопросов – статья годится.
Сначала написание статей было обязательным условием, чтобы принять функционал на поддержку. Со временем это вошло в привычку: каждые три месяца инженеры проводили внутренние разборы актуальных проблем.
Пример структуры статьи: заголовок, описание, симптомы, анализ, конкретное решение с командами.
Результаты
Количественные показатели
- Выращено L2/L3: 4 L2 + 2 L3 в первой компании (2015–2016), 2 L2 + 4 L3 во второй (2020–2021).
- Обращения к подрядчику по поддержке снизились на 50% за два года.
- MTTR на L2: с 6 до 3 часов.
- 127 статей в базе знаний за три месяца, 1077 статей за два года.
Качественные и финансовые эффекты
- Текучесть архитекторов не снизилась, но перестала быть критичной (система имеет дублёров, инструкции, резерв).
- Текучесть на L1 упала с 27% до 7% – люди перестали искать рост на стороне.
- Общий коэффициент удержания ИТ-службы вырос с 85% до 90%, средний срок работы увеличился с 2,5 до 4 лет.
- Ни одного срыва сроков по проектам из-за ухода ключевого сотрудника.
Что пошло не так и сопротивления
Главный риск – сопротивление самих архитекторов. Часть видела в программе угрозу: «Мы растим себе конкурентов». Их KPI не включали обучение, нагрузка росла, мотивация падала.
Мы не давили. Поддерживали лояльных, а где не получалось – брали дублёра с рынка. Один такой middle-специалист за квартал вырос до архитектора.
Вторая сложность – конфликт между подразделениями. Когда L1-специалист уходил в резерв, его руководителю требовалась замена. Это создавало дополнительную текучку на первой линии.
Решение – фокус на общие цели компании и публичное признание руководителей, которые вырастили кадры для следующих уровней.
Были и неудачи. Некоторые кандидаты, пройдя отбор, через 1–2 месяца на L2 говорили: «Я не хочу решать сложные задачи, дайте мне чек-листы». Мы к этому готовились – поэтому мотивация была ключевым фильтром.
Заключение
Мы приняли как данность: архитекторы уходят. Вместо борьбы с этим фактом мы построили систему, которая воспроизводит их быстрее, чем они уходят.
Это не HR-проект и не «обучение для галочки». Это операционная устойчивость. Когда знания живут в процессах и документации, компания перестаёт бояться ухода любого сотрудника.
Сегодня мы распространяем этот подход на внедрение новых информационных систем: наши инженеры проходят обучение у интегратора, потом сами ведут пользователей, а подрядчик подключается только к нетиповым проблемам.
Главный посыл: если процесс нельзя остановить – возглавь его. Преемственность не ждёт идеальных условий. Она начинается с одного добровольца, одной задачи и одного решения.