Как передать проект подрядчику и не потерять неделю

Начните не с репозитория, а с контекста

Первая ошибка — сразу погружать новых разработчиков в код.

До архитектуры им необходимо понять сам продукт.

За первый час человек должен получить ответы хотя бы на следующие вопросы:

• что это за игра;
• на какой стадии находится проект;
• какие платформы поддерживаются;
• что уже выпущено;
• какой ближайший milestone;
• какие задачи сейчас наиболее критичны;
• какие части проекта считаются стабильными;
• какие системы планируется переделывать;
• почему внешняя команда подключается именно сейчас.

Это кажется очевидным, но без такого контекста подрядчик начинает оптимизировать локальные решения, не понимая бизнес-задачу.

Например, разработчик может увидеть технически слабую систему и предложить её переписать. Но через месяц эта часть продукта вообще должна быть удалена.

Или, наоборот, временное решение уже стало фундаментом будущего LiveOps и требует внимания прямо сейчас.

Поэтому первым документом лучше сделать не описание классов, а короткий Project Overview.

Одна-две страницы зачастую полезнее двадцати страниц устаревшей технической документации.

Покажите ближайший результат

После общего контекста подрядчику нужно понять, что конкретно должно измениться благодаря его работе.

Не:

«Нужно помочь с Unity».

А:

«Через шесть недель нам нужен стабильный Android build новой версии с этой механикой, исправленными crash и установленным performance budget».

Или:

«Нужно принять существующий multiplayer-модуль, найти причины рассинхрона и подготовить план исправлений».

Тогда новая команда понимает, где находится граница задачи.

Если проект подключает специалистов для диагностики уже накопившихся проблем, полезно заранее определить, требуется ли обычное продолжение разработки или сначала нужен технический аудит Unity-проекта. Иногда несколько дней диагностики экономят недели попыток исправлять симптомы без понимания архитектурной причины.

Главный принцип: сначала сделать риск видимым, затем принимать решение о сроках, scope и составе работ.

Передайте рабочую сборку

Репозиторий сам по себе ещё не является переданным проектом.

У внешней команды должен существовать понятный путь:

clone → setup → build → run.

Желательно проверить этот путь на чистой машине до handover.

Если для сборки нужны:

• конкретная версия Unity;
• дополнительные модули;
• SDK;
• environment variables;
• локальные конфиги;
• сертификаты;
• package registry;
• Git LFS;
• submodules;

внешние библиотеки,

это должно находиться в одной инструкции.

Плохая документация выглядит так:

«Для Android там вроде нужен ещё один SDK, спросите у Паши».

Хорошая:

Unity 6000.x → Android Build Support → OpenJDK → Android SDK/NDK. После clone выполнить шаги 1–5.

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

Особенно полезно перед подключением внешней команды проверить build pipeline. Подрядчик не должен тратить первые дни на выяснение того, почему build работает только на одном компьютере внутри офиса.

Зафиксируйте эталонный билд

Новая команда должна знать, какое состояние проекта считается исходным.

Перед началом работ зафиксируйте:

• версию;
• build number;
• commit hash;
• branch;
• дату;
• основные известные проблемы;
• ссылку на build.

Так появляется точка сравнения.

Если после изменения возникает новый дефект, можно проверить предыдущую версию и понять, был ли он там раньше.

Без baseline очень быстро возникают обсуждения:

«По-моему, раньше это работало».

«Кажется, этот FPS уже был».

«Этот экран сломался после наших изменений или до них?»

Один сохранённый baseline build снимает значительную часть таких вопросов.

Опишите архитектуру на одном экране

Новой команде не нужен подробный UML каждого класса.

Гораздо полезнее простая схема основных систем.

Например:

Client

↓

Gameplay

UI

Inventory

Save System

Networking

Analytics

↓

Backend API

Для каждой критической системы можно добавить:

• где находится код;
• кто owner;
• что считается источником истины;
• какие есть внешние зависимости;
• какие известны ограничения.

Если в проекте используется Unity, отдельно стоит отметить:

• структуру scenes;
• Addressables;
• assembly definitions;
• основные ScriptableObjects;
• DI/service layer;
• save system;
• networking;
• analytics;
• платформенный код.

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

Не скрывайте технический долг

Перед handover возникает естественное желание привести проект в красивый вид.

Но подрядчику намного полезнее получить честную карту проблем.

Например:

Save System

Работает, но старая архитектура. Не менять до следующего milestone.

Inventory

Есть известный race condition после reconnect. Нужно исправить.

UI

Часть старых экранов будет удалена. Рефакторинг не нужен.

Android

Периодический crash на устройствах с небольшим объёмом памяти.

Так внешний специалист не тратит время на повторное обнаружение уже известных проблем.

Если технический долг значительный, полезно отдельно разделить его на:

• известный и принятый;
• требующий исправления сейчас;
• потенциально опасный;
• запланированный на будущий этап.

Иначе новый разработчик либо начинает «чинить всё неправильное», либо, наоборот, принимает опасное временное решение за нормальную архитектуру.

При большом количестве накопившихся проблем handover естественно связывается с улучшением существующей игры: сначала состояние проекта фиксируется и приоритизируется, затем команда решает, что действительно стоит переделывать.

Backlog должен объяснять приоритет

Передать доступ к Jira недостаточно.

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

Для ближайших задач полезно зафиксировать:

• priority;
• owner;
• dependency;
• acceptance criteria;
• target build или milestone;
• блокирующие факторы.

Вместо:

«Исправить загрузку уровня»

лучше:

«После пяти последовательных переходов между Level A и Level B память должна возвращаться к установленному baseline без накопительного роста».

Так результат можно проверить.

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

Особенно полезно дать подрядчику не весь backlog на полгода, а ближайший горизонт.

Например:

Сейчас — задачи текущих двух недель.

Дальше — следующий milestone.

Контекст — roadmap на несколько месяцев.

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

Назначьте владельцев систем

Документация не отменяет общения.

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

Можно сделать простую таблицу:

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

Особенно важно определить человека, который принимает решения со стороны заказчика.

Если contractor спрашивает:

«Мы можем изменить этот API?»

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

Один owner не обязан знать ответы на все вопросы.

Он должен знать, кто имеет право принять решение.

Доступы выдавайте до первого рабочего дня

Очень странно платить специалисту за день, который он проводит в ожидании приглашений.

Перед стартом проверьте:

• repository;
• task tracker;
• documentation;
• build storage;
• communication channels;
• design files;
• analytics;
• crash reporting;
• тестовые аккаунты;
• backend environments;
• platform portals — если необходимы;
• CI/CD.

Не каждый подрядчик должен получать полный доступ ко всему проекту.

Доступы выдаются по необходимости и с нормальным управлением правами.

Но то, что необходимо для первой задачи, должно работать в момент старта.

Полезно заранее создать тестового пользователя и пройти onboarding самостоятельно.

Так быстро находятся ссылки, которые уже не работают, отсутствующие permissions и инструкции, понятные только старой команде.

Первый день должен закончиться запуском проекта

Хорошая цель первого дня:

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

Ещё лучше — собрал development build.

Не нужно в этот же день требовать первого production commit.

Цель onboarding — убедиться, что рабочее окружение воспроизводимо.

Если человек потратил первый день на:

• установку движка;
• получение доступов;
• настройку SDK;
• запуск игры;
• чтение project overview;

знакомство с архитектурой,

это нормально.

Если то же самое продолжается пять дней, handover подготовлен плохо.

Дайте первую задачу небольшого размера

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

Полезнее выбрать работу, которая:

• реальна, а не придумана для onboarding;
• занимает ограниченное время;
• касается нескольких элементов pipeline;
• имеет понятный результат;
• позволяет пройти полный цикл review и QA.

Например, исправить конкретный UI-баг или небольшую проблему в gameplay.

Так команда проверяет весь процесс:

task → clarification → development → pull request → review → build → QA → acceptance.

Это практически пилот.

Если на этом этапе оказывается, что review занимает три дня или никто не знает, кто должен принять результат, лучше обнаружить проблему на маленькой задаче.

Тот же принцип используется в outsourcing production: сначала проверяется небольшой объём, и только после этого команда масштабирует сотрудничество.

Зафиксируйте правила Git и release process

Подрядчик должен заранее знать:

• от какой ветки создавать feature branch;
• naming branches;
• правила commit;
• нужен ли pull request;
• кто делает review;
• сколько approvals требуется;
• куда попадают fixes;
• как устроена release branch;
• кто имеет право делать merge.

Это особенно важно ближе к релизу.

Если внешняя команда подключается в период стабилизации, она должна соблюдать те же правила релизной ветки, что и внутренняя команда. Иначе один небольшой fix способен создать новый неконтролируемый release candidate.

Также заранее определите, где проходит граница ответственности подрядчика.

Например:

подрядчик делает PR → внутренняя команда review → CI собирает build → QA проверяет.

Или:

подрядчик полностью отвечает за модуль → делает review внутри своей команды → передаёт готовый build заказчику.

Обе модели могут работать.

Плохо, когда участники предполагают разные модели одновременно.

Договоритесь о коммуникации

Проблемы handover возникают не только из-за кода.

Нужно определить несколько простых правил:

• где задавать технические вопросы;
• где обсуждать production;
• где фиксируются решения;
• когда проходят синки;
• сколько времени нормально ждать ответа;
• кто собирает вопросы со стороны подрядчика.

Например:

Slack/Telegram — быстрые вопросы.

Jira — задачи и статус.

Confluence/Docs — решения и постоянная документация.

Weekly call — риски, scope и следующий этап.

Главное — не превращать чат в единственный источник знаний.

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

Не перегружайте созвонами

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

Заказчик хочет убедиться, что подрядчик понял проект, и ставит:

• daily;
• технический daily;
• status call;
• product sync;
• planning;
• retrospective;
• отдельные звонки по каждой системе.

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

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

Например:

• короткий регулярный sync на старте;
• planning;
• review по milestone;
• отдельные технические встречи по необходимости.

Через несколько недель, когда контекст передан, часть синков можно убрать.

Цель хорошего handover — сделать новую команду более самостоятельной, а не создать постоянную зависимость от встреч с заказчиком.

Проверьте bus factor

Handover отлично показывает системы, которые держатся на одном человеке.

Например, выясняется:

• только один разработчик умеет делать console build;
• только один человек знает, как работает экономика;
• только один artist понимает export pipeline;
• только один инженер может обновить backend.

Это один из ранних сигналов риска проекта.

Необязательно немедленно писать подробную документацию по каждой системе.

Но критический workflow должен уметь повторить хотя бы ещё один человек.

Минимальный вариант:

Владелец системы выполняет процесс.

Новый специалист наблюдает.

Шаги фиксируются.

Новый специалист повторяет процесс самостоятельно.

Документация корректируется по возникшим вопросам.

Так документация проверяется реальностью, а не создаётся «для галочки».

Не пытайтесь передать абсолютно всё

Другая крайность — месяц готовить идеальную документацию перед началом сотрудничества.

Она всё равно не будет полной.

Часть информации устареет ещё до окончания написания.

Поэтому handover лучше разделить на уровни.

Нужно в первый день

product overview;

• доступы;
• repository;
• запуск проекта;
• baseline build;
• ближайшие задачи;
• ответственные.

Нужно в первую неделю

architecture overview;

• основные pipeline;
• known issues;
• правила review;
• release process;
• технические ограничения.

Можно передавать по мере необходимости

детали редких систем;

• история старых архитектурных решений;
• специфичные platform workflows;
• дополнительные внутренние инструменты.

Так onboarding не становится отдельным проектом внутри проекта.

Как понять, что handover завершён

Передача закончена не тогда, когда отправлены все ссылки.

Хороший критерий:

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

Можно провести простой тест.

Новый специалист должен самостоятельно:

Получить repository.

Запустить проект.

Найти нужную систему.

Понять задачу.

Внести небольшое изменение.

Создать PR.

Получить review.

Собрать или получить build.

Передать его QA.

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

Если этот цикл работает, большая часть onboarding завершена.

Если на каждом шаге необходим отдельный человек из старой команды, нужно искать недостающий элемент процесса.

Чек-лист передачи проекта подрядчику

Перед первым рабочим днём полезно пройти короткий список.

Контекст

есть описание продукта;

• понятен текущий этап;
• известен ближайший milestone;
• зафиксирован scope подрядчика.

Проект

repository доступен;

• указана правильная branch;
• известна версия движка;
• проект запускается по инструкции;
• сохранён baseline build.

Архитектура

есть карта основных систем;

• известны owners;
• обозначены внешние зависимости;
• перечислены основные known issues.

Production

подрядчик видит backlog;

• понятны приоритеты;
• у задач есть критерии приёмки;
• зафиксирован процесс review;
• понятен release workflow.

Доступы

task tracker;

• документация;
• коммуникации;
• CI;
• build storage;
• необходимые сервисы.

Коммуникация

определён основной контакт;

• известны каналы для разных вопросов;
• важные решения фиксируются вне чата;
• установлена разумная частота синков.

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

Если нет — первая неделя почти неизбежно превращается в дорогостоящий поиск контекста.

Хороший handover сокращает зависимость от старой команды

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

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

Для этого обычно нужны пять вещей:

понятная цель → воспроизводимый проект → карта систем → владельцы решений → проверяемые критерии результата.

Всё остальное можно добавлять по мере необходимости.

NoPanic Studio подключается к уже существующим игровым проектам на разных этапах: от разработки на Unity и технического аудита до QA, оптимизации и усиления действующей команды. При старте с чужим кодом сначала фиксируем состояние проекта, собираем рабочую сборку, разбираем архитектуру и ближайший roadmap, а затем переходим к production-задачам.

Если нужно передать существующий проект внешней команде или быстро подключить дополнительных специалистов — пришлите текущий roadmap, описание проекта и область работ. Поможем провести технический onboarding и выстроить процесс так, чтобы первая неделя ушла на работу, а не на восстановление контекста.