Меня зовут Антон Марунько, и я тимлид в продуктовых компаниях уже более 5 лет. Сейчас я — iOS Lead в HiFi‑стриминге Звук, а также как консультант помогаю строить и обучать команды в сфере IT и околотехнического профиля. У меня есть и опыт СТО, и кофаундера в ряде проектов. В этой статье я хотел бы поделиться накопленной практикой управления командой и развеять некоторые мифы про работу тимлидов с джунами. Эта история беспокоит меня на протяжении последнего года, так как на консультациях новичков я часто сталкиваюсь с нечеловеческими требованиями к ним без соответствующего признания и вознаграждения.
Джуны — бесплатны (или почти)
Нет, джуны не бесплатны.
Да, есть тенденция на усложнение требований к начинающим разработчикам. Многие соглашаются работать «за еду» и опыт или долго стажироваться в поисках нормальной работы. Но это не значит, что такие джуны должны быть недооценены (скорее наоборот!). Потерять человека еще на старте — очень дорого. Джун окупается компании только если он проработает в ней достаточное время: иначе вы потеряете время, потраченное на онбординг, обучение и прочее, и останетесь ни с чем. Если вы ограничены в бюджете, то компромиссом может быть ставка стажера или обучающегося на первое время, но затем должен появиться озвученный и планомерный (зафиксированный на бумаге или еще где-то) план роста дохода джуна пропорционально его вкладу или внутренним регламентам вашей компании. В моей практике часто встречалось, что джуниоры закрывают много мелких задач, принося реальную пользу бизнесу.
Джуны должны учиться в свободное время
Действительно, многие джуны готовы сидеть день и ночь, чтобы скорее прокачаться в профессии. Но не у всех получается это без ущерба для себя: такой темп может привести к выгоранию на первом этапе погружения в профессию и, как следствие, утечке молодых умов из индустрии. Если вы берете джуна к себе — будьте ответственны за его обучение. Его стоит включить в рабочее время, в идеале — составить обучение по рекомендации наставника с промежуточными контрольными точками. Можно развивать человека и через рабочие задачи, если таких у вас достаточно в разных зонах. Мы в Звуке, например, пытаемся подобрать задачи на развитие из соседних областей ответственности, что-то реализовать в рамках техдолга или договориться с командой о совместном развитии сотрудника.
Джуны — пока не члены команды
Джун — полноправный член команды. А это значит, что ему нужно участвовать в ревью. Да, поначалу он вряд ли оставит деятельных комментариев по работе, однако джун точно будет учиться и наблюдать за стандартами команды, ее решениями, рассуждениями в дискуссиях и принимаемыми выводами. Джун участвует во всех встречах команды и учится не только коду, но и процессам, подходам, практике и культуре компании. У него незамыленный взгляд, поэтому джун может подсказать неочевидное решение для фикса бага или метод работы с какой-то определенной сущностью. Мы добавляем разных участников продуктовых стримов к ревью в командах для шаринга знаний и погружения в область ответственности, это, кстати, еще и хороший способ уменьшения bus-фактора.
Джуны превращаются в мидлов в установленные сроки
Самый бесячий и частый довод от лидов разных компаний. Нет, если вы наняли джуна, он не станет мидлом за 3 месяца или за какой-то назначенный вами срок. Я настолько часто встречаю такие заблуждения, что пришлось вынести эту ошибку в отдельный пункт статьи. Составляйте реалистичные планы развития джуна и корректируйте их под конкретного человека, не требуйте от сотрудника невозможного.
В IT-индустрии случались истории, когда джуну ставили условие — вырасти за 3 месяца до мидла или уволиться. Или после двухнедельного онбординга от джуна требовали перфоманс среднего мидла (вместе с отсутствием внятной документации и отказом обучать специалиста на задачах проекта).
Не надо так.
Джуны справятся со всем
Это тоже приходится объяснять. Нет, не справятся. Точнее, это не гарантировано. Вы дали всю документацию по функционалу? Описание методов работы с бэком и клиентами? Оставили поле для вопросов и обсуждений? Обозначили архитектурные вехи, рассказали о них в документации к проекту? Да? Тогда вероятность решения задачи выше. Если вы не дали всех ключей, то готовьтесь к итеративному подходу. Помогайте, направляйте, подсказывайте.
Джун уйдет сразу, как всему научится
Нет, не уйдет. Точнее не уйдет без причины. Потерять выращенного джуна можно, если вы не создали необходимых для его развития условий: обучения, введения в процесс, повышения зарплаты по мере роста компетенций.
Если этого нет, то подрощенный специалист пойдет искать работу с нормальными условиями (и это логично). Поэтому смотрите на рынок, будьте в рынке — и это тема для отдельной статьи (здесь пока примем как данность). Круто, если вы поделитесь своими историями роста в рамках компании с начального уровня в комментариях. Это поможет руководителям уменьшить страх потери специалиста после его обучения.
Джуны ничего не могут
Могут. Как раз джуны нередко находят свежие и интересные подходы в работе. Часто начинающие специалисты привносят что-то новое в команду. Это происходит потому что джуны учились с нуля, впитывали кучу знаний с разных источников информации и при этом не имеют груза бэкграунда и наработанных решений (то есть нет влияния опыта на работу). Поверьте, иногда джуны могут принести вагон пользы, закрыв задачи, которыми вы играете в пинг-понг на каждом ревью бэклога, и улучшить тем самым метрики и статистику команды.
Однажды я дал джуну баг (назойливый, но не самый приоритетный) на починку, будучи совсем неуверенным в решении задачи. Однако джун справился: он отрефакторил немного код и описал на будущее кейс в документации.
Вместо итога
Я привел здесь заблуждения, с которыми сталкивался в практике, однако в действительности таковых намного больше. Не будьте злым лидом, от работы с которым остаются негативные впечатления: выберите нетоксичную и созидательную манеру управления. Помните, что джуны вырастают и становятся теми, кто несет о вас и о вашей компании информацию в сообщество, а значит, они влияют на бренд и на найм в целом.
Если вы не готовы вкладываться, растить и развивать специалистов, то лучше джунов просто не брать в команду. Буду рад услышать про ваш опыт работы с джунами и обменяться мнениями в комментариях!
Комментарии (18)
dlinyj
10.07.2024 12:07Джуны превращаются в мидлов в установленные сроки
Самый бесячий и частый довод от лидов разных компаний. Нет, если вы наняли джуна, он не станет мидлом за 3 месяца или за какой-то назначенный вами срок.
Это в какой сфере джуны становятся мидлами за три месяца, пол года-год?
Antonio-banderas Автор
10.07.2024 12:07+1Я встречал такие запросы работодателей в мобилке и считаю их нереалистичными, поэтому про это в том числе упомянул
dlinyj
10.07.2024 12:07+2Просто в той сфере где я тружусь мидлом уверенным лет через десять только можно назваться (embedded), и то там кроличья нора так глубока, что шаг в стороны и ты снова джун.
zergon321
10.07.2024 12:07+1Да забудьте вы уже про джунов. Этого грэйда больше нет. Есть только миддлы, которых удалось прогнуть на джуновскую зарплату
scarab
10.07.2024 12:07+2В том смысле, что планка требований к мидлам уже снизилась до джуновского уровня?
zergon321
10.07.2024 12:07+1Наоборот, планка требований к джунам возросла до миддл и выше уровня. Кроме того, рынок работодательский и хороших мест на всех не хватит, кому-то придётся соглашаться на унизительные условия
Tikani93
10.07.2024 12:07Ну такое. Если вы про хардскиллы, то они необходимы (но не достаточны), чтобы быть мидлом и выше. Грейд растет только при реальном коммерческом опыте, потому что одно дело - писать в стол "пет-проекты" и быть админом локалхоста, а другое дело - набивать шишки на заковыристых задачах, при этом показывать нормальный KPI, развивать навык холистического видения предметной области, учиться быстро адаптироваться под код стайл и паттерны конкретной команды.
Я видел гиков, у которых хобби в свободное время решать литкод и портфолио проектов, которые они делали в одно лицо на фрилансе последние лет 5, но при этом они все равно джуны, так как при попадании в "боевые" условия стандартной большой компании все равно что слепые котята. Навыков вычитки ТЗ нет, чтобы сразу видеть противоречия и возвращать аналитику на доработку, а не в середине разработки задачи; на код ревью видят максимум поверхностные стилистические и технические ошибки (а-ля "заметил, что ходим в БД в цикле, но не заметил, что в рамках этой конкретной задачи в базу можно вообще не ходить, а рассчитать значение на месте"), навыков эффективного системного погружения в предметную область проекта тоже нет (плывет по течению, разбирается в бизнес-логике только тех частей проекта, код которых ему приходилось изучать/читать документацию в рамках распределенных на него тасок в трекере).
titan_pc
10.07.2024 12:07Опять Биг тех. Поколение саппортов. Джунов надо брать на ревью и совместно чесать языками. А то одному скучно, кроме задачек на 10 строк кода то и нет ничего. Бе. Фу.
Хоть бы раз вышла статья о том, как ни ревью нету, ни девопсов. И ребята порвали рынок, набрав джунов. Без рефакторинга и ревью.
Миф номер 8. Я возьму Джуна, посажу его в бигтех и он станет крутым самураем...
Да с такси условиями, где есть время джунов в ревью привлечь... Они просто сгорят как спички, когда станет задача "родить новое"
Swordman85
10.07.2024 12:07По поводу бесплатнности и джунов соглашусь что они не бесплатные в том плане что в компании на них тратят время другие сотрудники. Но с текущем уровне конкуренции джунов (от 100 до 2000+ откликов на вакансию) слишком велик соблазн не платить если есть такая возможность. Джунов не просто много, а очень много. И да, среди них большой процент тех кого даже джуном сложно назвать, но в конце концов вы берете 1 (или 10 если вы большая компания). Остальным 99-1999+ приходится искать дальше. С учётом динамики роста числа джунов и низким спросом на их услуги, работа за опыт уже норма, к сожалению.
По поводу свежих решений у джунов - безусловно такое возможно. Но достаточно ли часто это происходит? Даже если джун способный, то ему может просто не хватать опыта для реально рабочих решений.
onets
10.07.2024 12:07Я бы добавил еще несколько моментов:
Джун, который закончил вуз по прикладной математике или хотя бы прикладной информатике - это не тот джун, который таксист с онлайн курсами
Компании должны понимать - есть ли у них внутренние ресурсы на джунов
У 30-40 летнего Джуна с семьей не будет времени на учится во внерабочее время
scarab
Я бы сказал, что есть обратная тенденция.
Обучение? Почему отсутствие знаний у работника должно быть проблемой работодателя? Да, какое-то время на вникание в нюансы данной конкретной компании понадобится любому, в том числе самому сеньористому сеньору - но не более.
Выгорание от прокачки в профессии??? Это может случиться только в одном случае - если человек не любит своё дело и пришёл только за деньгами, а такому вообще не место в IT. Это же в кайф должно быть - каждый день узнавать новое, писать пет-проекты, развиваться. Если не в кайф - чувак, ты выбрал не те печеньки.
Antonio-banderas Автор
Спасибо за комментарий) Полное отсутствие знаний - это, конечно, не проблема работодателя. Я больше имею в виду про темп и таймлайн погружения. Если есть нормальная документация и наставник, то оно скорее всего будет быстрым.
Что касается выгорания, это дискуссионная тема) про это много статей есть и исследований. Я больше про то, что все люди разные. И не все живут только работой.
Vedomir
>Почему отсутствие знаний у работника должно быть проблемой работодателя?
Если есть дефицит специалистов, то это проблема в том числе и работодателя.
Если за забором очередь, то это конечно не проблема для работодателя.
>Выгорание от прокачки в профессии???
Выгорание может быть от чего угодно, если этим заниматься слишком много. Например от любимой компьютерной игры. От любимой еды. От любимой профессии тоже. Даже от любимого, но чрезмерно навязчивого человека. Хотя конечно всегда бывают исключения.
Ну и опять же неприемлемость людей, для которых профессия не любимая зависит от все того же дефицита и наличия очереди за забором.
Если людей найти сложно, то просто отвественный и неглупый человек тоже будет полезен, даже если он не испытывает идеалистической любви к своему делу.
Ivan_Pod
"Введите в практику подготовку и переподготовку кадров" У.Э.Деминг
Что касается тех или не тех печенек - на работе я пишу бэк на PHP, но, всегда мечтал писать приложения под iOS - чем я и занимаюсь в свободное от работы время
Т.е. если работодателю нужно прокачать сотрудника в какой-то технологии, нужной работодателю - не вопрос, но за ресурсы работодателя (время, деньги, курсы, менторы...). В свое свободное, неоплачиваемое время я буду "развиваться" так как хочу я - изучать свифт, играть на губной гармошке или лежать на диване (тоже не самый плохой вариант - можно вспомнить анекдот про Резерфорда и его лаборанта, который все время проводил на работе - Резерфорда заинтересовало, когда же молодой человек думает, если он постоянно работает)
scarab
С вышесказанным соглашусь полностью.
Но есть нюанс: если "в свободное, неоплачиваемое время" хочется играть на губной гармошке - возможно, стоило идти не в IT, а в джаз-бэнд и зарабатывать деньги тем, что нравится и хочется? Развиваясь не потому, что это нужно работодателю, даже если он это и оплатил, а просто потому что хочется уметь своё?
Если всегда мечталось писать приложения под iOS - почему не пойти туда? Вроде там платят не меньше, чем в PHP? Тогда и изучать свифт можно будет в своё удовольствие (и за деньги работодателя, конечно :) ).
zergon321
Во-первых, существует рынок и спрос на рынке. Спрос на написание сервисов куда выше, чем на выступленя с губной гармошкой. Во-вторых, "преврати хобби в работу, и тебе придётся искать новое хобби"
zergon321
На последнее я могу сказать вот что