Меня зовут Антон Лузин, я тимлид компании СИТЕК по направлению логистики. Хочу рассказать об опыте выстраивания системы наставничества в компании – от этапов формирования до результатов.
-
Каким образом небольшой компании быстро масштабировать свой отдел разработки в условиях острого дефицита кадров.
-
Как наладить систему наставничества у себя в отделе разработки и включить в этот процесс существующих разработчиков, которые работают в отделе.
-
С какими сложностями пришлось столкнуться, и как изменения повлияли на команду.
Почему мы пришли к системе наставничества
В процессе работы в компании было создано отдельное подразделение, сосредоточенное на монопродукте – 1С:WMS. Это связано с уникальной спецификой продукта, требующей определенных компетенций у персонала и разработки специализированной методологии внедрения проектов.
Поначалу подразделение было небольшим. Проекты в основной массе реализовывались собственными силами. По необходимости точечно привлекали разработчиков из смежных отделов. Быстрый рост направления привел сначала к периодическим, а позже к систематическим, перегрузкам и переработкам сотрудников.
Возникла потребность расширять штат. Из-за специфики продукта и дефицита специалистов нужной квалификации на рынке необходимо было не только нанять персонал, но и обучить. Я взял на себя роль наставника для новичков и лично курировал весь процесс.
«Болезни» при росте компании
У нас был план, и мы его придерживались: нанять, обучить, выпустить «в поле». Но возникло 3 проблемы.
Проблема 1: дефицит готовых кадров
HR-службе поставили план нанимать двух разработчиков в месяц. Выяснилось, что на рынке практически нет готовых специалистов, способных работать с продуктом «1С:WMS Логистика. Управление складом».
Решили брать специалистов «на вырост» – разработчиков уровня junior:
-
Снизили планку требований к входящим разработчикам;
-
Брали новых сотрудников на обучение;
-
Готовили квалифицированных специалистов.
Проблема 2: неоднородный поток соискателей
Случалось так, что в один месяц на обучение никто не приходил, в другой – одновременно приходили три человека. Неоднородный поток – это нагрузка для наставника, но упускать новичков мы не могли.
Поэтому сформировали команду наставников для обучения и адаптации стажеров.
Проблема 3: разработчики не хотят быть наставниками
К обучению новичков планировали привлекать разработчиков компании. Однако «леса рук» с их стороны не наблюдалось.
Возникли вопросы:
-
Как мотивировать сотрудника, чтобы он не уволился? Ведь мы, по сути, заставляем его исполнять роль наставника.
-
Как оценить качество такого обучения?
Проектирование системы наставничества
Нужно было выходить из сложившейся ситуации. Поэтому мы начали проектировать систему наставничества.
Процесс проходил в несколько этапов:
-
Поиск лидера. Так как я уже занимался наставничеством, эту роль я взял на себя.
-
Выявление возражений. При общении с разработчиками на тему «почему они так сопротивляются», у меня сформировался список, в котором я перечислил их возражения. На его основе проработал варианты решений.
-
Установка правил оплаты. Это одно из возражений. Решение: донести, что это оплачиваемый труд, а не волонтерство.
-
Составление плана обучения. Чтобы оперативно и качественно включать наставников в работу я скомпоновал имеющийся опыт наставничества, структурировал его и написал план обучения.
Система тестировалась. По необходимости вносились корректировки, чтобы она была максимально простой и удобной. Например – теоретический материал перевели в видеоформат.
Работа с возражениями потенциальных наставников
1. Не хочу
Решение: выяснить почему. Нужно понять, почему человек отказывается, какие есть сомнения, и как мы могли бы повлиять на его решение.
2. Нет времени
Решение: встроить наставничество в рабочий график. На наставничество закладывается определенное количество часов. Обучающая система разработана так, что роль наставника разработчик выполняет в течение рабочего дня. Это занимает у него не более часа в день, а то и полчаса.
3. Не хочу потерять в деньгах
Решение: оплатить труд. Никакого волонтерства. Наставничество – это инвестиционный проект. Труд должен быть и будет оплачен.
4. Проекты важнее
Решение: установить приоритет на усиление команды. Специалисты уже перегружены и, если ничего не делать, это приведет к катастрофе в ближайшем будущем. Поэтому выделим немного времени на обучение сейчас – нормализуем нагрузку завтра.
5. Не умею и не знаю как
Решение: стандартизировать план обучения. Ознакомившись с разработанным стандартным планом обучения, кандидат в наставники понимает, что система обучения несложная. От него требуется набор простых шагов:
-
планомерно выдавать материалы;
-
ставить тестовые задачи;
-
отвечать на вопросы, то есть консультировать.
Консультация включает в себя ответы на вопросы по теории, проверку выполненных задач и комментарии по ним.
Учебный план для стажеров
Учебный план включает в себя 5 теоретических блоков, состоящих из:
-
7 видеоуроков;
-
10 тестовых задач.
Стандартное время на прохождение курса – один месяц.
Мы не планировали полностью обучить работе с нашим продуктом за один месяц. Так в голове у человека была бы «каша», и, как итог, мы получили бы обратный эффект.
Задача месячного обучения:
-
показать основные блоки, модули;
-
объяснить, какие подсистемы используем;
-
рассказать какие существуют алгоритмы.
Курс помогает стажеру постепенно втягиваться в процесс через выполнение простых задач на «живых» базах. Сложные задачи новичкам не поручаются.
Если на прохождение потребовалось больше времени, то на промежуточных этапах обучения узнаем почему:
-
возможно, человек плохо усваивает, или ему что-то непонятно. В этом случае подключается наставник и дополнительно со стажером это прорабатывает.
-
возможно, человек медлителен. Нужно понять, что с этим можно сделать. Можно ли с этим работать? Или это для нас проблема?
Виды контроля на этапах обучения
Контроль входной
На собеседовании определяется:
-
каким багажом знаний обладает стажер;
-
какие пробелы у него в знаниях;
-
на что нужно обратить внимание, чтобы подобрать ему наставника.
Контроль промежуточный
В процессе изучения материала возникают вопросы, которые нужно разбирать, обсуждать. На контрольных точках мы собираем обратную связь от наставника и стажера, чтобы выявить проблемы и скорректировать процесс обучения.
Если возникают серьезные трудности, например, у наставника нет времени из-за перегрузки или по другой причине, мы принимаем меры, вплоть до замены наставника.
Контроль итоговый
По итогу курса, нужно зафиксировать результат. Мы запрашиваем:
-
обратную связь от наставника по стажеру;
-
проводим код-ревью;
-
проводим итоговую встречу.
Оцениваем, насколько успешно стажер прошел курс, будем ли мы работать дальше, если да, то как.
Если входной и итоговый контроль направлены на стажера, то промежуточный – на наставника.
Почему проектные команды не хотят брать новичков
Обучающий курс успешно пройден. Стажер подключается к работе. И тут возникает очередная сложность: проектная команда не хочет брать себе новичка. Она готова драться за ресурсы, ждать квалифицированного разработчика – делать что угодно, но не брать стажера.
Почему это происходит?
-
Новички влияют на бюджет проекта в негативную сторону.
У наших проектных команд в KPI вшито соблюдение рамок бюджета проекта. И получение в качестве разработчика новичка повышают риски срыва этого показателя.
-
Переделывать ошибки новичка долго и дорого.
К некоторым некачественно выполненным доработкам стажера приходится возвращаться несколько раз. И возможно даже не одному человеку, а целой команде. Ее приходится тестировать, проверять, дорабатывать и так далее.
-
Удовлетворенность заказчиков легче потерять, чем заработать.
Если ошибка не была обнаружена и просочилась до клиента, то под угрозой стоит удовлетворенность заказчика. Зарабатывать ее сложно. Это может привести к напряженному взаимодействию на проекте.
-
Новичкам нужно дольше и подробнее описывать техзадания.
Консультанты-аналитики, которые будут работать с молодым разработчиком, не любят давать более подробные инструкции, более четкое описание задач, тратить больше времени.
Как мотивировать проектные команды брать новеньких
Ситуация требует решения. Вот выходы, которые помогли нам решить вопрос.
-
Создание инвестиционного проекта «Обучение».
Анализ показал, что компании нужен инвестпроект – проект обучения. Создание системы, которая позволит получить квалифицированные кадры в нужном объеме.
При внедрении проекта установили правило: затраты на разработчика в испытательный срок относятся к инвестпроекту, а не к бюджету проекта.
Для проекта этот стажер становится бесплатными руками. Даже при дополнительных затратах времени и усилий консультантов-аналитиков на описание и контроль задач проект будет в плюсе. А разработчик при этом получит необходимый опыт и начнет войти в команду.
-
Прокачивать новичков в команде с опытными разработчиками.
Если команда со стажером-разработчиком уже работала, она охотнее берет его к себе. Но как заработать репутацию новичку, если его не берут на проект? Замкнутый круг. Поэтому, было принято решение – запускать новичка на проект в качестве помощника опытному разработчику.
-
Доработки новичка через ведущего разработчика проекта.
Разработчик распределяет задачи между новичками и контролирует их выполнение. На продакшн доработки попадают только через него. Он тратит дополнительное время на проверки, но с него снимается ряд задач. Он выполняет только функцию контроля.
Как DevRel может вдохновить наставников на подвиги
География расположения наших удаленных сотрудников широкая. Удаленная работа, распределение по разным командам, работа над проектами с разной спецификой – все это привело к низкому уровню взаимодействия между собой. Это препятствовало обмену опытом. В результате развитие специалистов могло стать однобоким.
На помощь пришел DevRel. Он:
-
Поднимает общий уровень компетенции при удаленной работе.
Благодаря DevRel происходит постоянный обмен опытом, повышается уровень компетенции. Встречи проходят раз в неделю по одному часу.
-
Привлекает к участию всех специалистов.
Принцип DevRel-общения заключается в участии разработчиков по очереди. То есть, одну неделю один, следующую неделю другой и так далее. На эти встречи сотрудники готовят теоретические темы, рассказывают о новых решениях на проектах, делятся опытом и проблемами. Люди видят опыт друг друга, узнают новое.
-
Прививает навык делиться знаниями.
Люди начинают привыкать делиться знаниями друг с другом. Когда нам потребуется наставник, то у кандидата на эту роль уже есть базовые навыки. У него достаточно легко получится подхватить этот процесс и включиться в работу наставника.
-
Формирует положительный образ наставников.
Помимо обмена технической информацией мы обмениваемся новостями, делимся успехами в обучающей программе, поздравляем завершивших испытательный срок и благодарим наставников. Это формирует положительный образ наставников.
-
Создает среду, где делиться знаниями – это норма.
Благодаря DevRel в компании формируется среда, в которой обмен знаниями становится нормой. Новички видят, как происходит обмен знаниями и вовлекаются в процесс, и это работает. Если, в следующий раз, когда нам опять будут нужны наставники, то никаких проблем в их поиске не будет.
Вместо итогов
Система наставничества рабочая и уже принесла нам результаты:
-
через нее выросли 15+ специалистов;
-
отдел разработки увеличился в 5 раз;
-
количество одновременно выполняемых проектов выросла в 7 раз;
Создание системы наставничества в компании – это не просто необходимость, это стратегический шаг к устойчивому развитию. В условиях кадрового дефицита и постоянных изменений на рынке, эффективное обучение и адаптация новых сотрудников становятся критически важными для успеха бизнеса.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
