Всем привет! Я Сергей, 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 лет онбординг эволюционировал из простого в сложный многослойный процесс. И главный парадокс в том, что с ростом опыта он не становится «проще». Он становится просто быстрее – если правильно к нему подходить.

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