Привет! Меня зовут Павел, я Head of Mobile в финансовом маркетплейсе Banki.ru. Сегодня я хочу остановиться не на mobile и нашей внутренней кухне направления, а рассказать про опыт создания программ стажировок на базе наших продуктовых команд. Поговорим о подходах, подводных камнях, первых результатах, да и вообще о целесообразности создания подобных программ.
Почему мы вообще решили вписаться в стажировку в IT
Идея попробовать стажерские программы в нашей компании витала давно. Но, как обычно бывает, то времени не хватает, то наставников нет, то проекты горят. В общем, всегда чего-то ждем и прокрастинируем.
Да и в целом мы были не уверены, сможем ли эффективно организовать процесс обучения, чтобы, с одной стороны, воспитать качественного начинающего инженера, а с другой — чтобы и для компании разработанный подход был целесообразным с экономической точки зрения. Мы все чаще задавали себе вопрос постановки запятой в предложении «Казнить нельзя помиловать» и никак не могли определиться.
Чем больше мы откладывали старт работ и чем сложнее становилось положение дел на рынке IТ по некоторым вакансиям, тем меньшее количество позиций успевал закрыть в спринт отдел рекрутмента. При этом мы понимали, что далеко не все задачи требуют грейда middle и выше. Много задач может заинтересовать начинающих инженеров и позволит развивать у них базовые компетенции.
К тому же сама идея создания стажерских программ не находила отклика во многих командах с формулировками: «у нас и так работы полно», «нам нужны опытные инженеры, наши задачи слишком сложные», «у нас нет менторов», «это отнимает много времени» и так далее.
Нам нужен был первый положительный пример, который смог бы стать локомотивом для развития остальных программ. Недолго думая, мы решили выплатить стажировку на каком-нибудь одном направлении и посмотреть на первые результаты.
Выбрали мы QA: с одной стороны, мы сразу нашли коллег, готовых заняться активностью, а с другой — видели огромную потребность в manual-QA инженерах. Мы сразу примерно представляли, какими базовыми навыками должен обладать инженер на этой позиции, чтобы с успехом справляться со своими должностными обязанностями.
Как выбирали подход и почему внезапно стажировку в Banki.ru изобрели инженеры
Изначально мы определились с подходом, длительностью, этапами, структурой и бюджетом. Первая мысль была создать программу стажировки вместе с HR-департаментом и разрабатывать наш MVP сразу с прицелом на масштабирование на всю компанию в будущем. Но, скажу честно, мы долго не могли договориться и сдвинуться с мертвой точки: представления о том, как должна выглядеть программа, у нас сильно отличались, как и сам подход к работе в целом.
Мы опасались, что при таком подходе MVP в этом полугодии мы не запустим, а нам, как обычно, нужно было «сегодня, а еще лучше — вчера». Да и в целом — почему бы не попробовать перенести наши инженерные навыки и продуктовый подход на что-то новое, напрямую не связанное с разработкой?
Мы проанализировали более чем 30 компаний, пообщались с реальными участниками процесса, начиная от стажеров и наставников, заканчивая руководителями подразделений и HR-департаментов. В целом не сказать, что результаты нас сильно удивили, но все же мы получили большой срез информации и смогли выделить несколько общих подходов.
Работа на бренд
Школы при компаниях: лекции, домашние работы, сессии — и вот это вот все. Такая стратегия распространена в основном в крупных компаниях. В этом случае цель — не только закрыть ресурсный план и создать кадровый резерв на будущее, но и развивать внешний бренд компании.
При этом фокус часто смещен именно в сторону бренда и внешнего пиара. Что удивило, далеко не все компании ведут обширную аналитику, да вообще мало смотрят на эффективность программ. На вопрос «Какой процент стажеров у вас выходят в штат и насколько долго задерживаются в компании?» я слышал примерно один ответ: «Ну, наверное, процентов 10–20, в штат берем, только если в этот момент есть бизнес-позиция и наше большое желание».
При этом коллеги всегда знали общие цифры по приему в школу и количество университетов и профильных курсов, с которыми сотрудничают. Но кое-что отличало все программы этой группы — системность. Коллеги сначала фокусируются на базовых инженерных практиках, постепенно переходя к более профильным знаниям, специфичным для специальности.
Кадровый резерв через проектную работу
Подход свойственен компаниям, чья экономическая модель направлена на аутстаф и проектную работу. Программа нацелена на прикладные практические знания, которые позволят стажеру пройти собеседование на проект и получить заветную работу в штате компании.
Компания Банки.ру фокусируется на разработке собственных IТ-продуктов и финтехе, и не все идеи программ применимы. Для нас же была интересна структура самого курса и подхода в целом. Для таких компаний характерно, что процесс стажировки поставлен на поток, стажеров берут много, обучают достаточно быстро и шаблонно. Изначально сотрудники на стажировке участвуют во внутренних проектах компании и только после прохождения собеседования на проект заказчика попадают в штат.
У такого подхода есть минусы. Компании не всегда заинтересованы в комплексном и долгосрочном развитии инженеров, могут переводить их между проектами в погоне за выручкой, не всегда уделяя достаточное внимание навыкам начинающего инженера. При этом компании считают как деньги и эффективность программы, так и ресурсы. Они не боятся расставаться со стажерами, у которых нет необходимых технических навыков, стараются анализировать программы и всячески оптимизировать их.
Кадровый резерв и обучение через «боевые задачи»
В этом случае свойственен серьезный и долгий процесс найма, который в целом не сильно отличается от найма уже опытного инженера: высокая входная планка по знаниям плюс длительная процедура подбора и большое количество собеседований. При этом часто отсутствует стажерская программа в классическом понимании, а обучение в большей степени проходит на реальных «боевых задачах». С первых дней на стажера смотрят как на зрелого инженера и будущего коллегу, который сам отвечает за свое развитие.
На чем остановились Banki.ru
Мы сразу решили отбросить на первом этапе подход «Стажировка как бренд». Это действительно важная история, и мы, наверное, к ней вернемся в скором времени, но на этапе MVP мы решили сфокусироваться на другой цели: создание кадрового резерва и ускорение найма.
Однако сама системность, свойственная таким программам, структурность и наличие контрольных этапов в течение всего периода нам понравились. С другой стороны, подход без программы, с тяжелым наймом тоже не про нас. В тот момент у рекрутмента существовал большой запрос на найм: коллеги с трудом закрывали планы и без дополнительной нагрузки по стажерам. К тому же без системности и структуры подход достаточно тяжело масштабируется: каждый кейс нужно рассматривать индивидуально, а сама работа начинает сильно зависеть от личностей стажера и ментора.
И тут мы подумали: а почему бы не попытаться убить даже не двух, а трех или четырех зайцев сразу, постаравшись взять лучшие практики из всех подходов, приправив их специями из нашей внутренней кухни?
Подход Banki.ru
А получилась у нас на старте рабочая группа, которая начала прорабатывать подход к стажировке в Banki.ru. С общим подходом мы определились достаточно быстро. Тут, не буду скрывать, мы воспользовались «академической» идеей: «в программе должны быть последовательные этапы с понятными и фиксированными сроками, инструментами контроля и правилами перехода между ними». Плюс мы отталкивались от основной цели стажерской программы — создание кадрового резерва для будущего развития и расширения IТ-подразделения.
На мой взгляд, мы выбрали предельно простой и в то же время подходящий практически под любое направление подход с тремя последовательными этапами. В упрощенном виде общая схема выглядит примерно так:
Basic — этап направлен как раз на инженерную базу в программе.
Advanced — подготовительно-практический этап. Направлен на подготовку к выходу в команду. Условно «боевые задачи» в обучающих репозиториях, сделанных на основе «боевых задач».
Team — этап работы в команде, production задачи, «боевой опыт» и стажер как полноценный коллега.
В дополнение к этапам стажировки мы добавили логичный этап подбора, о составе которого расскажу чуть позже, а также финальную выпускную работу. Мы сразу же зафиксировали, что программы не статичны, должны развиваться, учиться на ошибках и меняться. Для этого по каждому направлению была выделена роль куратора стажерской программы, в рамках которой заинтересованные инженеры лидировали процесс разработки и развития программ.
Подход есть, но теперь нужно сформировать прозрачный для наставников и руководителей способ перехода между уровнями и тайминги этапов:
Основная цель всех стажировок в компании Banki.ru — это создать кадровый резерв. Нам хотелось как можно скорее научить ценностям, исходя из этого мы выбрали как наихудший бенчмарк по этапам 2–2–2 месяца. Сразу отметили для всех наставников в памятке, что если стажер делает успехи и осваивает материал быстрее, нужно переводить его на следующий этап и выводить в команду. Как итог, в среднем за один год программы мы видим примерно такие цифры: 1,5–1,5–3 месяца. Мы довольны этим результатом.
Чтобы стажер сразу понимал, какие знания ему необходимы для перехода, мы решили внедрить матрицу компетенций. Это матрица необходимых навыков сотрудника. Для каждого направления матрица компетенций своя, и за ее составление и актуализацию отвечают инженеры этого профиля. Ниже представлена матрица компетенций по направлению frontend-разработки.
Пример небольшой части матрицы компетенций Frontend-стажера
Немного про этап найма
Как и на всех предыдущих этапах, мы хотели рационально подойти к найму стажеров. За свою карьеру в IТ я не раз слышал отзывы разработчиков, как временами они утопают в собеседованиях, сколько времени съедает найм и как выматывают интервью. Поэтому мы разделили процесс на два этапа — HR и технический. Это ограждает штатных инженеров от бесконечных собеседований стажеров.
Подобный подход всем знаком, но мы решили включить в HR-этап небольшой технический блок с простой скоринг-моделью. Исходя из матрицы компетенций мы составили список вопросов с однозначными ответами и количеством баллов, которые начисляются кандидату в случае правильного ответа. Рекрутер прогоняет этот опросник на начальном этапе интервью, сам же его сразу проверяет и быстро выдает финальный скоринг-балл по каждому кандидату.
Изначально мы хотели сразу зафиксировать проходной балл по каждому направлению, чтобы приглашать на техническое интервью только тех кандидатов, кто наберет выше границы. Практически сразу заменили на эмпирический подход: смотреть на результаты 5–10 интервью стажеров и звать на технику лучших.
Как ни странно, мы еще ни разу не встречали, чтобы оценки у всех кандидатов сходились. Всегда есть небольшая группа лучших, у остальных баллы на порядок меньше. Вот именно группа лидеров и есть наши потенциальные стажеры, которых мы с радостью зовем на этап техники.
Да, система не идеальна. Мы пропускаем кандидатов, которые по каким-либо причинам могли переволноваться и провалить первый этап. Или вопросы для скоринг-балла подобраны не лучшим образом, и рекрутер где-то не точно идентифицировал ответ стажера. Но мы сознательно приняли это ограничение, ведь главное — сократить общее время, затраченное на подбор. Пропустить одного-двух перспективных кандидатов, как показала практика, не так критично.
В дополнение по каждому направлению мы проводим тест и зовем на технический этап нескольких кандидатов с меньшими баллами, чтобы проверить, как наша скоринг-модель работает в действительности. Скоринг работает: практически 100% таких кандидатов показали себя на порядок хуже остальной группы.
На техническом этапе потенциальный стажер 30–40 минут разговаривает с будущим наставником, руководителем гильдии или куратором стажерской программы. Они задают вопросы по матрице компетенций и опыту стажера.
Для чего стажерам и нам выпускная работа
Некоторым может показаться, что мы тут напридумывали университет с формализмом. Но цели выпускной работы несколько другие в отличие от университетских:
Ввести ограничения, но при этом дать инженеру свободу выбора. Работа должна быть полезна и применима в компании.
IТ-добрые дела. В прошлом году мы решили помогать IТ-проектами коллегам из других подразделений и выполнять их при участии стажеров.
Проверить самостоятельность и командную работу стажеров. Над выпускной работой трудятся целые команды стажеров, но под пристальным наблюдением наставников.
Постараться таким образом заинтересовать и замотивировать не только стажеров, но и наших инженеров на IТ-свершения в рамках добрых дел.
На наш взгляд, получилось неплохо! Темы выпускных работ действительно разные, но при этом определенно полезные. От практических работ в рамках продуктовых команд: доработка дизайн-системы и ui-guide, тест-кейсы для автоматизации, unit и ui тесты, Yandex Load Testing (мы, кстати, уже успешно его применяем), до IТ-добрых дел — лендинги, магазин мерча и внутренний Тelegram-бот.
Что появилось нового?
Со временем к нам стало прилетать много вопросов: как переходить между уровнями и как понять, что стажер готов к этому переходу. Тут на помощь нам пришел кворум инженеров, которые совместно оценивают компетентность стажера и решают, пропускать его на следующий этап или нет. Мы подсмотрели у коллег по цеху слово «хурал» и в шутку стали между собой называть эти встречи так. В итоге название встреч так и закрепилось, и мы до сих пор его используем. Мы выделили два типа хуралов: level и final.
Level-хурал
Это встреча, организованная для контроля прогресса стажера при переходе между уровнями. На нем собираются наставники, руководитель гильдии и куратор направления. Встреча проходит в формате беседы, где стажер рассказывает, что изучил, какие были сложности и успехи. Участники задают дополнительные вопросы по матрице компетенций стажера.
Цель — не устроить полноценный экзамен и завалить стажера вопросами. На такой встрече нам важно понять, что он действительно усвоил то, о чем говорит, имеет представление по основным компетенциям и готов к следующему вызову.
Final-хурал
Это регулярная встреча по средам, на которой проходит финальная защита стажировки и выпускной работы. На встрече обязательно присутствует руководитель направления по профилю стажера, HR BP, наставник и приглашенные гости, которых коллеги из HR собирают исходя из профиля защищающегося.
Ко встрече стажер готовится: ретроспективно смотрит на пройденный путь и составляет презентацию с тезисами по следующим аспектам:
Почему он выбрал именно это направление?
Какие темы он изучил в рамках программы?
Какие он решал практические задачи в рамках тестовых заданий и в рамках команды?
Какие задачи ему показались наиболее интересными? Какие — менее? Почему?
Тема выпускной работы. Почему решил остановиться именно на этой теме? Демо работы.
Какие у него были ожидания по программе? Как они воплотились в реальность?
Какие у него дальнейшие планы?
И как показала практика, на защиту приходят уже действительно состоявшиеся начинающие инженеры, которые понимают, о чем говорят, и с удовольствием отвечают на вопросы. В общем, могу сказать (как минимум за себя), я правда был приятно удивлен уровнем некоторых выпускных работ бывших стажеров – уже текущих наших коллег.
Почему мы дополнительно обучаем наставников
Изначально на этапе MVP мы слукавили и решили закрыть глаза на то, что все мы разные, и далеко не всегда достаточно прочитать памятку в wiki и понять, что вообще требуется от наставника и как себя правильно вести в некоторых ситуациях при взаимодействии со стажером. К тому же некоторые стажеры оказались, мягко говоря, не робкого десятка и стали проверять наших наставников на прочность. Поэтому не так давно мы запустили обучение для наших наставников. Требования, как всегда, максимально простые и понятные:
Знать подход и программу. На первом этапе мы делимся с будущим наставником подходом, а на следующем, наоборот, задаем вопросы.
Уметь отрабатывать сложные кейсы. Для этого мы разыгрываем их по ролям, обсуждаем результаты и возможные варианты решения. Теперь мы всегда дополняем и обновляем список реальными кейсами. Уже определили наиболее сложные и полезные для наставников.
Помимо систематизации знаний это еще и повышает вовлеченность наставников. Передача опыта способствует раскрытию лидерских качеств, помогает инженерам прожить вместе со стажером цикл его развития, со стороны посмотреть на этапы зрелости инженера. Наставники учатся вместе со стажером. Эффективная передача опыта — это мощная управленческая компетенция, которая может стать первым шагом к роли тимлида или руководителя направления.
Каких результатов мы достигли и каковы наши дальнейшие планы
С начала запуска программы прошло более года, и мы с уверенностью можем сказать стажерской программе: «Казнить нельзя, помиловать». Сейчас мы полностью удовлетворяем свои потребности в junior инженерах, 20+ будущих инженеров проходят стажировку по множеству профилей: iOS, Android, PHP, QA, системная аналитика, DevOps , support engineer 2 line, frontend, data, java, около 20 инженеров уже успешно ее завершили и попали в штат нашей компании. Но нужно все-таки добавить несколько небольших ложек дегтя:
Разные профили требуют совершенно разный базовый уровень багажа знаний. Очевидно, что QA Manual через 1–1,5 месяца уже постепенно начинает посматривать на production, в то время как Java-инженер только через 3–4 месяца знакомится с production. А следовательно, цена ошибки подбора некоторых профилей гораздо выше.
Не все стажеры соответствуют нашим ожиданиям на этапе завершения программы. У нас уже были кейсы, когда на финальном хурале мы принимали решение не брать стажера в штат.
Проработанность программ сильно зависит от вовлеченности куратора и всей рабочей группы. Нужно признать, что пока не все программы одного качества. Неудивительно, что по таким направлениям компетенции стажеров на выходе могут сильно различаться и далеко не всегда в лучшую сторону.
Как показала практика, не все молодые инженеры сразу могут определиться со своим будущим направлением. Временами через 4–5 месяцев к наставнику мог поступить запрос от текущего стажера на ротацию на совершенно другой профиль. Это не соответствует нашим ожиданиям от стажерской программы и снижает ее эффективность
Пока мы планируем оставить численность стажеров на том же уровне и сфокусироваться на развитии программ вглубь и на запуске новых направлений. В то же время программы стажировки открывают нам большой потенциал, чтобы их применять в обучении текущих сотрудников и во внутренних ротациях сотрудников. Мы уже успели опробовать подход в следующих треках: support 2 line -> QA, helpDesk-> java, support 2 line -> android. Мы довольны первыми результатами и не собираемся останавливаться на достигнутом!
