Вы нашли работу в IT. Игра началась

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

После оффера уже начинается работа компании

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

Отдельно готовят информационный вход. Обычно это материалы по компании, welcome-видео, чек-лист первого дня и Onboarding book. HR остаётся контактом для человека до выхода, чтобы новичок не искал ответы через случайных людей в команде.

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

Для удалённой команды подготовка начинается ещё раньше: технику и welcome-pack отправляют до первого дня, иначе старт задержится из-за доставки, склада и ручных уточнений.

К первому дню у разработчика должен быть минимальный технический набор:

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

Команда должна знать, кто к ней пришёл

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

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

На старте лучше узнать:

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

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

Наставник

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

Первые задачи

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

Траектория задач в первое время у вас будет стандартная: баги → баги сложнее → фича с кем-то → своя фича. Сколько времени занимает каждый переход — зависит от размера проекта. В крупных командах на полное погружение уходит больше года. Это норма, не отставание.

Отдельно про ТЗ. В тикете почти никогда нет полного контекста. Часть вещей считается само собой разумеющейся, часть обросла локальным сленгом. Сделаете задачу — появится дополнительный контекст, который никто не упомянул, и придётся переделывать. Мотивация падает именно здесь.

Что помогает:

• Уточнять задачу до того, как начали, а не после
• Узнавать, кто писал этот код — иногда человек ещё в команде
• Не пытаться добивать задачу самостоятельно, где не понимаете систему, нужно уметь разговаривать

Атмосфера

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

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

Три месяца

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

Как выглядит нормальный ритм:

• Еженедельные one-to-one с руководителем — задачи, сложности, обратная связь
• Встреча с HR через две недели — как адаптируетесь, всё ли понятно, нужна ли дополнительная поддержка
• Итоговая встреча через три месяца — что получилось, что нет, что дальше

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

Компании, где онбординг выстроен правильно, фиксируют снижение увольнений в первые полгода на 7%. Цифра небольшая, но она про системный эффект: когда человек понимает правила игры с первого дня, он реже уходит из-за того, что просто не разобрался.

На что смотреть

Три признака, что онбординг нормальный:

• Техника пришла до первого дня, доступы открыты, HR на связи. 
• Есть наставник и план на три месяца.
• Вас представили команде — не попросили познакомиться самому.

Три красных флага:

1. Нет наставника вообще. 
2. Нет плана задач даже на первый месяц. 
3. HR исчез после первого дня и больше не появлялся.

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