С чего всё начиналось: MVP в 2022-м
Началось всё с концептуального названия: название IT2GO созвучно с coffee to go (кофе с собой) — это когда ты приходишь в любимую кофейню и просишь кофе в стаканчик с собой с удобной крышечкой, красивой картинкой, а тебе еще кричат: «Капучино на банановом с карамельным сиропом для Дмитрия готов!»
Вот мы делаем примерно то же самое, только в роли баристы тут выступает наша ИТ-школа, а вместо кофе, закрытого в стаканчик, мы готовим стажеров с тремя вкусами на выбор: аналитик, разработчик (тут есть еще варианты сиропов, стеков), тестировщик.
С чего всё началось? Простыми словами для маглов, в 2022 году нам понадобились ИТ-специалисты. А всё потому, что сразу несколько крупных проектов получили свое развитие и стали стремительно расти. Понадобились в большом количестве. В первую очередь ИТ-аналитики и разработчики. Рынок предлагал совсем кусачие хотелки, да и скиллы так называемых миддлов иногда не тянули даже до джуна.
Мы решили начать с классического подхода при обучении сотрудников:
● Описали профили потенциальных сотрудников, которые были нужны проектным командам (сколько ХП, маны, интеллекта должно хватить для решения типовых задач)
● Написали образовательные программы (в первую очередь для аналитиков и PHP-разработчиков)
● Разработали процедуры отбора (это было скрининг-интервью онлайн, ведь все работали на удаленке из дома после ковида, и вопросы в основном были про навыки и умения)
● Разработали и утвердили оценочные процедуры (как интерну стать джуном, как джуну пройти финальную аттестацию, сколько боссов пройти, кого победить, какие навыки отработать, какой стек изучить)
! Мы не брали с ребят денег за обучение, не берем и сейчас. Финансовая модель проекта строится на других показателях.
Более того, с первого дня стажировки интерны IT2GO получают зарплату. Белую (никаких конвертов)!
Что получили
Мы с нуля создали 2 программы: для ИТ-аналитиков и PHP-разработчиков.
Мы, конечно, решили, что наши сеньоры — это не только крутые разработчики, но и прирожденные преподаватели. Ну а куда им было деваться? Стажеры-то нужны!
Так и появилась альфа-версия нашей учебной программы, где тимлиды боевых проектов стали наставниками.
Первое время всё шло хорошо: интерны получали знания, а тимлиды — новый опыт (и, возможно, пару седых волос). В конце концов, это же стандартная практика всех стажерских программ, как мы считали.
Как стажеры попадали в проект и почему их судьба напоминала советское распределение
Мы брали ребят из одного канала (это была площадка HeadHunter).
С первого дня стажировки интерн числился в штате боевого подразделения ИТ-проекта, к которому был привязан (как в СССР при распределении — на завод после института).
Когда обучающий курс заканчивался, мы завершали обучение и переставали отслеживать дальнейшее развитие пришедших из ИТ-школы специалистов (или отсутствие развития…).
Мы получили «Ладу», хотя хотели «Феррари» (наши оправдания, почему так вышло)
Таким нехитрым способом мы обучили 35 стажеров, показатель COR (доходимости и конверсии из интерна в полноценного специалиста) был 86%, что выше среднего по отрасли и в целом неплохо и даже приемлемо для некоторых онлайн-школ, но вот конверсия разработчиков достигала всего 55%, а ведь мы вкладывались в каждого стажера!
Это было сомнительно, но ОК.
В процессе разбора полетов мы поняли:
1) Требования бизнеса и технологии меняются быстрее, чем мы успеваем писать под них программы (без быстрой кастомизации под актуальные стеки далеко не уедешь)
Хотите стажеров в закупочный ИТ-проект? Изучите его вдоль и поперек, измените курс таким образом, чтобы он включал в себя все детали проекта, образцы бэклога и технического задания, реальных боевых задач.
2) Внутренние эксперты в качестве преподавателей — не лучшая идея
Да, в идеальном мире тимлид или сеньор может стать еще и крутым преподавателем, но это как минимум лотерея. Есть сценарий, где он гениально объяснит, но есть и другой сценарий, где он начнет рассказывать про «это очевидно» и «просто посмотри в код». А еще есть такие нюансы, как методология обучения, групповая динамика.
На первом этапе нашего MVP ИТ-школы мы решили пойти по стандартному пути, но очень скоро поняли, что он не рабочий и не дает нам тех результатов, на которые мы рассчитывали.
В общем, мы поняли: быть экспертом и быть преподавателем — это два разных скилла. И если первый — это про «знать», то второй — это про «научить». А это, как оказалось, совсем другая история.
3) Мы перегрузили наших экспертов наставничеством
Совмещать наставничество и текущие рабочие задачи — это как сервер, на который внезапно положили еще один виртуальный хост. Вроде и должен справиться, но нагрузка распределяется неравномерно, и в итоге всё начинает дико тормозить.
Как мы поняли во время MVP, быть наставником — это не просто показать, где тут у вас баги и как их поправить, похлопать по плечу и сказать, что ты молодец.
Нашим наставникам было тяжело: они и так были загружены под завязку, а тут еще и стажеры, которых надо вести за руку. Время на всё они находили далеко не всегда.
4) Процедура отбора и трудоустройства должна быть доработана
Если в проекте в штате появляются 5 стажеров и 6 месяцев не приносят пользы, а только едят ФОТ, это не лучшим образом сказывается на финансовых показателях проекта.
А потом 4 из 5 стажеров решают, что им интереснее в другом смежном проекте, где кухня с шоколадными печеньками… Где будет ROI?
И самое главное, почему часть ребят приняла решение покинуть школу:
5) Отсутствие четких перспектив развития
У стажеров не было дорожной карты роста. Они не понимали, как развиваться, когда у наставников нет на них времени, ИТ-школа обучила и оставила их на произвол жестокого мира информационных технологий, а квесты становятся всё сложнее и сложнее, боссы всё злее и злее…
О том, как мы решили эти проблемы, выросли в 4 раза, достигли COR 95%, вышли на внешний рынок и разработали матрицы компетенций (гайды по развитию айтишников всех сортов и пород), читайте в продолжении этой статьи, которая скоро выйдет на нашем канале.
