Критерії приймання: що значить "готово" до того, як ми почали

Це для людей, які замовляють IT-розробку, але самі не пишуть код. Якщо ми колись підписували акт виконаних робіт і відчували “щось тут не так, але не можу довести” — це для нас.

Чому це болить

Найдорожчий рядок у договорі на розробку звучить безневинно: “MVP буде готовий за 3 місяці”.

Це не угода. Це лотерея. І ось чому:

“MVP” — у нас в голові одна штука, у виконавця друга, у дизайнера третя.
“Готовий” — для розробника це “запускається без помилок”. Для нас — “користувач може оплатити рахунок за 30 секунд”.
“3 місяці” — від якої дати? Від підписання? Від отримання предоплати? Від моменту “коли всі будуть готові”?

І коли через 3 місяці ми бачимо щось наполовину робоче, починається найгірша частина проекту — суперечка про те, що саме обіцяли. Без документа, у якому це було записано чорним по білому, виграє той, хто голосніший. А голосніший — не ми.

Усе це лікується одним документом, який чомусь часто пропускають. Він називається критерії приймання — або англійською acceptance criteria. Простими словами: список умов, виконання яких означає “роботу здали”.

Що таке критерії приймання — одне речення

Це перелік перевірок, які ми (замовник) можемо зробити самі, без виконавця, щоб переконатися, що зроблено саме те, що замовляли.

Ключове слово — самі. Якщо для перевірки потрібно, щоб розробник “відкрив консоль” або “запустив тест” — це не критерій приймання, а технічна нотатка. Гарний критерій формулюється так, що ми (нетехнічна людина) можемо клікнути по програмі і сказати “так” або “ні”.

Поганий → нормальний → гарний

Беремо ілюстративну задачу: користувач оплачує рахунок за комунальні послуги через застосунок. Поглянемо, як одне і те саме можна описати трьома способами.

Поганий критерій (так не треба)

“Користувач може оплатити рахунок.”

Проблема: не можемо перевірити. Може оплатити як саме? З якими методами оплати? Що бачить після успіху? А якщо банк відмовив? А якщо інтернет пропав посередині?

Нормальний критерій (вже краще)

“Користувач відкриває застосунок, бачить свій рахунок, натискає ‘Оплатити’, обирає банк, підтверджує — і отримує квитанцію на email протягом 1 хвилини.”

Що тут добре: є послідовність кроків, є вимірний результат (квитанція за 1 хвилину). Можемо перевірити з годинником у руці.

Що ще можна додати, щоб стало гарно:

Гарний критерій (з контр-прикладами)

Користувач відкриває застосунок, бачить свій рахунок, натискає “Оплатити”, обирає банк, підтверджує — і отримує квитанцію на email протягом 1 хвилини.

Додатково:

Якщо інтернет пропав посередині — застосунок показує повідомлення “Оплата не пройшла. Спробуйте ще раз” і не списує гроші двічі після відновлення.

Якщо банк відмовив — показуємо причину українською (не код помилки) і пропонуємо інший банк.

Якщо користувач не вказав email — питаємо перед натисканням “Оплатити”, не після.

Тепер це угода. Ми (замовник) можемо взяти телефон, спробувати оплатити в нормальних умовах, спробувати оплатити з вимкненим інтернетом, спробувати з неправильною карткою — і за кожним сценарієм сказати “працює” або “не працює” без участі розробника.

5 запитань, які варто поставити до контракту

Тепер найважливіше. Це не запитання, які треба ставити після того, як проект уже триває 2 місяці. Це запитання, які ми озвучуємо перед підписанням договору.

1. “Як ми перевірятимемо, що задача готова?”

Чесна відповідь звучить як список перевірок з вимірними результатами. Нечесна — “ну, ми покажемо, і ви побачите”.

2. “Що буде, якщо я перевірив і не працює?”

Має бути правило, яке діє до грошей. Наприклад: “якщо за критеріями приймання щось не пройшло — задача в статусі ‘на доопрацюванні’, і ми працюємо, поки не пройде, без додаткової оплати”.

3. “Хто пише ці критерії — ви чи я?”

Найкраща відповідь: “ми разом, у форматі коротких сесій по 30 хв на кожну велику задачу”. Друга найкраща: “ми пишемо чернетку, ви читаєте і додаєте свої сценарії — особливо ті, де щось іде не так”. Якщо відповідь “не хвилюйтесь, ми все знаємо” — це червоний прапор.

4. “Що, коли користувач робить щось неочікуване?”

Гарний виконавець завжди має приклади негативних сценаріїв: інтернет пропав, юзер натиснув двічі, банк відмовив. Якщо в розмові обговорюємо тільки “як все буде працювати ідеально” — половина проекту ще попереду в формі сюрпризів.

5. “Можна побачити приклад критеріїв приймання з минулого проекту?”

Це найдешевший фільтр якості. У виконавця, який щодня з цим працює, такі приклади є за 5 хвилин. У того, хто не працює з ними системно — несподівано не знаходяться.

Як виглядає файл “готовності” по факту

Не треба нічого складного. Звичайна Google-табличка з 3 колонками. Виглядає це приблизно так:

Що перевіряємо	Як перевіряємо	Статус
Користувач може оплатити з основним банком	Спробую сам зі своєю карткою. Отримую квитанцію за <1 хв	✅
При відсутності інтернету гроші не списуються двічі	Вимикаю Wi-Fi посередині оплати, перевіряю баланс	✅
Помилки показуються українською, не кодом	Спробую з картки з 0 балансом	⏳ перевіряємо
Email вимагається до натискання “Оплатити”	Видаляю email з профілю, спробую оплатити	❌ зараз дозволяє без email

Скільки рядків — стільки рядків. На задачу “оплата рахунку” зазвичай 5-10 критеріїв, а не 50. Якщо вийшло 50 — або задача занадто велика і її треба розбити, або ми пишемо технічні нотатки, а не критерії приймання.

Часті помилки на старті

Думаємо, що критерії приймання — це робота розробника. Це наша спільна робота. Розробник знає, як зробити. Ми знаємо, навіщо. Без нашого голосу критерії будуть про “технічну коректність”, а не про “користувач щасливий”.
Підписуємо критерії “пакетом” на 3 місяці вперед. Не треба. Достатньо описати наступну хвилю задач — і доповнювати по ходу. Контракт повинен дозволяти такий формат.
Не записуємо “негативні” сценарії. “Що буде, коли” — наша головна страховка. Скрізь, де є гроші, треті сторони (банки, оператори) або введення даних — обов’язково додаємо хоча б один сценарій “щось пішло не так”.
Здаємо проект без чек-листа. Якщо акт виконаних робіт підписуємо без проходження критеріїв приймання — підписуємо, по суті, “виконавець казав, що готово, я повірив”. Назад тоді вже не відмотати.

Що буде далі

Це перший пост серії про артефакти бізнес-аналізу — документи, які захищають нас на стороні замовника. Кожен наступний розпишу окремо, простими словами:

Брифінг до контракту (discovery brief) — документ, який економить 20K, бо без нього виконавець не може назвати чесну ціну.
Інструкція для команди (user story) — як читати, щоб зрозуміти, за що ми платимо.
Оцінка від IT-компанії — як читати правильно і де у виконавця можуть бути інші інтереси, ніж у нас.
Карта ризиків — як знаходити те, що сховане.
Порівняння постачальників — апельсини проти апельсинів, шаблон таблиці.
Брифінг по AI-фічі — коли AI справді допоможе, а коли — просто модно.

Якщо не хочемо пропустити — стежимо за мною у LinkedIn, там анонсую кожен матеріал.

Якщо в нас зараз на столі контракт без критеріїв приймання — це той момент, де варто поставити паузу. У Ascend Griffin ми робимо Vendor Audit — перевірку до підписання, на нашому боці столу.