Основатель молодого продуктового стартапа рассказывает про свою команду. Шесть человек, продукт запустили в январе, растет быстро. И вдруг фраза, от которой у половины сообщества дернулся глаз: джунов мы сейчас не берем.
Не потому что жалко денег на зарплату. И не из принципа «пусть сначала докажет». А потому что проект дорос до состояния, в котором вчерашний студент просто не вывозит: слишком много доменной сложности, слишком много контекста, который живет в головах, а не в коде.
Казалось бы, обычная бизнес-логика. Но именно с этой фразы началась двухчасовая дискуссия о том, кто вообще обязан растить джунов – сам джун, компания или рынок. И, что важнее, когда джун нужен, а когда это дорогая ошибка. Разберемся по порядку.
Спор, который старше нас всех: чья это ответственность
Первая линия фронта проходит по простому вопросу. Джун пришел сырой. Кто должен вложиться в то, чтобы он стал полезным?
Одна позиция звучит жестко и по-своему честно: развитие – это ответственность самого сотрудника, а не обязанность компании.
Спасение утопающих – дело рук самих утопающих.
Логика такая. Компания заключает с человеком социальный контракт: платит деньги, дает задачи, дает возможность учиться на реальных ошибках. Все. Дальше хочешь расти – расти сам: бери отпуск, плати за курс, читай, спрашивай. Один из участников привел собственную историю. Работодатель не был заинтересован в его развитии, потому что его устраивал текущий расклад. Человек накопил денег, сам оплатил обучение, вырос и ушел к другому за зарплату на 50% выше. «В гробу я видал такого работодателя, спасибо им за опыт».
Звучит убедительно. Но у этой позиции есть слепое пятно, и его быстро нашли.
Компания существует не в вакууме. Особенно в Казахстане, где инфляция создает постоянное давление на фонд оплаты труда. Продукты дорожают, сотрудники хотят больше денег, а чтобы дать больше денег и не разориться, нужно повышать производительность труда. Повышать производительность, не повышая квалификацию, невозможно.
Чтобы стоять на месте, надо быстро бежать.
И вот вам петля. Сотрудник хочет больше. Компания может дать больше только при росте выработки. Выработка растет только при росте квалификации. А квалификация сама себя не поднимет, если все сидят на уровне знаний пятилетней давности. Получается, что «развитие – дело сотрудника» работает ровно до тех пор, пока рынок и инфляция не выставят счет.
Компромисс, к которому в итоге подошли: верны обе позиции, просто для разных горизонтов. Для узкого прикладного IT модель «сотрудник учится сам, а мы берем готовых» – вполне рабочий бизнес. Для компании, которая хочет большего, чем закрывать сегодняшние тикеты, отказ от инвестиций в людей рано или поздно упирается в потолок. Вопрос не в том, должна ли компания вкладываться. Вопрос в том, какой у нее горизонт.
Почему на зрелом проекте джун не вывозит
Вернемся к тому основателю. Его аргумент не идеологический, а инженерный, и он заслуживает отдельного разбора.
Проекту 2,5–3 года. За это время накопился пласт доменных знаний, пограничных кейсов и неочевидных решений. Джун приходит и не может «сходу разобраться и начать приносить value»: слишком высокий порог входа. А задачи при этом сложные и почти все срочные – живые клиенты с реальными интеграциями, где ошибка стоит клиента.
Сравните с greenfield. Новый продукт, много принципиально новой разработки, микросервисы пишутся с нуля, минимум легаси-контекста. Вот здесь джуны отлично вывозят – «в любой конвейер можно джунов ставить». Разница не в людях, а в природе работы.
И тут в разговоре всплыла мысль, которая переворачивает весь спор. А что, если джун на зрелом проекте – это не проблема джуна, а диагноз архитектуры?
Сеньорность – это ведь не про то, чтобы писать сложный код. Это про то, чтобы писать сложное просто. Если у вас настолько высокий порог входа, что новый человек полгода не может ничего сделать, возможно, дело не в человеке, а в системе, и ее пора облегчать. Задача из категории «важная, но не срочная»: ее вечно откладывают ради очередной горящей фичи, а зря. Джун, которого вы вынуждены онбордить, работает как стресс-тест. Он показывает, где ваша система переусложнена настолько, что ее не понимает никто, кроме двух-трех старожилов.
Знакомая ситуация? Это ведь еще и про бас-фактор. Проект, в который невозможно ввести нового человека, держится на нескольких незаменимых головах. И если одна из них уйдет, заменить ее будет практически невозможно. Основатель это честно признал: такие риски мы пока принимаем.
Джун как инвестиция, а не как обуза
Есть еще один ракурс, который легко упустить за операционной суетой. Если вы никогда не берете джунов и все время докупаете готовых мидлов и сеньоров с рынка – что происходит с вашей командой в долгую?
Во-первых, у вас нет внутреннего трека роста. Некого менторить, а значит, ваши мидлы не превращаются в тимлидов: навык наставничества просто негде тренировать. А ведь менторство прокачивает в первую очередь самого ментора. Объясняя, ты сам начинаешь глубже понимать то, что раньше знал «в общих чертах».
Во-вторых, вы паразитируете на рынке, ничего в него не возвращая. Все хотят готовых специалистов, но готовые специалисты откуда-то берутся. Если никто не растит джунов, завтра не будет мидлов. Классическая трагедия общего ресурса.
В-третьих, джун – это инвестиция с отложенной отдачей. «Депозит, который вкладываешь сейчас, а получаешь больше потом». Не взяли и не вырастили сегодня – через год, когда людей будет остро не хватать, окажетесь перед выбором из плохих вариантов: либо переманивать дорого, либо срочно двигать кого-то на роль, к которой он не готов.
Тут важно не впасть в другую крайность и не начать нанимать джунов пачками «для галочки». Джун оправдан там, где есть кому его вести, есть поток задач подходящей сложности и есть горизонт, на котором вложение окупится. Если ничего из этого нет, честнее не брать, чем брать и бросить.
Две правды, которые придется держать в голове одновременно
Дискуссия так и не свелась к единому ответу, и это нормально. Вот как разложились позиции.
| Вопрос | «Ответственность сотрудника» | «Ответственность компании» |
|---|---|---|
| Кто вкладывается в рост джуна? | Сам человек: учится на ошибках, платит за курсы, растет и уходит выше | Компания: иначе упрется в потолок выработки и потеряет людей |
| Что должна компания? | Соблюдать социальный контракт: деньги, задачи, право на ошибку | Инвестировать в квалификацию, потому что инфляция не оставляет выбора |
| Когда модель работает? | Узкое прикладное IT, стабильные процессы | Когда компания хочет расти, а не только закрывать тикеты |
А поверх этого – инженерный водораздел про сам факт найма джуна:
| Ситуация | Брать джуна? | Почему |
|---|---|---|
| Greenfield, много новой разработки | Да | Низкий порог входа, джуны отлично вывозят конвейер |
| Зрелый проект (2,5–3 года), высокая доменная сложность | Осторожно | Джун долго не приносит value, но это еще и сигнал облегчить архитектуру |
| Все горит, задачи срочные и сложные | Нет, пока горит | Некому вести, а онбординг требует ресурса, которого нет |
Обратите внимание: ни одна колонка не «неправильная». Правильный ответ зависит от стадии продукта, зрелости архитектуры и горизонта планирования. Тот, кто продает вам универсальное «джунов надо / не надо брать», скорее всего, не додумал контекст.
Как онбордить джуна в маленькой команде: рабочая схема
Самое ценное из встречи – конкретная механика, которую один из участников обкатал на своей команде. Если вы все-таки берете джуна и людей мало, вот подход, который не убивает команду ресурсом на присмотр.
Трехмесячная стажировка со сдвигом от тестирования к разработке.
- Недели 1–2. Человек занимается только тестированием фич, которые написали более опытные ребята. Не пишет код, а проверяет.
- Постепенный сдвиг. Каждые две недели фокус смещается: сначала тестирование, потом мелкие багфиксы, потом все более содержательная разработка.
- К концу трех месяцев. У человека есть и понимание доменной области (потому что тестирование – это лучший способ ее изучить), и первый реальный код.
Почему это работает лучше, чем «вот тебе задача, разбирайся»? Потому что тестирование – это клей, который наращивает доменные знания без риска сломать прод. Джун изучает систему изнутри, глядя на нее глазами пользователя фич, а не сразу ныряя в архитектуру, которую еще не понимает.
Чек-лист перед тем, как открыть вакансию джуна:
- Есть ли поток задач подходящей сложности – или все горит и все срочное?
- Есть ли кому вести – человек, для которого менторство станет точкой роста, а не обузой?
- Терпит ли архитектура нового человека – или порог входа сигналит, что систему пора упрощать?
- Какой горизонт – успеет ли вложение окупиться до того, как джун вырастет и уйдет?
- Готовы ли вы к тому, что первые месяцы это минус к скорости, а не плюс?
Если на большинство пунктов честное «нет», возможно, сейчас не время. И это нормально. Отложить наем джуна до подходящей стадии – это не жадность, а зрелость.
Почему это важно за пределами одной команды
Вопрос «растить или докупать» выглядит как операционная мелочь, но определяет он куда больше, чем кажется.
Он определяет ваш бюджет найма: переманивать готовых дороже, чем растить, но растить – это отложенные затраты с риском, что человек уйдет. Он определяет ваш бас-фактор: команда без притока новых людей костенеет вокруг нескольких незаменимых. Он определяет здоровье всего рынка: если каждая компания хочет только готовых, готовые закончатся.
И, пожалуй, главное – он определяет, честны ли вы с собой насчет своей архитектуры. Потому что «джун у нас не вывезет» слишком часто означает не «джун плохой», а «мы построили систему, которую не понимает никто, кроме нас самих».
Так чья же ответственность растить джунов? Похоже, ничья в одиночку – и всех сразу. Сотрудник отвечает за инициативу, компания – за среду, в которой эта инициатива окупается. А вы у себя в команде на какой стадии сейчас: greenfield, где джун ускорит, или зрелый проект, который пора упрощать?
Эта статья основана на встрече сообщества «Тимлид не кодит» 1 июля 2026 года. Присоединяйтесь к обсуждению в Telegram.