Сергей Путятинский, вице-президент по операционной деятельности и ИТ ФГ БКС:

— Когда в твоем подчинении больше тысячи ИТ-специалистов, быстро понимаешь простую вещь: ручное управление не работает. Нельзя лично контролировать каждого разработчика, аналитика или администратора. Нельзя каждый раз вручную объяснять новичку, как устроены процессы, и надеяться, что опытный коллега как-нибудь сам передаст ему знания.

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

В 2024 году только в Москве потребность в ИТ-кадрах измерялась десятками тысяч специалистов. Это живые люди, которых нужно найти, нанять и ввести в должность. И если процесс ввода сломан, можно хоть трижды переплачивать рекрутерам — толку не будет, новичок просто утонет. Но большинство компаний наступает на одни и те же грабли.

Три стадии эволюции (и деградации) наставничества

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

Стадия 1. Ремесленная мастерская

В стартапе или небольшой команде все просто: новичок садится рядом с опытным разработчиком и насматривает код. Опытный работник — герой, потому что успевает и делать свою работу, и объяснять. Системы нет, результат зависит от личных качеств объясняющего и его настроения. Пока команда маленькая — это работает. Как только компания перешагивает порог в 200–300 человек, модель ломается. Наставники перегорают, знания остаются в головах, не переходя в процессы.

Стадия 2. Формальное закрепление

Компания вырастает, появляется HR-функция, которая резонно замечает: «Процесс надо формализовать». Опытного разработчика назначают наставником официально. Ему дают положенные 5–10 новичков, но… не снимают с него прежние продуктовые задачи. Он выгорает окончательно, новички учатся методом проб и ошибок, а наставничество превращается в бюрократическую отчетность. Инициатива есть, результата — ноль.

В одной компании, где я работал, мы насчитали три разных CRM-системы: для маркетинга, продаж и сервиса. Новичок в отделе продаж должен был учиться работать сразу во всех трех. Каждая — со своим интерфейсом, логикой, правилами. Время вхождения в должность выросло в два раза. Наставник тратил часы не на передачу экспертизы, а на объяснение того, где какая кнопка находится. Мы пытались лечить это наставничеством, а надо было — унификацией платформы.

Стадия 3. Бюрократизация

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

Платформенная модель

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

Суть проста: мы разделяем функции между платформой (центром компетенций) и продуктовыми командами (наставниками на местах). Ровно так же, как мы строим платформенное управление в ИТ, где центр отвечает за инфраструктуру и стандарты, а бизнес-команды — за гибкость решений.

Что делает платформа (HR + методологи + архитекторы процесса)

• Единые стандарты. Определяем, что такое «хорошо»: какие компетенции должны быть переданы, какие контрольные точки пройдены. Без этого каждый наставник будет учить по-своему, и на выходе мы получим зоопарк знаний.

• Обучающий контент. Вместо того чтобы каждому наставнику изобретать велосипед, платформа предоставляет библиотеку материалов: как давать обратную связь, как проводить код-ревью с новичком, как не выгорать.

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

Что остается наставникам

Автономия в применении инструментов. Они не пишут 50-страничных отчетов, просто фиксируют ключевые вехи в легкой форме. Они могут экспериментировать в рамках утвержденных стандартов. Именно такой подход — баланс между системностью и свободой — мы выстраивали, когда переходили от жесткой иерархии к гибким командам.

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

Почему это работает

Главная беда классического наставничества — когнитивная нагрузка на лучших специалистов. Они тратят время вместо творческой работы на бесконечные объяснения базовых вещей. Платформенная модель снимает эту проблему. Вместе с этим улучшаются и упрощаются и другие важные параметры.

• Снижение срока вхождения в должность. Когда у наставника есть готовая библиотека подходов, он не изобретает велосипед, а сразу учит новичка правильным паттернам. Срок вхождения в продуктивную работу сокращается.

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

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

Роль лидера

Переход к системному наставничеству требует перестройки роли руководителя. В иерархической модели менеджер — контролер. Он ставит задачи, проверяет отчеты, наказывает за срывы.

В платформенной модели задача лидера — проектировать среду. Я в своей практике всегда исходил из принципа: команда из квалифицированных и мотивированных людей сама выбирает правильные методы, если ей не мешать и дать правильные инструменты. Задачи руководителя перестраиваются и сводятся во многом к координации процессов.

• Убирать барьеры: бюрократические согласования, конфликты между наставником и линейным руководителем, устаревшие регламенты.

• Обеспечивать обмен знаниями. Создавать горизонтальные связи, проводить собрания наставников, поощрять открытость практик. В децентрализованной структуре велик риск, что каждый будет вариться в собственном соку. Я помню, как мы выстраивали коммуникацию между разработчиками в Твери и бизнес-заказчиками в Москве. Формально они были в одной компании, но говорили на разных языках. Можно было написать регламент взаимодействия на 50 страницах. Вместо этого мы посадили их в одну электричку. Буквально. Разработчики приехали в Москву, сели рядом с операционистами, увидели их глаза, услышали их боль. После этого код стал другим. Потому что появилось понимание, кому и зачем это нужно.

• Формировать культуру, где передача знаний — норма и признак профессионального роста. Как мы в свое время выстраивали открытость между ИТ и бизнесом, чтобы разработчики перестали быть просто исполнителями задач и начали помогать бизнесу генерировать идеи.

Метрики, которые не убивают процесс

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

1. Время выхода на полную продуктивность. Сколько времени нужно новому сотруднику, чтобы начать закрывать задачи, сопоставимые по сложности с опытными коллегами? Это главный KPI. Если он не сокращается — система не работает.

2. Удержание среди прошедших менторинг. Какая доля новичков остается в компании через год? Сравнение с теми, кто был предоставлен сам себе, дает жесткую цифру ROI.

3. Текучесть среди наставников. Если ваши ключевые эксперты отказываются от роли наставника или уходят — ищите проблему в системе. Здоровый процесс должен давать им энергию, а не высасывать ее. Однажды мы заметили, что наставники тратят по два часа в неделю на заполнение «Отчета о работе с новичком». Красивый excel-файл, 12 вкладок, цветовая кодировка. Мы спросили, а кто это вообще читает? Тишина. Тогда предложили эксперимент: на месяц отменить отчет совсем. С условием, что, если кому-то данные понадобятся, — вернем. Прошел месяц, второй, третий. Никто не пришел. Отчет похоронили. А время наставников вернули живой работе.

4. Доля внутренних назначений. Сколько ключевых позиций закрывается своими силами? Низкий процент — признак того, что наставничество не готовит кадровый резерв.

Вместо заключения

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

В условиях, когда экономике России требуются сотни тысяч ИТ-специалистов, а конкуренция за лучших только растет, компании, не умеющие системно выращивать кадры, просто проиграют. Потому что в турбулентном мире единственное устойчивое конкурентное преимущество — это способность быстро учиться и адаптироваться. И наставничество здесь — не нагрузка и не благотворительность. Это жесткий бизнес-процесс, от которого зависит выживание.