Создаем отдел джунов в помощь основным командам, используя лишь Slack, Jira и синюю изоленту

Создаем отдел джунов в помощь основным командам, используя лишь Slack, Jira и синюю изоленту

Почти вся команда разработки Skyeng, состоящая из более чем 100 человек, работает удаленно и требования к специалистам всегда были высоки: мы искали синьоров, fullstack-девелоперов и мидлов. Но в начале 2019 года мы впервые наняли трех джуниоров. Сделано это было по нескольким причинам: найм только супер-специалистов не решает всех проблем, а для создания здоровой атмосферы в разработке нужны люди разного уровня профессионализма.

Когда вы работаете удаленно, то крайне важно, чтобы человек пришел на проект и сразу же начал приносить пользу, без каких-то долгих процессов обучения и раскачки. С джуниорами так не получается, плюс, кроме обучения, требуется еще и грамотная интеграция новичка в команду, ведь ему все в новинку. А это уже отдельная задача для тимлида. Поэтому мы были сконцентрированы на поиске и найме более опытных и уже состоявшихся девелоперов. Но со временем выяснилось, что в командах, состоящих только из синьоров и fullstack-разработчиков, есть свои проблемы. Например, кто будет заниматься рутинными, но обязательными задачами, которые не требуют супер-квалификации и каких-то особенных знаний?

Раньше вместо найма джуниоров мы возились с фрилансерами

Пока задач было немного, наши синьоры кое-как сжав зубы брали эти неинтересные для себя задачи, ведь разработка должна двигаться вперед. Но долго так продолжаться не могло: проекты росли, количество рутинных простых задач увеличивалось. Ситуация все больше и больше стала походить на анекдот, когда гвозди забиваются микроскопом вместо молотка. Для наглядности можно обратиться к арифметике: если вы привлекаете человека, рейт которого составляет условные 50$/час к работам, с которыми справится сотрудник с рейтом 10$/час, то у вас проблемы.

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

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

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

Тут важно обозначить, что удаленный сотрудник и фрилансер — две разные сущности. Удаленный работник полноценно оформлен в компании, имеет обозначенное рабочее время, команду, начальство и так далее. Фрилансер — это проектная работа, которая регулируется, в основном, только дедлайнами. Фрилансер, в отличие от удаленного сотрудника, в основном предоставлен сам себе и слабо взаимодействует с командой. Отсюда и потенциальные риски от взаимодействия с подобными исполнителями.

Как мы пришли к созданию «отдела простых задач» и что у нас получилось

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

  1. На короткой дистанции нанимать их экономически невыгодно. Вместо пяти-десяти джунов «прямо сейчас» лучше взять одного синьора и платить ему миллионы денег за качественную работу, чем тратить бюджеты на новичков.
  2. У джуниоров длительный период вхождения в проект и обучения.
  3. В тот момент, когда джун чему-то научился и вроде как должен начать «отрабатывать» инвестиции в себя за первые полгода работы, его нужно повышать до мидла, или он уходит на эту позицию в другую компанию. Так что найм джунов подходит только зрелым организациям, которые готовы вкладывать в них деньги без гарантий получения профита на короткой дистанции.

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

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

Во главе созданного нами отдела стоит опытный ПМ, который отвечает за распределение рабочих тасков по джунам и их взаимодействию с другими командами. Джун получает таск, выполняет его, получает обратную связь как от команды, так и от своего менеджера. На стадии работы в отделе простых задач мы не закрепляем новичков за конкретными командами и проектами — они имеют доступ ко всему пулу тасков согласно своим навыкам (сейчас мы нанимаем фронтэндеров на AngularJS, бэкеров на PHP или ищем кандидатов на позицию веб-разработчика с обоими языками) и могут поработать сразу с несколькими проектами.

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

Первое, с чем мы определились — это добровольное менторство в здравых объемах. То есть, кроме того, что мы никого к менторству из существующих специалистов не принуждали, было четко обозначено, что обучение новичка не должно становиться заменой основной работе. Никакого «50% времени работаем, 50% учим джуна». Чтобы иметь четкое представление, сколько времени уйдет на менторство, был составлен небольшой «учебный план»: список задач, которые должен был выполнить каждый ментор со своим подопечным. Тоже самое было сделано и для проджект-менеджера джунов, и в итоге мы получили весьма гладкий и понятный сценарий подготовки новичков и их вхождения в работу.

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

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

Итого

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

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

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

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

Мы уверены, что наш подход можно спокойно распространять и на другие компании, которые используют модель удаленной разработки. Он одновременно позволяет точечно нанимать талантливых джуниоров из любой точки России или СНГ, и при этом прокачивать наставнические скиллы опытных разработчиков. В финансовом же плане эта история крайне недорогая, так что в выигрыше остаются все: компания, наши разработчики и, конечно же, джуниоры, которым не приходится переезжать в крупные города или столицы для того, чтобы стать часть опытной команды и работать над интересными проектами.

Источник: habr.com