Scope creep: причини і наслідки

Чи виникало у Вас коли-небудь таке відчуття, що продукт ніколи не вийде в реліз? Щоразу після зустрічі з представниками замовника з’являється потреба у новій функціональності, а обсяг робіт по існуючому функціоналу росте як на дріжджах. Як наслідок, усі початкові бюджети перевищено, а строки завершення робіт протерміновано. Знайомтесь — перед вами розростання обсягів проекту (в англомовній літературі «scope creep»).

Дослідження Ламрі, проведене більш ніж десять років тому (грудень 2003 — січень 2004), виявило, що 71% проектів перевищують запланований бюджет або потребують перегляду початкового обсягу робіт. У 63% випадків саме scope creep був визнаний основною причиною перегляду бюджетів та термінів виконання проектів. Навіть зараз, через багато років активного розвитку методів управління проектами та обсягом робіт в ІТ, scope creep залишається головним болем. За даними дослідження PMI, 44% завершених у 2015 році проектів страждали від цього явища. При цьому scope creep присутній навіть у проектах із фіксованим бюджетом (так звані fix price), де обсяги робіт та бюджет мали би бути чітко визначеними і зафіксованими наперед.

Часто вважається, що scope creep є проблемою виключно команди розробників, однак він також може викликати неприємності і для замовника продукту. Порушення встановлених дедлайнів, збільшення часу виходу на ринок, зростання бюджетів за проектами може бути шкідливим для всього бізнесу в цілому. Уявіть затримку релізу продукту на декілька місяців на конкурентному ринку, як наприклад, ринок мобільних телефонів. За цей час конкуренти зможуть вкинути на ринок більш ніж достатньо власних пристроїв, і навіть більше — покращити деякі їх характеристики. У той же час ваша компанія буде як і раніше на шляху до випуску свого первістка. Проблема може бути ще гіршою, якщо мова йде про продукти, які купуються один раз на багато років, наприклад, корпоративні інформаційні системи.

А як щодо програмного забезпечення для внутрішнього використання? Чи впливає scope creep на компанії в цьому випадку? Це ще більш очевидно, scope creep може стати причиною провалу проекту розробки програмного забезпечення, і компанія недоотримає прибуток через відсутність бажаного софта.

Чому виникає scope creep?

Scope creep, або розростання обсягів роботи, — це неконтрольовані зміни або безперервне зростання обсягу робіт проекту, що відбувається в основному через наступні причини:

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

— Швидкі зміни в бізнес-середовищі клієнта. Впровадження нових норм регулювання бізнесу клієнта, наприклад, неодмінно призведе до різкого зростання чи зміни вимог у відповідних частинах його програмного забезпечення.

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

— Відсутність документації з чітко визначеним початковим набором вимог. Навіть якщо є певний процес управління змінами, майбутнє побажання клієнта не може бути ідентифіковане як запит на зміну (change request), не порівнюючи його з початковими вимогами, зафіксованими в документації.

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

— Використання модних слів (buzzwords) або термінів без належного пояснення. Одне і те ж слово може мати різні значення в різних предметних областях. Наприклад, слово «кластер» може використовуватися як в хімії чи математиці, так і в музиці, і хоча вони мають подібне значення, використання таких слів без узгодження їхнього значення в рамках проекту призводить до нерозуміння вимог проекту і цілей клієнта.

— Відсутність процесу управління змінами. Кожне бажання клієнта, особливо важливого для компанії-розробника, розглядається як обов’язкова вимога без будь-якого аналізу наслідків та її впливу на загальний графік проекту.

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

— Активний мікроменеджмент зі сторони клієнта. Клієнти іноді ставлять завдання безпосередньо одному розробнику, обговорюючи та змінюючи деталі під час приватних Skype дзвінків без інформування всієї команди. Такі дії можуть принести хаос в процес розробки і сприяти появі scope creep на проекті.

Як зарадити розростанню обсягів робіт на проекті?

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

Не існує єдиного методу боротьби із scope creep, але деякі прості кроки можуть зменшити ризик його появи до прийнятного рівня:

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

— Розумійте бізнес-потреби клієнта. Деякі розширення об’єму робіт можуть бути продиктовані не бізнес-потребами, а бажанням зробити продукт кращим на вигляд, або просто додати «вау» ефект. Тим не менше, ви не зможете відокремити один тип запитів від іншого, не розуміючи реальні потреби клієнта. Переконайтеся в тому, що вся команда розуміє бізнес-цілі, і ряд запитів на зміну зникне. Іноді навіть замовникам необхідно нагадати про цілі проекту для запобігання появи зайвого функціоналу.

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

— Не скупіться на фазу discovery. Discovery ваша потужна зброя проти scope creep, і якщо ви вирішили використовувати її, переконайтеся, що вона потрапить в ціль. Оцініть, скільки бізнес-аналітиків і часу вам буде потрібно, щоб виявити і проаналізувати потреби. Слід пам’ятати, що розробка програмного забезпечення — це командна гра, і недостатньо просто виділити аналітика для проекту; для ефективного discovery ви також повинні з самого початку планувати час і залучення зацікавлених сторін у проекті.

— Документуйте початкові вимоги. Вимоги, отримані від клієнта, або ті, що виявились під час discovery, з якими ви збираєтеся почати проект, повинні бути зафіксовані в документі. Незалежно від того, як називатиметься цей документ і як він буде виглядати (формальна специфікація SRS або просто пріоритизований список завдань), і ви, і замовник повинні погодитися, що це базовий рівень, відповідно до якого буде оцінюватися будь-який майбутній запит.

— Задокументуйте і те, що виходить за рамки проекту (out of scope). Не тільки ті функції, які повинні бути розроблені під час проекту, повинні бути задокументовані, список функцій, які однозначно не повинні бути включеними в проект, такі як інтеграція з інструментами сторонніх розробників, також є хорошою ідеєю. Попередньо визначений список речей, які не будуть реалізовані в ході проекту, може допомогти в класифікації нових запитів як розширення обсягів робіт на проекті.

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

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

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

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

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