О том, что с нанятым джуном не делать, мы поговорили.
Теперь поговорим о том, а как растить, чтоб продуктивно было. Опять же, я так ращу и ребят, которых менторю вне работы, и стажеров на работе. Делюсь именно моим подходом.
С джунами, вопреки расхожему заблуждению, не надо сидеть круглые сутки, над ними не надо висеть и бдить с контролем. Это не маленький ребенок, ему не нужна "мамка" каждые пять минут.
В принципе, часа-полутора в день достаточно будет на все про все поначалу, потом - меньше
Первое, что важно для продуктивного обучения: научить правильно задавать вопросы. Правильно заданные вопросы снимают кучу нагрузки с ментора и дисциплинируют менти.
Я считаю, что вопрос от менти должен строиться так:
- текстовое описание проблемы со скринами;
- список вещей, которые человек попробовал, и результаты этих попыток;
Пока нет "списка" - ментора не дергаем. Пока не прошло, условно, 30-90 минут разнообразных попыток - тоже
Количество затраченного на попытки времени зависит от того, что не получается и что мы, собственно, делаем. Это лучше обговорить на берегу, чтобы джун точно знал, раньше какого времени ментора имеет смысл беспокоить только в крайнем случае
В итоге, мы получим ситуацию, в которой, по ходу развернутого написания вопроса, с 90% шансами, джун сам разберется, где и что пошло не так. И до ментора будет долетать только самое актуальное и действительно важное.
Второе: научить декомпозировать и дебажить. Если говорить человеку сразу: поди туда, поправь то, он не особо научится чинить свои ошибки и не так быстро станет самостоятельным, как нам хотелось бы. Соответственно, такой подход, в перспективе, натратит больше времени ментора
Как учим: даем алгоритм поиска проблемы в коде, дальше, в рамках ответа на вопрос помогаем пройти путь по этому алгоритму несколько раз в режиме монолога. Аналогично - с декомпозицией.
Несколько таких заходов, и самостоятельность стажера сильно увеличивается.
Третье: дать направление роста.
Выдать книгу/статью/видосик (актуальные для роста на этом проекте) и предложить потом обсудить минут на 15-30. Потом еще и еще. Выдавать имеет смысл по одному за раз.
Лично я одной из первых вещей люблю кидаться "Чистым кодом". Отличная штука.
Составить тезисный план развития на испытательный срок (не напихивая туда все лучшее сразу) и синкаться по нему 1-2 раза в неделю, тоже минут на 15.
План должен включать как фундаментальные вещи для общего развития, так и конкретику для данного проекта.
Четвертое: код-ревью.
В код-ревью делаем акцент на "почему надо не так, а эдак". Чем развернутее поначалу будет ваше "почему", тем быстрее менти вырастет.
Отдельно делаем акцент на том, что один раз объясненную ошибку второй-третий раз повторять - безобразие.
Ну а поскольку мы - не роботы с идеальной памятью, я люблю предлагать джунам вести какой-то текстовый файл, в котором они первое время будут хранить объясняшки из ревью.
Выполнять или нет - на их усмотрение, главное, чтобы одни и те же косяки не мигрировали из мр в мр.
Еще один классный момент: подключать джуна к перекрестному ревью, чтоб он и сам поревьюить мог. Это и понимание код-стайла проекта прокачает, и самого джунчика как специалиста.
Лично меня это, в свое время, очень бустануло: качается сразу куча навыков.
Пятое: повышаем градус ответственности.
Сначала - маленькие баги, потом маленькие фичи, потом фичи побольше;
Сначала - делаем в своем темпе, потом постепенно начинаем помещаться в релиз;
Сначала - ставим дедлайны совсем на глазок, потом постепенно повышаем точность;
В результате, мы даем стажеру не рыбу, а удочку, чтобы эту рыбу ловить, и освобождаем себе кучу времени, сил и нервов.
Если человек понимает, как отлавливать баги, как разбивать страшную задачу на нестрашные, как задавать вопросы и куда расти, он очень шустро прогрессирует
Наталия Давыдова