Как принять проект разработки и что передаётся заказчику

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

Что такое приёмка и почему о ней думают заранее

Приёмка программного обеспечения — это момент, когда заказчик проверяет результат и подтверждает, что получил то, о чём договаривались. На практике это не одна подпись, а набор проверок: продукт работает, данные на месте, доступы у вас, а команда, которая продолжит работу, сможет разобраться в коде без автора.

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

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

Что передаётся заказчику

Состав передачи зависит от проекта, но базовый набор одинаков для бота, ИИ-агента и приложения. В JEEKSSHIRE 24 на выходе заказчик получает следующее (так это описано на странице разработки ПО):

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

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

Что передаётся и зачем это нужно

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

Исходный код и права на него

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

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

Отдельно стоит обсудить сторонние компоненты: библиотеки, шрифты, платные сервисы, внешние API. Ими вы пользуетесь по их собственным лицензиям, и это нормально, но лучше знать заранее, что в продукте своё, а что подключено. Юридические формулировки — вопрос для юриста: правила о передаче прав различаются по странам, и договор стоит проверить у специалиста, который знает ваше право.

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

Доступы и секреты: хранятся вне кода

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

В JEEKSSHIRE 24 хранение секретов вне кода и вне репозитория — не отдельный этап перед сдачей, а требование к каждой правке. Так устроены и наши собственные продукты.

Что проверить по доступам

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

Проверки перед релизом: красный шлюз — релиза нет

Перед каждой выкаткой продукт должен пройти автоматические проверки: сборку, линт (проверку кода на ошибки и единый стиль) и тесты. Если хотя бы одна проверка не прошла, шлюз красный, и релиза нет, каким бы срочным он ни был.

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

На приёмке стоит попросить показать, как проходит выпуск: запустить проверки, увидеть зелёный результат и выкатку. Это займёт немного времени и сразу покажет, насколько процесс воспроизводим без автора.

Приёмка частями вместо одной сдачи в конце

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

Так устроена работа в JEEKSSHIRE 24: первая версия с главным сценарием выходит раньше, остальное — следующими релизами. По ориентирам со страницы: бот или небольшая автоматизация — обычно от одной до нескольких недель, первая версия ИИ-агента — несколько недель, отдельное приложение — от нескольких месяцев. Подробнее о сроках — в разборе сколько длится разработка приложения, а о первой версии — в гайде MVP: с чего начать.

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

Чек-лист приёмки проекта

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

1. Сверьте результат с договором и ТЗ: все ли сценарии из критериев приёмки работают.
2. Пройдите главные сценарии сами в проде — на реальных устройствах и платформах, для которых делался продукт.
3. Если продукт многоязычный, проверьте каждый язык, включая вёрстку справа налево для арабского.
4. Получите исходный код в репозитории с историей изменений и убедитесь, что доступ к нему у вас, а не только у исполнителя.
5. Проверьте, что права на код переходят к вам так, как записано в договоре.
6. Получите описание того, как продукт устроен и как его выпускать.
7. Попросите показать выпуск новой версии: сборка, линт и тесты зелёные, выкатка проходит.
8. Проверьте доступы: домен, серверы, облако, магазины приложений и платёжные сервисы на вас.
9. Убедитесь, что секретов нет в коде и репозитории, а скомпрометированные ключи заменены.
10. Проверьте оповещения о сбоях: кому они приходят и как быстро.
11. Проверьте резервные копии: где они хранятся, как часто делаются и как из них восстановиться.
12. Договоритесь о режиме сопровождения после запуска.

Сопровождение после запуска

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

В JEEKSSHIRE 24 настраиваем наблюдение, оповещения о сбоях и резервные копии, чтобы о проблеме узнавали вы от нас, а не от клиентов, и договариваемся о режиме сопровождения. Та же команда держит в проде собственные продукты — Wallet и Legal, — поэтому наблюдение и обновления для нас обычная работа, а не отдельная история.

Если хотите обсудить проект и порядок его приёмки, опишите задачу своими словами в форме заявки: готовое ТЗ не обязательно. Ответы на другие частые вопросы собраны на странице «Ответы».

Приёмочное тестирование (UAT): кто и как проверяет

Приёмочное тестирование (UAT, user acceptance testing) — проверка продукта глазами тех, кто будет с ним работать. Команда разработки проверяет код и сценарии до выкатки, а UAT отвечает на другой вопрос: решает ли продукт задачу заказчика в реальной работе.

Чтобы такая проверка дала результат, её готовят заранее:

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

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

Замечания, акт и закрытие этапа

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

• Дефект — продукт не выполняет согласованный критерий приёмки. Это исправляется в рамках этапа.
• Новое пожелание — того, что хочется изменить, не было в договорённостях. Это оценивается и планируется отдельно.
• Блокирующее замечание — без исправления продуктом нельзя пользоваться. Неблокирующее можно исправить следующим релизом по согласованию.

Когда блокирующих дефектов нет, этап закрывают актом приёмки: документом, где стороны фиксируют, что работа выполнена по договорённостям. Если проект идёт частями, акт подписывают по каждой части. Акт фиксирует и то, какие неблокирующие замечания переносятся на следующий релиз.

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