С чего всё начиналось: 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%, вышли на внешний рынок и разработали матрицы компетенций (гайды по развитию айтишников всех сортов и пород), читайте в продолжении этой статьи, которая скоро выйдет на нашем канале.