Меня зовут Антон Марунько, и я тимлид в продуктовых компаниях уже более 5 лет. Сейчас я — iOS Lead в HiFi‑стриминге Звук, а также как консультант помогаю строить и обучать команды в сфере IT и околотехнического профиля. У меня есть и опыт СТО, и кофаундера в ряде проектов. В этой статье я хотел бы поделиться накопленной практикой управления командой и развеять некоторые мифы про работу тимлидов с джунами. Эта история беспокоит меня на протяжении последнего года, так как на консультациях новичков я часто сталкиваюсь с нечеловеческими требованиями к ним без соответствующего признания и вознаграждения.
Джуны — бесплатны (или почти)
Нет, джуны не бесплатны.
Да, есть тенденция на усложнение требований к начинающим разработчикам. Многие соглашаются работать «за еду» и опыт или долго стажироваться в поисках нормальной работы. Но это не значит, что такие джуны должны быть недооценены (скорее наоборот!). Потерять человека еще на старте — очень дорого. Джун окупается компании только если он проработает в ней достаточное время: иначе вы потеряете время, потраченное на онбординг, обучение и прочее, и останетесь ни с чем. Если вы ограничены в бюджете, то компромиссом может быть ставка стажера или обучающегося на первое время, но затем должен появиться озвученный и планомерный (зафиксированный на бумаге или еще где-то) план роста дохода джуна пропорционально его вкладу или внутренним регламентам вашей компании. В моей практике часто встречалось, что джуниоры закрывают много мелких задач, принося реальную пользу бизнесу.
Джуны должны учиться в свободное время
Действительно, многие джуны готовы сидеть день и ночь, чтобы скорее прокачаться в профессии. Но не у всех получается это без ущерба для себя: такой темп может привести к выгоранию на первом этапе погружения в профессию и, как следствие, утечке молодых умов из индустрии. Если вы берете джуна к себе — будьте ответственны за его обучение. Его стоит включить в рабочее время, в идеале — составить обучение по рекомендации наставника с промежуточными контрольными точками. Можно развивать человека и через рабочие задачи, если таких у вас достаточно в разных зонах. Мы в Звуке, например, пытаемся подобрать задачи на развитие из соседних областей ответственности, что-то реализовать в рамках техдолга или договориться с командой о совместном развитии сотрудника.
Джуны — пока не члены команды
Джун — полноправный член команды. А это значит, что ему нужно участвовать в ревью. Да, поначалу он вряд ли оставит деятельных комментариев по работе, однако джун точно будет учиться и наблюдать за стандартами команды, ее решениями, рассуждениями в дискуссиях и принимаемыми выводами. Джун участвует во всех встречах команды и учится не только коду, но и процессам, подходам, практике и культуре компании. У него незамыленный взгляд, поэтому джун может подсказать неочевидное решение для фикса бага или метод работы с какой-то определенной сущностью. Мы добавляем разных участников продуктовых стримов к ревью в командах для шаринга знаний и погружения в область ответственности, это, кстати, еще и хороший способ уменьшения bus-фактора.
Джуны превращаются в мидлов в установленные сроки
Самый бесячий и частый довод от лидов разных компаний. Нет, если вы наняли джуна, он не станет мидлом за 3 месяца или за какой-то назначенный вами срок. Я настолько часто встречаю такие заблуждения, что пришлось вынести эту ошибку в отдельный пункт статьи. Составляйте реалистичные планы развития джуна и корректируйте их под конкретного человека, не требуйте от сотрудника невозможного.
В IT-индустрии случались истории, когда джуну ставили условие — вырасти за 3 месяца до мидла или уволиться. Или после двухнедельного онбординга от джуна требовали перфоманс среднего мидла (вместе с отсутствием внятной документации и отказом обучать специалиста на задачах проекта).
Не надо так.
Джуны справятся со всем
Это тоже приходится объяснять. Нет, не справятся. Точнее, это не гарантировано. Вы дали всю документацию по функционалу? Описание методов работы с бэком и клиентами? Оставили поле для вопросов и обсуждений? Обозначили архитектурные вехи, рассказали о них в документации к проекту? Да? Тогда вероятность решения задачи выше. Если вы не дали всех ключей, то готовьтесь к итеративному подходу. Помогайте, направляйте, подсказывайте.
Джун уйдет сразу, как всему научится
Нет, не уйдет. Точнее не уйдет без причины. Потерять выращенного джуна можно, если вы не создали необходимых для его развития условий: обучения, введения в процесс, повышения зарплаты по мере роста компетенций.
Если этого нет, то подрощенный специалист пойдет искать работу с нормальными условиями (и это логично). Поэтому смотрите на рынок, будьте в рынке — и это тема для отдельной статьи (здесь пока примем как данность). Круто, если вы поделитесь своими историями роста в рамках компании с начального уровня в комментариях. Это поможет руководителям уменьшить страх потери специалиста после его обучения.
Джуны ничего не могут
Могут. Как раз джуны нередко находят свежие и интересные подходы в работе. Часто начинающие специалисты привносят что-то новое в команду. Это происходит потому что джуны учились с нуля, впитывали кучу знаний с разных источников информации и при этом не имеют груза бэкграунда и наработанных решений (то есть нет влияния опыта на работу). Поверьте, иногда джуны могут принести вагон пользы, закрыв задачи, которыми вы играете в пинг-понг на каждом ревью бэклога, и улучшить тем самым метрики и статистику команды.
Однажды я дал джуну баг (назойливый, но не самый приоритетный) на починку, будучи совсем неуверенным в решении задачи. Однако джун справился: он отрефакторил немного код и описал на будущее кейс в документации.
Вместо итога
Я привел здесь заблуждения, с которыми сталкивался в практике, однако в действительности таковых намного больше. Не будьте злым лидом, от работы с которым остаются негативные впечатления: выберите нетоксичную и созидательную манеру управления. Помните, что джуны вырастают и становятся теми, кто несет о вас и о вашей компании информацию в сообщество, а значит, они влияют на бренд и на найм в целом.
Если вы не готовы вкладываться, растить и развивать специалистов, то лучше джунов просто не брать в команду. Буду рад услышать про ваш опыт работы с джунами и обменяться мнениями в комментариях!
