Вы приходите на работу, завариваете кофе, подходите к своему рабочему месту, душите нового сотрудника, садитесь за свой стол, разбираете письма, начинаете писать код... Вроде все правильно, да?
Нет. Не душите нового сотрудника.
Всем привет! Меня зовут Павел Стрельченко, я — Android-разработчик в hh.ru, и сегодня мы поговорим про онбординг. Онбординг — это организованная помощь новому сотруднику в адаптации к необычным для него условиям. Все это необходимо, чтобы новичок как можно скорее разобрался: куда можно обратиться за информацией, где искать необходимые доступы, откуда скачивать софт, и начал приносить пользу команде и бизнесу.
В сегодняшней статье я опишу типичную первую неделю нового сотрудника в мобильных командах hh.ru.
Онбординг по чек-листам
Только недавно в наших мобильных командах появились понятные чек-листы для новых сотрудников, до этого мы передавали сокровенные знания из уст в уста, а ещё посредством объёмных статей в нашей Wiki. Однако из-за этого либо мы забывали что-то сделать, либо новый человек сильно уставал от большого объёма текста, в котором вперемешку с полезной информацией была ещё и тонна устаревшего материала.
В итоге, прохождение заданий из чек-листа и чтение полезных материалов оттуда обычно занимают первые несколько дней, превращая новичка в полноценного сотрудника, готового к решению повседневных задач.
Чек-листы?
Вот кусочек чек-листа Android-разработчика:
Обязательно ли каждая компания должна иметь такие чек-листы? Зависит от того, что именно должен сделать новый человек в команде. Если только получить пароль от сервисов и скачать IDE – смысла в чек-листе нет.
В нашем же случае, когда нужно сделать множество дел, проверить кучу доступов, не забыть подписаться на какие-то каналы и рассылки, настроить рабочее окружение так, как нужно - чек-лист очень помогает и снимает множество вопросов ещё на ранней стадии.
День первый
Первый день на самом деле довольно скучный, но нам с новичком нужно успеть сделать ряд важных вещей:
Пообщаться с HR-отделом и подписать гигантскую кипу бумаг: всевозможные трудовые договоры, дополнения к ним, ознакомление с техникой безопасности и всё в таком духе.
Забрать рабочую технику. Новому разработчику выдают ноутбук на Linux или MacOs (выбор, на деле, есть только у Android-разработчиков ;)), и тестовый мобильный девайс, чтобы отлаживать приложения.
Получить доступы к основным сервисам. Все наши внутренние сервисы (такие как Jira, Wiki, CI/CD, Grafana, etc) закрыты под VPN с двухфакторной авторизацией. На настройку безопасного доступа ко всем ресурсам нужно выделить время. Параллельно надо установить почтовые клиенты, мессенджер (Mattermost, Microsoft Teams), завести аккаунт в Github, получить доступ к основным репозиториям, проектам в Firebase, Figma, и так далее, и тому подобное.
Настроить рабочее окружение. В работе мобильные команды используют большое количество разных инструментов, вроде Android Studio, XCode, Docker, разные консольные утилиты.
Можно ли как-то упростить настройку?
Можно и нужно. Например, наши iOS-команды создали специальный скрипт для установки всех необходимых для iOS-разработки утилиты — bootstrap.sh. Они просто просто запускают его на своей рабочей машине, а дальше все нужные программы скачаются и установятся автоматически.
Есть ли что-то подобное в Android-командах?
Нет.
Для Android-разработки наличие такого bootstrap-скрипта не так критично, как для iOS. Нам для написания кода требуется только Android Studio (её легко скачать через JetBrains Toolbox), с ней уже поставляется Java для компиляции кодовой базы. В качестве системы сборки Android-команды используют Gradle, который и сам себя скачает, синхронизирует проект, выкачает гигабайты библиотек, и запустит все необходимые задачи. Поэтому новичку, который не собирается в ближайшее время заниматься инфраструктурными задачами, особо и не нужно устанавливать Ruby, Docker, Allure и прочие утилиты. А если он всё-таки захочет, мы написали хорошую инструкцию.
Ознакомиться с общими правилами командной работы. В нашей Wiki есть довольно много разных статей, посвящённых самым разным правилам: как правильно заводить портфели (наборы связанных задач), какие у нас есть каденции (регулярные встречи), какие у нас вообще есть проекты, по каким статусам мы ведём задачи и многое другое. В первые дни мы просим ознакомиться с несколькими такими статьями, чтобы у человека не взрывалась голова от переизбытка информации.
Хотя бы один раз запустить приложение, над которым новый сотрудник собирается работать. Обычно на этом первый день новичка полностью заканчивается.
В основном все новички успевают сделать всё, что мы для них запланировали на первый день. Разумеется, бывают разные ситуации: кто-то живет слишком далеко от офиса, кто-то вообще работает на удаленке, кто-то виснет на процессе подписания бумаг и делает это по почте.
День второй
Второй день нового сотрудника — день встреч.
Целая толпа?..
О, да.
Зачем это нужно? Во-первых, это забавно и весело, можно узнавать интересные и неожиданные факты о коллегах. Во-вторых, человек, который пришел в команду уже после того, как ковид обрушился на наш привычный мир, скорее всего никого не лицезрел вживую. И не факт, что вообще увидит в ближайшее время. Так что, увы, порой это единственный способ напомнить новичку, что он работает с живыми настоящими человеками, а не каким-то там роботами или аватарками в мессенджерах.
Тимлид и планы
После знакомства с командой приходит время впервые созвониться со своим тимлидом, чтобы обсудить план прохождения испытательного срока. Испытательный срок длится три месяца, и в этот период мы еще не составляем индивидуальный план развития (ИПР). Однако мы разрабатываем план по исправлению замечаний, обнаруженных нами в ходе собеседования.
План развития
В процессе собеседования мы составляем специальную табличку, где оцениваем технические и софтовые навыки кандидата, а также понимание различных процессов и многое другое. А затем обсуждаем с сотрудником то, что следует подтянуть во время испытательного периода.
У нас обычно нет стремления насильно превращать каждого сотрудника в супер-прокаченного специалиста, который знает всё и обо всём, полностью разбирается в любой области. В первое время более полезным будет прокачать знание нашего технологического стека, дать опыт работы со всеми нужными нам технологиями. Когда человек превратится в “прокаченного мидла”, можно будет развивать его дальше.
После прохождения испыталки мы составляем для сотрудника полноценный ИПР с учетом всех пожеланий: его и команды.
Еще на встрече с тимлидом мы обсуждаем первую задачу нового сотрудника. И чаще всего такой задачей является рефакторинг легаси экрана. Может показаться, что это скучно и грустно, но на самом деле оно очень полезно для онбординга нового сотрудника. Рефакторинг легаси охватывает множество архитектурных аспектов и помогает вовлечься в кодовую базу для ее наилучшего понимания. Таким образом новичок успеет поработать и с DI, и с межмодульным взаимодействием, и поймет, какие фреймворки сейчас используются в команде. А заодно и пощупает все необходимые библиотеки.
Последний вопрос в обсуждении с тимлидом — это назначение ментора.
Как узнать своего ментора?..
Шутка, конечно, но доля истины в ней есть.
Ментор необходим, чтобы задавать ему вопросы. Мы стараемся не отвлекать всю команду, а выделяем специального человека, который будет отвечать на 95% вопросов. Совершенно неважно, кто к нам пришел – зеленый стажер или ультрамегакрутой сеньор-милорд, ментор будет полезен абсолютно всем.
Техническая картина проекта
Еще во второй день нужно успеть послушать первую часть обучающей лекции о нашем проекте.
Первая часть лекции по Android-проекту
Впервые мы подготовили подобную лекцию где-то в середине 2020 года, с тех пор стараемся обновлять её содержимое примерно каждые полгода. В презентации мы очень подробно рассказываем абсолютно обо всех аспектах, связанных с разработкой нашего продукта. Мы разделили большую лекцию на три части, поскольку сотрудники не вывозят такой объем информации в один день. В первой части делимся самой базовой информацией: как скачать проект, как его настроить, чтобы с него удобно работать, какие есть правила взаимодействия между модулями.
Обязательно ли иметь такую лекцию?
Зависит от вашего проекта. Если у проект типичный, использует фреймворки без каких-то собственных изменений, то может быть вам будет достаточно просто списка полезных материалов: статей, видео, презентаций. У наших коллег из iOS-команды, кстати, сейчас нет такой всеобъемлющей презентации, погружение в проект происходит за счёт чтения дополнительных материалов в вики и небольшой демонстрации структуры проекта.
На этом второй день у нас тоже заканчивается. Здесь нет никаких жестких дедлайнов и активностей, которые занимают огромное количество времени, поэтому все обычно всё успевают.
День третий
Третий день — продолжаем обучение, но при этом наконец-то даём новичку поработать над задачей: он наконец-то разбирается с кодом, задаёт вопросы ментору, и получает обратную связь.
Еще мы даем новому сотруднику послушать вторую часть нашей лекции. Она посвящена стеку технологий и архитектуре нашего проекта. Пожалуй, это самый сложный фрагмент нашей обучающей лекции — после него точно нужен перерыв. В ходе лекции мы демонстрируем архитектуру проекта изнутри, приводим много примеров кода, показываем, как пользоваться внутренними инструментами, в общем, довольно хардовая информация, которую обязательно надо переварить. А главное — она действительно пригодится сотруднику, когда он будет работать над своей первой задачей.
Вторая часть лекции в Android
Ещё одна активность в третий день – новичку предстоит узнать побольше о процессах в нашей команде. Тимлид звонит сотруднику и рассказывает ему про общие принципы Kanban, как мы перетягиваем задачи с одной части доски на другую.
Обучение Kanban-у
Когда мы еще все были в офисе, мы проводили специальную встречу, где коллеги играли в getKanban. Это специальная настольная игра, которая позволяет обучиться главным принципам Kanban. Очень классная вещь — рекомендую.
На этом заканчивается третий день. Обычно здесь тоже всё успевается. Лекция занимает не полдня, а всего лишь час. Просто она очень тяжеловесная и человек потом просто сразу использует эти знания на практике работы над своей задачей.
День четвертый
В этот день из обязательных встреч только рассказ последней части нашей лекции. Она посвящена уже таким вещам, с которыми, возможно, этот сотрудник даже никогда не столкнется: различной инфраструктуре, дебрям аналитики, деталям всяких тестов и многому другому.
Третья часть лекции в Android
День пятый
Пятый день — последний в рабочей неделе. Сегодня новичок работает над своей задачей, а также приходит на встречу под названием “Технологизация”.
Это специальная еженедельная встреча, где мы узнаем, чем занимались наши коллеги на протяжении всей недели, таким образом мы синхронизируемся между командами. Это помогает держать в голове, что все мы работаем над одним и тем же продуктом. Еще на этой встрече мы обсуждаем интересные новости из мира Android и iOS, делимся новыми открытиями, интересными статьями и обсуждаем их.
На технологизации обязательно будут холивары по техническим решениям. Порой в течение недели возникают разные казусы, связанные с кодом, и два сотрудника не могут разобраться между собой самостоятельно. Они выносят эту ситуацию на общий суд, а мы уже вместе набрасываемся и вырабатываем общее решение.
Также на этой встрече мы ведем конспект для отсутствующих. Некоторые ребята могут быть в отпуске, некоторые просто быть на других встречах, поэтому мы ведем специальный конспектик.
Немного про "Технологизацию"
Каждую неделю специальный бот создаёт нам страничку в Wiki про технологизацию и напоминает нам о её заполнении.
Страничка представляет из себя большую табличку, где мы перечисляем всех участников из всех команд, и каждый самостоятельно описывает, чем он занимался на неделе. В колонке “Комментарии” мы записываем наши обсуждения. Все принятые решения затем выносятся либо в Wiki, либо в какие-то другие соглашения.
На технологизации мы включаем камеры. В течение недели ты можешь вообще не общаться с коллегами, потому что был глубоко погружен в свою задачу, и встречаться с ними только на синках. А на этой встрече мы хотя бы раз в неделю, но включаем камеры и вспоминаем, то что по ту сторону экрана живые люди.
Стоит признаться, что такая встреча возможна только благодаря тому, что наша команда пока не очень большая: нас всё ещё меньше двадцати человек. За один час мы успеваем проговорить все важные вещи, похоливарить, обсудить статьи и рассказать, кто чем занимался. Если у вас совсем большие команды, возможно для вас всё будет по-другому.
Последнее, что нужно сделать в пятый день — обсудить с тимлидом первую рабочую неделю. Что получалось, что нет, и можем ли мы как-то помочь друг другу.
Вот, собственно, так и заканчивается первая неделя новичка в hh.ru.
Заключение
В течение первой рабочей недели мы довольно плотно нагружаем нового сотрудника необходимой информацией, даем первую задачу, рассказываем всё необходимое проекте и знакомим с коллегами.
У новичка остается обучающая лекция, к которой он всегда может вернуться и узнать дополнительные вещи, которые случайно пропустил при первом просмотре.
Мы не прекращаем помогать сотруднику по окончании первой недели, просто дальше всё происходит не так интенсивно. Благодаря налаженному процессу онбординга новые сотрудники быстрее вкатываются и начинают приносить килотонны пользы.
Делитесь в комментах, как проходит онбординг у вас в компаниях, нам правда интересно.
