Что считается работающим первым этапом и как его принимать

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

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

Для каждого критерия должен существовать способ воспроизвести вход, увидеть выход и зафиксировать вывод. Формулировка «работает качественно» непроверяема. Формулировка «для контрольного документа система извлекает обязательные поля и показывает исходные фрагменты» задает наблюдаемое поведение.

В одном документе зафиксируйте:

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

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

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

Контрольный набор не следует незаметно менять во время приемки. Новые примеры можно использовать для исследования, но решение о соответствии этапа принимается на согласованной версии набора и правил.

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

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

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

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

Такой подход полезнее общей просьбы о «максимальной точности».

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

Для каждого контрольного случая фиксируйте:

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

Не объединяйте несколько разных проблем в одно замечание. Точное описание ускоряет воспроизведение и показывает, относится ли вопрос к ТЗ.

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

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

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

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

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