Фриланс: как подготовить проект к передаче заказчику и инструкции по запуску

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

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

• Исходный код и понятную структуру файлов, переданные через согласованный канал.
• Краткую инструкцию: требования к окружению, установка зависимостей, настройка и запуск.
• Пример файла переменных окружения без действующих паролей и секретных ключей.
• Список необходимых сервисов, аккаунтов, доступов и действий для проверки проекта.
• Информацию о проверенных сценариях, известных ограничениях и нерешённых задачах.
• Согласованные условия приёмки, поддержки и возможных доработок.

Проверьте готовность проекта перед передачей

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

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

Независимо от того, заказал ли клиент разработку сайта под ключ или отдельную доработку, заранее определите критерии приёмки. Услуги фрилансера по разработке сайта могут включать разные объёмы работ, поэтому состав передаваемых материалов следует сверить с договорённостями, а не предполагать.

Соберите исходники, доступы и рабочие материалы

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

• Исходники: актуальная версия проекта, файлы конфигурации-шаблоны, миграции, тесты и статические материалы, если они входят в работу.
• Репозиторий: ссылка на проект, сведения о нужной ветке или версии и инструкция, как получить код.
• Зависимости: файл или команда, с помощью которых устанавливаются библиотеки и инструменты.
• Сервисы: перечень внешних систем, которые нужны для запуска, например база данных, почтовый сервис или хранилище файлов.
• Доступы: список аккаунтов и ролей, которые потребуются заказчику. Передавайте права через приглашение в сервис или менеджер паролей, а не открытым текстом.
• Рабочие материалы: макеты, лицензии, инструкции к сторонним компонентам и описание известных ограничений, если они относятся к проекту.

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

Опишите запуск: от установки зависимостей до первого старта

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

1. Укажите требования.
   Перечислите операционную систему или среду, версии языка, платформы и необходимые системные инструменты. Если проект проверялся только в определённой конфигурации, назовите её.
2. Объясните получение проекта.
   Дайте ссылку на репозиторий или расположение архива и укажите, какую версию нужно использовать. Проверьте, что у заказчика есть права на чтение и, если нужно, на развёртывание.
3. Опишите установку зависимостей.
   Приведите команду для используемого менеджера пакетов и уточните, из какой папки её выполнять. Укажите, если до этого необходимо установить системные компоненты.
4. Перечислите подготовительные действия.
   Объясните, как создать локальную конфигурацию, подключить необходимые сервисы и выполнить миграции или подготовку данных. Не публикуйте секреты в инструкции.
5. Дайте команду запуска и способ проверки.
   Укажите, какую команду выполнить и где увидеть результат: адрес страницы, сообщение в консоли или другой проверяемый признак. Добавьте один-два основных сценария, которые заказчик может пройти вручную.
6. Добавьте порядок действий при сбое.
   Укажите, где посмотреть журналы, как проверить наличие зависимостей и какие сведения приложить к обращению за помощью. Не предлагайте передавать пароли или полные дампы данных без проверки на конфиденциальную информацию.

Быстрый режим запуска проекта

1. Передайте актуальную версию исходников и проверьте права доступа.
2. Запишите требования к среде и команды установки зависимостей.
3. Опишите настройку локальной конфигурации и запуск, не раскрывая секреты.
4. Проверьте инструкцию на чистой среде и попросите заказчика подтвердить результат.

Добавьте инструкции по настройке окружения и переменных

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

• В примере перечислены необходимые переменные и объяснено назначение каждой.
• Указано, где создать локальный файл конфигурации и нужно ли исключить его из системы контроля версий.
• Отмечено, какие значения выдаёт заказчик, а какие нужно получить у стороннего сервиса.
• Описаны обязательные настройки базы данных, почты, хранилища и других подключённых систем.
• Проверено, что секреты не попали в архив, репозиторий, журналы или снимки экрана.
• Указано, какие значения нужны только локально, а какие - для тестовой или рабочей среды.
• Описано, как безопасно заменить или отозвать переданные ключи, если они были раскрыты.

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

Передайте проект безопасно и подтвердите получение

Частые ошибки при передаче обычно связаны не с кодом, а с неполными доступами, неясными версиями и незащищёнными секретами. Проверьте эти пункты перед тем, как считать передачу состоявшейся:

• Отправлен не тот архив или не указана версия проекта.
• Заказчику не предоставлены права на репозиторий, хостинг или связанные сервисы.
• В переписке, исходниках или истории репозитория остались действующие ключи и пароли.
• Инструкция предполагает инструменты или версии, которые нигде не перечислены.
• Не обозначено, какие функции проверены, а какие требуют отдельной настройки.
• Переданы материалы третьих лиц без проверки условий использования и права передачи.
• Не согласован канал для конфиденциальных данных и порядок отзыва временных доступов.
• Заказчик не подтвердил, что получил файлы, открыл репозиторий и смог пройти описанную проверку.

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

Согласуйте поддержку после сдачи и границы доработок

После передачи можно выбрать один из форматов, исходя из потребностей заказчика и договорённостей:

• Разовая передача. Подходит, если заказчик принимает проект и дальнейшую поддержку организует самостоятельно. Зафиксируйте состав результата и способ сообщить о проблеме, обнаруженной при проверке.
• Короткий период исправления ошибок. Уместен, когда стороны заранее определили срок и критерии ошибки, относящейся к выполненной работе. Новые функции и изменения требований не следует автоматически считать исправлениями.
• Почасовая поддержка. Подходит для нерегулярных запросов. Согласуйте порядок постановки задач, оценку и подтверждение объёма до начала работ.
• Регулярное сопровождение. Уместно, если нужны плановые обновления или наблюдение за работой проекта. Отдельно определите состав работ, доступы и порядок согласования изменений.

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

Об авторе

Андрей Федотов

Практические ситуации при передаче проекта

Что делать, если заказчик не может запустить проект по инструкции?

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

Можно ли передать заказчику архив вместо доступа к репозиторию?

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

Нужно ли передавать фрилансеру пароль от аккаунта заказчика?

Не следует передавать общий пароль. Безопаснее выдать отдельную учётную запись с минимальными необходимыми правами, а после завершения работ отозвать временный доступ.

Как передать настройки, если для запуска нужны секретные ключи?

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

Что фиксировать, если часть работ ещё не завершена?

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

Как подтвердить, что проект принят?

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