Главная » Хабрахабр » Добро пожаловать на борт: вводим новых разработчиков в команду

Добро пожаловать на борт: вводим новых разработчиков в команду

Привет, Хабр!

Меня зовут Андрей Гоменюк, я тимлид одной из команд серверной разработки Badoo.

А сегодня делюсь текстовым дополненным и улучшенным вариантом своего доклада. На майском Badoo Techleads Meetup, посвящённом управлению разработкой, я поделился опытом интеграции новичков в команду.

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

Об этом мы спрашиваем на собеседовании. Заметьте, что здесь нет ничего вроде «писать на PHP» и «знать MySQL». И чем раньше вы со всем этим познакомитесь, тем лучше. А в этом списке — все наши инструменты, технологии и термины, а также общие вещи, которые мы, скорее всего, делаем не так, как все.

Термин onboarding означает ввод человека в команду, ознакомление его с проектом и процессами. Поскольку наш отдел серверной разработки за последние пару лет вырос вдвое (сейчас нас больше сорока человек), мы стали первыми в Badoo, кто озаботился интенсивной адаптацией новичков и их интеграцией в работу.

Я выделяю две основные цели онбординга.

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

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

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

Кто встретит новичка

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


Источник

Казалось бы, что после этого уже можно посадить человека за стол, но есть ещё одна важная деталь.

Кто будет «вести» новичка

В некоторых компаниях весь процесс онбординга «завязан» на менторах. Это люди, которые всё объясняют, показывают, что, где и как, отвечают на вопросы новичка и сводят его с нужными людьми.

Просто эта роль возложена на лида, который может делегировать её кому-то из сотрудников. Мы таким термином не пользуемся, но, как поётся в известной песне, ментор есть, а слова нет. Во время небольшой встречи он знакомит новичка с проектом, рассказывает о принятых в компании процессах. Как правило, лид (или назначенный им человек) является для новичка входной точкой по всем вопросам. И очень важно, чтобы новичок понял, что, как и почему мы делаем. Это начало передачи нашей культуры человеку, который до этого работал в других компаниях и привык делать вещи по-другому.

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

  • человек сидит за ноутбуком
  • с настроенным рабочим окружением
  • и делает тикеты.
  • Может спроектировать новую фичу
  • и работать самостоятельно.

Дальше рассмотрим, что происходит на каждом этапе.

1. Ноутбук

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

2. Рабочее окружение

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

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

На этом этапе я уже готов дать новичку первый тикет.

3. Тикеты

Допустим, первый тикет пришёл такой:

Или такой:

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

Как было раньше

Когда семь лет назад я пришёл в Badoo, было примерно так. Лид подсаживается к новичку и начинает рассказывать: «Смотри, у нас есть очереди, скриптовый фреймворк. Они работают вот так. Обрати внимание на это. В этом тикете тебе нужно будет сделать это».

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

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


Кадр из к/ф «День сурка»

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

Туда накидали кучу ссылок, которые хорошо было бы прочитать разработчику. В какой-то момент кто-то создал в Wiki страницу «Welcome new developer».

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

Она пополнялась примерно так. У той нашей страницы не было общей структуры. Чтобы делали хорошо, я написал статью в Wiki. Ко мне подходит лид другой команды и говорит: «Андрюха, твои разработчики делают нехорошо. Добавил её в «Welcome new developer», чтобы все твои разработчики обязательно её прочитали».

В итоге на новичка сваливается одна большая страница с кучей ссылок, которые, возможно, ему понадобятся. Естественно, он считает свою статью самой важной, размещает её на самом видном месте, выделяет жирным, красным. С обилием жирных фраз, MUST READ и «Читать обязательно!».

Решили взять всё лучшее из этих инструментов и сделать что-то новое. В какой-то момент мы поняли, что лекции, видео и Wiki нас больше не устраивают. Не сочтите за рекламу. И нужную идею нам подкинул… фреймворк Laravel. И в нём нам очень понравился раздел документации Quick Start, в котором на реальном примере рассказывается о базовых принципах и имеющихся инструментах (и, поняв основы, можно приступать к чтению подробного описания). Просто в то время мы как раз подбирали фреймворк для одного проекта, в поисковике по запросу «best PHP framework» на первом месте выскочил Laravel, мы его и взяли.

Quick Start

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


Источник

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

Да это было бы и неэффективно. Мы не смогли придумать одну общую задачу для всего раздела Quick Start. Он будет работать над ней месяц-два, и всё это время вы не можете отвлекать его тикетами, а это противоречит первой цели онбординга. Представьте, что вы даёте человеку задачу — по сути, одну огромную фичу, которая покрывает все разделы.

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

И здесь нам помогли те же самые задачи. Затем встал вопрос о том, как поддерживать актуальность всего этого массива информации. В обычной жизни разработчикам об этом знать не нужно, потому что они пользуются высокоуровневым API. К примеру, у нас есть споты (виртуальные шарды) и сервис, который отвечает за сопоставление пользователей и спотов. Но мы требуем от них понимания того, как это работает внутри.

Если в этой процедуре что-то изменится, то обычные разработчики об этом не узнают. Даём задачу: зарегистрировать пользователя на девеле, по его адресу почты получить идентификатор спота, получить по споту данные о базе, зайти туда, выбрать и посмотреть, что там есть. Зато разработчик, который в данный момент этим занимается, поймёт: что-то не так. Они не узнают, что нужно зайти и исправить описание. Лид с ним сядет, разберётся — и мы актуализируем документ. Он подойдёт к лиду и скажет, что что-то не работает. Вместо этого мы создали Google Doc, в который они могут записывать свои пожелания. Мы стараемся не поощрять разработчиков самостоятельно изменять Quick Start, чтобы не нарушать структуру и стиль изложения. Потом этот список просматривается ответственным сотрудником, который вносит изменения в нашу статью.

А ответственные люди потом решают, частный ли это случай, не интересный большинству разработчиков, или всё же стоит об этом написать в Quick Start. Новая информация добавляется в Quick Start таким же образом: кто-то сталкивается с новым инструментом, который не описан в документе, и пишет об этом в Google Doc.

Например, в каждую главу добавили счётчик длительности чтения и количество страниц. Сами разработчики иногда добавляют в документ прикольные «рюшечки». Также в некоторые разделы добавили ссылки, которые сразу открывают нужный класс в PhpStorm.

Ведь Quick Start получился огромным, и тратить на его чтение две недели никто не хотел. Потом мы начали думать, как заставить проштудировать документ «старичков»? Каждому разработчику давалось на выбор около 40 вопросов. Тогда мы придумали тест: на основе документа составили около 100 вопросов на разные темы и всем предлагали анонимно его пройти. То есть тест был инструментом обучения, а не проверки, и при неправильном ответе на вопрос тут же предлагались подсказки и ссылки, где в Quick Start можно об этом почитать. Цель была не в том, чтобы проверить знания, а в том, чтобы помочь людям понять, чего они не знают.


Пример вопроса из теста

Считается, что для них это будет логичным завершением изучения Quick Start. Мы никак не контролируем прохождение теста новичками. Когда «старички» прошли тест, мы выбрали несколько вопросов, на которые они ответили не так, как нам хотелось бы, и попросили опытных ребят написать на эти темы статьи. При этом мы ведём статистику по всем ответам.

Quick Start и тест — это самая внушительная часть нашего процесса онбординга.

Больше тикетов

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

После того как вы прочитаете Quick Start, смысл приведённых выше тикетов станет вам гораздо понятнее:

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

Или второй пример:

Здесь то же самое: фотография попала не в тот альбом, скорее всего, клиент просто прислал неправильный альбом; нужно понять, есть ли ещё такие случаи, и исправить.

Тикеты, на самом деле, простые, на час работы.

4. Проектирование новой фичи

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

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

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

В заключение встречи лид собирает фидбек и может предложить разработчику внимательнее изучить какой-то раздел и подумать над тем, что он узнал.

5. Самостоятельная работа

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


Источник

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

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

Также мы практически сразу добавляем человека в performance review, просто для того, чтобы он мог получать обратную связь не только от своего лида, но и от всех, с кем взаимодействует: от продуктовой, QA- и клиентских команд.

Вот, пожалуй, пять основных компонентов нашего процесса ввода новичка в строй:

  • Минимум внимания маловажному. Делаем всё, чтобы человек сосредоточился на работе и не отвлекался на мелочи (в том числе) бытовые.
  • Quick Start. Мы долго не решались к нему приступить и считали, что сделать это невозможно. Но это оказалось проще, чем мы думали, а окупилось уже многократно.
  • Тест. По соотношению полученной пользы к затраченному времени он несколько проигрывает Quick Start, но тоже является важным элементом процесса обучения.
  • Практические задачи.
  • Обратная связь от команды и лида. Чем больше, тем лучше.

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

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


Источник

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

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

Вы наверняка подумали: «А зачем вообще столько?». Наконец, помните первую картинку с кучей терминов? Читая Quick Start, очень легко увидеть вещи, которые можно упростить, и мы работаем в этом направлении. Выглядит так, будто у нас всё слишком сложно и разработчику наверняка не нужно обо всём этом знать.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Как уйти на пенсию до 40 лет с миллионом долларов на счету в банке

Намучавшись с работами, требующими слишком больших нагрузок, миллениалы увольняются и присоединяются к движению FIRE Карл Дженсен испытал то, что он называет «пробуждением», примерно в 2012-м году. Работа была напряжённой: ему приходилось документировать каждый шаг для Управления по санитарному надзору за ...

Дизайн-процессы в ISPsystem. Как внедрить идеологию, построить отдел и остаться в живых

История об одном редизайне, который изменил подход к разработке в ISPsystem. На тот момент ситуация с продуктовым дизайном была следующая: решения по продуктам принимались руководством и программистами, никаких дизайнеров или проектировщиков не было. Я пришёл в ISPsystem в апреле 2016 ...