nmk

Лекція №4 (4 години). Управління вимогами та обсягом робіт (Scope Management)

План лекції

Життєвий цикл вимог в IT-проєкті. Класифікація вимог.
Роль бізнес-аналітика (Business Analyst) у проєкті.
Техніки та методи виявлення (збору) вимог.
Формати документування: класична специфікація (SRS) vs Agile-підхід (User Stories).
Визначення обсягу проєкту (Scope Management) та межі проєкту.
Техніка декомпозиції: створення Ієрархічної структури робіт (WBS).
Що таке Scope Creep (розповзання меж) і як PM має захищати проєкт від нього.

Перелік умовних скорочень

BA (Business Analyst) — бізнес-аналітик;
SRS (Software Requirements Specification) — специфікація вимог до програмного забезпечення;
WBS (Work Breakdown Structure) — ієрархічна структура робіт;
MVP (Minimum Viable Product) — мінімально життєздатний продукт;
Scope Creep — розповзання меж (неконтрольоване збільшення обсягу) проєкту;
SME (Subject Matter Expert) — експерт у предметній галузі.

Вступ

Згідно з дослідженнями Standish Group (знаменитий CHAOS Report), понад 40% усіх провалів в IT-проєктах стаються через одну ключову проблему: неправильні, неповні документативно або постійно мінливі вимоги.

Можна найняти найкращих у світі Senior-розробників, ідеально налаштувати CI/CD пайплайни, але якщо команда розроблятиме не те, що насправді потрібно бізнесу замовника, проєкт буде провальним. Управління обсягом (Scope Management) — це мистецтво чітко окреслити периметр: де починається наша робота, і, що ще важливіше, де вона закінчується. У цій лекції ми розберемо, як витягнути з клієнта розуміння того, чого він хоче, як це задокументувати та як захистити розробників від нескінченного потоку нових “крутих ідей” замовника посеред спринту.

1. Класифікація вимог в IT-проєкті

Вимога (Requirement) — це умова або характеристика, якій повинна відповідати система, щоб задовольнити контракт, стандарт або очікування замовника.

В IT заведено ділити вимоги на декілька рівнів (від загального до технічного):

Бізнес-вимоги (Business Requirements):
- Відповідають на запитання: “ЧОМУ ми взагалі це робимо? Яку фінансову/бізнес ціль переслідуємо?”
- Приклад: “Збільшити продажі онлайн на 20% до кінця року шляхом впровадження мобільного застосунку”.
- Вони не говорять про кнопки і бази даних. Вони говорять про гроші та частку ринку.
Вимоги користувача (User Requirements):
- Що конкретні користувачі повинні вміти робити в системі для досягнення бізнес-вимог.
- Приклад: “Покупець повинен мати можливість відфільтрувати товари за ціною та брендом”.
Системні вимоги (System Requirements): Діляться на дві великі підгрупи:
- а) Функціональні (Functional Requirements - “ЩО система робить”):
  - Описують поведінку системи. Якщо ми натискаємо Х, має відбутися Y.
  - Приклад: “Система повинна відправити email-підтвердження з унікальним штрих-кодом одразу після успішної оплати замовлення”.
- б) Нефункціональні (Non-functional Requirements - “ЯК система працює”):
  - Описують атрибути якості: продуктивність, безпеку, надійність, зручність (UI/UX). Вони часто є найдорожчими в реалізації.
  - Приклад: “Сторінка каталогу повинна завантажуватися не довше ніж 2 секунди при одночасному підключенні 10 000 користувачів”.
  - Примітка: Якщо PM забуде зібрати нефункціональні вимоги, сайт може ідеально працювати на комп’ютері розробника, але “впаде” в перший день рекламної кампанії через навантаження.

2. Роль бізнес-аналітика (Business Analyst)

Щоб перетворити хаотичні ідеї стейкхолдерів (“хочу програму як Uber, але для доставки піци дронами”) на структурований технічний план, потрібен “перекладач”. Ним є Бізнес-аналітик (BA).

Специфіка професії: BA стоїть між бізнес-замовником (який не розуміє термінів API, JSON чи Docker) і командою розробки (яка не хоче слухати про маркетингові стратегії, а хоче знати, скільки символів має бути в полі “Пароль”).
Відповідальність BA:
1. Виявлення справжньої проблеми. (Клієнт каже: “Мені потрібен новий сайт”. BA з’ясовує: “Старий сайт повільний, і ви втрачаєте молодь. Можливо, вам потрібен не просто сайт, а мобільний застосунок?”).
2. Фасилітація зустрічей між розробниками та SME (Subject Matter Experts — експертами, наприклад, головним бухгалтером компанії клієнта).
3. Написання документації (SRS, User Stories, Acceptance Criteria).
4. Створення Wireframes (схематичних малюнків інтерфейсу) до того, як за роботу візьмуться UI/UX дизайнери.

Різниця між PM та BA: PM керує бюджетом, членами команди та строками. BA відповідає виключно за контент (те, ВИМОГИ до якої системи ми збираємо). У невеликих компаніях ці ролі часто поєднує одна людина.

3. Техніки та методи збору (виявлення) вимог

Як дістати з голови клієнта інформацію? BA та PM використовують різні техніки:

Інтерв’ювання: Класична розмова 1-на-1 із ключовими стейкхолдерами. Дозволяє глибоко розібратися в специфіці, але займає багато часу організатора.
Анкетування/Опитування: Якщо є 500 співробітників відділу продажів, легше розіслати їм Google Форму з питанням: “Якої функції вам найбільше не вистачає в поточній CRM?”.
Аналіз документів (Document Analysis): Вивчення тих бланків, звітів і паперів, які клієнт використовує ЗАРАЗ. Якщо ми автоматизуємо документообіг податкової, ми маємо зібрати всі існуючі паперові форми.
Спостереження (Shadowing): Аналітик сідає поруч із працівником клієнта (наприклад, оператором колл-центру) на цілий робочий день і мовчки дивиться, куди той клікає, з якими програмами працює і де втрачає час. Ідеально виявляє непомітні рутинні проблеми.
Прототипування (Prototyping): Створення клікабельного макета (наприклад, у Figma). Клієнти жахливо читають тексти ТЗ, але коли їм даєш у руки візуальний прототип (“клікніть сюди”), вони миттєво згадують: “Ой, а ми ж ще забули додати знижку для пенсіонерів!”.

4. Документування: SRS vs. User Stories

Класичний підхід (Waterfall) — SRS

Software Requirements Specification (SRS) — це товстий документ, який містить вичерпний опис усієї системи до початку її створення.

Написаний строгою, сухою мовою (“Система повинна…”, “Користувач зобов’язаний…”).
Містить діаграми використання (Use Case diagrams), ER-діаграми баз даних.
Проблема: Ніхто, крім аналітика і архітектора, його повністю не читає. Доки він пишеться, ринок може змінитися.

Гнучкий підхід (Agile) — User Stories

Замість товстого ТЗ команда створює короткі “Історії користувача”. Вони пишуться на картках (на дошці в Jira) і не є технічним завданням — це лише запрошення до розмови між програмістом і клієнтом.

Шаблон User Story: ЯК [тип користувача], Я ХОЧУ ПОМАТИ МОЖЛИВІСТЬ [виконати дію], ЩОБ [отримати бізнес-цінність/користь].

Приклад:

Як зареєстрований клієнт магазину, я хочу мати можливість зберігати свою банківську картку у профілі, щоб економити час при наступних покупках.

До кожної User Story обов’язково пишуться AC (Acceptance Criteria - Критерії приймання) — чек-лист, за яким QA-інженер перевіряє, чи фіча готова. Наприклад:

“Картка зберігається лише у зашифрованому вигляді”.
“Якщо строк дії картки вийшов, система підсвічує її червоним”.

5. Управління обсягом проєкту (Project Scope)

Project Scope (Обсяг проєкту) — це робота (і ТІЛЬКИ та робота), яку необхідно виконати для створення продукту із заданими вимогами.

Одне з головних завдань PM-а на старті — визначити Scope Exclusions (Межі проєкту / Out of Scope). Це список у контракті або статуті, де чітко написано, що ми НЕ РОБИМО.

Приклад для розробки інтернет-магазину (Out of Scope):

Ми не робимо мобільні застосунки для iOS/Android (лише адаптивний веб).
Ми не наповнюємо каталог товарами (всі 10 000 позицій фотографує і додає сам клієнт).
Ми не інтегруємо сайт із 1С бухгалтерією (вивантаження йде в Excel). Це захищає IT-компанію від того, що через пів року клієнт скаже: “А чому у вас немає програми в AppStore? Це ж логічно, що інтернет-магазин має бути в AppStore, я думав це включено у вартість!”

6. Ієрархічна структура робіт (WBS)

Коли вимоги зібрані й межі визначені, проєкт (як великого слона) треба нарізати на шматочки, щоб його можна було оцінити. Для цього створюють WBS (Work Breakdown Structure).

WBS — це орієнтована на результати ієрархічна декомпозиція всього обсягу робіт. Звучить складно, але візуально це нагадує перевернуте дерево (або генеалогічне дерево).

Правила побудови WBS:

Правило 100%: Верхній рівень дерева — це 100% проєкту. Сума всіх “гілок” (Work Packages) нижнього рівня повинна дорівнювати 100% роботи. Якщо ви чогось не намалювали у WBS — цього не існує в проєкті і бюджет на це не виділяється.
Орієнтація на результат, а не дію: WBS складається з іменників (що ми створили), а не з дієслів. (Не “Малювати дизайн”, а “Макет головної сторінки”).
Глибина декомпозиції: Дробити потрібно доти, доки елемент нижнього рівня (Work Package) не можна буде легко оцінити в годинах (зазвичай він має тривати від 8 до 80 годин роботи одного фахівця). Далі дробити не має сенсу — це мікроменеджмент.

WBS стає основою для побудови розкладу (діаграми Ганта), призначення ресурсів та складання бюджету (тому що легше оцінити 100 маленьких задач по 8 годин, ніж одну задачу “зробити систему” на 3 місяці).

7. Scope Creep: розповзання меж і як з цим боротися

Scope Creep — це найстрашніший жах менеджера традиційних проєктів. Це поступове, непомітне додавання нових фіч або вимог до проєкту без відповідного збільшення бюджету чи часу.

Як це зазвичай відбувається: Замовник приїжджає в офіс розробників з піцою. Програміст Вася п’є з ним каву. Клієнт: “Слухай, Вась, а ви можете ще кнопочку зробити, щоб зразу в Інстаграм постило товар? Це ж вам п’ять хвилин роботи”. Вася: “Та без проблем”. Потім Вася робить кнопку. Вона конфліктує з базою даних. Сервер “падає” на вихідних. DevOps-інженер витрачає 20 годин на відновлення системи, проєкт зриває дедлайн релізу. А бюджет компанії зменшується на зарплату фахівців. Сумно те, що ця фіча насправді була клієнту не дуже й потрібна.

Причини Scope Creep:

Відсутність чітко задокументованих вимог (клієнт впевнений, що “це само собою мало бути”).
Пряма робота розробників із замовником в обхід менеджера (як у прикладі з Васею).
Синдром “золотого покриття” (Gold Plating), коли самі розробники додають непотрібні “круті” фічі, про які клієнт навіть не просив, тільки щоб показати свої навички.

Як PM має захищати проєкт (Процес контролю змін):

Створити та підписати процедуру змін (Change Request Process).
Якщо клієнт хоче нову “просту” фічу, PM каже: “Чудова ідея! Оформіть її у форму Change Request. Ми візьмемо 3 дні на аналіз впливу цієї фічі на архітектуру”.
Через 3 дні PM повертається: “Ця кнопка для Інстаграму впливає на 3 модулі. Це додасть 42 години роботи розробників та 10 годин QA. Сумарно це буде коштувати вам +$2500 і відсуне дату релізу на тиждень. Ви підписуєте інвойс?”
У 90% випадків клієнт каже: “Ого, ні, давайте обійдемось без Інстаграму”. Scope Creep подолано. Проєкт врятовано.

Висновки

Управління вимогами починається зі з’ясування справжньої бізнес-потреби замовника. Без цього будь-яка грандіозна архітектура є марною.
Бізнес-аналітик (BA) відіграє критичну роль “мосту” між бізнесом (замовником) і технологіями (розробниками).
Збір вимог включає інтерв’ю, спостереження, опитування та прототипування інтерфейсів.
Традиційні проєкти використовують важку документацію (SRS), а гнучкі підходи (Agile) — орієнтовані на користувача формати: User Stories + Acceptance Criteria.
PM зобов’язаний чітко прописувати “Out of Scope” (те, що розроблятися не буде), щоб уникнути непорозумінь.
WBS допомагає структурувати хаос великого проєкту, розбиваючи його на дрібні, керовані пакети робіт.
Scope Creep — головний ворог бюджету. Боротися з ним можна лише через формальний процес контролю змін (Change Request) і заборону неформальних домовленостей між девами та клієнтами.

Джерела

Вігерс, К., Бітті, Д. (2013). Розробка вимог до програмного забезпечення (Software Requirements). Класика для бізнес-аналітиків.
Інститут управління проєктами (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Розділ: Scope Management.
User Stories Applied: For Agile Software Development - Mike Cohn.
The Standish Group. CHAOS Report (дослідження причин провалів проєктів).

Запитання для самоперевірки

Чим нефункціональні вимоги небезпечніші для архітектури системи, ніж функціональні? Наведіть приклад.
Опишіть ситуацію, в якій метод збору вимог “Спостереження (Shadowing)” буде набагато ефективнішим, ніж проведення “Інтерв’ю”.
Як звучить шаблон написання класичної User Story? Яку роль у ній відіграють Acceptance Criteria?
Що означає “Правило 100%” при побудові WBS (Ієрархічної структури робіт)?
Яким чином чітко прописаний розділ “Out of Scope” допомагає менеджеру керувати очікуваннями клієнта?
Ви — Project Manager. Під час дзвінка з розробниками клієнт просить програмістів: “А давайте сьогодні ще швиденько змінимо логіку сортування каталогу”. Ваші дії для уникнення Scope Creep?