Здравствуйте, форумчане! Меня зовут Артём, я в IT с 2014 года, последние четыре года — тимлид и наставник. И сегодня хочу поделиться тем, что меня бесит: джуны не растут. Но давайте честно — проблема не в них. Проблема в том, как мы выстраиваем менторинг в командах.
Первая ошибка — «кинули и забыли». Знаете, когда джуна ставят в команду, дают пару задач на первой неделе и говорят: «Ну, разбирайся»? Я видел десятки таких случаев. Люди чувствуют себя брошенными, боятся спрашивать глупые вопросы, а потом просто застревают на уровне copy-paste из Stack Overflow на месяцы.
Вторая ошибка — менторинг через микроменеджмент. Вместо того чтобы научить думать, мы просто даём готовые решения. «Сделай вот так, через if, без циклов». Джуниор выполняет, но не понимает почему. Через год он по-прежнему не может принять самостоятельное решение по архитектуре. Это не рост, это программирование по шаблону.
Третья — отсутствие обратной связи. Мы хвалим за результат, но не объясняем, что именно хорошо и что нужно улучшить. Или наоборот — критикуют только в коде, а по личностному росту молчим. Джуны остаются в тумане: они не знают, движутся ли в правильном направлении.
Четвёртая ошибка — перегруз ментором. Обычно ментор — это сеньор, у которого своя гора задач. И менторство становится очередным пунктом в списке, который никто не приоритизирует. В итоге встречи раз в две недели, где ментор бегло глядит в камеру и говорит: «Ну, как дела?» Это не менторство, это формальность.
Пятая и самая коварная — когда компания считает, что менторство — это «бонус», а не инвестиция. Мы не выделяем время, не ставим KPI на рост джунов, не тренируем менторов. А потом удивляемся, почему текучка среди новичков 40 процентов.
Что я рекомендую: выделяйте ментору 30 процентов его рабочего времени на наставничество. Проводите еженедельные встречи по одному часу с чёткой структурой. Давайте джунам задачи на грани возможностей, но с поддержкой. И главное — учите думать, а не делать по инструкции.
Друзья, расскажите в комментариях — а что в вашем опыте реально работает для роста джунов? Какие приёмы или инструменты помогли вашим новичкам стать уверенными специалистами за короткие сроки?
Первая ошибка — «кинули и забыли». Знаете, когда джуна ставят в команду, дают пару задач на первой неделе и говорят: «Ну, разбирайся»? Я видел десятки таких случаев. Люди чувствуют себя брошенными, боятся спрашивать глупые вопросы, а потом просто застревают на уровне copy-paste из Stack Overflow на месяцы.
Вторая ошибка — менторинг через микроменеджмент. Вместо того чтобы научить думать, мы просто даём готовые решения. «Сделай вот так, через if, без циклов». Джуниор выполняет, но не понимает почему. Через год он по-прежнему не может принять самостоятельное решение по архитектуре. Это не рост, это программирование по шаблону.
Третья — отсутствие обратной связи. Мы хвалим за результат, но не объясняем, что именно хорошо и что нужно улучшить. Или наоборот — критикуют только в коде, а по личностному росту молчим. Джуны остаются в тумане: они не знают, движутся ли в правильном направлении.
Четвёртая ошибка — перегруз ментором. Обычно ментор — это сеньор, у которого своя гора задач. И менторство становится очередным пунктом в списке, который никто не приоритизирует. В итоге встречи раз в две недели, где ментор бегло глядит в камеру и говорит: «Ну, как дела?» Это не менторство, это формальность.
Пятая и самая коварная — когда компания считает, что менторство — это «бонус», а не инвестиция. Мы не выделяем время, не ставим KPI на рост джунов, не тренируем менторов. А потом удивляемся, почему текучка среди новичков 40 процентов.
Что я рекомендую: выделяйте ментору 30 процентов его рабочего времени на наставничество. Проводите еженедельные встречи по одному часу с чёткой структурой. Давайте джунам задачи на грани возможностей, но с поддержкой. И главное — учите думать, а не делать по инструкции.
Друзья, расскажите в комментариях — а что в вашем опыте реально работает для роста джунов? Какие приёмы или инструменты помогли вашим новичкам стать уверенными специалистами за короткие сроки?