Антон Репьев, технический директор Lodoss Team, специально для блога Нетологии поделился кейсом, как внутри компании организовать программу стажировки и вырастить с нуля молодых специалистов.

Кадровый голод — вечная проблема IT-компаний. Все решают её по-своему: кто-то прокачивает HR-бренд и хантит кандидатов в LinkedIn, кто-то воспитывает своих разработчиков с нуля. Мы в Lodoss Team выбрали второй путь. Я разработал тренинг для начинающих специалистов и курирую обучение стажеров в компании. Что из этого получилось и зачем нам это надо, читайте в этой статье.

Зачем растить джунов


Наша цель — вырастить качественного джуниор-разработчика, такого человека, который по окончании курса мог бы самостоятельно работать над несложными задачами под надзором тимлида или ментора. За три месяца обучения он должен получить обширный опыт и понимание технологий, с которыми мы работаем, разобраться в процессах внутри компании.

Хороших специалистов в разработке мало, и часто те, кто приходят из других компаний, не соответствуют нашему портрету идеального программиста — приходится переучивать.

Зачастую в IT проще обучить сотрудников «с нуля», чем переучивать человека с опытом.

Люди, которые приходят из других компаний, уже привыкли к определённому типу ведения проектов, стилистике кода и отношениям в команде. Им сложнее принимать новые корпоративные ценности, они постоянно сравнивают подходы к работе в предыдущей компании и в нынешней. Таким сотрудникам, как правило, сложнее развиваться и расти дальше. Это сильно тормозит скорость адаптации человека в команде.

Если с самого начала специалист растёт в стенах компании, то он развивается с нами, проще воспринимает наши корпоративные ценности и становится лоялен к компании. Плюс он будет знаком со стеком технологий, с которым мы работаем.

Когда мы окончательно определились, что нам нужно организовать обучение стажеров на постоянной основе, передо мной встали два главных вопроса:

  • Как и откуда привлекать стажеров?
  • Как составить план обучения и организовать курсы?

Организация обучения


Я долго не мог выбрать формат обучения, но в итоге решил, что это должны быть полноценные обучающие курсы с теорией и практическими заданиями.

Первую проблему помогло решить то, что у нас есть Технологический институт ЮФУ. Его выпускники и студенты старших курсов — наша потенциальная аудитория, многие планируют развиваться и работать в IT, а наша компания может предоставить такую возможность.

На разработку плана обучения я потратил две недели. За это время я продумал, что и как мы будем изучать, создал регламент процесса. Дальше мы сделали лендинг с детальным описанием курсов и их преимуществ.

image
На лендинге также прописали качества, которые требуются претендентам на стажировку

Дальше рассказали о стажировке в соцсетях:

image

Эффект не заставил себя долго ждать — уже на следующий день на собеседование к нам записалось больше десяти человек.

На входе у нас было довольно жёсткое ограничение — мы не брали студентов младших курсов и людей, далёких от программирования. Я сделал порог вхождения на обучение достаточно серьёзным. У меня большая загруженность текущими рабочими проектами и я физически не смог бы уделять много времени, чтобы обучать основам программирования. Поэтому нашей целевой аудиторией были ребята, которые уже неплохо разбираются в разработке.

Наша идея была в том, чтобы выпускник курсов продолжил с нами работать после успешного окончания. Помимо этого, у нас есть фильтр по минимальным навыкам, которыми должны владеть стажеры. Это необходимо, чтобы они смогли освоить непростую и достаточно объёмную программу. Поэтому из 20 человек, которые пришли к нам в первом потоке, мы взяли всего двоих. Потом мы повторили набор и отобрали ещё троих кандидатов. Четыре из них сейчас проходят обучение, а одного стажера мы уже отчислили — не справился с высоким темпом занятий.

Проведение курсов стало проверкой и для меня самого. Я понял, сколько стажеров смогу одновременно курировать со своей загрузкой. Сейчас я объективно понимаю, что пять – это уже много. Если на старте я нормально справлялся, то потом стало тяжеловато. Это логично: чем дальше мы двигаемся по плану, тем сложнее становятся темы и тем большего времени требует контроль.

Чему учить


Я специально разработал курс так, чтобы не проводить обучение в группах. Каждый может в любое время подключиться к обучению. Это удобно, не надо контролировать всех одномоментно. У нас был опыт, когда мы пошли по схеме академического обучения: собрали группу, подготовили помещение для занятий и выделяли по нескольку часов в неделю на обучение. Разбирали теорию и выполняли практические задания. К сожалению, такой подход себя не оправдал — из десяти человек, прошедших обучение, у нас остался работать только один. Так себе конверсия.

Составляя план занятий, я исходил из тех знаний и компетенций, которые необходимы специалисту в нашей компании. Я сам разработчик и у меня есть понимание, какого уровня должен быть программист, какие задачи он должен уметь решать.

Темы подбирал таким образом, чтобы каждая последующая строилась на материале предыдущей, а знания, полученные на одном занятии, стажер мог использовать уже на следующем. Сначала просто собрал важные для нас вопросы в одну кучу: Git, JavaScript, CSS и HTML, современные фреймворки и работа с асинхронностью. Потом выстроил логическую последовательность от простого к сложному: от работы с консолью и git до фреймворков.

Здесь я учитывал картину, которую видел почти на каждом собеседовании. Соискатели, понимая, что требуются специалисты со знанием фреймворков, пытаются быстро изучить документацию и сделать пару туториалов. После этого они считают себя экспертами, хотя реальным опытом не обладают, а именно он нужен гораздо больше знаний синтаксиса и функций фреймворков.

Требования к стажерам, тематический план, схему и правила обучения я прописал в специальном регламенте.
image
Требования к стажерам из нашего регламента

Потом стал продумывать способ контроля за ходом обучения. На втором занятии стажеры проходят управление проектами. После изучения этой темы они самостоятельно заносят свои обучающие проекты в Trello, ведут диаграмму Ганта:

image

Мне остаётся проводить только трекинг прогресса учеников, смотреть что сделано на данный момент, а что нет. Это позволяет сильно экономить моё время. Ученики же учатся давать оценки проектам и управлять процессом обучения. Это очень важно, потому что любой программист должен уметь корректно оценивать свою работу.

К каждому тематическому блоку я разработал контрольные вопросы. Вот как выглядит учебный план с темами и заданиями:



Блоки можно изучать в любое удобное время, но обязательно последовательно и все разделы ребята сдают мне устно.

Стажеры не просто должны воспроизвести информацию, а защитить темы, показать, что владеют материалом. Защита выглядит следующим образом: в первую очередь я проверяю обязательную практическую часть и решение задач. Задаю вопросы по коду и даю свои рекомендации по его улучшению. После этого переходим к теории и здесь для меня важно общее понимание темы стажером. Каждому достаётся порция каверзных вопросов, когда нужно подумать и дать неочевидный на первый взгляд, но правильный ответ.  

Кстати, если у стажера задолженность более трёх тем, то его отчисляют. Это дополнительная мотивация для обучения.  

Как учить


Я не дипломированный преподаватель, мне сложно описать, какие подходы и методологии обучения лучше всего работают со стажерами-программистами.
Но одно могу сказать точно — нужно уметь делиться своим опытом и быть к ним отзывчивым. Нужно проявить свою экспертность и заслужить уважение. Никогда не врать, когда ты пытаешься что-то скрыть — ученикам это прекрасно видно.

Невозможно знать все, главное — не бояться в этом откровенно признаться. Когда мне задают вопрос на тему, в которой не очень хорошо ориентируюсь, я честно говорю, что не знаю ответа или что мне нужно проконсультироваться с коллегой-специалистом.

Продумывая схему обучения, я хотел создать мини-комьюнити стажеров и решил сделать это с помощью Slack. Ведь помимо получения профессиональных знаний, стажеры должны обучаться работе в команде, уметь находить ответы на вопросы и помогать своим коллегам. Все эти навыки необходимы и в повседневной работе программиста.

Очень часто разработчики — это типичные интроверты: для них общение с коллегами даётся очень тяжело. В реальных проектах бывают проблемы из-за плохой коммуникации в команде, поэтому мы решили прокачивать у ребят эти скилы на этапе тренировки.

Я создал в Slack два канала: News и Help. В первом транслируются новости, связанные с обучением. Второй я запланировал для неформального общения. В этом канале стажеры могут обсуждать рабочие вопросы и просить помощи у товарищей. Я наблюдаю, как ребята взаимодействуют друг с другом и оцениваю их навыки коммуникации, открытость и готовность помочь коллегам. Можно сказать, что здесь мы прокачиваем soft skills стажеров.  

Заканчивается обучение итоговым заданием. Стажер получает небольшой приближенный к настоящему проект — примерно на две недели разработки. Тут все по-взрослому: нужно самостоятельно принимать решения, продумывать стратегию реализации, чтобы в итоге достигнуть целей проекта.

Уровень выпускных проектов оценивается комплексно. Я учитываю такие моменты, как время, потраченное на оценку и выполнение, и решения, которые применялись для достижения целей. Старший программист смотрит на качество кода, насколько он соответствует внутренним стандартам и правилам. После чего мы выставляем общую оценку.

Если стажер успешно закончил обучение и пошёл работать к нам, мы не бросаем его на произвол судьбы. За каждым новым человеком закрепляем ментора — сотрудника, к которому можно официально обращаться за помощью. Ментор по мере возможности будет проверять код стажера. Это при том, что мы ещё работаем по схеме кросс-ревью, то есть все в команде проверяют всех. Даже стажеры оценивают код своих старших коллег.

Сперва, скорее всего, новички будут работать как помощники на проектах. Их добавляют в команду, а тимлид или проджект-менеджер ставят конкретные задачи и следят за процессом. Пару раз в месяц IT-директор может поинтересоваться, как проходит адаптация новичка, может провести дополнительное тестирование нового сотрудника, если на это будут какие-то причины. После чего принимается решение — остаётся ли выпускник дальше работать в нашей компании.

Что мы получаем от программы корпоративного обучения


  1. Поиск и наём качественных новых кадров.
  2. Не нужно проводить подробное техническое собеседование и выяснять уровень кандидата. Все становится ясно в процессе обучения.
  3. Максимально сокращается время на адаптацию сотрудника в компании.
  4. После трудоустройства не нужно тщательно контролировать новичка.
  5. Формируется понимание, какие по масштабу и сложности проекты можно отдавать бывшему стажеру.
  6. Выпускник знаком со стеком всех технологий, с которыми работают в компании. Ему не нужно переучиваться.
  7. Получаем постоянный поток новых людей, в среднем 1?2 человека в месяц

В целом ресурсы, потраченные на обучение, окупаются. Если говорить о моём времени как времени руководителя, то пока я не сильно много его трачу. Когда мы поставим систему на поток и поймём, что у нас получилось — введём отдельного специалиста по корпоративному обучению.

От редакции


Курсы «Нетологии» по теме:

Комментарии (12)


  1. tamtakoe
    21.05.2018 12:32

    Как вы решаете проблему, что ваш джун через год попросит зп в полтора-два раза больше или просто свалит от вас на бОльшие деньги?


    1. shabelskiy
      21.05.2018 12:38

      Подробности описаны здесь — goo.gl/JYKfmu.


      1. shabelskiy
        21.05.2018 12:53

        В компании мы используем многоуровневую систему испытаний для разработчиков. Программисты могут проходить испытания на повышение уровня по их запросу.

        Время между попытками сдачи — от месяца до четырех в зависимости от того, на какой уровень претендует сотрудник. Финальным испытанием служит сдача технического экзамена комиссии минимум из трех человек, среди которых есть люди в чьих прямых интересах иметь сильную техническую команду.


  1. myxo
    21.05.2018 17:09

    «они постоянно сравнивают подходы к работе в предыдущей компании и в нынешней»
    Так это… — нормально, нет?
    Проблемы тут только если работник уверен, что предыдущий подход лучше просто потому-что он был на пред. работе.


    1. repjov
      21.05.2018 17:50

      Это не хорошо и не плохо, это просто мешает нормальному восприятию действительности и интеграции. Человеку всегда сложно и не очень приятно делать что-то, что отличается от его привычных действий.
      Поэтому процесс интеграции затягивается, и даже может привести к плачевным результатам, когда человек будет в явном или не явном виде бороться с системой.

      Например. Человек привык работать один или с небольшой командой, поэтому работает не в отдельной ветке и заливает в репозиторий большое количество изменений, и только после завершения работы над задачей. Хотя на новом месте принято работать по gitflow и заливать изменения несколько раз в день в определенную ветку, чтобы коллеги могли провести ревью кода. Когда его просят, он, конечно, соглашается, но делает это с неохотой, так как его заставляют делать “ненужную” работу. И он начинает обсуждать это на кухне, или в курилке, возможно если он сильная личность, он сможет пробить свои интересы, и тем самым ломает процессы.


      1. Kanut79
        22.05.2018 09:15
        +1

        Если один человек способен «пробить» свою точку зрения в уже сложившейся команде и при сложившейся структуре/образе действий, то я бы задумался о том насколько этот образ действий действительно осмыслен и нет ли ситуации когда «святость» процесса стоит выше чем здравый смысл. Особенно если это способен сделать джуниор :)
        И сам себя часто ловил что на том, что на вопрос «нафига вы так делаете» единственным ответом, который приходил в голову, был «потому что тут так принято». А это по моему не особо хороший ответ.

        П.С. И по моему опыту адекватного человека несложно научить делать вещи по другому если это «по другому» имеет смысл. А если человек неадекватный, то его и с нуля обучать бесполезно.


        1. repjov
          22.05.2018 11:10

          Когда я говорил «способен пробить», это был пример как раз не о джуниоре, а о человеке с опытом, может даже нанятой «звезде», который привык работать по-другому.

          А что касается ответа «потому что тут так прнято», я обсолютно согласен что это не хороший ответ, поэтому мы не используем эту формулировку и всегда можем объяснить почему мы делаем так, а не иначе. У нас есть регламенты, которые описывают процессы.


          1. Kanut79
            22.05.2018 11:16

            Когда я говорил «способен пробить», это был пример как раз не о джуниоре, а о человеке с опытом, может даже нанятой «звезде», который привык работать по-другому.

            А людей с опытом вы тоже с нуля обучаете? Если нет, то тогда мне не совсем понятно зачем вообще был приведён этот пример :)

            А что касается ответа «потому что тут так прнято», я обсолютно согласен что это не хороший ответ, поэтому мы не используем эту формулировку и всегда можем объяснить почему мы делаем так, а не иначе. У нас есть регламенты, которые описывают процессы.


            И если при этом вы не можете обьяснить это так, что адекватный человек с этим соглашется и следует вашим правилам, то тут для меня есть три варианта:
            — человек на самом деле не является адекватным.
            — вы не умеете нормально обьяснять.
            — ваши процессы на самом деле не так хороши как вам кажется.


            1. repjov
              22.05.2018 11:46

              А людей с опытом вы тоже с нуля обучаете? Если нет, то тогда мне не совсем понятно зачем вообще был приведён этот пример :)

              Нет, конечно. Я же объяснил, что человек приходя с опытом, у него есть уже выработанные привычки, которые не подходят под процессы новой организации, и человеку самому довольно сложно изменить свое привычное поведение.
              Ну и проблемы бывают не только в процессах и технических вещах, есть еще софт скилы, которые в каждой организации разные и их тоже иногда нужно менять и подстаиваться.

              Я просто хочу сказать, что человеку иногда проще принять то, что для него ново, чем переучиваться.


  1. vldby
    22.05.2018 09:29

    Наверное это странный вопрос, но как даёте знать стажёру об отчислении?

    Некоторые компании, которые проводят стажировки, часто делают это жёстко (что портит мнение человека как о себе, так и о компании) либо игнорируют человека. Это мелочь, но довольно важная с точки зрения стажёра, мне кажется.


  1. SiliconValleyHobo
    22.05.2018 09:30

    С первых же строк я впал в ступор.
    "Я разработал тренинг для начинающих специалистов и курирую обучение стажеров в компании" — CTO это последний человек в конторе после CEO, от которого могут и должны исходить такие слова…
    То ли кто-то делает чужую работу, то ли работает не тем, кем должен.


    1. repjov
      22.05.2018 11:36

      Не особо понимаю почему вы впали в ступор, я как человек отвечающий за техническое развитие компании, вижу определенные проблемы и принимаю решение наладить процесс обучения. Так как я прекрасно понимаю, какими знаниями должен обладать разработчик, я составил план, внедрил процесс, провожу обкатку, изменяю. После этого, мы введем отдельного человека на эту должность, что и было сказано в статье.

      “В целом ресурсы, потраченные на обучение, окупаются. Если говорить о моём времени как времени руководителя, то пока я не сильно много его трачу. Когда мы поставим систему на поток и поймём, что у нас получилось — введём отдельного специалиста по корпоративному обучению.”