Одним из важнейших инструментов в работе с требованиями являются acceptance criteria — четкие условия, которые определяют, что именно должно быть реализовано в рамках конкретной задачи или user story. Это не общие формулировки типа «быстро», «качественно» или «юзерфрендли», а конкретные проверяемые утверждения, которые позволяют команде сказать: да, это сделано, и сделано правильно.
Acceptance criteria — это не просто технический термин. Это мостик между «хочу» заказчика и «можем сделать» команды. Их формулировка — ключевой этап, который определяет, насколько эффективно команда поймет задачу и сможет ли реализовать именно то, что действительно нужно.
В этой статье рассмотрим, как project manager или бизнес-аналитик может превратить нечеткие пожелания заказчика в конкретные acceptance criteria. Мы также коснемся связанных понятий, типичных ошибок, примеров и практик, которые помогают командам работать с требованиями на качественном уровне.
Этот материал подготовлен на основе лекции Анны Лавровой — организационной Agile-коуча в компании Humanity. На протяжении многих лет она работает с командами продуктовых и аутсорсинговых компаний, а также обучает проектных менеджеров, бизнес-аналитиков и product owner’ов создавать понятные требования.
Что такое acceptance criteria — и почему это не то же самое, что definition of done
Acceptance criteria — это набор четких, проверяемых утверждений, которые описывают, каким должен быть результат реализации конкретной задачи. Они создаются не на уровне всего проекта, а для каждой отдельной user story. Их цель — дать однозначный ответ на вопрос: сделано ли именно то, что нужно, и имеет ли это ценность для пользователя?
В отличие от общих пожеланий заказчика типа «отчет должен быть полным» или «должен выглядеть профессионально», acceptance criteria должны быть конкретными: что именно должно быть в отчете, в каком формате, какого объема, как быстро генерируется, как выглядит файл, какова логика сортировки и т. д.
«Acceptance criteria — это не о технической реализации, это о бизнес-ожиданиях. Это способ описать, как выглядит ценность, которую мы создаем. Нельзя просто сказать «функционал сделан» — нужно сказать, что именно должно работать и как мы это проверим».
Важно не путать acceptance criteria с другим известным термином — definition of done (DoD). Оба эти понятия важны в работе с требованиями, но имеют совершенно разную природу:
Definition of done — это внутренняя договоренность команды о том, что означает «завершено». Это критерии качества и процесса: написан код, покрыт тестами, прошел code review, задеплоирован на staging и т. д.
Acceptance criteria — это описание результата, которого ожидает заказчик или пользователь. Это проверка того, действительно ли задача решает бизнес-проблему и работает ли созданный функционал в соответствии с ожиданиями.
Разница между aceptance criteria и definition of done
| Критерии приемки | Определение выполненного (DoD) |
| Что описывает | Ожидаемое поведение функционала с точки зрения пользователя | Внутренние технические шаги, свидетельствующие о завершении задачи |
| Уровень | Для каждой конкретной user story | Для всей команды или отдельного типа задач |
| Авторство | Формируется в диалоге с бизнесом или заказчиком | Формируется командой самостоятельно |
| Тип утверждений | Проверяемые бизнес-условия («да»/«нет») | Стандартизированные действия процесса разработки |
| Цель | Подтвердить, что результат ценен и соответствует ожиданиям | Обеспечить техническое качество и завершенность задачи |
| Формат | Конкретные кейсы, часто в формате Given-When-Then | Список этапов (написанный код, покрыт тестами, задеплоен) |
DoD — это о процессе и технической завершенности. Acceptance criteria — о бизнес-ценности и ожидаемом поведении системы.
Только в случае, когда и DoD, и acceptance criteria выполнены, мы можем сказать, что user story завершена полностью — и технически, и с точки зрения пользователя.
«Критерии приемки не создаются для кого-то одного. Это общее пространство понимания между всеми: PM-ом, аналитиком, разработчиком, тестировщиком, продакт-овнером. Они должны быть понятны и проверяемы для каждого»
Характеристики Acceptance criteria
В целом, критерии приемки должны соответствовать следующим характеристикам:
- Четкие. У них должно быть 2 уникальных результата: успех или отказ. Нет термина «частичный успех» — критерий приемлемости всегда должен давать нам зеленый или красный.
- Однозначные. Acceptance criteria должны интерпретировать их только одним способом. Не должно быть чего-то вроде «Форма должна быть окрашена в веселый цвет» — хотя худшие вещи были замечены на практике.
- Подтверждаемые. Они должны быть написаны так, чтобы клиент мог их быстро проверить.
- Полные. Набор критериев приемлемости должен включать все функциональные требования.
О требованиях отдельно — далее в статье. А пока давайте разберем типичные ошибки при создании критериев приемлемости.
«Если вы не можете проверить критерий «да» или «нет», это не критерий»
Что не так с этими критериями приемки? Типичные ошибки на практике
Формально, критерии приемки есть. Но по сути — команда все еще не понимает, что именно нужно сделать. Самая распространенная проблема: заказчик (или иногда и сам PM) формулирует критерии слишком обще, абстрактно или нечетко.
Вот пример user story:
Как администратор, я хочу иметь возможность создавать отчеты, чтобы отслеживать активность пользователей.
Вот «плохие» критерии приемки, которые сопровождают эту историю:
- Система генерирует отчеты.
- Отчеты должны содержать все необходимые данные.
- Отчеты должны быть экспортированы во все популярные форматы.
На первый взгляд, звучит логично. Но для разработчика и тестировщика это — набор вопросов без ответов:
- Что означает «все данные»? Какие именно метрики должны быть в отчете?
- Что такое «популярные форматы»? PDF? CSV? Excel? JSON?
- Что считается успешной генерацией? Есть ли ограничения на размер файла? Название? Скорость?
В таких формулировках нет конкретики, они не поддаются проверке, и команда не сможет однозначно сказать: «да, сделано».
Как это исправить?
Вместо общих формулировок, каждый пункт должен быть четким, конкретным и легко проверяемым. Например:
- Отчет содержит поля: имя пользователя, ID, дата последнего входа, IP-адрес.
- Отчет можно сгенерировать в форматах: PDF (до 5 МБ), CSV (до 2 МБ).
- Название файла должно соответствовать шаблону activity_report_<дата>.pdf.
- Генерация отчета длится не более 10 секунд.
Эти формулировки уже являются настоящими acceptance criteria — такими, которые помогут команде понять задачу, а тестировщику — проверить результат.
Хотите научиться работать с acceptance criteria, как профи? Приходите на PM Hard Skills Planning. Это полная программа навыков проектного менеджера для планирования, работы с рисками и ведения проектов разного уровня. Смотрите подробности на сайте.
Еще пример: как превратить восстановление пароля в понятные критерии
Вот еще один пример user story, который можно встретить в любом цифровом продукте:
Как пользователь, я хочу иметь возможность сбросить пароль, чтобы получить доступ к моей учетной записи, если я его забыл.
И вот так часто выглядят сопроводительные «критерии приемки»:
- Пользователь может запросить сброс пароля.
- Пользователь может установить новый пароль.
- Пользователь получает письмо со ссылкой для сброса.
Почему этого недостаточно?
Потому что такие формулировки не учитывают большинство сценариев, с которыми столкнется и пользователь, и команда. Остается открытыми много важных вопросов:
- Какой именно механизм подтверждения личности?
- Как выглядит письмо и с какого email оно приходит?
- Каков срок действия ссылки?
- Что будет, если пользователь нажмет на ссылку второй раз?
- Каковы требования к новому паролю?
Все это — критически важные детали, которые не должны «додумываться» разработчиком или тестировщиком. Их следует включать в форму acceptance criteria.
Как это могло бы выглядеть лучше?
- После запроса пользователь получает email от support@product.com с темой «Password reset» и уникальной ссылкой.
- Ссылка активна в течение 30 минут и одноразовая.
- При переходе по ссылке пользователь попадает на страницу ввода нового пароля.
- Пароль должен содержать минимум 8 символов, одну цифру и одну заглавную букву.
- Если ссылка недействительна или просрочена, пользователь видит сообщение: «Ссылка недействительна или уже использована».
Такие критерии уже позволяют четко проверить, соответствует ли реализованная функция ожиданиям. И что важно — все эти детали нужно выстраивать через диалог с заказчиком или командой, задавая уточняющие вопросы, а не принимая формулировку «все просто, как у всех».
Какие бывают требования: не только «функциональные»
Работа с acceptance criteria предполагает понимание, что в User Story могут быть разные типы требований. Часто команды сосредотачиваются только на функциональности («что должно быть реализовано»), но для качественного результата нужно учитывать также нефункциональные и системные аспекты.
Вот основные типы требований, которые нужно уметь различать и включать в разработку:
1. Функциональные требования
Это — то, что система должна делать. Они описывают функциональность с точки зрения пользователя или бизнеса.
Примеры:
- Пользователь может войти в аккаунт по email и паролю.
- Система отправляет письмо подтверждения после регистрации.
- Администратор имеет доступ к дашборду статистики.
2. Нефункциональные требования
Это требования к качеству работы системы, а не к функциям как таковым. Они часто остаются без внимания — и именно из-за них продукт «медленный», «непонятный» или «опасный».
Примеры:
- Время генерации отчета не превышает 10 секунд.
- Интерфейс адаптируется под мобильные устройства.
- Данные хранятся в соответствии со стандартом GDPR.
- Страница доступна по WCAG-уровню доступности.
3. Системные требования
Это требования к инфраструктуре или среде, в которой работает продукт. Их часто описывают DevOps-инженеры или архитекторы.
Примеры:
- Сервис должен поддерживать не менее 2000 одновременных соединений.
- Работает с базой данных PostgreSQL 14+.
- Развертывается в среде AWS (EC2 + S3).
4. Независимые требования
Это условия, которые выполняются автоматически или в фоновом режиме, независимо от действий пользователя. Их важно учитывать при планировании.
Примеры:
- Ежедневное резервное копирование базы данных в 02:00.
- Логирование действий пользователя в систему аудита.
- Автоматическое завершение сессии после 30 минут неактивности.
Эти требования не всегда имеют вид отдельных acceptance criteria, но они влияют на готовность задачи, планирование тестирования и общее качество продукта. Хорошая практика — всегда уточнять: «А что мы забыли из нефункционального или системного?»
«Если критерии приемки не написаны, команда будет реализовывать то, что поняла, а не то, что нужно»
Вывод
Acceptance criteria — это один из ключевых инструментов в работе проектного менеджера, аналитика или любой команды, взаимодействующей с требованиями. Именно от качества этих критериев зависит, насколько точно команда поймет задачу, будет ли она выполнена правильно и получит ли заказчик настоящую бизнес-ценность.
Формулировка критериев приемки — это не механическое действие. Это процесс мышления, обсуждения, уточнения и проверки. Это способ избежать неправильных предположений и сэкономить время на исправлениях в будущем.
Если вы умеете превращать общие пожелания в конкретные проверяемые критерии — вы строите мосты между ожиданием и реализацией. И именно это делает вас сильным специалистом.