Ефективне управління змінами є одним із ключових завдань у проєктах з розробки програмного забезпечення, оскільки воно дозволяє уникнути неконтрольованого розширення обсягів проєкту (scope creep), а відтак — його можливого зриву.
Вимоги змінюватимуться і розростатимуться протягом усього життєвого циклу будь-якого проєкту з розробки програмного забезпечення. Команда розробників має це передбачати і планувати потенційне розширення списку вимог, зокрема шляхом закладання проєктних резервів на випадок непередбачених обставин під час взяття зобов’язань.
Втім, термін «неконтрольоване розширення обсягів проєкту» (також відомий як scope creep, feature creep або requirements creep) означає неконтрольоване розростання елементів функціоналу, які команда намагається втиснути в уже й без того переповнену «коробку» проєкту. Все просто не поміститься. Постійне зростання кількості вимог ускладнює своєчасну реалізацію пріоритетного функціоналу, призводить до затримок, проблем із якістю та неефективного використання ресурсів.
Всім хотілося б, аби зміни були «безкоштовними». «Хіба ти не можеш додати ще однісіньку вимогу – і все одно встигнути до четверга. В чому проблема?» На жаль, це так не працює. Зміни ніколи не бувають безкоштовними. Намагання втиснути додаткову вимогу в план роботи команди, яка працює за фіксованим графіком і з обмеженими ресурсами, — нереалістичне. Найімовірніше, доведеться пожертвувати чимось і цим «чимось» буде якість.
Набагато ефективнішим буде впровадити процеси, що дозволятимуть адаптуватися до змін і розширення списку вимог із мінімальними втратами. Протидія неконтрольованому розширенню обсягу проєкту (scope creep) – це про вміння керувати планами й очікуваннями задля досягнення найкращого результату проєкту.
Визначаємо обсяг проєкту
Першим кроком до ефективного контролю над неконтрольованим розширенням обсягу проєкту (scope creep) є документування чітко сформульованого та узгодженого обсягу робіт. Без визначеного обсягу ви навіть не зможете усвідомити, що саме виходить за його межі. Спробуйте скористатися цими методами для визначення обсягу вашого проєкту.
У Agile-проєктах доцільно створювати короткий опис обсягу для кожної ітерації – це допоможе переконатися, що всі розуміють, що саме буде реалізовано, а що – ні. Також можна надавати кожній ітерації лаконічну назву, що відображає її основну мету та робить зміст ітерації більш чітким та зрозумілим.
До теми: Як управляти та обмінюватися вимогами, і повторно використувати їх
Під час обговорення вимог зазвичай увага зосереджена на тому, які елементи функціональності включити до рішення. Водночас зацікавлені сторони (stakeholders) повинні також домовитися про те, що не буде включено. Рекомендую використовувати шаблон документа Vision and Scope (Бачення й обсяг проєкту), який містить розділ під назвою Обмеження та виключення (Limitations and Exclusions) . У цьому розділі можна перелічити ті функції, на які зацікавлені сторони можуть очікувати, але які на цьому етапі не плануються до реалізації.
Визначаємо, що саме належить до обсягу проєкту
Другим кроком у боротьбі з неконтрольованим розширенням обсягу проєкту (scope creep) є просте запитання: «Чи входить це до обсягу проєкту?» щоразу, коли хтось пропонує новий випадок використання, історію користувача, функціональну вимогу, елемент функціоналу чи очікує на додатковий результат. Встановлення обмежень заздалегідь допоможе команді швидко ухвалювати рішення, якщо надходить запит на функціонал поза межами обсягу проєкту.
Варто пам’ятати, що обсяг проєкту може охоплювати не лише програмні продукти, а й супутні активності та артефакти. Наприклад, клієнт може замовити розробку онлайн-курсу для навчання користувачів роботі з новою системою. Такий запит не змінює саме програмне рішення, але розширює загальний обсяг робіт, які необхідно виконати.
Обсяг робіт має бути визначеним чітко настільки, щоби члени команди могли впевнено відповісти на запитання: «Чи входить це до обсягу робіт?»
В одному з проєктів замовник уклав договір із постачальником готового рішення на перенесення трьох наборів історичних даних до нової системи. На півдорозі клієнт дійшов висновку, що потрібні ще шість додаткових конверсій даних. Замовник був переконаний, що це входить до погодженого обсягу, тоді як постачальник наполягав, що ці роботи виходять за межі проєкту та потребують додаткової оплати.
Буде цікаво: ВІГЕРСОПЕДІЯ – Комунікація вимог: від голоса замовника до вуха розробника
Невизначеність щодо обсягу робіт стала однією з причин скасування проєкту та судового позову на мільйони доларів.
Чітке попереднє визначення обсягу робіт, а також чітка домовленість про те, як і ким покриватимуться витрати на зміни, могли б запобігти цьому негативному сценарію.
Адаптуємо обсяг проєкту
Існує три можливі відповіді на питання «Чи входить це до обсягу робіт?». Якщо новий елемент функціоналу точно входить до меж обсягу робіт, команді слід включити його до плану розробки. Якщо новий елемент функціоналу знаходиться поза межами обсягу робіт, команді не потрібно включати його до плану розробки принаймні найближчим часом. Вона може запланувати цей елемент в більш пізньому періоді.
Іноді новий елемент функціоналу знаходиться поза межами обсягу робіт, що вже був попередньо визначений, але є настільки гарним та доцільним, що заради нього план робіт можна змінити. В такому випадку власник бізнесових вимог – спонсор управлінського рівня – повинен вирішити, чи зміни, запропоновані на рівні користувача чи рішення будуть включені до завдань команди шляхом розширення обсягу робіт (Рисунок 1).
Рисунок 1. Зміни користувацьких вимог та вимог рішень вимагають обговорень щодо змін обсягів проєкту та всіх можливих наслідків таких рішень на рівні бізнес-вимог.
Зверніть увагу: ВІГЕРСОПЕДІЯ – Виявлення невидимих вимог
Прийняття рішення про розширення обсягу проєкту – це бізнес-рішення. Ключові особи, що ухвалюють рішення, повинні врахувати вартість, ризики, графік виконання та вплив на ринок. Це вимагає участі керівника проєкту (проєктного менеджера), бізнес спонсора та ключових замовників у процесі узгодження, щоб визначити, як найкраще впоратися із запропонованими змінами щодо обсягу робіт.
У Agile-проєкті, як тільки для ітерації визначено обсяг робіт шляхом розподілу певного набору історій користувачів відповідно до їх пріоритетності, він більше не змінюється. Agile-команди залишаються відкритими до нових вимог та змін до існуючих, але це не означає, що нові завдання просто додаються в поточну ітерацію – вона вже сформована.
Натомість нові вимоги додаються до продуктової черги (product backlog) та пріоритизуються відносно вже наявних історій користувачів та реалізуються в наступних ітераціях.
Стратегія боротьби з неконтрольованим збільшенням обсягу проєкту
Ось декілька можливих стратегій, які допоможуть впоратися із зростанням вимог і запитами на зміни, щоб уникнути руйнівного впливу неконтрольованого розширення обсягу (scope creep):
- Відкласти або відмовитись від реалізації деяких менш пріоритетних елементів функціоналу, запланованих для поточного випуску (релізу).
- Залучити додаткових розробників, щоб опрацювати збільшений обсяг робіт.
- Отримати додаткове фінансування — можливо, для оплати понаднормової роботи (гаразд-гаразд, це жарт, але в кожному жарті є частка правди), аутсорсингу окремих завдань або придбання інструментів для підвищення продуктивності.
- Подовжити графік поточного випуску (релізу), щоб встигнути реалізувати додатковий функціонал.
- Пожертвувати якістю, виконавши роботу поспіхом, що призведе до технічного боргу, який доведеться «погашати» в майбутньому (не найкращий варіант, відверто кажучи).
Будь-яке розширення обсягу робіт має свою ціну. Особи, які фінансують або замовляють проєкт, мають усвідомлено обирати стратегію управління обсягом, що є найбільш доречною у кожній конкретній ситуації.
Головна мета – це забезпечити максимальну цінність для замовника, узгоджену з бізнес-цілями та критеріями успішності проєкту, в рамках наявних обмежень.
Не слід вдавати, що команда розробки здатна реалізовувати постійно зростаючу кількість елементів функціоналу без жодних наслідків. Набагато розумніше – ще на старті проєкту передбачити певне зростання обсягу. Досвідчений проєктний менеджер закладе певні резерви в план робіт, що дозволить команді гнучко реагувати на обґрунтовані зміни, не порушуючи графік та зобов’язання.
Зважене управління обсягом потребує кількох умов:
- Вимоги повинні бути пріоритизовані, щоби особи, які ухвалюють рішення, могли обрати функціонал для наступного релізу або ітерації та оцінити нові запити відповідно до встановлених пріоритетів.
- Обсяг кожної вимоги необхідно оцінити, щоби команда мала уявлення про приблизні зусилля, потрібні для її реалізації.
- Команда має знати свій середній рівень продуктивності (velocity – у термінах Agile), щоби мати змогу спрогнозувати, скільки вимог реально можна реалізувати й протестувати за одиницю часу.
- Кожен запит на зміну слід проаналізувати на предмет впливу (impact analysis) – щоби розуміти його вартість, ризики, вплив на графік і потенційні компроміси.
- Необхідно чітко визначити, хто приймає рішення у проєкті, та як саме це відбувається, щоб зміни обсягу затверджувались швидко, ефективно і тоді, коли це справді необхідно.
Не дозволяйте «привиду» неконтрольованого розростання обсягів проєкту себе «переслідувати», водночас не намагайтесь марно придушити зміни.
Також цікаво: Топ-10 порад для збору вимог
Натомість визначте чіткі межі обсягу робіт ще на початку проєкту і впевніться, що зацікавлені сторони розуміють, чому усі запити на зміни мають проходити через узгоджений (і ефективний!) процес контролю змін.
Контроль змін – це не перешкода, а механізм, що дозволяє правильним людям приймати правильні рішення у правильний момент. Сповіщайте всі зацікавлені сторони про затверджені зміни, а також про те, як це впливає на їх зону відповідальності.
Зміни трапляються. Тож будьте готовими до них 🙂
Оригінальна стаття – Control Scope Creep Before It Controls You від Карла Вігерса, переклад – Катерина Манойло, ревью – Іван Вільчавський. Оригінальне фото з статті.