7 идей для онбординга нового разработчика в штат

Когда принимаете нового разработчика в команду, объясните ему всё: от кодовой базы до стандартов кода, от командной работы до командной культуры. Чтобы помочь, мы дадим рекомендации по внедрению нового разработчика, включая:

• наём;
• документацию;
• наставничество;
• связь;
• культуру;
• оценку;
• интеграцию удалённых разработчиков.

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

Наём

Соцсети и репозитории кандидата. Ссылки и социальная активность в аккаунтах — отличный способ проверить достоверность кандидатов. Вы также можете посмотреть проекты с открытым исходным кодом, которые они внесли в репозитории, такие как GitHub или SourceForge. Изучение результатов работ даст лучшее представление об их технических навыках и типах проектов, в которых они наиболее заинтересованы.

Интерес к своему делу. Ищите разработчика, который искренне увлечён специализацией, бизнес-моделью и технологиями. Тогда он проделает долгий путь не только в первые несколько недель работы и станет замотивированным и продуктивным членом команды на всё время своей работы.

Опыт использования продукта. Главный технический директор Zapier Брайан Хельмиг сказал, что при опросе кандидата он уделяет первоочередное внимание заинтересованности в работе и знаниях. Также Хельмиг любит находить людей, которые уже являются частью сообщества Zapier в качестве пользователей, потому что они с удовольствием привносят свой опыт в проект.

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

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

Дополнительные советы по найму вы можете прочитать в статье The Ultimate Guide for Hiring Freelance Developers.

Документация

Документируйте всё. Чтобы предоставить членам команды информацию, необходимую им для эффективной работы, вы должны документировать всё: руководства пользователя общедоступных инструментов, организационные диаграммы, SOP, общие ошибки и способы их решения, настройки рабочего места, учебные пособия по программному обеспечению. Чтобы оставаться организованным, вся эта информация должна находиться в общедоступном месте, например, на внутренней Wiki-странице.

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

Структурируйте процессы. Каждая команда разработчиков должна самостоятельно придумать стандартизованный способ настройки своей локальной среды разработки и рабочие процессы. Коллектив должен выбрать наиболее подходящую для их проектов и процессов структуру. Некоторые популярные рабочие процессы включают в себя GitFlow, Feature Branch и Trunk-Based Development. Это поможет как можно раньше интегрировать своего нового разработчика в рабочий процесс.

Наставничество

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

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

Обучайте в процессе работы. Когда в Codementor приходит новый человек, команда вводит программистов в рабочий процесс, обозначая легкую задачу для выполнения с использованием практик GitFlow. Так новый разработчик будет помогать и изучать рабочий процесс одновременно. Задачи могут включать в себя восстановление панелей мониторинга, написание нового алгоритма для соответствующей функции, обновление или создание новых функций или любую другую лёгкую задачу, которая позволит новому разработчику почувствовать себя членом команды.

Первоначальные задачи должны быть чётко определены, чтобы избежать путаницы и разочарования. Вот несколько советов для будущих наставников:

• начните с самого начала — планирования, документации и SOP;
• не решайте их проблемы — помогите им разобраться самостоятельно;
• помогите им учиться на своих ошибках;
• проработайте обратную связь;
• давайте регулярные упражнения по кодированию;
• поощряйте самостоятельное обучение с рекомендуемым списком литературы.

Связь

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

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

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

Организуйте обратную связь. Менеджеры должны поощрять новых сотрудников, честно отзываться об их работе и делиться тем, что понравилось. У Zapier есть полезная стратегия таких встреч, чтобы запросить двустороннюю обратную связь:

 Одна вещь в компании, о которой вы беспокоитесь.

 Одна вещь, от которой вы в восторге.

 Одна вещь, которую вы хотели бы сделать лучше, чтобы помочь компании.

 Одна вещь, которую вы сами можете сделать, чтобы улучшить положение компании.

Культура

Поощрение творчества и спонтанности в коллективе — отличный способ помочь новому разработчику чувствовать себя как дома.

Поощряйте обмен профессиональным опытом. Zapier, например, разбивает весь коллектив по парам. Это случайное «стравливание» двух коллег приводит к десятиминутному продуктивному разговору. Сосредоточиться стоит не на работе, а скорее на личном или профессиональном обмене. Конечная цель — более сильные рабочие отношения.

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

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

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

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

Оценка

Организуйте прозрачную работу. Чтобы лучше оценить производительность новых разработчиков, важно, чтобы они работали на виду. Задачи, связанные с программированием, могут выполняться на таких платформах, как Bitbucket или GitHub, где каждый имеет доступ к репозиторию и видит, какие запросы были отправлены на сервер или какие изменения были внесены. Задачи, не относящиеся к кодированию, должны выполняться в облачных хранилищах, таких как Google Docs, а обновления сделаны в инструментах управления проектами вроде Asana или Trello.

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

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

Ищите и устраняйте слабые места. Периодически обсуждайте текущие процессы документооборота и устраняйте любые преграды и слабые места.

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

Интеграция

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

Объясните главные цели. Если удаленные члены команды понимают компанию и ее цели, они с большей вероятностью почувствуют, что являются частью команды. Важно, чтобы удаленные разработчики чувствовали целеустремленность внутри компании и товарищество с членами команды.

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

Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.