Смена подрядчика без боли: как передать код, документацию и контекст, чтобы новый разработчик быстро вошёл в проект
60% проектов теряют часть кода, документации или доступов при смене подрядчика. Иногда - весь контекст, без которого новый разработчик не способен продолжать работу. В итоге бизнес теряет месяц, два или начинает проект с нуля. Я собрал практический чеклист, который позволяет передать проект новой команде за 2-7 дней - без срывов и откатов.
В этом посте разберёмся, как сменить IT-подрядчика так, чтобы проект не развалился: какие артефакты нужно собрать, как провести аудит кода, какие доступы проверить, что передать новой команде и как ускорить вход разработчиков в проект.
Меня зовут Дмитрий Харитонов, я больше 10 лет управляю IT-проектами, последние 5 - в 2PEOPLE IT, где веду разработку веб-, мобильных и AI-решений под заказ: от идеи до релиза и последующей поддержки.
За это время я видел десятки кейсов, когда компания была вынуждена менять подрядчика: кто-то срывал сроки, кто-то снижал качество, кто-то просто пропадал. Иногда проект удавалось спасти за пару недель. Но бывали ситуации, когда приходилось фактически собирать систему с нуля - потому что предыдущая команда не оставила документацию, потеряла доступы или держала контекст в головах одного-двух разработчиков.
Хорошая новость - смена подрядчика может пройти без боли, если действовать по структуре. Ниже - максимально практическое руководство на основе реальных кейсов.
Почему смена подрядчика - это всегда риск
Смена команды разработки - это не просто "отдать проект другим людям". Это почти хирургическая операция.
Основные риски:
- Потерянные или фрагментированные доступы.
- Отсутствие архитектурной документации.
- Чужой код без комментариев и структурных пояснений.
- Зашитые в код "быстрые фиксы", о которых никто не знает.
- Отсутствие DevOps-инфраструктуры или понимания окружений.
- Контекст разработки живёт в голове одного человека.
И главный риск - вступление в проект без документации и без технической карты, из-за чего новый подрядчик тратит недели, разбираясь в том, что можно было передать за один созвон.
Что нужно собрать до передачи проекта
Это базовый набор артефактов, без которых handover невозможен. Если этих материалов нет - заказчик должен настоять на их подготовке прежней командой.
Техническая документация
Не обязательно идеальная, но обязательная. Минимум - описание:
- архитектуры;
- основных сервисов и модулей;
- ключевых бизнес-процессов;
- используемых библиотек и интеграций;
- известных ограничений и технического долга.
Если документа нет - новый подрядчик начинает с аудита кода.
Репозиторий и структура кода
Нужно собрать:
- доступ к основному Git-репозиторию;
- ветки, релизы, теги;
- CI/CD-пайплайны;
- комментированные пулл-реквесты;
- незакрытые задачи, связанные с кодом.
Важно: репозиторий должен быть передан ВЛАДЕЛЬЦУ проекта, а не оставаться на Git аккаунте подрядчика.
Инфраструктура
Частая причина катастроф.
Список:
- доступы к серверам (SSH/FTP), хостингу, доменам;
- окружения: dev / stage / prod;
- базы данных;
- хранилища, очереди, очередные сервисы;
- Cron, фоновые задачи;
- контейнеры, если есть Docker/K8s;
- SSL, IP, ограничения firewall.
Доступы
Формируем единый документ.
Сюда входят:
- Git, CI/CD;
- сервера;
- базы данных;
- Figma, Miro;
- Jira/YouTrack;
- аналитика (GA4, Amplitude, Firebase);
- облака: AWS, GCP, Yandex, DigitalOcean.
Контекст разработки
Это то, чего всегда НЕ хватает.
Контекст - это:
- почему решения принимались именно так;
- какие "костыли" стоят в коде;
- что откладывалось;
- какой технический долг известен;
- какие баги считаются некритичными, но могут всплыть;
- где "тонкие места" системы.
Именно контекст экономит новой команде недели.
Product-контекст
Передача подрядчика - это не только код.
Нужно передать:
- roadmap проекта;
- backlog задач;
- список приоритетов;
- пользовательские сценарии;
- цели релизов;
- требования к SLA.
Аудит проекта перед сменой подрядчика
Аудит - это страховка, которая показывает реальное состояние системы.
Аудит кода
Что проверяется:
- качество архитектуры;
- структура, читаемость, покрытие тестами;
- потенциальные точки падения;
- legacy-модули;
- использование best practices.
Аудит архитектуры
Особенно важен для сложных проектов. Включает:
- схему систем;
- взаимодействия сервисов;
- масштабируемость;
- рискованность интеграций.
Аудит инфраструктуры
Проверяем:
- систему деплоя;
- резервные копии;
- мониторинг;
- логи;
- безопасность.
Аудит документации
Проверяем наличие и качество ключевых артефактов.
Как правильно передать контекст и знания (идеальный handover)
Пошаговый процесс, который работает в 100% кейсов.
Шаг 1. Kick-off созвон: прежняя команда -> новая команда
Обзор архитектуры, модулей, проблемных точек.
Шаг 2. Проход по коду (Code Walkthrough)
Старая команда показывает критические пути, новые - задают вопросы.
Шаг 3. Передача бизнес-логики
Почему важны те или иные решения.
Шаг 4. Передача backlog и незакрытых задач
С пояснениями.
Шаг 5. Две недели "переходного периода"
Старая команда остаётся на связи для уточнений.
Шаг 6. Полное отключение после подтверждения новой команды
Когда проект стабилен.
Типовые ошибки при смене подрядчика
❌ Нет полного списка доступов.
❌ Репозиторий принадлежит подрядчику.
❌ Архитектуры нет даже в виде схемы.
❌ Код наследуется без ревью.
❌ Вся информация из головы одного разработчика.
❌ Резкое отключение старой команды.
❌ Смена подрядчика в момент активного релиза.
Эти ошибки вызывают 80% проблем.
Чеклист передачи проекта новой команде
✅ Репозиторий
✅ Документация
✅ Архитектурная схема
✅ Доступы (полный список)
✅ Инфраструктура (все окружения)
✅ Список библиотек и интеграций
✅ Technical debt
✅ Known issues
✅ Product backlog
✅ Roadmap
✅ CI/CD
✅ База данных + резервные копии
✅ Список доменов, SSL, IP
✅ Настройки DevOps
✅ Шаги деплоя
✅ Список критичных багов
✅ Wish-лист заказчика
✅ UX-документы (если есть)
Этот чеклист экономит 30-60% времени on-boarding новой команды.
Как выбрать нового подрядчика
- Запрашивайте процесс: как ставят задачи, как делают ревью.
- Узнайте, есть ли у команды архитектор.
- Проверьте их подход к документации.
- Спросите, как они входят в legacy-проекты.
- Требуйте видимость: weekly демо, статусы, доступ к задачам.
Заключение
Смена подрядчика - это не кризис, если действовать по структуре. Соберите артефакты, проведите аудит, передайте контекст - и новая команда войдёт в проект за дни, а не месяцы.
Если у вас появилась идея или перед вами стоит задача, и нужно понять реальный объём работ, бюджет и сроки - мы можем помочь.
В 2PEOPLE IT уже более 8 лет занимаемся разработкой IT-решений и цифровых продуктов на заказ, поэтому можем быстро провести бесплатную консультацию и дать предварительную оценку проекта.