Короткий ответ
Передача проекта новой команде должна начинаться не с передачи архива, а с восстановления картины: что есть в проекте, как он работает, где риски, какие доступы нужны и какие задачи нельзя трогать без подготовки.
Чем сложнее портал, личный кабинет или CRM, тем важнее передавать не только код, но и бизнес-логику.
Этап 1. Зафиксировать состояние
Сначала нужно понять, что именно передаётся:
- репозиторий;
- серверы и окружения;
- база данных;
- домены и SSL;
- внешние сервисы;
- CRM, 1C и другие интеграции;
- документация;
- текущие задачи;
- список известных ошибок.
Если часть информации отсутствует, это не повод останавливать процесс. Но нужно явно пометить зоны неизвестности.
Этап 2. Собрать доступы
Доступы лучше собирать по чек-листу. Важно не только получить логины, но и понять, кто владелец каждого сервиса.
Проверьте:
- хостинг и серверы;
- домен и DNS;
- репозитории;
- CI/CD или процесс деплоя;
- CRM и 1C;
- почтовые сервисы;
- аналитика;
- платёжные системы;
- облачные хранилища;
- сервисы уведомлений.
Передавать доступы нужно безопасно, без пересылки паролей в открытых чатах.
Этап 3. Восстановить бизнес-логику
Новая команда должна понимать, как проект используется бизнесом.
Нужно описать:
- основные роли пользователей;
- ключевые пользовательские сценарии;
- статусы заявок, заказов или документов;
- исключения и ручные операции;
- критичные отчёты;
- правила обмена с внешними системами.
Если бизнес-логика не описана, новая команда будет принимать технические решения вслепую.
Этап 4. Выделить зоны риска
Не все части проекта одинаково опасны. Нужно заранее понять, где изменения могут привести к поломкам.
Обычно риск высок в интеграциях, правах доступа, платежах, обмене документами, нестандартных отчётах, миграциях данных и старых модулях без владельца.
Если проект передаётся из-за конфликта или срыва сроков, стоит отдельно изучить сценарий смены подрядчика.
Этап 5. Согласовать первые действия
Новая команда не должна сразу брать крупные доработки. Лучше начать с безопасных шагов:
- локальный запуск;
- проверка окружений;
- анализ архитектуры;
- исправление критичных ошибок;
- обновление документации;
- подготовка плана развития.
Для сложных проектов подходит внешний CTO или технический контроль подрядчика на период передачи.
Практический вывод
Хорошая передача проекта снижает риск для бизнеса и новой команды. Главное - передать не только код, но и контекст: процессы, зависимости, ограничения, доступы и известные проблемы.
Если документации мало, начните с аудита и карты проекта. Это дешевле, чем передавать систему вслепую и заново открывать старые ошибки.
Материалы по теме
| Материал | Когда смотреть |
|---|---|
| Что должно быть в технической документации web-проекта | Если нужно понять, какие разделы документации собрать до передачи |
| Документация перед сменой подрядчика | Если передача связана со сменой текущего исполнителя |
| Проект без технической документации | Если сначала нужно восстановить карту системы, доступов и интеграций |
