Всем привет! Я Сергей, backend-разработчик в Банки.ру. За последние 15 лет я прошёл онбординг в разных компаниях — от SEO и e-commerce до финтеха. Каждый раз сталкивался с одной и той же проблемой: даже с опытом первые недели уходят не на задачи, а на попытки понять, как устроена система. В этой статье я объясню, почему так происходит, и покажу, какие подходы помогают ускорить онбординг — как для разработчика, так и для тимлида.

Несмотря на опыт, первые недели ощущаются так, будто я снова джун. В какой-то момент ловлю себя на мысли: «Каждый новый проект — как новый сервер в MMORPG. Неважно, сколько у меня часов на аккаунте — я снова 1 уровень». Сначала это бьёт по самолюбию. Кажется, что я должен схватывать всё на лету. Но проблема не в уровне знаний. За последние годы онбординг изменился — и старые стратегии «просто разобраться в коде» больше не работают.

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

Лет 15 назад онбординг был проще. Я работал над сайтами, интернет-магазинами, SEO-проектами. Обычно всё сводилось к одной схеме: дают доступ (FTP или SSH), показывают, как запустить проект, и задача — разобраться в коде. Архитектура была монолитной, бизнес-логика — в одном месте. Чтобы начать приносить пользу, достаточно было понять структуру и аккуратно встроиться в неё.

Потом появились code review, pull request, CI/CD. Это добавило слои: нужно было понимать, как изменения проходят в продакшен. Доступы стали разграничёнными — сначала только к коду, остальное — по мере необходимости. Но система оставалась прозрачной: можно было быстро проследить путь от запроса до результата.

Что изменилось сейчас

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

Самое неожиданное: главная сложность — не технологии. Языки, фреймворки, инструменты — к ним адаптироваться легко. Основная трудность — контекст. Где на самом деле логика? За что отвечает каждый сервис? Откуда данные и куда уходят? Что — источник истины, а что — прокси?

Например, мне нужно было обновить библиотеку и добавить переменные для деплоя через k8s/ansible. Задача простая: найти конфиги, прописать значения, задеплоить. Но часть переменных — в одном репозитории, часть — в другом сервисе, часть — формируется в CI, часть — переопределяется в Kubernetes. Изнутри одного сервиса картина не складывается. Только когда собираешь цепочку целиком — всё становится понятно.

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

Поэтому даже сильные разработчики могут «тормозить» в первые недели. Дело не в навыках, а в перегрузке контекстом: слишком много новых сущностей, связей, терминов. Плюс внутреннее давление: «Я же не новичок!» — из-за чего копаешь дольше, вместо того чтобы просто уточнить.

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

Что помогает нарисовать карту системы

Успех онбординга зависит от прозрачности процессов, коммуникаций и наличия, к кому обратиться. Но и сам разработчик может ускорить процесс. Два ключевых инструмента — code review и ИИ.

Первая — code review

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

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

Ещё пример: нужно было отдать клиенту данные. Я получил их напрямую и обработал у себя. Решение работало, но дублировало логику. В ревью написали: «Здесь дублирование. Лучше доработать сервис, чем переносить обработку сюда.»

Опять — пересобрал решение, но зато понял, где должна жить логика и как выстраиваются границы. Комментарии были не про синтаксис, а про архитектуру. Именно поэтому code review ускоряет онбординг сильнее, чем любые другие правки.

Вторая — ИИ

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

• Быстрый навигатор по команде. В первые дни анализировал чаты через ИИ: какие вопросы где решаются, к кому идти. За пару запросов получил карту коммуникаций.
• Разбор участников задачи. Через ИИ анализировал описание и логи, чтобы сформировать гипотезы: какие сервисы участвуют, где источник данных, какие зависимости. Это помогает не начинать «вслепую».
• Разбор комментариев из ревью. Проверял правки через ИИ, чтобы выделить архитектурные принципы: где источник данных, где живёт логика, какие границы у сервисов. Так отдельные замечания складываются в цельную картину.

Чаще всего работаю с ИИ через CLI — рядом с кодом и логами. В UI переключаюсь, когда нужно разобрать запросы с фронта. ИИ не заменяет понимание. Он ускоряет онбординг только при базовой карте системы. Без неё он может направить в неправильную сторону.

Взгляд со стороны тимлида

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

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

• Понятно, с чего начать.
• Есть путь от первого дня до первых задач.
• Заранее сняты основные точки застревания.

Разница очевидна: в одном случае разработчик тратит недели на «сбор картинки», в другом — приносит пользу уже в первые дни. Без управления онбордингом энергия уходит не на задачи, а на борьбу с неопределённостью.

В одном проекте с первого дня мне назначили человека — точку опоры. Он помог разобраться в базовых вещах, показал, куда смотреть. Тимлид провёл вводный созвон: объяснил архитектуру, дал ссылки на вики, обозначил ключевые сервисы. Доступы выдавали по мере необходимости. Уже в первые дни была задача, покрывающая полный цикл — от кода до продакшена. Благодаря этому быстро стало понятно, как устроена система.

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

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

В таких командах онбординг эффективен, когда:

• Информацию дают дозированно.
• Первую задачу выдают быстро — чтобы пройти полный цикл.
• Архитектуру объясняют на примерах, а не только через документацию.
• Есть точка опоры — бадди или опытный разработчик.

Как пройти онбординг: чек-лист из 9 пунктов для разработчика

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

Как в MMORPG: вопрос не в уровне, а в «механиках прокачки». Ниже — практические шаги, которые реально ускоряют онбординг.

1/9 — Сначала посмотрите, как система ведёт себя в реальности.
Не начинайте с кода и документации. Сначала изучите:
• логи — что реально происходит,
• CI/CD — как изменения доходят до продакшена,
• runtime — как система работает в реальных сценариях.
Без этого картина будет неполной.

2/9 — Соберите карту системы, потом идите в код.
Код без контекста редко даёт понимание. На старте зафиксируйте:
• какие есть домены,
• какие сервисы участвуют,
• где источник данных, а где прокси,
• как проходит пользовательский сценарий от начала до конца.
После этого код станет осмысленнее.

3/9 — Задавайте вопросы коллегам раньше, чем кажется нужным.
Не ждите, пока всё застрянет. Достаточно уточнить:
• где источник данных,
• сервис обрабатывает данные или просто проксирует.
Это быстрее корректирует модель системы, чем долгий разбор.

4/9 — Code review — один из самых быстрых способов учиться.
Используйте его не только как этап сдачи задачи. Смотрите:
• какие правки оставляют,
• где останавливают,
• какие решения считаются нормой.
Так вы быстрее поймёте, как в команде принято писать код.

5/9 — Проверяйте гипотезы через runtime.
Документация и код не всегда отражают реальное поведение. Ориентируйтесь на:
• реальные запросы,
• реальные ошибки,
• реальные пользовательские сценарии.
Там видно, как система работает на практике.

6/9 — ИИ — инструмент, а не источник истины.
Он полезен, когда уже есть базовое понимание:
• помогает проверять гипотезы,
• ускоряет разбор кода.
Без контекста ИИ может дать правдоподобные, но неверные объяснения.

7/9 — Не пытайтесь понять всю систему сразу.
Эффективнее сначала собрать связную картину хотя бы одного сценария. Понимание одного полного пути полезнее, чем поверхностное знание всей системы.

8/9 — Ограничьте время на самостоятельный поиск.
Если гипотеза не подтверждается за разумное время — уточните контекст у коллег. Нужный ответ часто можно получить быстрее, чем дойти до него самому.

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

Как это выглядит со стороны команды

Большинство проблем онбординга — не разработчика, а системы. Если:

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

За 15 лет онбординг эволюционировал из простого в сложный многослойный процесс. Главный парадокс: с ростом опыта он не становится проще. Он становится только быстрее — если к нему правильно подходить.

Всем привет! Я Сергей, backend-разработчик в Банки.ру. За последние 15 лет я несколько раз проходил онбординг в разных компаниях – от SEO и E-commerce до финтеха. И каждый раз видел одну и ту же проблему: даже с опытом первые недели уходят не на задачи, а на попытки понять, как вообще устроена система.В этой статье я разберу, почему так происходит и какие подходы помогают ускорить онбординг – как для разработчика, так и для тимлида, который его выстраивает.

Несмотря на опыт, первые недели всё равно ощущаются так, будто я снова джун. В какой-то момент ловлю себя на мысли: «Каждый новый проект – это как новый сервер в MMORPG. И неважно, сколько у меня часов на аккаунте – я снова 1 уровень».Сначала это немного бьёт по самолюбию. Кажется, что я должен быстрее. Что «здесь-то я точно сейчас разберусь». Но на практике проблема оказывается не в скорости или уровне разработчика. За последние годы сам онбординг сильно изменился – и старые стратегии «просто разобраться в коде» больше не работают.

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

Если откатиться примерно на 15 лет назад, онбординг действительно был проще – по крайней мере, в тех проектах, с которыми я работал. В то время я в основном занимался разработкой сайтов для клиентов, в том числе интернет-магазинов и информационных порталов. Параллельно мы делали SEO – готовили технические задания и дорабатывали проекты под требования поисковых систем. Обычно всё сводилось к довольно понятной схеме: тебе дают доступ к проекту (обычно было FTP или SSH), показывают, как его запустить, и дальше основная задача – разобраться в коде. Архитектура чаще всего была монолитной, бизнес-логика – в одном месте, и чтобы начать приносить пользу, нужно было просто понять структуру и аккуратно в неё встроиться.

Со временем начали появляться дополнительные процессы: code review, pull request, CI/CD – всё это добавило новый слой и необходимость разобраться как в команде происходят изменения и как они доходят до продакшена. При этом доступы к системе стали более сложными и многоуровневыми: обычно на старте пускали только  в кодовую базу, а остальные части инфраструктуры «открывали» по мере необходимости. Но при этом сама система всё ещё оставалась прозрачной: можно было относительно быстро проследить путь от запроса до результата.

Что изменилось сейчас

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

На практике это хорошо видно даже на базовых задачах. Например, в первые дни мне нужно было обновить библиотеку и добавить новые переменные для деплоя сервиса через k8s/ansible. На первый взгляд задача выглядела простой: найти конфиги, прописать значения и задеплоить изменения.

В итоге оказалось, что часть переменных лежит в одном репозитории, часть подтягивается из другого сервиса, часть формируется на этапе CI, а часть переопределяется в окружении Kubernetes. Если смотреть на это «изнутри одного сервиса», картина не сходится. Но как только начинаешь собирать цепочку целиком – от конфигов до деплоя – всё становится на свои места.

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

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

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

Что помогает нарисовать карту системы

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

Первая – code review

Когда я смотрю, какие правки мне оставляют, какие решения обсуждаются, какие паттерны считаются нормой – я гораздо быстрее встраиваюсь в команду, чем если бы просто читал код в одиночку. В моём опыте особенно хорошо это работает, когда в ревью участвуют не только разработчики из команды, но и тимлиды или коллеги из соседних сервисов.Например, в одном из ревью мне оставили комментарий примерно такого вида:«Лучше не ходить напрямую в этот сервис. Он не источник и в некоторых сценариях может вернуть устаревшие данные. Для этого кейса есть отдельный сервис.»После этого пришлось заметно переработать решение, но при этом стало понятно, как правильно устроен этот кусок системы и где находится источник данных.Ещё один пример – когда решение работает, но нарушает границы системы. В одной из задач нужно было отдать клиенту определённые данные. Я получил их напрямую из другого метода и добавил необходимую обработку у себя. Решение работало, но по сути обходило нормальный путь получения данных и дублировало логику. В ревью мне оставили комментарий:«Здесь получается дублирование логики. Лучше доработать сервис, чем переносить обработку сюда.»

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

И вторая – ИИ

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

Конкретно в онбординге он помогает в нескольких сценариях:

1. Быстрый навигатор по команде и процессамВ первые дни я использовал ИИ, чтобы разобрать структуру рабочих чатов и каналов: какие вопросы где решаются, к кому идти с конкретной проблемой. За один-два запроса получается карта коммуникаций – кто отвечает за инфраструктуру, где обсуждают релизы, куда писать по багам. Это сильно сокращает время, когда не понимаешь, «куда вообще идти с вопросом».

2. Разобраться, какие сервисы участвуют в задачеПри разборе первой задачи я анализировал с помощью ИИ описание и логи, чтобы быстро сформировать гипотезы: какие сервисы участвуют в сценарии, где может быть источник данных, какие зависимости есть. Это не даёт готового ответа, но помогает быстрее собрать первичную модель системы и не начинать «вслепую» с кода.

3. Разбор комментариев из code reviewПосле ревью я проверял комментарии через ИИ, чтобы зафиксировать, какие архитектурные принципы за ними стоят: где находится источник данных, где должна жить логика, какие границы у сервисов. В результате отдельные правки складываются в понятную картину системы, а не остаются разрозненными замечаниями.

Чаще всего я работаю с ИИ через CLI – это позволяет использовать его прямо рядом с кодом и логами, без переключения контекста. В UI переключаюсь, когда нужно посмотреть поведение системы или разобрать запросы с фронта. ИИ не заменяет понимание системы. Он ускоряет онбординг только тогда, когда есть хотя бы базовая карта. Без неё он скорее помогает быстрее пойти в неправильную сторону.

Взгляд со стороны тимлида

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

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

Разницу между этими подходами я хорошо видел на практике: в одном случае разработчик тратит недели на попытки «собрать картину», в другом – начинает приносить пользу уже в первые дни. И если этим не управлять, разработчик будет тратить энергию не на задачи, а на борьбу с неопределённостью.

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

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

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

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

Как пройти онбординг: чек-лист из 9 пунктов для разработчика

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

И, как показывает практика, именно это и отличает «долгий онбординг» от быстрого.

Если продолжить метафору с MMORPG – вопрос не в том, какой у тебя уровень, а в том, какие у тебя есть «механики прокачки».

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

1/9 – Сначала стоит посмотреть, как система ведёт себя в реальности.Не стоит начинать с кода и документации. Сначала полезно посмотреть:• логи – что реально происходит,• CI/CD – как изменения доходят до продакшена,• runtime – как система ведёт себя в реальных сценариях.

Без этого картина почти всегда будет неполной.

2/9 – Собрать карту системы, потом идти в код.Код без контекста редко даёт полное понимание системы. На старте полезно зафиксировать:• какие есть домены,• какие сервисы участвуют,• где источник данных, а где прокси,• как проходит пользовательский сценарий от начала до конца.

После этого код начинает восприниматься гораздо осмысленнее.

3/9 – Вопросы коллегам лучше задавать раньше, чем кажется нужным.Не дожидаясь ситуации, когда всё уже зашло в тупик. Обычно достаточно уточнить:• где в этом сценарии источник данных,• сервис обрабатывает данные или просто проксирует.

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

4/9 – Code review – это один из самых быстрых способов учиться.Важно использовать его не только как этап «сдать задачу». Полезно смотреть:• какие правки оставляют,• где останавливают,• какие решения считаются нормой.

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

5/9 – Проверка гипотез через runtime.Документация и код не всегда отражают текущее поведение системы. Поэтому имеет смысл ориентироваться на:• реальные запросы,• реальные ошибки,• реальные пользовательские сценарии.

Именно там видно, как система работает на практике.

6/9 – ИИ работает как инструмент, а не как источник истины.ИИ начинает приносить пользу, когда уже есть базовое понимание системы:• помогает проверять гипотезы,• ускоряет разбор кода.

Без этого он может давать правдоподобные, но неверные объяснения.

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

8/9 – Ограничение времени на самостоятельный поиск.Если гипотеза не подтверждается за разумное время, имеет смысл уточнить контекст у коллег. На практике нужный ответ часто можно получить быстрее, чем дойти до него самостоятельно.

9/9 – Найти носителя контекста.Это может быть тимлид, опытный разработчик, или любой, кто хорошо понимает систему. Наличие такого человека на старте заметно сокращает время онбординга.

Как это выглядит со стороны команды

С другой стороны, большинство проблем онбординга – это не проблема разработчика, а проблема системы. Если:

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

Если подытожить, то за последние 15 лет онбординг эволюционировал из простого в сложный многослойный процесс. И главный парадокс в том, что с ростом опыта он не становится «проще». Он становится просто быстрее – если правильно к нему подходить.

Спасибо что прочитали статью, буду рад пообщаться в комментариях!