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



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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

    Итого


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

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

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

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

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

    Comments 14

      0
      Вообще это древняя практика. Так еще в царские времена детей отправляли к различным ремесленникам для обучения (ну и по причине того, что прокормить было тяжело), возвращались они уже полноценными умельцами, если возвращались. И до царских времен тоже, думаю, было что-то похожее. Этот же институт менторства наставничества был крайне развит на производствах СССР.
        0
        «Миллениалы изобрели», как теперь модно говорить?)

        Хотя институт наставничества, безусловно, существует веками (если не тысячелетиями, вы правы), мне кажется, именно в дистанционном формате его воссоздать — интересная задачка.
          0
          На мой взгляд, разница при удаленке лишь в видоизменении привычных каналов общения. С другой стороны, если просто общаться по видеосвязи (да еще использовать функцию демонстрации рабочего стола) проблема исчезает. Ну и мотивировать/контролировать нужно правильно. К тому же на удаленке сразу отсеиваются те, кто не может работать не «из-под палки».
          Почаще стыкуемся с новичками, оказываем поддержку, поощряем высказывание своего мнения по поводу решения задачи (даже если оно не совпадает с нашим). Я еще делал так: с утра на 5-15 минут конференция с приветствием и постановкой задач на день, в течение дня звонки один на один при возникновении вопросов или для выяснения, не появились ли вопросы.
          Через три месяца притирки часть процессов была полностью делегирована (в соответствии с имеющимися навыками), а сами ребята стали полноценной боевой единицей с выявленными и обозначенными лидерами. Кроме того, была сформирована карта отличительных навыков, благодаря которой задачи выдавались тем, кому они больше всего подходят (то есть значительно экономилось время обработки задач).
          Мы с командой находились в разных городах, но если бы и сидели в одном офисе, то ничего бы не изменилось, использовались бы все те же приемы.
            0
            Александр, спасибо, что поделились опытом! Да, тоже пришли к похожим практикам: видео, мягкий контроль, побольше общения, это все.
      +1
      ИМХО — это больше похоже на какую-то оплачиваемую стажировку, чем на испытательный срок.
        0
        Привет, да, грань трудноуловима — дьявол в деталях: мы берем именно столько ребят, сколько можем «переварить». Стажировки это все же часто более массовое явление по числу участников
        +1

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

          0
          Если говорить о девушках и прочих непривыкших, то лучше потратить время на создание инструкций в картинках. И по ходу обучения-привыкания, а также при выдаче заданий, проговаривать: «для этого сделай вот так в слаке».
            0

            Благодарю, у нас планируется для решения как раз видеоконференция с демонстрацией экрана, про инструкции с картинками не думали, а ведь реально это хороший вариант.

            0
            Привет, спасибо за интересный вопрос! Мы в Skyeng ввели обучение работе со слаком для всех при онбординге — это часть вводного курса (инструкция в картинках и правила общения) с проверочными заданиями. Плюс ребята многие не стесняются подсказывать («пиши все мысли в одном сообщении»), напоминать о договоренностях (что SLA на ответ в слаке 3 часа в рабочее время, например, или что рабочее в рабочем мессенджере, а телеграм — это если срочно или внешние контакты) — т.е. дообучают в процессе немного, если что.

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

            Можете пошарить конретный план?
            +1

            Здорово! Страшилка по теме, исключительно для контраста и в честь праздника:


            Один коллега потрудившийся на аутсорсе в одной экзотической стране, рассказал про местный метод работы стаффинга, называемый им "карусель".

            Грубо говоря контора сметает с рынка всех, кто умеет в stackoverflow. Процесс иногда тормозится, но, так как специалисты дешевые, а объемы большие, последнее случается нечасто. Наем 15-20% на фоне attrition rate 5-10% от числа инженеров = 5-10% роста в год.

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

            Далее, если новичок тянет (читай, "начальник" может на него не отвлекаться), его добавляют в команду "официально" под предлогом "для спасения чего-нибудь" (благо, спасать у них всегда что-то надо). А если не прокатывает, "начальник" срочно ложится в больницу, попадает под слона, уезжает на свадьбу и т.д. В общем, так или иначе, джуна либо продают "как есть", с увеличением команды (и инвойса! профит!), или вписывают на позицию мида с сохранением рейтов последнего (инвойс тот же, но маржа больше! профит!).

            А если не тянет (читай, "начальник" вынужден продолжать делать значительную часть своей работы), бедолагу высылают на другой проект. Кто совершил круг почета по всем проектам и нигде не был продан клиенту выкидывается обратно на улицу. Потому и название "карусель".

            Начиная работать с новым клиентом, на проект загоняют неплохую команду (часто, кстати, укомплектованную суб-контракторами), а потом за пол-года "вымывают" специалистов. Получается долгосрочная маржа 50%+ даже при рейте а $15-25/час.

            Ваша система тоже построена по принципу естественной фильтрации, но при этом остается честной и прозрачной, что очень здорово.

            Only users with full accounts can post comments. Log in, please.