1. Контекст приемки
Приемка проверяет готовность релиза к production
ПроектB2B-личный кабинет для обработки заявок клиентов
Релизv1.8.0-rc3
Окружениеstaging
Область приемкисоздание заявки, CRM-интеграция, статусы, документы, уведомления, роли и права доступа
Цель проверкиопределить готовность релиза к production и зафиксировать риски для бизнеса
Итоговая цель приемки: подтвердить, что клиент проходит ключевой end-to-end сценарий без ручных обходов, потери данных, дублей, неверных статусов и вмешательства поддержки.
2. Что именно проверяется
Проверка продукта, данных, интеграций и операционной готовности
| Блок | Что проверяем | Почему это важно |
|---|---|---|
| Бизнес-сценарии | Создание заявки, уточнение, подтверждение, статус, документы | Это основная ценность личного кабинета |
| Интеграции | ЛК → CRM, ERP → ЛК, ЛК → уведомления | Ошибка интеграции может привести к потере заявки или неверному статусу |
| Данные | Полнота, уникальность, отсутствие дублей, корректные ID | Без качества данных автоматизация создает хаос быстрее, чем ручной процесс |
| Роли и доступы | Клиент, менеджер, финансы, поддержка, администратор | Ошибка доступа может стать критичным инцидентом |
| Регресс | Ранее работавшие сценарии | Новый релиз не должен ломать базовые функции |
| Операционная готовность | Поддержка, инструкции, мониторинг, rollback | Релиз должен быть управляем после запуска |
| Аналитика и KPI | Фиксация метрик процесса | После запуска нужно понимать, достигнут ли эффект |
3. Acceptance strategy
Решение строится вокруг риска для бизнеса
Релиз может иметь несколько UI-дефектов низкой критичности и быть принят. Но релиз не может быть принят, если есть риск потери заявок, дублей в CRM, некорректной авторизации, неверных статусов заказа или невозможности отката.
Выпуск блокируется не количеством дефектов, а риском для заявок, CRM, документов и клиентских статусов.
8открытых дефектов
4блокирующих риска
0готовых обходных путей
Профиль дефектов 63% Critical / High
Critical · 3 High · 2 Medium · 2 Low · 1
Ключевые сценарии не проходят
CRM, доступы и статусы сломаны
Есть дубли и риск потери заявки
Релиз возвращается на исправления
| Решение | Условия |
|---|---|
| Принимать | Нет открытых Critical/High дефектов, smoke и ключевой регресс пройдены, поддержка и мониторинг готовы |
| Принимать с ограничениями | Есть Medium/Low дефекты, не влияющие на ключевые бизнес-сценарии; ограничения описаны и согласованы |
| Не принимать | Есть Critical/High дефекты, риск потери данных, нарушения доступа, дублей, неверных статусов или отсутствует rollback |
4. Карта критичных сценариев приемки
UAT-сценарии, которые определяют Go / No-Go
| ID | Сценарий | Роль | Бизнес-значимость | Критерий успеха |
|---|---|---|---|---|
| UAT-01 | Клиент создает заявку с полными данными | Клиент | Основной входящий поток | Заявка создана, имеет ID, отображается в ЛК |
| UAT-02 | Заявка передается в CRM | Система | Исключение ручного переноса | В CRM создана сделка, CRM ID сохранен в ЛК |
| UAT-03 | Ошибка CRM API обрабатывается без потери заявки | Система | Защита от потери выручки | Заявка ставится в очередь повторной отправки |
| UAT-04 | Менеджер видит заявку и меняет статус | Менеджер | Операционная обработка | Клиент видит обновленный клиентский статус |
| UAT-05 | ERP передает статус заказа в ЛК | Система | Прозрачность для клиента | Статус обновляется по правилам маппинга |
| UAT-06 | Клиент скачивает документы | Клиент | Закрытие процесса | Документ открывается, принадлежит компании клиента |
| UAT-07 | Пользователь видит только данные своей компании | Клиент | Безопасность и конфиденциальность | Доступ к чужим заявкам и документам невозможен |
| UAT-08 | Уведомления отправляются по ключевым событиям | Система | Снижение обращений в поддержку | Email/SMS отправлены и залогированы |
| UAT-09 | Поддержка видит журнал событий заявки | Поддержка | Управление инцидентами | История статусов и ошибок доступна первой линии |
| UAT-10 | Откат релиза возможен без потери данных | IT | Управление production-риском | Rollback plan проверен и согласован |
5. Executive summary
Не принимать релиз в текущем состоянии
Обнаружены критичные дефекты в сценариях создания заявки, обработки ошибок CRM API и разграничения доступа к документам. Эти дефекты создают риск дублей сделок, потери заявок, некорректной отчетности и доступа к данным другой компании.
BUG-017 Critical
Повторный клик создает дубли заявок и сделок в CRM
BUG-021 Critical
При ошибке CRM API заявка не попадает в очередь повторной отправки
BUG-025 Critical
Клиент может получить документ, не принадлежащий его компании
BUG-031 High
ERP-статус cancelled отображается клиенту как «В работе»
Условия для повторной приемки: устранить блокеры, повторить smoke и регресс по заявкам, CRM-интеграции, документам и статусам, провести сверку данных и подтвердить мониторинг с rollback plan.
6-7. Сводка дефектов и пример баг-репорта
BUG-017. Дублирование заявки при повторной отправке формы
| ID | Severity | Компонент | Описание | Бизнес-риск | Статус |
|---|---|---|---|---|---|
| BUG-017 | Critical | Создание заявки | При повторном клике создаются дубли заявок | Дубли сделок, искажение воронки, ручная очистка CRM | Open |
| BUG-021 | Critical | Интеграция CRM | При ошибке CRM API заявка не попадает в retry-очередь | Потеря заявок и потенциальной выручки | Open |
| BUG-025 | Critical | Документы / доступы | Пользователь может открыть документ другой компании по прямой ссылке | Нарушение конфиденциальности | Open |
| BUG-031 | High | Статусы ERP → ЛК | Отмененный заказ отображается как «В работе» | Клиент получает неверную информацию | Open |
| BUG-034 | High | Уведомления | Не отправляется уведомление о запросе уточнений | Клиент не реагирует, SLA срывается | In progress |
| BUG-037 | Medium | Файлы | Файл больше 20 МБ загружается без предупреждения, но затем не открывается | Ошибки в документообороте | Open |
| BUG-041 | Medium | Аналитика | Не фиксируется timestamp первой реакции менеджера | Невозможно измерить SLA | Open |
| BUG-046 | Low | UI | Некорректный отступ в карточке заявки на мобильном экране | Не влияет на бизнес-сценарий | Open |
Паспорт дефекта
| Severity | Critical |
|---|---|
| Priority | P1 |
| Компонент | Личный кабинет / Создание заявки |
| Окружение | staging |
| Версия | v1.8.0-rc3 |
| Связанные требования | FR-01, INT-01, ACC-01, ACC-04 |
| Связанные сценарии | UAT-01, UAT-02, UAT-03 |
Шаги воспроизведения
| 1 | Авторизоваться как клиент компании ООО Альфа |
|---|---|
| 2 | Перейти в раздел «Заявки» |
| 3 | Нажать «Создать заявку» |
| 4 | Заполнить обязательные поля |
| 5 | Быстро нажать кнопку «Отправить» 2–3 раза |
| 6 | Открыть список заявок в ЛК |
| 7 | Проверить сделки в CRM по external ID клиента |
Фактический и ожидаемый результат
Фактически: создаются две или более заявки с одинаковым составом данных, а в CRM появляются независимые сделки-дубли.
Ожидаемо: кнопка отправки блокируется, backend использует idempotency key и возвращает уже созданную заявку при повторной отправке.
Бизнес-влияние
| Среднее количество заявок в месяц | 1 200 |
|---|---|
| Оценочная частота повторного клика при задержке API | 3–5% |
| Потенциальное количество дублей в месяц | 36–60 |
| Среднее время ручной проверки одного дубля | 12 минут |
| Прямая операционная нагрузка | 7–12 часов / месяц |
| Дополнительный риск | Искажение воронки продаж и ошибочные коммуникации с клиентом |
8-9. Матрица регресса и сверка данных
Матрица регресса показывает, что проблема не локальна
| Блок | Сценарий | Статус | Комментарий |
|---|---|---|---|
| Авторизация | Вход клиента по логину и паролю | Passed | Критичных замечаний нет |
| Роли | Клиент видит только свою компанию | Failed | BUG-025 |
| Заявки | Создание заявки | Failed | BUG-017 |
| CRM | Создание сделки | Failed | BUG-017, BUG-021 |
| CRM | Ошибка API и retry | Failed | BUG-021 |
| ERP | Получение статуса заказа | Failed | BUG-031 |
| Документы | Загрузка документа клиентом | Failed | BUG-025 |
| Уведомления | Уведомление о запросе уточнений | Failed | BUG-034 |
| Аналитика | Время первой реакции менеджера | Failed | BUG-041 |
| Поддержка | Журнал событий заявки | Passed with notes | Не хватает фильтра по ошибкам интеграции |
Сверка данных между системами
| Проверка | Выборка | Ожидаемо | Фактически | Статус |
|---|---|---|---|---|
| Заявки ЛК → CRM | 100 | 100 сделок | 104 сделки | Failed |
| Уникальность external request ID | 100 | 100 уникальных ID | 96 уникальных ID | Failed |
| Наличие CRM ID в ЛК | 100 | 100 | 92 | Failed |
| ERP-статусы → клиентские статусы | 40 | 40 корректных маппингов | 37 | Failed |
| Документы ERP → ЛК | 30 | 30 документов | 30 документов | Passed |
| Права доступа к документам | 30 | Доступ только своей компании | 1 нарушение | Failed |
10-12. Readiness checklist
Операционная готовность и экономический риск выпуска
| Блок готовности | Критерий | Статус | Комментарий |
|---|---|---|---|
| Критичные дефекты | Нет открытых Critical и High | Failed | Открыты BUG-017, BUG-021, BUG-025, BUG-031 |
| Smoke-тест | Все ключевые сценарии проходят | Failed | Не проходят заявка, CRM, документы, статусы |
| Регресс | Нет поломок в ранее работающих сценариях | Failed | Регресс по CRM и статусам |
| Интеграции | Ошибки интеграций не приводят к потере данных | Failed | Нет retry-очереди для CRM |
| Роли и доступы | Пользователь видит только разрешенные данные | Failed | BUG-025 |
| Мониторинг | Ошибки API логируются и доступны поддержке | Partial | Логи есть, но нет алертов по дублям и retry |
| Rollback plan | Есть понятный план отката | Passed with notes | Откат возможен до v1.7.2, но нужна сверка новых заявок |
| UAT | Бизнес подтвердил ключевые сценарии | Not ready | Требуется повторная приемка после исправлений |
Операционная готовность релиза
| Вопрос | Ответ | Риск |
|---|---|---|
| Кто отвечает за инциденты в первые 72 часа после релиза? | IT + Product owner + Support lead | Риск снижен |
| Есть ли инструкция для поддержки? | Частично | Поддержка не знает, как классифицировать дубли CRM |
| Есть ли алерты по ошибкам интеграции? | Частично | Ошибки CRM API могут копиться без реакции |
| Есть ли процедура ручной сверки? | Нет | При инциденте сложно восстановить картину |
| Есть ли план отката? | Да | Требуется дополнить сверкой новых заявок |
Экономический риск выпуска с дефектами
| Риск | Потенциальный эффект | Оценка влияния |
|---|---|---|
| Дубли сделок в CRM | Ручная очистка, ошибки менеджеров, некорректная аналитика | 70 000–120 000 ₽ / месяц |
| Потеря заявок при сбое CRM API | Потеря потенциальной выручки и SLA | Высокое, зависит от стоимости заказа |
| Некорректный статус заказа | Рост обращений в поддержку, недоверие клиентов | 150–250 обращений / месяц |
| Ошибка доступа к документам | Юридический и репутационный риск | Критично, денежная оценка не применяется |
| Отсутствие timestamp первой реакции | Невозможно измерить KPI внедрения | Срывает контроль эффекта проекта |
Вывод: даже если интерфейс визуально готов, релиз несет высокий операционный и управленческий риск. Выпускать его до устранения блокеров не рекомендуется.
13. Матрица решения Go / No-Go
Итоговое решение: No-Go
| Критерий | Go | No-Go | Текущий статус |
|---|---|---|---|
| Critical/High дефекты | Отсутствуют | Есть открытые | No-Go |
| Потеря данных | Не выявлена | Есть риск потери заявки | No-Go |
| Дубли | Не создаются | Есть дубли заявок или сделок | No-Go |
| Доступы | Данные изолированы по компаниям | Есть доступ к чужим данным | No-Go |
| Статусы | Маппинг корректен | Клиент видит неверный статус | No-Go |
| Retry интеграций | Работает | Ошибка API теряет заявку | No-Go |
| Rollback | Описан и проверен | Не описан или неполный | Partial |
| Поддержка | Инструкции готовы | Нет инструкций по инцидентам | Partial |
14-16. План исправлений и повторной приемки
Релиз v1.8.0-rc3 не готов к production
План исправлений перед повторной приемкой
| Приоритет | Что исправить | Владелец | Критерий готовности |
|---|---|---|---|
| P1 | Устранить дублирование заявок | Backend + Frontend | 50 повторных отправок не создают дублей |
| P1 | Реализовать retry-очередь CRM | Backend + Integration team | Ошибка CRM API не теряет заявку |
| P1 | Исправить доступ к документам | Backend + Security | Документ доступен только компании-владельцу |
| P1 | Исправить маппинг статуса cancelled | Backend + Product | Клиент видит статус «Отменен» |
| P2 | Настроить алерты по ошибкам интеграции | IT operations | Алерт создается при ошибке CRM API |
| P2 | Добавить timestamp первой реакции | Backend + CRM | SLA фиксируется в карточке заявки |
План повторной приемки
Все P1 исправлены и подтверждены
1. Проверка исправлений P1
Retest BUG-017, BUG-021, BUG-025, BUG-031
Все ключевые сценарии Passed
2. Smoke-тест
Проверка UAT-01 — UAT-10
Нет потерь, дублей и неверных статусов
3. Регресс интеграций
CRM, ERP, документы, уведомления
Расхождения отсутствуют или объяснены
4. Сверка данных
ЛК ↔ CRM ↔ ERP
Поддержка и IT готовы к запуску
5. Проверка операционной готовности
Мониторинг, инструкции, rollback
Решение зафиксировано протоколом
6. Финальное Go / No-Go
Совместное решение Product, IT, Business
Финальная подпись для сайта: на выходе клиент получает не просто «список багов», а управленческое заключение по релизу: что сломано, насколько это критично, какие бизнес-риски несет выпуск и можно ли принимать систему в production.