На демонстрации всё может выглядеть готовым: страницы открываются, кнопки работают, заказ появляется в кабинете. Но этого недостаточно для приёмки. После передачи проект должен работать в согласованных условиях, принадлежать заказчику в оговорённом объёме и не зависеть от единственного человека, который знает, как его запустить.
Приёмка нужна не для поиска повода не платить разработчикам. Это проверка общего результата: что сделано, какие ограничения остаются и кто отвечает за систему после запуска. Чем раньше команда и заказчик согласуют эти условия, тем меньше спорных ситуаций будет в конце.
Ниже разберём, что можно проверить самостоятельно, какие подтверждения запросить и где потребуется технический специалист.
1. Проверять сценарии, а не отдельные экраны
Основой приёмки должны быть требования и пользовательские сценарии, согласованные до разработки. Если ожидания остались только в переписке, сначала соберите их в общий список и отдельно отметьте изменения, которые команда приняла в работу.
Проверяйте путь целиком. Для интернет-магазина это не только карточка товара, но и выбор варианта, расчёт стоимости, оформление заказа, оплата, подтверждение и отображение заказа у менеджера. Для сервиса записи важно, чтобы занятый слот исчезал из доступных, а отмена корректно меняла расписание.
У каждого сценария стоит проверить не только успешный результат:
- Что происходит при неправильных данных или недостаточных правах?
- Можно ли случайно создать два заказа повторным нажатием кнопки?
- Что увидит пользователь при обрыве сети или недоступности внешнего сервиса?
- Сохраняется ли результат после обновления страницы и повторного входа?
- Как выполняются отмена, возврат и исправление ошибки?
Проводите проверки на согласованных устройствах и браузерах, с разными ролями пользователей. Платежи сначала тестируйте в тестовом режиме провайдера. Проверку реальной операции согласуйте отдельно, включая сумму, возврат и ответственного, чтобы приёмка не создавала случайные расходы.
Найденные проблемы фиксируйте с шагами воспроизведения, ожидаемым результатом и скриншотом или видео. Формулировка «оплата работает странно» менее полезна, чем конкретный сценарий, который команда может повторить.
2. Получить код, доступы и контроль над аккаунтами
Архив исходников в мессенджере не заменяет нормальную передачу проекта. Заказчику нужен доступ к репозиторию, версия релиза и понимание, какой код работает на сервере. История изменений помогает другой команде разобраться в решениях и продолжить разработку.
Попросите составить реестр ресурсов:
- Репозитории и организация, в которой они находятся.
- Домен, DNS и аккаунт регистратора.
- Серверы, облачные сервисы, базы данных и хранилища файлов.
- Платёжный провайдер, почтовые сервисы и внешние API.
- Аналитика, мониторинг, магазины приложений и связанные аккаунты.
Для каждого ресурса нужны владелец, администраторы, способ восстановления доступа и источник оплаты. Критичные аккаунты лучше оформлять на заказчика там, где это допускают условия сервиса. Доступ подрядчика можно сохранить как рабочий, но он не должен быть единственным способом управления продуктом.
Пароли и секретные ключи передавайте через согласованный защищённый канал, а не в общей таблице или открытом репозитории. После передачи пересмотрите права, включите многофакторную аутентификацию, где она доступна, и замените чувствительные ключи по согласованному плану. Резкая замена всех ключей без проверки зависимостей может остановить сервис.
3. Убедиться, что проект можно запустить и восстановить
Документация считается полезной, если по ней можно выполнить работу, а не просто прочитать описание архитектуры. В комплект передачи должны входить инструкции запуска, сборки и обновления, список необходимых сервисов и описание настроек окружения без раскрытия секретов.
Отдельно нужны порядок изменения базы данных, резервного копирования и отката релиза. Важно знать не только где лежит копия, но и что она содержит: базу, загруженные файлы, настройки или лишь часть системы.
Хорошая проверка передачи: инженер, который не участвовал в разработке, разворачивает проект в отдельном окружении по документации. Если ему приходится постоянно спрашивать автора кода, какие команды выполнить, инструкции ещё требуют доработки.
Восстановление резервной копии тоже проверяют отдельно, не поверх действующей базы. После него нужно убедиться, что данные читаются и основные сценарии работают. Наличие файла с названием backup не подтверждает возможность восстановления.
Согласуйте допустимую потерю данных и время восстановления. Для небольшого информационного сайта и сервиса, который принимает заказы круглосуточно, требования будут разными. Универсальной нормы здесь нет, но отсутствие договорённости оставляет бизнес без понятного плана при сбое.
4. Проверить безопасность и работу с данными
Заказчику не обязательно читать весь код, чтобы задать правильные вопросы. Попросите команду показать, как разделены роли, где хранятся секреты, какие данные попадают в логи и что происходит при попытке открыть чужой заказ или документ.
Скрытая кнопка в интерфейсе не является защитой. Ограничения должны проверяться на сервере: обычный пользователь не должен получать административные данные только потому, что знает адрес запроса.
В базовую проверку обычно входят:
- Контроль доступа к чужим данным и действиям администратора.
- Отсутствие секретов в публичном коде и клиентской сборке.
- Корректная обработка повторных платёжных уведомлений.
- Ограничение лишних данных в логах, выгрузках и ответах API.
- Проверка зависимостей и устранение либо документирование значимых рисков.
Объём проверки зависит от последствий ошибки. Для продукта с деньгами пользователей, чувствительными данными или смарт-контрактами может потребоваться независимый аудит. Его границы нужно согласовать: что проверено, какой версией кода ограничен отчёт и какие замечания закрыты.
Успешный тест или отчёт не гарантирует отсутствие всех уязвимостей. Он даёт подтверждение конкретных проверок. Приёмка должна фиксировать оставшиеся риски и ответственных, а не сводиться к обещанию «у нас всё безопасно».
5. Разобраться с правами и поддержкой после запуска
Доступ к исходникам и право использовать или изменять их не одно и то же. В договоре и документах передачи нужно проверить объём передаваемых прав, условия работы с дизайном и контентом, а также лицензии сторонних компонентов. Для спорных вопросов привлеките юриста с учётом применимого права.
Не все библиотеки становятся собственностью заказчика вместе с проектом. Некоторые элементы используются по лицензии, другие требуют подписки. Нужен список таких зависимостей, ограничений и регулярных расходов, включая шрифты, изображения и внешние сервисы.
До финальной передачи согласуйте, что происходит после релиза:
- Кто следит за ошибками и доступностью системы?
- Какие дефекты входят в гарантийные исправления и на какой срок?
- Чем исправление ошибки отличается от новой функции или изменения требований?
- Как принимаются обращения и какие сроки реакции согласованы?
- Кто отвечает за обновления, резервные копии и продление сервисов?
Приёмка не должна требовать бесконечных бесплатных доработок. Но и передача проекта без понятной границы ответственности создаёт риск: при первом сбое каждая сторона может считать, что заниматься им должна другая.
6. Отдельно проверить результат AI-разработки
Использование нейросетей само по себе не является недостатком. AI может помочь быстрее написать типовой код, тесты и документацию. Но заказчик принимает работающую систему, а не количество сгенерированных строк.
Попросите подтверждение того, что изменения проходят ревью, основные сценарии покрыты проверками, а используемые зависимости известны команде. Особенно важны права доступа, платежи и обработка ошибок: внешне убедительный код в этих местах может содержать серьёзные дефекты.
Сгенерированная документация должна соответствовать реальному проекту. Проверка запуска в отдельном окружении быстро показывает, существуют ли указанные команды, переменные и сервисы на самом деле.
Также стоит согласовать правила использования AI-инструментов: какие данные можно передавать провайдеру, допускается ли загрузка закрытого кода и как защищаются секреты. Условия зависят от инструмента, настроек и договора. Ответственность за выбранный процесс и результат остаётся у команды.
Таблица приёмки: что запросить у команды
| Что проверить | Какое подтверждение получить | Что блокирует запуск |
|---|---|---|
| Основные сценарии | Результаты проверок по согласованному списку | Критичный путь нельзя завершить |
| Код и доступы | Репозиторий, версия релиза и реестр аккаунтов | Заказчик не контролирует критичные ресурсы |
| Развёртывание | Проверенный запуск по инструкции | Проект нельзя воспроизвести без автора |
| Резервные копии | Проверка восстановления в отдельном окружении | Нет подтверждённого восстановления критичных данных |
| Безопасность | Результаты проверок и список оставшихся рисков | Известная критичная уязвимость или доступ к чужим данным |
| Права | Согласованные документы и список лицензий | Нет необходимых прав для планируемого использования |
| Поддержка | Зафиксированные зоны ответственности | Для запуска нет согласованного плана реагирования на сбои |
Не каждое замечание должно останавливать релиз. Небольшую визуальную неточность можно перенести в согласованный список исправлений, если она не мешает использованию. Потерю данных, неверное списание денег или нарушение прав доступа откладывать нельзя. Приоритеты и допустимые ограничения стороны фиксируют вместе.
Хорошо переданный проект можно понять, запустить, восстановить и развивать другой командой. Именно это, вместе с работающими пользовательскими сценариями и понятными правами, стоит считать результатом приёмки. Красивое демо показывает интерфейс. Полноценная передача показывает, что бизнес действительно получил свой продукт.