Привет, Хабр! Я — Алексей Григорьев, лид iOS-разработки продуктов Future Crew в MWS. Наша команда со стартап-вайбом: технологий свежих много, стек обновляется часто, требования к скорости внедрения — высокие. Нужны мотивированные сотрудники, но нет времени и сил искать готовых сеньоров. Поэтому мы ставим на рост внутри команды. Не просто не боимся брать стажеров и джунов — нам даже это интересно.

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

Типичные ошибки в работе с джунами

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

Вся зона ответственности — баги и скучная рутина. По кругу, неделями. Ментор максимум один, общение ограничено тестировщиком и парой разработчиков. Нет среды для роста, нет подпитки интереса, вместо этого — «ты исполнитель, а мы тебе багов». Ожидание креатива и развития — 0, к исполнительности — 146%.

Почему постоянные мелкие задачи (багфиксы, покраска кнопок) убивают мотивацию

Представьте, что вы приходите на работу, а изо дня в день у вас только баги и перекраска кнопок. Один раз — норм, второй — тоже ничего. Но на третий появляется вопрос: «А чему я тут учусь?». Расти некуда, горизонт сужается до тикетов в жире.

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

Почему джун у нас сразу получает свободу и сложные задачи

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

В команде людей мало, тогда как задач хватает с головой — и продуктовых, и технических. Делать нужно много, времени всегда в обрез. Не приходится выбирать, кто чем займется: пришедший(-ая) сразу получает задачу:  «зарефакторить сборку продуктовых метрик», «обновить мажорную версию какой-нибудь зависимости, например SSO», «пофиксить какой-нибудь фликающий тест», а не «нарисуй новую ��конку». Это не жест доброй воли, но реальность стартапа — нет лишних рук, нет простых тикетов, всё по-взрослому.

В итоге джун не застревает в болоте из мелких правок: сразу втягивается в разработку и растет.

Баланс между самостоятельностью и поддержкой

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

В обучении это называется скаффолдинг: наставник сначала помогает, а потом постепенно убирает «страховку».

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

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

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

Что получил проект от такого подхода

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

Как быстро можно вырастить из джуна мидла

За год. У меня есть кейс, когда, начав с простого рефакторинга аналитики, джун начал исследовать новые технологии для проекта, брать на себя продуктовые задачи, самостоятельно общаться со всеми участниками команды — от дизайнеров и тестировщиков до бэкенда и продакт-оунера. Помогал с переездом всего проекта и зависимостей на Swift 6, участвует в обмене знаниями внутри MWS, накидывает идеи улучшения процессов и продукта.

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

Советы

…лидам: как доверять джунам

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

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

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

  • Разрешайте ошибаться — но помогайте разбирать ошибки и учиться на них.

  • Держите проект на современных технологиях — это мотивирует всех участников команды, а не только джунов.

  • Помните, что рост сотрудников — инвестиция, которая быстро окупается.

…джунам: как не бояться ошибок и ответственности

  • Не ждите идеальных условий — не наступят. Берите задачи, даже если они кажутся сложными.

  • Застряли — просите помощи. Это не слабость, а часть обучения.

  • Интересуйтесь контекстом задач: зачем мы это делаем, как оно вписывается в продукт.

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

Как LLM помогают джунам

В MWS есть сервис MWS GPT с локально развёрнутыми LLM. Всё крутится на наших серверах, наружу ничего не утекает. Для джуна это супер-сила: можно быстро снять страх «чистого листа», распутать незнакомый модуль, набросать пример, варианты тестов и направление копать дальше. 

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

Если что-то кажется хрупким, странным или «магическим» — нужно уточнять запрос, докапываться до деталей, упрощать. Важно помнить, что  LLM — усиливает мышление, а не заменяет его. Не можешь объяснить решение — выкидывай и переделывай.

Почему подход работает

Потому что адаптирован под реальность. Мотивированных и голодных до роста джунов всегда больше, чем сеньоров, готовых быстро вникнуть в новые технологии. «Единорога» можно искать на рынке месяцами — успеешь вырастить новичков под нужды проекта.

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