Кадровый голод — вечная проблема IT-компаний. Все решают её по-своему: кто-то прокачивает HR-бренд и хантит кандидатов в LinkedIn, кто-то воспитывает своих разработчиков с нуля. Мы в Lodoss Team выбрали второй путь. Я разработал тренинг для начинающих специалистов и курирую обучение стажеров в компании. Что из этого получилось и зачем нам это надо, читайте в этой статье.
Зачем растить джунов
Наша цель — вырастить качественного джуниор-разработчика, такого человека, который по окончании курса мог бы самостоятельно работать над несложными задачами под надзором тимлида или ментора. За три месяца обучения он должен получить обширный опыт и понимание технологий, с которыми мы работаем, разобраться в процессах внутри компании.
Хороших специалистов в разработке мало, и часто те, кто приходят из других компаний, не соответствуют нашему портрету идеального программиста — приходится переучивать.
Зачастую в IT проще обучить сотрудников «с нуля», чем переучивать человека с опытом.
Люди, которые приходят из других компаний, уже привыкли к определённому типу ведения проектов, стилистике кода и отношениям в команде. Им сложнее принимать новые корпоративные ценности, они постоянно сравнивают подходы к работе в предыдущей компании и в нынешней. Таким сотрудникам, как правило, сложнее развиваться и расти дальше. Это сильно тормозит скорость адаптации человека в команде.
Если с самого начала специалист растёт в стенах компании, то он развивается с нами, проще воспринимает наши корпоративные ценности и становится лоялен к компании. Плюс он будет знаком со стеком технологий, с которым мы работаем.
Когда мы окончательно определились, что нам нужно организовать обучение стажеров на постоянной основе, передо мной встали два главных вопроса:
- Как и откуда привлекать стажеров?
- Как составить план обучения и организовать курсы?
Организация обучения
Я долго не мог выбрать формат обучения, но в итоге решил, что это должны быть полноценные обучающие курсы с теорией и практическими заданиями.
Первую проблему помогло решить то, что у нас есть Технологический институт ЮФУ. Его выпускники и студенты старших курсов — наша потенциальная аудитория, многие планируют развиваться и работать в IT, а наша компания может предоставить такую возможность.
На разработку плана обучения я потратил две недели. За это время я продумал, что и как мы будем изучать, создал регламент процесса. Дальше мы сделали лендинг с детальным описанием курсов и их преимуществ.
На лендинге также прописали качества, которые требуются претендентам на стажировку
Дальше рассказали о стажировке в соцсетях:
Эффект не заставил себя долго ждать — уже на следующий день на собеседование к нам записалось больше десяти человек.
На входе у нас было довольно жёсткое ограничение — мы не брали студентов младших курсов и людей, далёких от программирования. Я сделал порог вхождения на обучение достаточно серьёзным. У меня большая загруженность текущими рабочими проектами и я физически не смог бы уделять много времени, чтобы обучать основам программирования. Поэтому нашей целевой аудиторией были ребята, которые уже неплохо разбираются в разработке.
Наша идея была в том, чтобы выпускник курсов продолжил с нами работать после успешного окончания. Помимо этого, у нас есть фильтр по минимальным навыкам, которыми должны владеть стажеры. Это необходимо, чтобы они смогли освоить непростую и достаточно объёмную программу. Поэтому из 20 человек, которые пришли к нам в первом потоке, мы взяли всего двоих. Потом мы повторили набор и отобрали ещё троих кандидатов. Четыре из них сейчас проходят обучение, а одного стажера мы уже отчислили — не справился с высоким темпом занятий.
Проведение курсов стало проверкой и для меня самого. Я понял, сколько стажеров смогу одновременно курировать со своей загрузкой. Сейчас я объективно понимаю, что пять – это уже много. Если на старте я нормально справлялся, то потом стало тяжеловато. Это логично: чем дальше мы двигаемся по плану, тем сложнее становятся темы и тем большего времени требует контроль.
Чему учить
Я специально разработал курс так, чтобы не проводить обучение в группах. Каждый может в любое время подключиться к обучению. Это удобно, не надо контролировать всех одномоментно. У нас был опыт, когда мы пошли по схеме академического обучения: собрали группу, подготовили помещение для занятий и выделяли по нескольку часов в неделю на обучение. Разбирали теорию и выполняли практические задания. К сожалению, такой подход себя не оправдал — из десяти человек, прошедших обучение, у нас остался работать только один. Так себе конверсия.
Составляя план занятий, я исходил из тех знаний и компетенций, которые необходимы специалисту в нашей компании. Я сам разработчик и у меня есть понимание, какого уровня должен быть программист, какие задачи он должен уметь решать.
Темы подбирал таким образом, чтобы каждая последующая строилась на материале предыдущей, а знания, полученные на одном занятии, стажер мог использовать уже на следующем. Сначала просто собрал важные для нас вопросы в одну кучу: Git, JavaScript, CSS и HTML, современные фреймворки и работа с асинхронностью. Потом выстроил логическую последовательность от простого к сложному: от работы с консолью и git до фреймворков.
Здесь я учитывал картину, которую видел почти на каждом собеседовании. Соискатели, понимая, что требуются специалисты со знанием фреймворков, пытаются быстро изучить документацию и сделать пару туториалов. После этого они считают себя экспертами, хотя реальным опытом не обладают, а именно он нужен гораздо больше знаний синтаксиса и функций фреймворков.
Требования к стажерам, тематический план, схему и правила обучения я прописал в специальном регламенте.
Требования к стажерам из нашего регламента
Потом стал продумывать способ контроля за ходом обучения. На втором занятии стажеры проходят управление проектами. После изучения этой темы они самостоятельно заносят свои обучающие проекты в Trello, ведут диаграмму Ганта:
Мне остаётся проводить только трекинг прогресса учеников, смотреть что сделано на данный момент, а что нет. Это позволяет сильно экономить моё время. Ученики же учатся давать оценки проектам и управлять процессом обучения. Это очень важно, потому что любой программист должен уметь корректно оценивать свою работу.
К каждому тематическому блоку я разработал контрольные вопросы. Вот как выглядит учебный план с темами и заданиями:
Блоки можно изучать в любое удобное время, но обязательно последовательно и все разделы ребята сдают мне устно.
Стажеры не просто должны воспроизвести информацию, а защитить темы, показать, что владеют материалом. Защита выглядит следующим образом: в первую очередь я проверяю обязательную практическую часть и решение задач. Задаю вопросы по коду и даю свои рекомендации по его улучшению. После этого переходим к теории и здесь для меня важно общее понимание темы стажером. Каждому достаётся порция каверзных вопросов, когда нужно подумать и дать неочевидный на первый взгляд, но правильный ответ.
Кстати, если у стажера задолженность более трёх тем, то его отчисляют. Это дополнительная мотивация для обучения.
Как учить
Я не дипломированный преподаватель, мне сложно описать, какие подходы и методологии обучения лучше всего работают со стажерами-программистами.
Но одно могу сказать точно — нужно уметь делиться своим опытом и быть к ним отзывчивым. Нужно проявить свою экспертность и заслужить уважение. Никогда не врать, когда ты пытаешься что-то скрыть — ученикам это прекрасно видно.
Невозможно знать все, главное — не бояться в этом откровенно признаться. Когда мне задают вопрос на тему, в которой не очень хорошо ориентируюсь, я честно говорю, что не знаю ответа или что мне нужно проконсультироваться с коллегой-специалистом.
Продумывая схему обучения, я хотел создать мини-комьюнити стажеров и решил сделать это с помощью Slack. Ведь помимо получения профессиональных знаний, стажеры должны обучаться работе в команде, уметь находить ответы на вопросы и помогать своим коллегам. Все эти навыки необходимы и в повседневной работе программиста.
Очень часто разработчики — это типичные интроверты: для них общение с коллегами даётся очень тяжело. В реальных проектах бывают проблемы из-за плохой коммуникации в команде, поэтому мы решили прокачивать у ребят эти скилы на этапе тренировки.
Я создал в Slack два канала: News и Help. В первом транслируются новости, связанные с обучением. Второй я запланировал для неформального общения. В этом канале стажеры могут обсуждать рабочие вопросы и просить помощи у товарищей. Я наблюдаю, как ребята взаимодействуют друг с другом и оцениваю их навыки коммуникации, открытость и готовность помочь коллегам. Можно сказать, что здесь мы прокачиваем soft skills стажеров.
Заканчивается обучение итоговым заданием. Стажер получает небольшой приближенный к настоящему проект — примерно на две недели разработки. Тут все по-взрослому: нужно самостоятельно принимать решения, продумывать стратегию реализации, чтобы в итоге достигнуть целей проекта.
Уровень выпускных проектов оценивается комплексно. Я учитываю такие моменты, как время, потраченное на оценку и выполнение, и решения, которые применялись для достижения целей. Старший программист смотрит на качество кода, насколько он соответствует внутренним стандартам и правилам. После чего мы выставляем общую оценку.
Если стажер успешно закончил обучение и пошёл работать к нам, мы не бросаем его на произвол судьбы. За каждым новым человеком закрепляем ментора — сотрудника, к которому можно официально обращаться за помощью. Ментор по мере возможности будет проверять код стажера. Это при том, что мы ещё работаем по схеме кросс-ревью, то есть все в команде проверяют всех. Даже стажеры оценивают код своих старших коллег.
Сперва, скорее всего, новички будут работать как помощники на проектах. Их добавляют в команду, а тимлид или проджект-менеджер ставят конкретные задачи и следят за процессом. Пару раз в месяц IT-директор может поинтересоваться, как проходит адаптация новичка, может провести дополнительное тестирование нового сотрудника, если на это будут какие-то причины. После чего принимается решение — остаётся ли выпускник дальше работать в нашей компании.
Что мы получаем от программы корпоративного обучения
- Поиск и наём качественных новых кадров.
- Не нужно проводить подробное техническое собеседование и выяснять уровень кандидата. Все становится ясно в процессе обучения.
- Максимально сокращается время на адаптацию сотрудника в компании.
- После трудоустройства не нужно тщательно контролировать новичка.
- Формируется понимание, какие по масштабу и сложности проекты можно отдавать бывшему стажеру.
- Выпускник знаком со стеком всех технологий, с которыми работают в компании. Ему не нужно переучиваться.
- Получаем постоянный поток новых людей, в среднем 1?2 человека в месяц
В целом ресурсы, потраченные на обучение, окупаются. Если говорить о моём времени как времени руководителя, то пока я не сильно много его трачу. Когда мы поставим систему на поток и поймём, что у нас получилось — введём отдельного специалиста по корпоративному обучению.
От редакции
Курсы «Нетологии» по теме:
- очная программа «Руководитель digital-продукта»;
- онлайн-профессия «Профессия менеджер по продукту»;
- офлайн-интенсив «Аналитика для руководителей»;
- Конструктор стажировок.
Комментарии (12)
myxo
21.05.2018 17:09«они постоянно сравнивают подходы к работе в предыдущей компании и в нынешней»
Так это… — нормально, нет?
Проблемы тут только если работник уверен, что предыдущий подход лучше просто потому-что он был на пред. работе.repjov
21.05.2018 17:50Это не хорошо и не плохо, это просто мешает нормальному восприятию действительности и интеграции. Человеку всегда сложно и не очень приятно делать что-то, что отличается от его привычных действий.
Поэтому процесс интеграции затягивается, и даже может привести к плачевным результатам, когда человек будет в явном или не явном виде бороться с системой.
Например. Человек привык работать один или с небольшой командой, поэтому работает не в отдельной ветке и заливает в репозиторий большое количество изменений, и только после завершения работы над задачей. Хотя на новом месте принято работать по gitflow и заливать изменения несколько раз в день в определенную ветку, чтобы коллеги могли провести ревью кода. Когда его просят, он, конечно, соглашается, но делает это с неохотой, так как его заставляют делать “ненужную” работу. И он начинает обсуждать это на кухне, или в курилке, возможно если он сильная личность, он сможет пробить свои интересы, и тем самым ломает процессы.Kanut79
22.05.2018 09:15+1Если один человек способен «пробить» свою точку зрения в уже сложившейся команде и при сложившейся структуре/образе действий, то я бы задумался о том насколько этот образ действий действительно осмыслен и нет ли ситуации когда «святость» процесса стоит выше чем здравый смысл. Особенно если это способен сделать джуниор :)
И сам себя часто ловил что на том, что на вопрос «нафига вы так делаете» единственным ответом, который приходил в голову, был «потому что тут так принято». А это по моему не особо хороший ответ.
П.С. И по моему опыту адекватного человека несложно научить делать вещи по другому если это «по другому» имеет смысл. А если человек неадекватный, то его и с нуля обучать бесполезно.repjov
22.05.2018 11:10Когда я говорил «способен пробить», это был пример как раз не о джуниоре, а о человеке с опытом, может даже нанятой «звезде», который привык работать по-другому.
А что касается ответа «потому что тут так прнято», я обсолютно согласен что это не хороший ответ, поэтому мы не используем эту формулировку и всегда можем объяснить почему мы делаем так, а не иначе. У нас есть регламенты, которые описывают процессы.Kanut79
22.05.2018 11:16Когда я говорил «способен пробить», это был пример как раз не о джуниоре, а о человеке с опытом, может даже нанятой «звезде», который привык работать по-другому.
А людей с опытом вы тоже с нуля обучаете? Если нет, то тогда мне не совсем понятно зачем вообще был приведён этот пример :)
А что касается ответа «потому что тут так прнято», я обсолютно согласен что это не хороший ответ, поэтому мы не используем эту формулировку и всегда можем объяснить почему мы делаем так, а не иначе. У нас есть регламенты, которые описывают процессы.
И если при этом вы не можете обьяснить это так, что адекватный человек с этим соглашется и следует вашим правилам, то тут для меня есть три варианта:
— человек на самом деле не является адекватным.
— вы не умеете нормально обьяснять.
— ваши процессы на самом деле не так хороши как вам кажется.repjov
22.05.2018 11:46А людей с опытом вы тоже с нуля обучаете? Если нет, то тогда мне не совсем понятно зачем вообще был приведён этот пример :)
Нет, конечно. Я же объяснил, что человек приходя с опытом, у него есть уже выработанные привычки, которые не подходят под процессы новой организации, и человеку самому довольно сложно изменить свое привычное поведение.
Ну и проблемы бывают не только в процессах и технических вещах, есть еще софт скилы, которые в каждой организации разные и их тоже иногда нужно менять и подстаиваться.
Я просто хочу сказать, что человеку иногда проще принять то, что для него ново, чем переучиваться.
vldby
22.05.2018 09:29Наверное это странный вопрос, но как даёте знать стажёру об отчислении?
Некоторые компании, которые проводят стажировки, часто делают это жёстко (что портит мнение человека как о себе, так и о компании) либо игнорируют человека. Это мелочь, но довольно важная с точки зрения стажёра, мне кажется.
SiliconValleyHobo
22.05.2018 09:30С первых же строк я впал в ступор.
"Я разработал тренинг для начинающих специалистов и курирую обучение стажеров в компании" — CTO это последний человек в конторе после CEO, от которого могут и должны исходить такие слова…
То ли кто-то делает чужую работу, то ли работает не тем, кем должен.repjov
22.05.2018 11:36Не особо понимаю почему вы впали в ступор, я как человек отвечающий за техническое развитие компании, вижу определенные проблемы и принимаю решение наладить процесс обучения. Так как я прекрасно понимаю, какими знаниями должен обладать разработчик, я составил план, внедрил процесс, провожу обкатку, изменяю. После этого, мы введем отдельного человека на эту должность, что и было сказано в статье.
“В целом ресурсы, потраченные на обучение, окупаются. Если говорить о моём времени как времени руководителя, то пока я не сильно много его трачу. Когда мы поставим систему на поток и поймём, что у нас получилось — введём отдельного специалиста по корпоративному обучению.”
tamtakoe
Как вы решаете проблему, что ваш джун через год попросит зп в полтора-два раза больше или просто свалит от вас на бОльшие деньги?
shabelskiy
Подробности описаны здесь — goo.gl/JYKfmu.
shabelskiy
В компании мы используем многоуровневую систему испытаний для разработчиков. Программисты могут проходить испытания на повышение уровня по их запросу.
Время между попытками сдачи — от месяца до четырех в зависимости от того, на какой уровень претендует сотрудник. Финальным испытанием служит сдача технического экзамена комиссии минимум из трех человек, среди которых есть люди в чьих прямых интересах иметь сильную техническую команду.