Онбординг разработчика: быстрая схема | АйТи-Капитан Объясняет

Привет, я Михаил, канал IT капитан. Сегодня 

поговорим про процесс онбординга. Мы нанимаем программиста. Один из них нам понравился. 

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

быстрее погрузить разработчика в рабочий процесс. Давайте об этом сегодня поговорим. И 

нам с вами, разработчику, которого мы нанимаем, важно понимать, что это за компания, в которую 

мы его приглашаем, что это за проект, над которым будет работать и с кем он будет работать. Всё 

это мы можем сделать ещё до трудоустройства, тем самым меньше времени потратим в первый рабочий 

день человека. А компании можно сделать какую-то презентацию и прикрепить её к оферу. Отправить 

просто двумя файлами. офер с предложением о работе и второй файл информации о компании, о 

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

стресс. хорошим тоном будет рассказать ему о том, что его ждёт, куда он подъедет, по какому адресу, 

кому позвонить, если заблудится или напишет, где он припаркует машину платно или бесплатно, какие 

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

принести в оригинале. Всё это тема для отдельного видео, на самом деле, про то, как создать и 

развить свой HR бренд на рынке труда. Но мы сейчас не об этом. Мы о том, что часть мероприятий можно 

провести не в первый рабочий день сотрудника, а ещё до его трудоустройства. Итак, наступает 

первый рабочий день нашего программиста. И он попадает вот сюда. Вот наш разработчик. 

Вот, например, наш IT-отдел, в котором много людей и много процессов. И первое, что мы должны 

сделать - это разобраться с бумагами. Как можно оптимизировать процесс оформления? Можно взять у 

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

человека ждать процесса оформления, а просто, например, подписать NDA, если он у вас есть, 

и всё, уже можно начинать вводить человека в курс дела потихоньку. Всё, пока отдел кадров 

занимается оформлением, мы не сидим, не ждём. подписали соглашение, неразглашение и уже можем 

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

Первоочередное - это доступ к корпоративной почте, доступ к задачнику, к документации проекта, доступ 

к каким-то тестовым серверам, доступ к кодовой базе, к системе контроля версий, может быть уже к 

CICD платформы, если у нас какая-то она отдельная, и может быть к мониторингу. Здесь важно понимать, 

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

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

человека: "Проверь, получилось дать доступ или не получилось". Ой, не получилось. Сейчас вот здесь, 

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

очень быстренько человек оказывается на своей рабочей почте, в вашем рабочем чате и получает 

ссылку на документацию по процессам в отделе и по проекту, над которым ему предстоит работать. 

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

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

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

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

понимать, куда этот код потом выкатывается. То есть где находится тестовый сервер, где находится 

prodдаction, может быть ещё stage где-то здесь посерединке. И здесь вопросов может быть огромное 

количество для того, чтобы разработчик на каждый на каждое свои действие не ходил с вопросами к 

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

документации по процессам. Очень часто об этом забывают, но, по-моему, это очень важно. Весь вот 

этот процесс должен быть описан, причём с разных сторон. У бэкэнд разработчиков свой процесс, 

у фронтв может чуть-чуть отличаться. Окей, свой процесс, у девопсов свой. Вот мы сейчас 

говорим вот об этом человеке, окэнд разработчике. Что им предстоит сделать? Взять какой-то 

репозиторий, создать там ветку, а как её назвать? внести изменения в коде, закоммитить. А как 

назвать комит? В какой статус перевести задачу после того, как закомитил? Нужно ли кому-то кидать 

ссылку на ветку или на мешреквест? Сколько опрувов ждать во время кодрев? Кто должен заопрувить? 

Что дальше будет с этим кодом происходить? Его кто-то кто-то возьмёт в релизную ветку 

или тестировщики сами выкатят или разработчик должен куда-то это выкатить. Что будет дальше 

с этим происходить? Когда будет происходить процесс тестирования? Где появятся баги, если они 

обнаружатся в задачах? И какой порядок их правки? как часто код попадает в продакшн и как 

разработчик будет узнавать о каких-то инцидентах. Мы должны ввести человека в курс дела 

о том, когда у него происходят созвоны, например, или собрание в переговорке с его коллегами. Какие 

есть ритуалы в команде, там ежедневные, допустим, митинги, ретроспективы? спрингпнинге. Если это 

спринт, то какая его длительность? И вот это вот всё очень большое количество информации, которое 

полезно будет сдокументировать нам с вами самим же. А человек просто придёт и прочитает всё 

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

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

ознакомился с проектом. Запустить проект вместе со всеми зависимостями. Это очень важно. 

Сейчас расскажу про это подробнее. Вот посмотрим, например, на тестовый сервер. У 

нас есть несколько приложений. база данных, допустим, SQL, допустим, для поиска 

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

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

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

будет у себя настраивать отдельно базу данных, отдельно эластик, отдельно кавку, то это вообще 

неэффективно и займёт кучу времени. Конфиги ещё у каждого будут свои. Всё уже давно придумано. 

Все эти конфигурации зависимости описываются в docker compost файлах, например, и проект 

должен разворачиваться в две или три команды. То есть делаем сначала gitкcone, выкачиваем 

репозиторий и пишем какой-нибудь makeit. И после этого docker compos up, всё, проект должен 

начать работать. Если у нас с вами не так, то процесс развёртывания проекта на компьютере 

разработчика может затянуться и очень сильно в зависимости от размера проекта. Когда проект 

развёрнут, то наступает время первой задачи. Всё. Можно подготовить для человека простую 

задачу. Чаще всего это какой-то баг, например, хорошо описанный и легко воспроизводимый. 

Что будет происходить дальше? Разработчик зайдёт вктрекер, где на него назначит задачку, 

которую надо выполнить, прочитает. Если это баг, то не ТЗ, а, например, текущий результат 

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

Проект у него на компьютере уже запущен, поэтому может он уже прочитал всю документацию 

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

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

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

мы создаём мерреквесты, кого назначаем ревьюверами на код. Весь вот этот, э, путь новый сотрудник уже 

проделает. И всё, что мы с вами проделали. Новому сотруднику интересно же, в какой компании он будет 

работать. Интересно. Интересно узнать о проекте, над которым он будет трудиться. Да, интересно. 

Мы заранее выслали ему всю эту информацию и не потратили время в первый его рабочий день. После 

этого приняли бумаги на оформление и не заставили сотрудника ждать, а просто потом вызвали 

его за подписью. Тем временем предоставили доступы, если он подписал соглашение о 

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

где подробно расписано о процессах и о проекте. Всё, человек читает, ознакамливается и после этого 

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

чётко. После этого человека можно взять простейшую задачку в работу. То есть должен подготовить 

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

просто прошёлся по всем вот этим вот э процессам, которые сопровождают задачу. И всё, официальная 

часть презентации закончилась. Хочется сказать немного про ошибки. Ну, не все, не будем прямо все 

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

пятый пункт. Переносимое окружение. Вот. Давайте сейчас ещё раз вернёмся к схеме нашей. Для того, 

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

четыре разработчика, все четверо будут всё это разворачивать, это займёт большое количество 

времени. И зачем? Всё уже придумано. Приходит разработчик, пишет Docker Compost App, всё, всё 

вот это вот поднимается, вся инфраструктура. Я встречал в своей практике компании, 

которые этого не делали, несмотря на то, что проекты были очень большие. И между 

первым рабочим днём программиста до того, как он приступит к своей первой простейшей задаче, 

уходило до 3 недель. Это просто что-то невероятное и очень невыгодное для компании. Я скажу так, 

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

разворачивать всё это у себя вот на компьютере вот по отдельности на хостмашине, скажем 

так. По времени примерно одинаково занимает. Что так? Что описать инфраструктуру в докере, 

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

Вот лучше на это потратьте усилия. Ну и в моём личном рейтинге на втором месте по 

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

что в компаниях не отлажен этот процесс и выдача доступов новых новым 

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

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

Капитан. Будет много интересного. Пока. M.