Одним із найважливіших інструментів у роботі з вимогами є 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 — це опис результату, який очікує замовник або користувач. Це перевірка того, чи дійсно задача вирішує бізнес-проблему, і чи створений функціонал працює відповідно до очікувань.
Різниця між acceptance criteria та definition of done
| Acceptance Criteria | Definition of Done (DoD) |
| Що описує | Очікувану поведінку функціоналу з точки зору користувача | Внутрішні технічні кроки, які свідчать про завершення задачі |
| Рівень | Для кожної конкретної user story | Для всієї команди або окремого типу задач |
| Авторство | Формується в діалозі з бізнесом або замовником | Формується командою самостійно |
| Тип тверджень | Перевірювані бізнес-умови («так» / «ні») | Стандартизовані дії процесу розробки |
| Мета | Підтвердити, що результат цінний та відповідає очікуванням | Забезпечити технічну якість і завершеність задачі |
| Формат | Конкретні кейси, часто у форматі Given–When–Then | Список етапів (написаний код, покрито тестами, задеплоєно) |
DoD — це про процес і технічну завершеність. Acceptance criteria — про бізнес-цінність і очікувану поведінку системи.
Тільки у випадку, коли і DoD, і acceptance criteria виконані, ми можемо сказати, що user story завершена повністю — і технічно, і з точки зору користувача.
«Критерії прийомки не створюються для когось одного. Це спільний простір розуміння між усіма: PM-ом, аналітиком, розробником, тестувальником, продакт-овнером. Вони повинні бути зрозумілі й перевірювані для кожного»
Характеристики Acceptance criteria
Загалом, критерії прийомки мають відповідати таким характеристикам:
- Чіткі. У них має бути 2 унікальні результати: успіх або відмова. Немає терміна «частковий успіх» – критерій прийнятності завжди повинен давати нам зелений або червоний.
- Однозначні. Acceptance criteria повинні інтерпретувати їх тільки в один спосіб. Не повинно бути чогось на кшталт «Форма має бути пофарбована у веселий колір» – хоча найгірші речі були помічені на практиці.
- Підтверджувані. Вони мають бути написані так, щоб клієнт міг їх швидко перевірити.
- Повні. Набір критеріїв прийнятності має включати всі функціональні вимоги.
Про вимоги окремо – далі у статті. А поки що розберімо типові помилки при створенні acceptance criteria.
«Якщо ви не можете перевірити критерій «так» або «ні», це не критерій»
Що не так із цими acceptance criteria? Типові помилки на практиці
Формально, acceptance criteria є. Але по суті — команда все ще не розуміє, що саме треба зробити. Найпоширеніша проблема: замовник (або іноді й сам PM) формулює критерії занадто загально, абстрактно або нечітко.
Ось приклад user story:
Як адміністратор, я хочу мати можливість створювати звіти, щоб відстежувати активність користувачів.
Ось «погані» acceptance criteria, які супроводжують цю історію:
- Система генерує звіти.
- Звіти мають містити всі необхідні дані.
- Звіти мають бути експортовані у всі популярні формати.
На перший погляд, звучить логічно. Але для розробника і тестувальника це — набір запитань без відповідей:
- Що означає «всі дані»? Які саме метрики мають бути у звіті?
- Що таке «популярні формати»? 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 — це один із ключових інструментів у роботі проєктного менеджера, аналітика чи будь-якої команди, що взаємодіє з вимогами. Саме від якості цих критеріїв залежить, наскільки точно команда зрозуміє задачу, чи буде вона виконана правильно, і чи отримає замовник справжню бізнес-цінність.
Формулювання критеріїв прийомки — це не механічна дія. Це процес мислення, обговорення, уточнення і перевірки. Це спосіб уникнути неправильних припущень і заощадити час на виправленнях у майбутньому.
Якщо ви вмієте перетворювати загальні побажання на конкретні перевірювані критерії — ви будуєте мости між очікуванням і реалізацією. І саме це робить вас сильним фахівцем.