Адаптация новичка: первые недели глазами руководителя

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

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

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

Что вы покупаете этими неделями

Онбординг — не «знакомство с компанией», а перевод человека из состояния, где он потребляет ёмкость команды, в состояние, где он её добавляет. Обе фазы реальны и обе стоят денег.

Ключевое свойство площади под нулём: её оплачивают самые загруженные люди команды. Вопрос задают не случайному инженеру, а тому, кто знает систему, — обычно это тот же человек, кто ведёт критичную задачу и дежурит. Тот самый механизм, что описал Брукс в «Мифическом человеко-месяце» (1975): вход в контекст оплачивается временем тех, у кого его меньше всего.

def cost_hours(weeks: int = 6,        # недель до нулевого вклада
               buddy_week1: float = 6.0,  # часы buddy в первую неделю
               decay: float = 0.6,        # во сколько раз меньше каждую следующую
               lead_week: float = 2.5,    # ваши часы в неделю
               others_week: float = 3.0)  -> float:
    """Часы команды, потраченные на одного новичка до его выхода в плюс."""
    buddy = sum(buddy_week1 * decay ** w for w in range(weeks))
    return buddy + (lead_week + others_week) * weeks


for name, hours in [("с планом", cost_hours()),
                    ("без плана", cost_hours(weeks=12, buddy_week1=1.0, others_week=4.0))]:
    print(f"{name}: {hours:.0f} ч ≈ {hours / 40:.1f} чел-недели")
# с планом: 47 ч ≈ 1.2 чел-недели   (цифры подставляйте свои: ценность не в
# без плана: 80 ч ≈ 2.0 чел-недели   результате, а в том, что счёт сделан заранее)

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

Честно про доказательную базу

Онбординг — редкий для управленческих тем случай, где эмпирика есть, хотя и не там, где хочется.

Мета-анализ. Bauer, Bodner, Erdogan, Truxillo, Tucker, Newcomer adjustment during organizational socialization (Journal of Applied Psychology, 2007): ясность роли, самоэффективность и принятие командой связаны с включённостью и намерением остаться. Это корреляции на опросных данных, причинность из них не следует, но набор величин полезен — он говорит, что наблюдать: понимает ли человек, чего от него ждут, верит ли, что справляется, принят ли командой.

Полевой эксперимент — самое ценное, что здесь есть. Cable, Gino, Staats, Breaking Them In or Eliciting Their Best (Administrative Science Quarterly, 2013): в крупной аутсорсинговой компании новичков случайно распределили по вариантам вводного дня. Там, где человека просили рассказать о своих сильных сторонах и о том, что он привнесёт, текучесть через полгода оказалась заметно ниже, чем там, где ему рассказывали о компании и ценностях. Это рандомизация, а не опрос. Осторожность: одна компания, не инженерная работа, эффект мерили на удержании. Перенос: первый день, где спрашивают человека, работает лучше первого дня, где вещают ему.

Практические фреймворки. Талия Бауэр («Onboarding New Employees», SHRM Foundation, 2010) раскладывает адаптацию на формальности, ясность роли, культуру и связи. Не проверенная модель, а разметка: помогает заметить, что вы закрыли формальности и больше ничего.

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

Инженерная специфика. Begel, Simon, Novice Software Developers, All Over Again (ICER 2008) и Ju, Sajnani, Kelly, Herzig, A Case Study of Onboarding in Software Teams (ICSE 2021) — качественные разборы входа в реальные команды. Общий мотив: основные потери новичка идут не на язык и алгоритмы, а на инструменты, сборку, инфраструктуру и поиск владельца — ровно то, что старожилы считают очевидным и потому не документируют.

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

Что готовится до выхода

Главное отличие вашей позиции от позиции новичка: бо́льшая часть работы по адаптации делается до того, как человек появился. Неподготовленное превращается в простой первой недели, а он запоминается лучше всего остального.

Минимальный набор артефактов — с владельцем, сроком и признаком «не сделано»:

Отдельно про доступы — самый частый и самый обидный сбой. Заявка на прод в крупной компании проходит два-три согласования и живёт неделю; поданная в первый рабочий день, она означает, что человек неделю не может ни собрать проект, ни посмотреть логи. Если новичок не может выкатить изменение из-за прав, счётчик потерь идёт с первого дня — и это не только часы, но и первое, что человек узнаёт о команде: его выхода не ждали.

Первый день

Расписанный по часам первый день дёшев и непропорционально полезен; эмпирика Cable, Gino и Staats говорит, что устроить его лучше как разговор, а не как инструктаж.

## План первого дня — Миша, 16.07

10:00 Я. Полчаса: чем занимается команда, что сейчас горит. Дальше его вопросы.
10:30 Buddy (Аня). Окружение, сборка, прогон тестов локально. До обеда.
13:00 Обед с командой, без программы.
14:00 Buddy. Первая задача: почему она нужна, где менять.
15:00 Он один. Аня рядом, но не над душой.
16:30 Я. 20 минут: что непонятно, что мешает, чего не хватает.

Правила, которые я проговариваю в первый же час:
- Застрял больше чем на 30-40 минут — пиши. Это не «отвлекать», это работа.
- Вопросы — в общий канал, не мне в личку: отвечает тот, кто свободен,
  и ответ остаётся другим.
- Всё, обо что споткнулся в документации, правишь сам. Это часть задачи.
- Первые две недели ты ничего не ломаешь необратимо: есть ревью и откат.

Правило «застрял на 30–40 минут — спрашивай» проговаривается с числом: иначе новичок выберет одну из двух плохих стратегий — молчать сутки, чтобы не выглядеть беспомощным, или спрашивать по любому поводу. Оба поведения потом читаются как черта характера, хотя это отсутствие нормы.

Первая задача

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

• Настоящая, из бэклога. Нарушение: задача придумана специально и никому не нужна — человек понимает это к среде, и права спросить у него больше нет.
• Маленькая, но проходит весь конвейер «тикет → ветка → ревью → CI → стенд → прод → логи». Нарушение: код написан на второй день, а выкатили через три недели вместе с релизом.
• Некритичная по срокам и с понятным критерием готовности. Нарушения: «поторопись, ждут» на четвёртый день; «посмотри, что там можно улучшить» вместо постановки.
• Со стабильным ревьюером. Нарушение: первый PR висит два дня без комментариев — сильнейший из возможных сигналов «твоя работа никому не нужна».
• Затрагивает код, который команда трогает часто. Нарушение: новичка отправили в мёртвый угол системы, где он выучил то, что больше не пригодится.

Величина, которую стоит завести, — время до первого изменения в проде. Полезна она не как бенчмарк (в банке и в стартапе это разные числа), а как тренд по последним новичкам: если у троих подряд это две недели, проблема не в людях, а в конвейере. Заодно это честный тест среды — он измеряет, насколько система понятна и насколько дёшево внести в неё изменение; ту же величину берут как индикатор опыта разработчика в SPACE и DevEx (queue.acm.org).

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

Кто с ним работает, кроме вас

Три роли, которые склеивают в одну, и от склейки страдают все.

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

Кого назначать: не обязательно сильнейшего инженера — buddy нужна доступность, а не глубина. Разумный выбор — тот, кто сам вышел полгода-год назад: он помнит, что было непонятно, и его знания не «схлопнулись» в очевидность. Побочная польза — первая проба ответственности за другого человека (Делегирование).

Чего новичок не может узнать сам

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

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

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

Ритм разговоров в первый месяц

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

Чаще и короче. Два раза в неделю по 25–30 минут первые 6–8 недель: плотность вопросов высокая, а порог «достаточно ли это важно, чтобы отвлекать» не откалиброван. Признак, что интервал велик, — регулярное «я неделю назад застрял, но сам разобрался»: день-два ушли впустую.

Другое содержание. Не «как дела», а сверка картины мира:

• «Расскажи своими словами, чем занимается наша команда и за что мы отвечаем» — на второй неделе. Ответ почти всегда расходится с вашей версией; сейчас это чинится за десять минут, через полгода это уже «он не понимает приоритетов».
• «Что за эту неделю оказалось устроено не так, как ты ожидал?»
• «Где ты потерял время на то, что должно было быть простым?» — самый урожайный вопрос первых недель: собирает дефекты вашей среды, а не жалобы.
• «Что тебе непонятно, но спрашивать про это неудобно?»

Обратная связь идёт сразу и мелкими порциями. Репутации у новичка ещё нет, цена ранней корректировки минимальна, а отложенной — максимальна: через два месяца привычка стала нормой, и «описывай в PR причину, а не только что сделано» превращается в «у тебя проблемы с коммуникацией» (Обратная связь).

Ожидания на 30, 60, 90 дней

Ожидания формулируются до выхода и в наблюдаемых способностях, а не в словах «освоился» и «влился»: как и в Оценке и росте, формулировка годится, если по ней понятно, как выглядит невыполнение.

Числа условны: в зрелом монолите с трёхлетней историей 90 дней реалистичны, в маленьком сервисе на знакомом стеке те же способности появляются к 30-му дню. Важно не значение, а два факта: ожидания записаны до начала и сверяются вслух, а не держатся в голове до решения об испытательном сроке. Ожидания к джуну, мидлу и сеньору отличаются не сроками, а масштабом самостоятельности: нормальный для джуна темп для сеньора — сигнал (устройство уровней со стороны сотрудника — Грейды).

Когда адаптация идёт не так

Главная ошибка здесь — рано перейти от вопроса «что не так в среде» к вопросу «что не так с человеком». Первые два-три месяца низкий результат — норма, а не сигнал (Слабый результат); сигнал — не уровень, а форма кривой: человек не двигается или двигается не туда. Ранние признаки:

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

Особые случаи

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

Джун. Отличается не темпом, а тем, что нужна декомпозиция извне: задача, которую мидл режет сам, для джуна должна быть нарезана. Нагрузка на buddy выше в разы, её надо считать при планировании; признак, что недооценили, — buddy перестал успевать своё к третьей неделе.

Удалённый новичок. Исчезает весь неявный канал: он не слышит обсуждений, не видит, кто занят, не может «спросить через стол». Компенсации (отраслевая практика): видео на разговорах, ежедневный короткий созвон с buddy первые две недели, публичные каналы вместо личных сообщений, явное представление в каждом чате. Нарушение: к третьей неделе он написал в общие каналы меньше пяти раз. Специфика — Удалённая работа.

Внутренний перевод. Ошибка — считать, что адаптация не нужна: связи есть, компания знакома, а технического контекста ноль, и спросить психологически труднее — он же не новичок. Онбординг нужен полный, кроме организационной части. Если вы сами новый лид, чек-лист собирается вместе с buddy, а вопрос «что здесь устроено непонятно» работает и как ваша разведка (Из инженера в лида).

Вход в дежурство. Отдельная квалификация: сопровождение опытного дежурного, обратное сопровождение, дневные смены. Условие перехода называется заранее, иначе превращается в «когда лид почувствует, что готов» (Дежурства).

Испытательный срок: решение, которое нельзя тянуть

Испытательный срок — не формальность, а последний дешёвый момент исправить ошибку найма; дальше дорожает и для команды, и для человека, который через полгода получает вместо корректировки увольнение. Порядок (юридическая часть везде своя, это к HR и юристам):

1. Проверьте среду прежде человека. Не дали доступов, задачу и ревьюера — у вас нет данных о нём, есть данные о вас.
2. Скажите вслух за месяц до конца срока, если что-то не сходится. Формулировка про наблюдаемое: «к 30-му дню мы ожидали, что задачи спринта ты берёшь сам; сейчас каждую приходится разбирать вместе. Вот что должно измениться и как я помогу».
3. Не растягивайте из жалости. Продление «а вдруг» без изменения условий — не шанс, а отложенный тот же разговор, к которому человек уже отказался от других офферов.
4. Разделяйте «не подошёл» и «плохой инженер». Несовпадение со стеком, доменом или темпом — не приговор человеку, и говорить надо ровно так. Врать про причину нельзя: команда достроит свою версию, и она будет хуже правды.

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

Как понять, что онбординг работает

Признаки с наблюдаемым нарушением, а не ощущения.

Предупреждение про цель: время до первого деплоя — диагностика, а не KPI. Сделаете его целью — получите первую задачу «поправить опечатку в README», формально закрывающую метрику и не дающую ничего; закон Гудхарта работает здесь так же, как в инженерных метриках. Дешёвый способ поддерживать систему живой — ретро онбординга на 30-й день: двадцать минут, три вопроса, результат идёт в чек-лист.

## Онбординг-ретро, 30-й день — Миша

1. Что мешало сильнее всего? → Доступ к стенду ждали 4 дня; по инструкции
   проект не собрался, помог Костя.
2. Что оказалось не таким, как ты ожидал по собеседованию? → Думал, будет
   больше продуктовых задач, по факту первый месяц инфраструктура.
3. Чего не хватало, о чём ты не просил? → Карты сервисов: кто чей владелец.

Что меняю до следующего новичка:
- [x] Заявки на стенд подаю за неделю, а не в первый день.
- [x] Инструкцию по сборке правит новичок в первый день, это его первая задача.
- [ ] Полстраницы «кто чем владеет» — пишу до конца недели, поддерживает buddy.
- [ ] На собеседовании честно говорю про первый месяц на инфраструктуре.

Список «что меняю» отличает систему от разовой удачи: каждый новичок улучшает онбординг следующего. Без него вы будете каждый раз узнавать одно и то же заново.

Что ломается чаще всего

1. Доступы заказаны в первый день. Неделя простоя → человек читает код без задачи и делает вывод, что его выхода не ждали.
2. Buddy назначен без времени. Он в аврале → новичок перестаёт спрашивать, тишину принимают за успех.
3. Первая задача выбирается при новичке. Берут быстрое и мелкое → конвейер не пройден, на выкатке он споткнётся в следующий раз.
4. Ожидания не записаны. На 60-й день вы недовольны → человеку нечего было исправлять, а вам нечем обосновать решение.
5. Первый содержательный разговор через месяц. Мелкие сбои стали привычками → корректировка стоит вдесятеро дороже.
6. Новичка нагружают с третьей недели «как всех». Он держится за видимость → вопросы прекращаются, ошибки уходят вглубь.
7. Сеньору не дают контекст. «Он разберётся» → месяц решений на неверных допущениях.
8. Онбординг не меняется от новичка к новичку. Те же грабли → это не невезение, а процесс.

Мини-итог

• Адаптация — перевод человека из потребителя ёмкости команды в её источник; площадь под нулём оплачивают самые загруженные, и сэкономить на ней нельзя — можно только сделать её невидимой.
• Большая часть вашей работы делается до первого дня: доступы, buddy с выделенным временем, первая задача, записанные ожидания, календарь первой недели.
• Первая задача — настоящая, маленькая, проходит весь путь до прода, некритичная по сроку и с живым ревьюером. «Почитай пока код» — не задача, а отложенный провал.
• Buddy, наставник и руководитель — три разные роли; склеенные, они не выполняются ни одна.
• Знания, которых нет в коде и вики (владельцы, история решений, неписаные нормы), передаются только людьми и целенаправленно.
• Разговоры два раза в неделю первые 6–8 недель: сверка картины мира и обратная связь сразу.
• Ожидания — в наблюдаемых способностях и до выхода, иначе оценка превращается в произвол.
• Диагностику начинайте со среды и постановки: первые три развилки всегда про вашу работу.
• Решение о непрохождении принимается рано и с явно названной причиной; ранняя текучесть — данные о найме и онбординге, а не о людях.
• Каждый новичок должен улучшать онбординг следующего: ретро на 30-й день, правки в чек-лист.

Источники

• Bauer, Bodner, Erdogan, Truxillo, Tucker. Newcomer adjustment during organizational socialization: a meta-analytic review (JAP, 2007) — корреляционный мета-анализ.
• Cable, Gino, Staats. Breaking Them In or Eliciting Their Best? (Administrative Science Quarterly, 2013) — редкий полевой эксперимент с рандомизацией.
• Talya N. Bauer. Onboarding New Employees: Maximizing Success (SHRM Foundation, 2010) — разметка адаптации на четыре компонента.
• Google re:Work — rework.withgoogle.com, чек-лист руководителя накануне выхода новичка; внутреннее исследование, не рецензировалось.
• Begel, Simon. Novice Software Developers, All Over Again (ICER 2008); Ju, Sajnani, Kelly, Herzig. A Case Study of Onboarding in Software Teams (ICSE 2021) — что отнимает время у новичков в инженерных командах.
• Frederick Brooks. The Mythical Man-Month (1975) — цена ввода человека в контекст.
• Michael Watkins. The First 90 Days (HBR Press, 2003); Camille Fournier. The Manager’s Path (O’Reilly, 2017) — практика переходов и первых ролей.
• Noda, Storey, Forsgren, Greiler. DevEx: What Actually Drives Productivity (queue.acm.org) — время до первого изменения измеряет среду.
• Google SRE Book — sre.google/books, допуск к дежурствам.

Что дальше

Новичок вышел на нормальный темп, испытательный срок пройден. Дальше — длинная часть работы: сформулировать, что значит следующий уровень, собирать свидетельства весь период, защищать пакет на калибровке и уметь сказать «нет» так, чтобы это не разрушило доверие.

Оценка и рост: ожидания, грейды и разговор о повышении