Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как грамотно «воспитывать» джуниоров

Молодые специалисты считают, что для того, чтобы получить первую работу в ИТ, нужны активность, смекалка и хорошие теоретические знания. Большинством из них движет искренний интерес работать с технологиями, другие мотивированы потенциальной зарплатой, но все понимают, что профессия в этой области как ни в какой другой предполагает постоянное обучение и углубление своих умений. Так что учиться молодежь готова. А как и чему их учить?

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

1) Научить работать в команде

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

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

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

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

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

2) Научить работать самостоятельно

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

Важно с самого начала рассказать про цикл разработки проекта и стандарты кодинга, принятые в компании. Если не сделать этого сразу, позже новичку будет труднее адаптироваться.

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

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

3) Привить культуру управления временем

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

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

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

4) Запастись терпением и грамотно менторить

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

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

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

Резюме

  • Создавайте для джуниоров дисциплину, но в меру — чтобы не зарубить на корню инициативу.
  • С самого начала расскажите молодому специалисту про цикл разработки проекта и стандарты кодинга, принятые в компании.
  • Научите их оценивать свою работу с точки зрения совместного результата команды.
  • Объясните, что задавать вопросы — не стыдно. Стыдно просидеть весь день и не написать ни строчки, потому что чего-то не понял.
  • Проверяя задание, спрашивайте не только о том, что конкретно сделал новый сотрудник, а и с кем из коллег он пообщался в ходе работы.
  • Донесите до джуниора, по каким вопросам ему стоит искать ответы самостоятельно, пользуясь гуглом, а не коллегами.
  • Осторожно «гасите» юношеский перфекционизм там, где он излишний.
  • Давая задание, заведомо увеличивайте оценки по времени.
  • Посоветуйте джуниору концентрироваться от начала до конца на одном задании, а не переключаться между ними.
  • Напомните молодому коллеге, чтобы он предупреждал заранее, если не вписывается в дедлайн или если наоборот, справился с задачей быстрее.
  • Будьте готовым объяснять джуниору многие вещи, которые, вроде бы, сами собой должны быть понятны.
  • Следите, чтобы новичок сразу исправлял ошибки, на которые вы ему указали, а не просто принимал к сведению.

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


Благодарю за помощь в написании статьи семь ИТ-специалистов (среди которых 2 программиста, один QA, один Systems Architect, один Team Lead, один PM и один HR) с опытом ментроства новичков, которые охотно им поделились.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному2
LinkedIn

Схожі статті




44 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Гарна стаття! Єдина додаткова рекомендація — усі ці поради документуйте і наступному студенту — просто скидуйте лінк на інструкцію :-)

подскажите для ознакомления, куда сунуться java-интерну (ЕЕ уже в процессе, но набивать руку хочу сразу...)

и желательно пару-тройку ссылок, где можна на правах крабика поковырять чей то код без ущерба для окружающих (с каким то мини-заданием естественно)

╔(\/)Оо(\/)╗

1) Научить работать в команде
Добавлю, что когда приходит молодой специалист, который вообще ранее в компаниях не работал (или не совсем работал, или совсем немного), то его надо учить работе в компании — как использовать ресурсы и возможности компании, как работать с менеджерами (не только прямыми), как работать в своей команде и как работать вне команды.

2) Научить работать самостоятельно
Звучит после пункта 1) не совсем логично. Ибо есть разница между работой в компании (работами вообще) и выполнением заданий на проекте (таски, задания). Я бы назвал так:
2) Научить выполнять задания самостоятельно
Но я не автор статьи :)

Научить выполнять задания самостоятельно
Да, подразумевалось именно это :)

Если было б еще столько вакансий сколько статей о джунах и дефиците айтишников, было бы отлично )

Честно говоря, на этапе trainee — junior о менторстве как таковом речь не идёт. Скорее о дрессировке в духе дедовщины. Ибо дрессируемый ещё не постиг дзен. А он в том, что никто тебя не научит если ты не учишься сам и не научился задавать вопросы.

А нормально ли, когда устроился на работу, но как такового менторства в компании нет?

Нормально, учись сам — будешь ментором для других.

Я не знаю точно что такое «Editor в DOU.ua» :) и сколько джуниоров лично воспитала уважаемый аффтор, но ... наверно здесь тот случай когда очень хорошо передан смысл того, что ей рассказали «семь ИТ-специалистов» — решпект!

По сути. В основном согласен, но в раздел «Резюме» я бы после каждого слова типа «расскажите, покажите, напомните» и пр. добавлял — и обЪясните почему! Человек, который сознательно придерживается принятого в компании коде-стайла или сознательно «оценивает свою работу с точки зрения совместного результата команды» имеет 100%-е шансы вдвое быстрее вырасти в синьора и учить следующее поколение джунов.

Внизу была дискуссия, что лучше: страничка с FAQ-ми, или тренинг. Страничка конечно должна быть — для отмаза :), но правильный ответ есть в статье: «помощь ментора с железными нервами». А менторинг фактицки по определению предполагает работу с одним-двумя гавриками, не более, и пахарошему начинается с выяснения — а знает ли чел что и почему от него хотят, и только потом — умеет ли. Мой опыт говорит, что в случает эффективного наставника «полгода-год» льохко ужимаются в 4-8 месяцев; и под «реальной пользой» я имею ввиду ситуацию, когда джуник уже экономит время на проекте для своего наставника (т.е. с джуном становицца легче чем без него). Я понимаю, что такой подход не везде возможен, но он окупается: люди запоминают не только х-ню, но и хорошие весчи :8)

сколько джуниоров лично воспитала уважаемый аффтор
С таким подходом в пору прояснить пару вопросов о прошлом Высоцкого:
1. Как долго он служил в пехоте
2. Сколько сбил самолетов
3. В каком звании плавал на подлодке
4. В скольких сражениях с пиратами побывал
6. Сколько лет проработал в шахте
7. Сколько совершил восхождений
и так далее

Юра, расслабтесь плз, у меня смайл нарисован после первой же фразы.

Евгений, к вам претензий нет. Сама тема актуальна.

Тема — интервью с Высоцким :) ?

:D
Тема — обязательно ли человек должен пройти через что-либо, чтобы иметь моральное право об этом рассказывать.

думаю, профессия журналиста и подразумевает это моральное право

Плохой пример, поэзия — это не руководство и не обмен опытом.

Editor в DOU.ua — это человек, который отвечает за dou.ua/lenta и всё, что там происходит :-)
Олицетворение абстрактной сущности «Редакция ДОУ»

Смысл старалась максимально передать :) Сама джуниоров не воспитывала, но воспитывали меня — это тоже опыт

Напишите «Редактор ленты» вместо Editor — будет просто и понятно

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

Тренинг эффективнее. Кстати оными в базе типа «где у нас интернет и общие корпоративные ит правила» занимаются серьезные компании при приёме на работу всех.

тренинг удобно организовывать когда есть группа пришедших одновременно

тренинг удобно всегда. Нужен тренер и хотя бы один студент.

Это ж где так молодежь любят и ждут! Можно год не приность пользу проекту! Живут же люди :)

менторить
5. Говорить проще и понятней.

да и вообще пункт 4 очень спорный. такое ощущение, что разговор идет о 10ти летних детях.

да и вообще пункт 4 очень спорный. такое ощущение, что разговор идет о 10ти летних детях.
То ви, значить, ніколи з джунами не працювали. Буває, що людина, ніби, розумна і якийсь досвід вже має, але ніяк не може зрозуміти якусь річ, яка тобі здається неймовірно простою.

Давайте не путать

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

Skill — Teaming and Cooperation.
Если очень хороший специалист, но только в одиночку — вперед локомотивом во фриланс. Такому компания и кампания не нужны.

да и вообще пункт 4 очень спорный. такое ощущение, что разговор идет о 10ти летних детях.
От как раз по пункту 4, вопросом быть не должно:
Джун потому и джун что у него мало опыта, и поэтому он __часто не может__ принимать правильные решения.
Важно не то как часто джун лажает, а как он обучается (не повторяет ли он допущенные ошибки по нескольку раз).

Не нужно давать джунам задачу которая допускает вольную интерпретацию. Адекватная задача это написать юниты и аксептанс тесты.

Не нужно давать джунам задачу которая допускает вольную интерпретацию.
Согласен и это вполне попадает под «Запастись терпением и грамотно менторить» (больше под вторую часть)
Адекватная задача это написать юниты и аксептанс тесты.
Не адекватная задача, особенно в такой постановке:
1) Юнит тесты должен писать тот разработчик который будет имплементировать код. Или же более опытный разработчик для джуна, поскольку джун может что-то упустить (см первую часть сообщения)
2) Аксептенс тесты — это довольно специфический и специализированный участок работы, требующих определенных навыков (в том числе и аналитических, что таки противоречит первой части вашего же утверждения)
.
P.S. Сложилось впечатление (по комментам в этой теме), что подход к подготовке джунов у вас «классический» — скинуть все гавно которое не хотят делать другие и лучше еще и так чтобы его (джуна) вообще не видеть. Надеюсь впечатление ошибочно.

Правильно, зачем его ограждать забором от ошибок? Так он ничему не научится. Пусть набивает шишки — куда без них? А самое главное, что толковые молодые специалисты, очень часто делают по-своему, но при этом очень удачно. Я вот, например, регулярно смотрю как и чего они там творят. И задаю вопросы почему именно так — часто ответы открывают мне новые вещи, на которые я никогда не обращал внимание или не смотрел с этой стороны.
Лично я учусь у молодых инженеров, так же как они учатся у меня. Довольно занятно и держит в тонусе!

Как грамотно «воспитывать» лидов? :-)

Как грамотно поднять бунт против проджект-менеджера.

Поднять бунт != воспитать.
К тому же в задачи проджект-менеджера обычно не входит «воспитание» джунов(не ПМ).

Сыр с плесенью подавать за каждый успешный релиз

С вискарем или еще чем-то)

Вовсе не смешная тема. А очень даже востребованная. Чем и приходится заниматься...

Первейшее правило, которое массово нарушается:

НЕ надо из хороших программистов лепить хе-вых лидов.

«Кто неправильно застегнул первую пуговицу, уже не застегнется как следует.» Гете.

как тимлидам, ПМам и другим участникам происходящего выстроить отношения со вчерашними выпускниками
1) Научить работать в команде
2) Научить работать самостоятельно
3) Привить культуру управления временем
По первым 3 пунктам вопрос: Чем занимались их родители, учителя в школе, преподы в универе?
Ценность джуниора в его потенциале. Вероятность того что человек, который не научился обучатся к 20-25 годам, имеет хороший потенциал к развитию, как бы не высока.
4) Запастись терпением и грамотно менторить
С этим можно согласится. Про то что первые 0,5-1 год от джуна больше проблем чем выгоды (технической) — это правда, и это нормально.
Вероятность того что человек, который не научился обучатся к 20-25 годам, имеет хороший потенциал к развитию, как бы не высока.
Возможно человек научился обучаться, но просто не привык к каким-то корпоративным нормам.
Например —
бывает, джуниор не считает нужным сообщать ментору об успешном выполнении задачи и ждёт, пока наставник увидит/спросит сам. Такие моменты нужно проговаривать, чтобы новичок понимал, как себя вести.
— это не выдуманный случай. Возможно, как у технического специалиста у него есть потенциал, просто не знает, как общаться с ментором.

Или совет

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

Еще кейс —

Если, наоборот, он завершил задание раньше оценочного срока, то ему следует сказать об этом начальнику, а не тратить оставшееся время на свои дела, ведь рост скорости работы — это показатель его развития.
— тут тоже речь не идет о том, что он не умеет обучаться, а о том, что его надо познакомить с рабочим процессом.
Если, наоборот, он завершил задание раньше оценочного срока, то ему следует сказать об этом начальнику, а не тратить оставшееся время на свои дела, ведь рост скорости работы — это показатель его развития.
— тут тоже речь не идет о том, что он не умеет обучаться, а о том, что его надо познакомить с рабочим процессом.
От только про рабочий процесс тут так же речь не идет :)
Если человек (и особенно джун) считает что может «тратить время на свои дела» в описанной вами ситуации, это говорит о его безответственности и/или неинициативности — для ИТ это означает его профнепригодность.
бывает, джуниор не считает нужным сообщать ментору об успешном выполнении задачи и ждёт, пока наставник увидит/спросит сам. Такие моменты нужно проговаривать, чтобы новичок понимал, как себя вести.
Скорее сообщить на вводном инструктаже. Если не помогло, то см предыдущий пункт.
.
Моя мысль в том что на джунов надо тратить время (от этого никуда не деться), но инициатива должна исходить от джуна, ибо это показатель его профпригодности. Если человека нужно тянуть, то он, скорее всего, останется баластом для компании и для индустрии.
1) Научить работать в команде
2) Научить работать самостоятельно

По первым 3 пунктам вопрос: Чем занимались их родители, учителя в школе, преподы в универе?

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

Підписатись на коментарі