Провалений ІТ-проект. Чому змінюються вимоги?

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

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

Волатильність (Volatility) була визнана однією з причин провалу ІТ -проектів. Волатильність стосується різних аспектів проекту: використовуваних технологій, стосунків з постачальниками, ресурсів та вимог бізнесу. Я пережив дві історії, які спричинили нестабільність проекту з майже провальними наслідками. В одному випадку ключовий постачальник відмовився від контрактної угоди з проектом на півдорозі. Це створило “дірку” у закупівлях технологій, яку важко було швидко замінити. Наслідком цього стало припинення проекту та судовий позов проти постачальника. В іншому випадку, понад вісімдесят відсотків виконавців проекту подали у відставку на знак протесту проти стилю управління та прийнятого рішення. Це призвело до втрати кваліфікованих релевантних виконавців із знанням продукту. Схожі події окремо або в поєднанні можуть мати шкідливі наслідки для проектів. Однак, як бізнес-аналітиків, нас більше турбує певний тип мінливості: Волатильність вимог.

Часті та непередбачувані зміни вимог призводять до волатильності вимог. Волатильність вимог зберігається незалежно від методології розробки програмного забезпечення (Agile, Waterfall, JAD тощо) або наявного процесу управління вимогами. Жодна з методологій чи процесів не гарантує відсутності нестабільності.

“Змінність вимог” емпірично визначається як часті зміни вимог від етапу проектування до впровадження. Усі методології розробки програмного забезпечення передбачають, що коли вимоги переходять до фази проектування, вони є «завершеними» і не підлягають змінам. Однак це не завжди так. Протягом життєвого циклу розвитку завжди існує певний рівень невизначеності та непередбачуваності. Незважаючи на те, що Agile «вітає зміни» і стверджує, що «спільний та адаптивний» підхід сприяє роботі з непередбачуваним змінам, це припущення буде доволі спірним, коли частота змін буде високою. Нестабільність вимог створює значний ризик для результатів проекту. Однак розділ «Управління вимогами» у  BABOK не включає опис заходів з управління волатильністю.

Слід підкреслити, що волатильність вимог – це не «зміна обсягів проекту» (scope change). Це дві різні речі.

1. Волатильність вимог: Тут обсяг залишається статичним, тоді як вимоги є динамічними. Це зміна на мікрорівні, яка врешті-решт впливає на наступні фази проектування та розробки рішення.
2. Зміна обсягів проекту (scope change): Зміна обсягів проекту проявляються через “я хочу більше”. Це зміна на макрорівні, яка впливає на все наскрізне рішення. Це перевизначення початкового узгодженого результату.

Зміна обсягів проекту може призвести до волатильності вимог, але не завжди.

Причини волатильності вимог

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

1. Зміни в потребах зацікавлених сторін
2. Зовнішні фактори
3. Внутрішні фактори
4. Величина зміни
5. Процес аналізу вимог
6. Організаційна культура

Волатильність вимог може мати значний вплив на розробку рішення. Це погіршується, коли ступінь змін висока. Деяким випадкам волатильності можна запобігти; проте, існують лише невеликі інструменти контролю над певними причинами волатильності. Наприклад, зовнішні зміни, такі як державне регулювання, неможливо контролювати.

Зміни в потребах зацікавлених сторін

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

Зовнішні фактори

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

Внутрішні фактори

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

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

Величина зміни

Складність проекту прямо пропорційна величині змін. Великі та складні трансформації бізнесу, як правило, вразливі до волатильності. Це пов’язано з обробкою великої кількістю інформації та значним ризиком невідомої та квантової зміни, яку необхідно реалізувати. На додаток до всього, може бути й часове обмеження.

Процес аналізу вимог

Це етап, коли волатильність може бути мінімізована. Усіх, хо впливає на процес можна класифікувати згідно чотирьох ознак:

1. Зрілість процесу
2. Аналіз вимог
3. Досвід бізнес-аналітика
4. Культура організації

Зрілість процесу

Це означає рівень зрілості процесу. Різні організації мають різний рівень зрілості у процесі виконання своїх проектів. Модель зрілості реалізації програмного забезпечення визначає п’ять рівнів зрілості процесу.

Зрілість процесу	Визначення
Рівень 1 — Початковий (Хаотичний)	На початковому рівні процеси дезорганізовані, навіть «хаотичні».
Рівень 2 — Повторюваний	На цьому рівні чіткість процесу ще недостатня, але там, де вона вже існує – вона може допомогти забезпечити підтримку процесності у часи стресу
Рівень 3 — Визначений	Стандартні процеси існують і використовуються для встановлення послідовності виконання процесів у всій організації.
Рівень 4 — Керований	Процес налагоджений. Є можливість регулювати та адаптувати із мінімальним впливом на рівень якості
Рівень 5 — Оптимізований	Характерною рисою процесів на цьому рівні є те, що основна увага приділяється постійному поліпшенню продуктивності процесу шляхом поступових та інноваційних технологічних змін/удосконалень.

Простіше кажучи, чим менш зрілий процес, тим більша можливість змін. Менш жорсткі процеси призводять до більш високих випадків змін.

Процес аналізу вимог

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

Спрощене визначення аналізу вимог може полягати в перетворенні невідомої сутності на відому.

• Що таке невідомі сутності?

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

• Перетворення невідомого у відоме

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

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

Досвід бізнес-аналітика

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

Культура організації

Кожна організація має власний набір цінностей, правил та практик, які сприяють культурі цієї організації. Культура може впливати на процес аналізу вимог як прямо, так і опосередковано. Ставлення до управління вимогами може бути відображенням культури організації. З власного досвіду, «маленькі організації» схильні повідомляти вимоги та очікувати змін незалежно від фази проектів. Вплив організаційної культури на виконання проектів та управління вимогами є складною та нерозкритою сферою дослідження.

Висновок

Серед варіантів стратегії реалізації проекту методологія Agile є найбільш підходящою за умови частої зміни вимог. Однак це не означає, що зміна вимог не впливає на бюджет та графік проекту в Agile. Гнучкість не означає відсутності волатильності. Процеси можуть стати хаотичними, незалежно від того, чи це методологія виконання ‘Agile’, ‘Waterfall’, ‘JAD’ чи інша. Значення має досвід команди та досвід бізнес-аналітика.

Ніхто не любить непередбачуваності! Це ризиковано і впливає на вартість проекту. Вимоги є основою для розробки рішення. Вони є базовими для оцінки витрат та графіків; таким чином, вони є «джерелом входу» для наступних фаз оцінки, проектування, розробки та тестування.

Автор: Adam Alami, PhD Fellow, IT University of Copenhagen