company_banner

Как обучать джуниоров внутри компании: опыт компании Lodoss Team

    Антон Репьев, технический директор 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 человека в месяц

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

    От редакции


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

    Нетология
    Образовательная платформа

    Похожие публикации

    Комментарии 17

      +1
      Как вы решаете проблему, что ваш джун через год попросит зп в полтора-два раза больше или просто свалит от вас на бОльшие деньги?
        +1
        Подробности описаны здесь — goo.gl/JYKfmu.
          +2
          В компании мы используем многоуровневую систему испытаний для разработчиков. Программисты могут проходить испытания на повышение уровня по их запросу.

          Время между попытками сдачи — от месяца до четырех в зависимости от того, на какой уровень претендует сотрудник. Финальным испытанием служит сдача технического экзамена комиссии минимум из трех человек, среди которых есть люди в чьих прямых интересах иметь сильную техническую команду.
          0
          Это проблема только если вы собираетесь, имея более квалифицированного специалиста (кто его сделал таковым — вы или «само вышло» — совершенно неважно), держать его на той же ЗП начинающего.
          +2
          «они постоянно сравнивают подходы к работе в предыдущей компании и в нынешней»
          Так это… — нормально, нет?
          Проблемы тут только если работник уверен, что предыдущий подход лучше просто потому-что он был на пред. работе.
            –1
            Это не хорошо и не плохо, это просто мешает нормальному восприятию действительности и интеграции. Человеку всегда сложно и не очень приятно делать что-то, что отличается от его привычных действий.
            Поэтому процесс интеграции затягивается, и даже может привести к плачевным результатам, когда человек будет в явном или не явном виде бороться с системой.

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

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

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

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

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


                  И если при этом вы не можете обьяснить это так, что адекватный человек с этим соглашется и следует вашим правилам, то тут для меня есть три варианта:
                  — человек на самом деле не является адекватным.
                  — вы не умеете нормально обьяснять.
                  — ваши процессы на самом деле не так хороши как вам кажется.
                    0
                    А людей с опытом вы тоже с нуля обучаете? Если нет, то тогда мне не совсем понятно зачем вообще был приведён этот пример :)

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

                    Я просто хочу сказать, что человеку иногда проще принять то, что для него ново, чем переучиваться.
            +2
            Наверное это странный вопрос, но как даёте знать стажёру об отчислении?

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

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

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

                “В целом ресурсы, потраченные на обучение, окупаются. Если говорить о моём времени как времени руководителя, то пока я не сильно много его трачу. Когда мы поставим систему на поток и поймём, что у нас получилось — введём отдельного специалиста по корпоративному обучению.”
                0
                Большое спасибо за познавательный материал! Скажите, а есть ли у вас проблема, что стажеры после прохождения курсов уйдут в другую компанию, так и не восполнив вам потраченных на них усилий? И как вы решаете эту проблему?
                  0
                  Да, безусловно такая возможность есть, любой человек волен выбирать, то что ему больше нравится. Именно поэтому мы проводим стажировку в нашем офисе и стараемся прививать корпоративную культуру ребятам уже на стадии стажировки. Они являются такими же членами команды как и основной состав, участвуют на пятничных докладах, где мы делимся опытом, играют с ребятами в настолки и другие корпоративные игры. А при успешном прохождении обучения, мы выплачиваем единовременную стипендию и предлагаем работу.
                  0
                  Еще пара вопросов возникла.

                  1) Как вы видите разницу между стажором и джуниором?

                  2) Даете ли вы стажерам решать реальные задачи компании? Или их деятельность сугубо умозрительная, и они решают абстрактные задачи, и результаты решений вы потом никак не используете в компании?
                    0
                    1) Джуниор – это человек, который уже не плохо владеет теорией и умеет быстро находить информацию, готов выполнять не очень сложные задания.
                    Стажер – человек, который еще не имеет уверенных знаний в области, но имеет желание и тягу к развитию. Может делать простые задания, но очень долго и скорее всего не с первого раза.

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

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

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

                  Самое читаемое