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