Момент смены подрядчика выглядит как передышка. Старая команда уходит, новая заходит с энергией и свежим взглядом, и кажется, что скоро всё наладится. Но именно в этот период большинство продуктов теряют три-шесть недель полезной разработки. Происходит это по одной и той же причине: переход никто не выстраивал как отдельный проект со своими задачами и метриками. Он просто начался сам по себе, и каждая сторона понимала его по-своему.
Ниже — конкретная механика того, как этот месяц пройти с минимальными потерями скорости.
Почему первые 30 дней определяют всё
У нового подрядчика в начале работы есть два одновременных дефицита: контекст и доверие. Контекст — это понимание того, зачем был сделан тот или иной архитектурный выбор, почему вот этот модуль написан именно так, что означает «срочно» в конкретной команде. Доверие — это ощущение заказчика, что он не ошибся с выбором. Оба дефицита устраняются структурированной работой в первые четыре недели, а не тем, что команда просто «поварится и разберётся».
Если подрядчик в первый месяц ничего не поставил в прод и не дал измеримого сигнала, что понимает продукт, тревога заказчика начинает расти. Если заказчик в первый месяц не передал документацию, не познакомил с командой и не ответил на уточняющие вопросы, у подрядчика нет шансов работать быстро. Обе стороны могут облегчить друг другу этот месяц, и дальше описано, как именно.
Неделя 1: контекст важнее кода
Первая неделя посвящена передаче понимания, а не написанию кода. Новая команда должна получить достаточно контекста для самостоятельных решений, иначе заказчик станет узким горлышком каждого вопроса уже через несколько дней.
Со стороны заказчика главная задача — передать документацию в том виде, в котором она существует, даже если она неполная или частично устаревшая. Новому подрядчику важнее видеть реальную картину, чем идеальную. Устаревшая схема архитектуры с пометками «это уже не так» ценнее её отсутствия, потому что показывает, откуда система пришла к текущему состоянию.
Кроме документации, стоит организовать одну большую сессию знакомства с участием продуктового менеджера, технического лида и хотя бы одного разработчика со стороны заказчика. Цель такой встречи — живые вопросы и ответы, а не презентация с красивыми слайдами. Именно в разговоре вскрываются вещи, которые никто не думал документировать: неочевидные зависимости, исторические решения, негласные договорённости о приоритетах.
Доступы ко всем системам — репозиторий, таск-трекер, мессенджер, CI/CD, staging-среда — должны быть выданы в первый рабочий день. Каждый день ожидания доступов конвертируется в простой, который потом трудно объяснить чем-то, кроме низкой скорости команды.
Со стороны подрядчика первая неделя выглядит иначе. Команда изучает кодовую базу и фиксирует список вопросов, но не рассыпает их хаотично в рабочем чате, а собирает в структурированный документ и проводит одну сессию разбора. Это экономит время заказчика и сразу показывает уровень команды — по тому, какие вопросы задаются, видно, насколько глубоко люди погрузились в материал.
Параллельно подрядчик делает первый технический срез: оценивает состояние кода, фиксирует узкие места и накопленный технический долг. Это важно не для того, чтобы критиковать предыдущую команду, а чтобы у всех участников было общее понимание стартовой точки. К концу первой недели у подрядчика должен быть ответ на вопрос: что мы будем делать в следующие три недели и почему именно это?
Неделя 2: первое касание с продуктом
Вторая неделя — момент первой реальной задачи. Здесь важно сопротивляться желанию сразу поставить команду на самое горящее. Первая задача должна быть настоящей производственной, но достаточно изолированной, чтобы её можно было выполнить без полного понимания всей системы: небольшая фича или исправление бага, затрагивающее один модуль с чётким критерием готовности.
Новая команда на сложной задаче без контекста работает медленно и делает больше ошибок. Несколько успехов на понятном материале строят уверенность и рабочий ритм быстрее, чем один большой релиз через месяц ожидания.
В эту же неделю устанавливается ритм коммуникации. Конкретно: как часто синк, в каком формате, кто принимает решения по приоритетам, как фиксируются договорённости. Если этот ритм не установить осознанно сейчас, он сложится стихийно — и почти всегда неудобно для обеих сторон.
Отдельно стоит договориться о том, как команда сообщает о блокерах. Хорошая практика: блокер фиксируется сразу, с описанием того, что именно заблокировано и что нужно для продолжения работы. Без такой договорённости заказчик узнаёт о проблеме на пятничном синке, когда уже потеряно три дня.
Неделя 3: самостоятельная работа как индикатор
К третьей неделе подрядчик должен работать преимущественно без постоянных уточнений у заказчика. Если на каждом шагу требуется дополнительный контекст, это сигнал, что первые две недели дали меньше, чем должны были, и стоит разобраться, где именно потерялась информация.
В эту неделю хорошо провести первый промежуточный ретроспектив. Он не должен быть большим: тридцать-сорок минут на три вопроса — что работает хорошо, что мешает работать быстрее, что нужно изменить. Проводить его раньше третьей недели слишком рано, потому что паттерны ещё не успели устояться. Позже четвёртой — уже поздно, потому что привычки закрепились и менять их дороже.
На этой же неделе подрядчик показывает первый результат, который можно потрогать. Это важно для обеих сторон: заказчик видит, что движение есть, а команда получает обратную связь на реальном коде. Обратная связь на этом этапе ценнее любой документации — она уточняет понимание продукта быстрее, чем часы чтения спецификаций.
Неделя 4: выравнивание ожиданий
К четвёртой неделе у обеих сторон накапливается реальный материал для честного разговора. У заказчика сложились наблюдения о том, как работает команда. У подрядчика появилось понимание того, что в проекте устроено сложнее, чем казалось на старте. Это нормальная ситуация, и важно проговорить её вслух, а не оставлять в виде невысказанных ожиданий.
Хорошая структура для этой недели: демо плюс ретроспектив плюс корректировка плана. Демо показывает, что сделано. Ретроспектив разбирает, как это делалось и что мешало. Корректировка плана отвечает на вопрос: что мы знаем теперь, чего не знали в начале, и как это меняет следующие спринты? Этот вопрос кажется банальным, но именно его обычно не задают — и потом удивляются, что план разошёлся с реальностью уже на втором месяце.
Если к концу первого месяца обе стороны могут ответить на вопрос «всё ли идёт по плану» без долгих раздумий, онбординг прошёл как надо. Если кто-то из двух чувствует, что что-то не так, но не может сформулировать что именно, это повод для отдельного честного разговора — пока не прошло ещё два месяца и потери не накопились.
Три ошибки, которые чаще всего ломают онбординг
Заказчик не выделяет время на первый месяц. Логика понятна: подрядчик нанят, чтобы освободить ресурс. Но в первый месяц эта логика работает против результата. Онбординг требует активного участия заказчика: отвечать на вопросы, давать обратную связь, принимать решения по приоритетам. Команда, которая неделями ждёт ответа на уточняющий вопрос, не работает медленно, она просто не может работать быстрее.
Первая задача оказывается слишком сложной. Желание немедленно поставить команду на самое горящее объяснимо, но на практике это затягивает выход на рабочую скорость. Первые задачи должны давать команде возможность разобраться в системе на управляемом материале, а не бороться одновременно со сложностью задачи и незнакомой кодовой базой.
Устные договорённости вместо письменных. Договорённости о приоритетах, критериях готовности и процессах работают устно ровно до первого конфликта. После него каждая сторона помнит разговор по-своему. Письменная фиксация — это не выражение недоверия, а способ не тратить время на выяснение того, о чём договорились две недели назад.
Что считать результатом
К концу первых тридцати дней картина должна выглядеть так: несколько задач закрыто в прод самостоятельно, рабочий ритм коммуникации установлен, приоритеты на следующий спринт понятны обеим сторонам. Если хотя бы один из этих пунктов вызывает затруднение, стоит разобраться с причиной сейчас, а не ждать, пока три месяца работы покажут, что фундамент был заложен неправильно.
Команды, которые относятся к онбордингу подрядчика как к отдельному проекту с конкретными целями и ответственными, в среднем выходят на рабочую скорость в два раза быстрее. Это не теоретическая оценка — это наблюдение из десятков проектов, где мы заходили как новая команда и видели, как устроен этот переход у разных заказчиков.