Как передать проект новому разработчику: чек-лист доступа и документации
Чек-лист передачи проекта: репозиторий, сервер, база данных, внешние сервисы, окружения и правила безопасного доступа.
Коротко
- • Передача — это воспроизводимый запуск и понятные зоны ответственности.
- • Секреты передают через менеджер доступа, а не в чате или документе.
- • После передачи нужно отозвать старые доступы и проверить резервное восстановление.
СодержаниеПоказать разделы
Новый разработчик должен получить не набор ссылок, а возможность безопасно понять, запустить и изменить проект. Если передать только репозиторий, работа может остановиться на первом же вопросе о базе данных, переменных окружения или публикации.
Минимальный комплект передачи
| Область | Что описать |
|---|---|
| Репозиторий | Адрес, ветка, правила изменений, последние релизы |
| Запуск | Команды, версия окружения, зависимости и тестовые данные |
| Продакшен | Где работает приложение, как публиковать и как откатывать |
| Данные | Схема базы, миграции, резервные копии и ответственный |
| Интеграции | Платежи, почта, аналитика, боты и внешние API |
Как передавать доступы безопасно
- Составьте список систем и назначьте владельца каждой.
- Создайте персональный доступ новому разработчику с минимальными правами.
- Передайте секреты через менеджер паролей или штатный секрет-стор.
- Не отправляйте токены в мессенджере, задачах и открытом README.
- После завершения передачи удалите временные ключи и доступ бывшего подрядчика.
Не нужно передавать все права администратора «на всякий случай». Доступ должен соответствовать задаче: чтение логов, работа с тестом или публикация — это разные полномочия.
Проверка передачи
Попросите нового разработчика самостоятельно выполнить короткий сценарий: получить код, запустить проект, открыть тестовую страницу, изменить безопасный текст и описать, как изменение попало бы в продакшен. Отдельно проверьте, что резервная копия существует и из неё можно восстановиться.
Какие документы оставить
- короткое описание продукта и его главного пользовательского сценария;
- карта сервисов и интеграций;
- список известных ограничений и ошибок;
- история важных решений;
- контакты владельцев домена, платежей и инфраструктуры;
- правила приёмки и план ближайших задач.
Если документации нет, не пытайтесь написать энциклопедию. Начните с запуска, критичных доступов и действий при сбое. Дальше документацию можно дополнять вместе с поддержкой проекта.
Что должен сделать фрилансер при передаче
Передача проекта — это отдельный результат, а не бесплатные пятнадцать минут в конце работы. В план стоит включить подготовку инструкции, очистку временных доступов, запись короткого видео или созвон и время на вопросы нового исполнителя.
Если проект передаётся после завершения контракта, заранее согласуйте формат: документ, встреча, период ответов в чате или ограниченное окно поддержки. Не обещайте бессрочные консультации без отдельной договорённости.
Матрица доступов
| Система | Владелец | Новый доступ | Что отозвать |
|---|---|---|---|
| Репозиторий | Заказчик или команда | Персональный аккаунт | Общие и временные токены |
| Хостинг | Владелец продукта | Минимальная роль | Доступ подрядчика после передачи |
| Сервисы | Ответственный за интеграцию | Отдельный ключ | Ключи из старого окружения |
Не передавайте пароль от личного аккаунта, если сервис позволяет пригласить пользователя. Для секретов опишите название и назначение, но не вставляйте сами значения в обычную документацию. После передачи заказчик должен иметь возможность самостоятельно изменить или отозвать доступ.
Как оценить работу по передаче
Для фрилансера удобно разделить работу на подготовку, встречу и короткое пост-сопровождение. Подготовка занимает время на проверку запуска и документов, встреча — на объяснение решений, пост-сопровождение — на ответы по тем вопросам, которые возникли при первом самостоятельном запуске.
Эту работу можно считать по часовой ставке или включить в этап проекта отдельной строкой. Главное — не прятать передачу в «мелкие правки». Клиент получает снижение зависимости от одного исполнителя, а фрилансер показывает профессиональное завершение работы.
Проверка через неделю
Хорошая передача заканчивается короткой проверкой: новый разработчик запускает проект, меняет безопасный элемент, проверяет тесты и описывает порядок релиза. Если этого не сделать, документ может выглядеть полным, но оставаться непригодным в реальной ситуации.
После передачи сохраните финальный список доступов, дату отзыва старых ключей и список известных ограничений. Эти три записи часто экономят больше времени, чем длинная техническая история проекта.
Признак завершённой передачи
Передача завершена, когда новый разработчик может ответить на четыре вопроса: как запустить проект, где проверить изменения, как выпустить релиз и что делать при сбое. Если ответ зависит от старого исполнителя, процесс ещё не закончен.
Завершите документ датой, версией проекта и ответственными лицами. Через несколько месяцев это поможет отличить актуальные инструкции от старых заметок.