Как быстрее онбордить инженеров – не про документацию
Как быстрее онбордить инженеров, устранив реальное узкое место: разрозненный контекст в Slack, GitHub и Linear, который не захватит никакая вики.
By Ellis Keane · 2026-03-31
Когда я пришёл в команду, которая понятия не имела о том, как она работает
Если вас интересует, как быстрее онбордить инженеров, позвольте рассказать о моём собственном опыте онбординга – это, пожалуй, лучший аргумент, который у меня есть.
В 2019 году я пришёл в стартап в Сан-Франциско третьим инженером. CTO – блестящий и феноменально неорганизованный парень – вручил мне ноутбук в первый день и фактически сказал: «Код на GitHub. Всё остальное – в Slack. Удачи.»
Вот и весь онбординг.
Первые три недели я занимался тем, что, если вдуматься, не имело никакого отношения к инженерии: археологией. Копался в тредах Slack шестимесячной давности, пытаясь понять, почему система аутентификации была построена именно так. Листал закрытые PR в GitHub в поисках разговоров о решениях по схеме базы данных, которые никто нигде не задокументировал (само собой). Задавая вопросы в #general, получал ответы вроде «а, это – мы пересмотрели решение в январе, посмотри тред с нашим дизайнером».
Какой тред? С каким дизайнером? В каком канале?
Он не был плохим менеджером. Он работал в мире, где институциональные знания жили исключительно в головах людей и были разбросаны по четырём разным инструментам – что, если честно, описывает большинство инженерных команд. Каждый мой вопрос требовал, чтобы кто-то прерывал свою работу, переключал контекст в «режим онбординга», откапывал нужный тред или документ и пытался восстановить обоснование решения, принятого месяцы назад. Можно было почти услышать, как скрипят ментальные шестерёнки.
Три недели инженера, занимавшегося археологией вместо инженерии, плюс суммарный Cost прерываний всех, кто отвечал на мои вопросы, – это реальные деньги, даже если они никогда не появляются в балансе.
Этот опыт был не уникальным. Я провёл десять лет, управляя Vulcan – нашим агентством дизайна и инжиниринга, – и потратил на удивление много этого времени, входя в организации, которые были ещё более дезорганизованы, чем я (невысокая планка, честно говоря). Каждый клиент, один и тот же паттерн: знания существовали, но жили в головах людей и в инструментах, которые никто не догадался связать.
Как быстрее онбордить инженеров: решайте проблему поиска, а не документации
Большинство онбординговых плейбуков рассматривают онбординг инженеров как проблему контента. Пишите лучшую документацию! Стройте вики в Notion! Создавайте цветные чек-листы с майлстоунами!
Чек-листы – дело хорошее. Я не призываю выбросить шаблон «День 1 – День 30». Но настоящее узкое место не в том, что «у нас мало документации». Полезный контекст – запутанный, нюансированный, реальный – живёт в тредах Slack, комментариях к PR в GitHub, описаниях задач в Linear и в случайной аннотации Figma, которую дизайнер оставил за шесть недель до прихода нового сотрудника. Коллективно за два десятилетия мы строили вики, описывающие, что делает программное обеспечение, и почти не тратили время на то, чтобы сделать «почему» discoverable.
Ни одна вики не захватывает «почему». Вики захватывает то, что кто-то счёл достойным записи, – а это совершенно другое дело, не то, что новый инженер на самом деле должен знать.
Настоящее узкое место онбординга – не документация: это то, что полезный контекст живёт в инструментах, о которых никто не подумал, что их можно искать. attribution: Chris Calo
С тех пор, онбордя инженеров – сначала в агентстве дизайна, потом создавая Sugarbug, – я видел, как один и тот же паттерн повторяется. Вопросы новых сотрудников делятся примерно на четыре категории, из которых только одна закрывается традиционной документацией для онбординга:
Что покрывают документы
- Обзор архитектуры – диаграммы систем, границы сервисов, топология деплоя
- Локальная настройка – как клонировать, собирать, запускать и тестировать
- Стандарты кода – правила линтинга, конвенции PR, паттерны именования
Чего документы не покрывают
- История решений – почему эта архитектура, а не три альтернативы, обсуждавшиеся в Slack?
- Неявные знания – кто реально отвечает за модуль биллинга? Кто принял то решение по CSS?
- Цепочки контекста – задача в Linear, связанная с PR, связанным с обсуждением дизайна, связанным со спецификацией продукта
- Текущее состояние – над чем сейчас работаем и почему?
Колонка «что покрывают документы» – это то, что оптимизирует большинство команд. По моему опыту, колонка «чего документы не покрывают» – это там, где новые инженеры проводят большую часть времени акклиматизации: там живут настоящие ответы, и именно туда никто не направляет новичков.
Эта информация отсутствует не потому, что её никто не записал. Она была записана – в сообщениях Slack, комментариях к ревью в GitHub, обновлениях задач в Linear. Проблема в обнаруживаемости, а не в документации.
Налог прерываний, который никто не закладывает в бюджет
Каждый раз, когда новый инженер спрашивает «почему мы это построили именно так?» и старший инженер бросает работу, чтобы ответить, происходят две вещи. Новый сотрудник получает ответ (хорошо), а старший теряет значительный блок продуктивной концентрации – не те 2 минуты, которые потребовались на вопрос, а около 15 минут, нужных для поиска нужного треда, восстановления обоснования и возвращения к тому, чем он занимался.
stat: "Несколько раз в день" headline: "Прерывания от одного адаптирующегося инженера" source: "На основе наших собственных паттернов онбординга в Sugarbug"
Когда вы нанимаете двух инженеров в одном квартале (что, если вы растущий стартап, вероятно и происходит), существующая команда поглощает непомерное количество прерываний неделями напролёт. Люди, которых вы наняли для увеличения скорости, временно её снижают. Никто это не закладывает в бюджет, потому что никто не измеряет – оно просто проявляется как смутное ощущение, что «команда в этом квартале работает медленнее», не связывая это с онбордингом.
И самое обидное: ответы на эти вопросы уже где-то существуют. В Slack, GitHub, Linear. Информация была зафиксирована в момент принятия решения. Она просто лежит в инструменте, в поиске по которому никто не научил нового сотрудника, в канале, о существовании которого он не знает, под заголовком треда, который ничего не значит без контекста.
Связанный контекст: что это значит на практике
Связанный контекст при онбординге инженеров означает, что новый сотрудник может искать по всем инструментам команды – Slack, GitHub, Linear, Notion – из единого интерфейса. Не просто поиск по ключевым словам (поиск в Slack, если честно, в лучшем случае сносный, а в худшем – активно мешающий), а контекстный поиск, понимающий связи между вещами.
«Покажи всё, связанное с рефакторингом модуля биллинга» возвращает: эпик в Linear, шесть PR в GitHub, тред Slack, где команда обсуждала подход, и архитектурный документ в Notion – всё связано, всё в хронологическом порядке, никакой археологии.
Вот в чём суть: граф знаний, который картирует связи между работой вашей команды во всех инструментах, создавая живой индекс того, кто что, где и почему решил.
Мы с Беном построили это, потому что провели годы, живя в альтернативе. В Vulcan мы управляли командами дизайна и инжиниринга в нескольких организациях одновременно – и без исключений наши реальные специальности сводились к одному: мы были прославленными человеческими роутерами информации. Два человека, которые должны были проектировать и строить, вместо этого проводили дни, отвечая на вопрос «где эта штука?» (душераздирающее осознание, поверьте). Это надо было остановить.
Связанный контекст – не про то, чтобы писать больше документации: это про то, чтобы сделать контекст, который уже существует в ваших инструментах, обнаруживаемым, доступным для поиска и связанным. Новым инженерам не нужно знать, в каком канале Slack искать или какой репозиторий GitHub проверять.
Именно это мы строим в Sugarbug. Граф знаний связывает задачи Linear с PR в GitHub, переписки Slack с документами Notion – и делает всё это доступным для поиска. Когда приходит новый сотрудник, с первого дня у него есть доступ к истории решений команды. (Рабочие процессы, специфические для онбординга, мы ещё шлифуем – но лежащий в основе граф и есть фундамент.)
Трёхнедельный фреймворк онбординга инженеров
Итак, вот фреймворк, который я хотел бы иметь, когда мне вручили ноутбук со словами «удачи». Если вы думаете о том, как быстрее онбордить инженеров, это работает, потому что решает реальное узкое место (обнаруживаемость), а не воображаемое (объём документации).
Неделя 1: Ориентация
Дайте новому сотруднику «компаньона по контексту» – не ментора, а человека, который хорошо знает, где живёт информация (необязательно самого опытного – иногда это тот, кто сам больше всех спрашивал в последнее время и имеет самую свежую карту расположения вещей). Задача компаньона – не отвечать на каждый вопрос. Его роль – говорить: «это решение было принято в канале #backend примерно в феврале, давай найдём тред».
Если вы используете инструмент связанного контекста вроде Sugarbug, задача компаньона становится значительно проще: «поищи "рефакторинг модуля биллинга" и увидишь всю цепочку решений».
Неделя 2: Навигация
К этому времени новый сотрудник должен уже делать первые PR, но важнее то, что он строит ментальную модель того, как общается команда. Какие обсуждения ведутся в Slack? Какие – в комментариях Linear? Какие – в ревью PR GitHub? Понимание топологии коммуникации важно не меньше, чем понимание кодовой базы – а в первый месяц, возможно, даже важнее. (Я видел инженеров, которые разобрались в коде за неделю, но через три недели всё ещё не знали, где искать решения.)
Неделя 3: Вклад
К третьей неделе, если проблема с контекстом решена, новый инженер должен вносить значимый вклад – не потому что выучил кодовую базу, а потому что знает, как найти нужное, не прерывая никого.
- [x] День 1: локальное окружение запущено, доступ ко всем инструментам выдан
- [x] Дни 2–3: назначен компаньон по контексту, проведён инструктаж по топологии коммуникаций
- [x] Неделя 1: завершены 2–3 «хорошие первые задачи» при поддержке компаньона
- [ ] Неделя 2: самостоятельные PR, поиск контекста перед тем как спросить
- [ ] Неделя 3: участие в обсуждениях дизайна, ревью PR коллег
- [ ] Месяц 2: самостоятельная продуктивность, еженедельные созвоны с компаньоном
Почему это накапливается (а вики – нет)
Разница между онбордингом инженеров через связанный контекст и через вики на 47 страниц в Notion, которую никто не ведёт (вы знаете эту – обновлялась восемь месяцев назад человеком, который уже ушёл), состоит в том, что связанный контекст накапливается. Каждый разговор команды в Slack, каждое ревью PR, каждое обновление задачи в Linear – всё индексируется, связывается и становится доступным для поиска. Граф знаний со временем становится богаче – без каких-либо дополнительных усилий с чьей-либо стороны.
Второй новый сотрудник извлекает выгоду из всего, что раскрыли вопросы онбординга первого. У пятого – граф ещё богаче. К десятому институциональные знания, которые раньше жили исключительно в голове у CTO, распределены, доступны для поиска и связаны.
И именно это по-настоящему меня захватывает в этом подходе! Не только выигрыш в эффективности – хотя из наших ранних разговоров с командами, практикующими связанный контекст, понятно, что сжатие времени акклиматизации реально. А ещё есть часть, которую я не предвидел: мы с Беном болтливые, и половина наших лучших идей исчезает в дневном шуме прежде, чем кто-то из нас их запишет (очень профессионально, знаю). Граф постоянно всплывает из наших разговоров ярлыки и действительно полезные инсайты, которые мы совершенно забыли. Если он может спасать контекст от двух человек, которые его построили, – представьте, что он делает для нового сотрудника, входящего в команду из пятнадцати.
Более глубокая ценность для команд, которые действительно хотят быстрее онбордить инженеров, – в том, что вы перестаёте терять институциональные знания, когда люди уходят. Цепочка контекста их решений остаётся – доступная для поиска – для всех, кто придёт после. Это не выигрыш в эффективности. Это организационная память.
Получайте сигнальную разведку прямо в свой почтовый ящик.
Часто задаваемые вопросы
Q: Как долго должен длиться онбординг нового инженера? A: По нашему опыту и из разговоров с другими инженерными командами: 2–3 месяца – типичный срок до полной продуктивности нового инженера. Узкое место редко связано с техническими навыками – речь идёт о том, чтобы понять, где хранятся решения, кто за что отвечает и как команда на самом деле общается через инструменты. Команды, использующие инструменты связанного контекста, сообщают о значительном сокращении этого срока, хотя точное улучшение зависит от размера команды и сложности инструментов.
Q: Помогает ли Sugarbug при онбординге инженеров? A: Да. Sugarbug строит живой граф знаний по всем вашим аккаунтам Linear, GitHub, Slack и Notion, чтобы новые инженеры могли искать прошлые решения, контекст того, почему фичи были построены именно так, и к кому обращаться с каким вопросом – не отвлекая никого.
Q: Что такое связанный контекст при онбординге инженеров? A: Связанный контекст означает связывание информации между инструментами так, чтобы новый сотрудник мог проследить решение от задачи в Linear через PR в GitHub до треда в Slack, где команда обсуждала подход. Когда эта цепочка становится доступной для поиска, новый сотрудник может самостоятельно находить ответы вместо того, чтобы отвлекать коллег, что сокращает время акклиматизации.
Q: Почему традиционные онбординговые вики не работают для инженеров? A: Вики захватывают то, что кто-то счёл достойным записи – обзоры архитектуры, гайды по настройке, стандарты кода. Настоящее узкое место акклиматизации – это запутанный, контекстный материал, живущий в тредах Slack, комментариях к PR и задачах Linear. Почему это было построено именно так? Кто принял это решение? Этот контекст уже зафиксирован в ваших инструментах – проблема в том, чтобы его найти, а не написать.
Q: Интегрируется ли Sugarbug с GitHub и Linear для онбординга? A: Да. Sugarbug подключается через API к GitHub, Linear, Slack, Notion, Figma и Google Calendar, индексируя переписки, задачи, PR-ы и документы в доступный для поиска граф знаний, который новые инженеры могут запрашивать с первого дня.