Контрольований UAT: як PM-у мінімізувати затримки з боку стейкхолдерів та зберегти нерви

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Знайома картина? Команда вчасно надала інкремент замовнику, готова рухатися далі. Для того, щоб задеплоїти фічі на прод потрібен лише фінальний крок — UAT з боку замовника. І ось тут процес зупиняється.

Найнеприємніше, що формально команда свою частину роботи вже виконала. Розробники чекають на нові задачі, QA не може закрити релізну гілку, наступна поставка залежить від попередньої, а PM опиняється між двох вогнів: з одного боку потрібно дотриматися плану, з іншого — неможливо змусити замовника тестувати швидше.

Працюючи над проєктами в телеком-домені в компанії Telesens IT, я неодноразово стикалася зі зворотнім боком процесу приймання. Щоразу виникало те саме питання: як збалансувати цей процес? Як захистити команду від розмивання рамок проекту, але водночас не стати для клієнта «токсичним проджектом», який лише сухо вимагає апрувів?

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

Що таке user acceptance testing?

Згідно з PMI Glossary, UAT (User Acceptance Testing) — це діяльність, яка перевіряє, чи відповідає продукт бізнес-вимогам.

Простими словами, це етап, який повністю належить замовнику. Саме він визначає, чи готовий продукт виконувати свої бізнес-задачі. І тут є важливий нюанс, про який часто забувають.

UAT це не про пошук технічних багів в стилі «все впало» або «кнопка попливла» (для цього є етапи QA та модульних тестів). Приймальне тестування більше про реальну відповідність логіці бізнесу та виявлення потенційних розходжень ще до міграції на прод.

Формат якісного фідбеку на цьому етапі звучить скоріше як: «Так, в SRS ми погодили такий варант, але зараз маємо більш ефективну логіку. Давайте зафіксуємо цей запит як покращення системи і вирішимо, коли зможемо виконати оновлення».

Хто проводить UAT?

На практиці більшість конфліктів виникає не через дефекти, а через різне бачення того, хто повинен приймати рішення щодо них.

Склад команди, яка перевіряє продукт, завжди варіюється, це залежить від масштабу проєкту, типу контракту, наявності складних інтеграцій (що для телекому класика) тощо.

Проте можна виділити основний кістяк ролей та їхні реальні завдання:

Кінцевий користувач або бізнес-замовник. Головна дійова особа. Його зона відповідальності, власне, провести тестування за сценаріями та зафіксувати результати у протоколі.

Проєктний / Продуктовий менеджер (PM). Ми не тестуємо руками, але керуємо всім життєвим циклом UAT. PM відповідає за те, щоб процес рухався, Scope проєкту не розмивався, а терміни не пробивали дедлайни.

Бізнес-аналітик (BA). Міст між бізнесом та розробкою. Він допомагає розробляти тест-сценарії, консультує замовника, якщо той «заблукав» у реалізації, та валідує знайдені дефекти: це дійсно баг чи просто клієнт захотів щось нове, чого не було у вимогах?

QA-інженер. Саппортить процес: допомагає зі створеннями тест-сценаріїв, а потім перевіряє виправлені розробниками дефекти, перш ніж знову віддати їх клієнту.

Розробник (Developer). Залишається «на зв’язку», щоб оперативно виправляти підтверджені дефекти.

Найкращі практики UAT

Як і будь-який інший етап проєкту, приймальне тестування вимагає детального планування заздалегідь. Щоб не загубити важливі кроки, я рекомендую використовувати чеклісти. В інтернеті є безліч готових шаблонів, можна взяти той, що найбільше підходить під процеси вашої компанії, та адаптувати його.

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

Фаза 1. Підготовка та превентивні інструменти

Готувати ґрунт для UAT потрібно задовго до того, як код потрапить на препрод. Ось кілька превентивних кроків, які рятують таймлайни.

1. Фіксація термінів та «правило мовчазної згоди». Якщо ви працюєте за Fix Price контрактом, чіткі терміни UAT мають бути прописані в договорі. Але навіть в інших моделях закладайте реалістичний період на приймання у загальний план і обов’язково погоджуйте його з клієнтом. Тут критично важливо «на березі» домовитися про правило мовчазної згоди (silent approval): якщо від замовника немає жодного фідбеку протягом, наприклад, 5 робочих днів, фіча автоматично вважається прийнятою, і ми рухаємося далі.
2. Ітеративне приймання замість «великого вибуху». Замість класичного величезного UAT наприкінці проєкту, намагайтеся впроваджувати ітеративну прийомку. Якщо масштаб проєкту дозволяє, закладайте кілька проміжних поставок. Це захистить клієнта від лавини функціоналу в останній момент, яку він фізично не в змозі опрацювати, а вас від заблокованого оточення.
3. Чіткі Acceptance criteria та Punch list. Усі критерії приймання мають бути зафіксовані документально (бодай у листі на ключових стейкхолдерів). Крім того, варто одразу проговорити: зауваження, які не є критичними (Critical severity), не повинні блокувати завершення UAT. Ми заносимо їх у Punch List (список зауважень), фіксуємо в Акті приймання робіт і спокійно виправляємо вже після офіційного закриття фази. Це залізобетонно захищає терміни від розмивання.
4. Актуалізація RACI-матриці. Навіть якщо розподіл ролей є в договорі, часто він або застарів, або занадто High-level. Складіть для внутрішнього використання деталізовану матрицю RACI до рівня конкретних людей і переконайся, що кожен учасник розуміє свою роль.
5. Тест-дані та інфраструктура. Перевірте, що для тестових сценаріїв готові всі необхідні дані, а у команди замовника є активні доступи до потрібної інфраструктури. Здається базовим кроком, але саме на доступах часто втрачаються перші дні UAT.
6. Система фіксації та канали зв’язку. Налаштуйте прозорий простір для трекінгу зауважень. Звичайна Excel-таблиця у спільному доступі (наприклад, у Sharepoint чи Google Sheets) впорається на відмінно. Також одразу додайте в календар регулярні мітинги на весь період тестування. Важливо чітко тримати рамки порядку денного, щоб зустрічі не перетворювалися на хаотичне обговорення «всього підряд». Результатом кожного зідзвону має бути документ із актуальним списком зауважень, розставленими пріоритетами, відповідальними та дедлайнами.

Фаза 2. Виконання та інструменти «в процесі»

Етап безпосереднього тестування вимагає постійного тримання руки на пульсі та відстеження «вузьких місць» на випередження. Коли процес запущено, я використовую такі активності:

• Офіційний старт через Kickoff-мітинг. Не можна просто кинути посилання на препрод у чат і чекати дива. Проведіть коротку стартову зустріч, де підтвердьте готовність усіх учасників, пройдіться по чеклісту та переконайтеся, що всі розуміють правила гри.
• Візуалізація прогресу та затримок на графіку Ганта. Якщо замовник затягує з тестуванням, покажіть йому це наочно. Достатньо раз на тиждень оновлювати графік Ганта. Коли клієнт бачить, як його дводенне мовчання автоматично зсуває фінальний реліз на прод (і накладається на наступну поставку), це протвережує краще за будь-які листи.
• Зміна фокусу пінгів: від контролю до управління ризиками. Замість пасивно-агресивного запитання «Ну що, ви вже протестували?», яке зазвичай викликає лише роздратування та захисну реакцію, переведіть комунікацію на мову ризиків і бізнес-наслідків. Як це працює: Пишіть проактивно. Наприклад: «Стефаніє, ми пройшли вже 60% тест-сценаріїв, для завершення цієї поставки нам потрібен ваш апрув щодо блоку білінгу. Якщо ми не закриємо його до середи, ми не встигнемо виставити реліз на прод у заплановане вікно, і наступна поставка заблокує препрод-середовище. Підкажіть, чи потрібна допомога нашого аналітика, щоб прискорити цей кейс?».
• Пріоритезація та групування в бандли. Замовник може сипати зауваженнями хаотично. Задача PM-а разом із командою групувати виправлення у логічні бандли, визначати чіткі терміни їх поставок на препрод і фіксувати, які саме баги є блокуючими, а які ні.

Фаза 3. Закриття

Коли всі погоджені сценарії перевірено, критичні дефекти виправлено за допомогою hot-fixes, Punch List зафіксовано, а Акт приймання підписано, можна видихнути. Але ненадовго.

Для PM-а фаза UAT вважається остаточно закритою лише тоді, коли всі зауваження з Punch List виправлені, перевірені QA та доставлені на відповідне оточення. Важливо не кидати цей список «на потім», адже невиправлені дрібниці мають тенденцію накопичуватися як снігова куля та вистрілювати в найбільш недоречний момент.

Висновки

Правильно організований UAT це не про везіння з «хорошим» замовником, а про вибудувану систему. Власником процесу приймання завжди є бізнес-замовник, адже саме він вирішує, чи готовий функціонал до промислової експлуатації. Проте команда розробки під керівництвом PM-а має бути не просто пасивним виконавцем, а надійним саппортом, який допомагає клієнту пройти цей етап безболісно.

Якщо виділити три найважливіші речі з усього списку рекомендацій, я б назвала такі:

• Проактивність. Виявлення потенційних блокерів (наприклад, проблем із доступами чи відсутністю тест-даних) ще до початку тестування.
• Чіткий розподіл ролей. Кожен має чітко знати свою зону відповідальності за матрицею RACI.
• Якісна комунікація. Правильно підібрана частота зустрічей, вміння фасилітувати мітинги, щоб фокус не зміщувався на абстрактні теми, та обов’язкова фіксація всіх рішень у вигляді follow-up листів.

Незалежно від того, наскільки складний чи зайнятий у вас замовник, цей підхід можна гнучко адаптувати під реалії вашого проекту. Головне пам’ятати, що UAT це спільна гра на один результат.