Коли Agile працює, а коли ні: Міфи, обмеження та реальна ефективність для бізнесу

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

Типи проєктів

Згідно зі стандартами з управління проєктами, за життєвим циклом розробки продукту розрізняють такі типи проєктів:

Прогнозовані (plan-driven) — проєкти, основні обмеження яких плануються (з певними плановими відхиленнями) на початковому етапі планування та виконуються за циклом PDCA (Plan-Do-Check-Act).

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

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

Своєю чергою, адаптивні проєкти включають у себе два підходи до побудови проєкту:

• Ітераційний — проєкт виконується короткими відрізками, які містять цикл PDCA (Plan-Do-Check-Act). Цей підхід застосовується до проєктів, початкові вимоги яких є слабо деталізованими, і тому в процесі реалізації проєкту ці вимоги уточнюватимуться або змінюватимуться.
• Інкрементальний — продукт створюється та передається Замовнику частинами. Цей підхід передбачає реалізацію вимог Замовника шляхом їх пріоритезації на основі кількох факторів, ключовими серед яких є цінність вимоги та ризик, пов’язаний з її реалізацією.

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

Це сімейство методів призначене для розв’язання таких завдань:

• Якнайшвидше доставити результати проєкту Замовнику (інкременти).
• Постійно вносити корективи у проєкт (ітерації).
• Зменшити час і витрати, що йдуть на планування проєкту.

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

Ознайомтеся з можливостями модуля Project Management & Accounting у Microsoft Dynamics 365 Finance.

Дізнатися більше

Поширені міфи

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

Міф 1. Не потрібно планувати, а потрібно робити.

Цей слоган зустрічається як один із принципів Agile. Звучить красиво, але викликає низку питань: робити що? у якій послідовності? якими ресурсами? з якими витратами? як передавати продукт Замовнику? тощо. На практиці в Agile необхідно застосовувати спрощене планування (порівняно з «водоспадом») через те, що:

а) проєкт виконується короткими ітераціями (спринтами) тривалістю від 2 до 4 тижнів (рекомендовано), і, відповідно, планування такої ітерації не повинно вимагати стільки ж зусиль, як «водоспадний проєкт» тривалістю 3 роки;

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

Міф 2. Будь-який проєкт може виконуватися за методиками Agile.

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

Міф 3. Agile — це «надутий міхур» — пропагований, але непридатний практиці.

Це зворотній бік помилкового уявлення №2 і також «відповідає дійсності». Agile добре застосовний у певних типах проєктів, як модель для реалізації всього проєкту (наприклад, проєкти Change Management, Six Sigma, IT-розробка тощо), і є невіддільною частиною гібридних проєктів, які незабаром стануть переважними, особливо з огляду на розвиток сучасних технологій, зокрема в IT-сфері.

Міф 4. Під час застосування Agile командою не потрібно керувати, бо вона самоорганізована і здатна приймати будь-які рішення самостійно.

Самоорганізація проєктних команд та людських ресурсів загалом дійсно є бажаним елементом успішного досягнення цілей у сучасному управлінні. Але твердження, що: а) команда апріорі є самоорганізованою, б) керувати проєктом не потрібно, в) якщо команда не самоорганізована, то це не Agile, — м’яко кажучи, спірні. Здатність команди самоорганізуватися залежить від її розміру, психології учасників, їхнього досвіду та кваліфікації, стресовості проєкту, значущості проєкту для Замовника, культури управління в організації та інших факторів. Тому на практиці метод управління проєктною командою (директивний або сервісний) має обиратися залежно від реальної ситуації, як при виконанні «адаптивного», так і «прогнозованого» типів проєктів, і взагалі може відрізнятися на різних стадіях.

Міф 5. «Водоспадна модель проєкту застаріла, а Agile — новий підхід до управління».

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

Міф 6. Кріплення та переміщення стікерів на Kanban-дошці — і є Agile.

Красиві та різнокольорові стікери, розділені за статусами, привертають увагу. Багато часу та зусиль присвячується цим «найважливішим» навичкам переміщення стікерів. Деякі люди щиро вважають, що це є найважливішим елементом Agile і управління проєктами загалом. Не хочеться засмучувати цих людей, але: а) Kanban взагалі-то створений не для управління проєктами; б) дошки статусів є всього лише засобом візуалізації і можуть застосовуватися, а можуть і не застосовуватися для відстеження фактичного стану проєкту. Взагалі, існують набагато потужніші інструменти для таких завдань.

Доцільність

Вбудованою сутністю будь-якого проєкту є «трикутне обмеження» (triple constraint). Відповідно, перед початком проєкту із Замовником погоджується одне з обмежень (Зміст/Тривалість/Вартість), якому підлягатимуть усі дії проєктної команди щодо планування та реалізації.
Встановлення двох обмежень значно ускладнює реалізацію проєкту, а трьох – перетворює проєкт на подвиг. Якщо у «водоспадній» моделі (прогнозований тип) ключовим обмеженням є Зміст, тобто те, що має бути виконано для досягнення результату, то в Agile-методах — зазвичай, тривалість. Тобто застосування Agile — це насамперед спроба доставити Замовнику продукт (зазвичай частинами, тобто інкрементально) якнайшвидше.

Таким чином застосовується «обмін» Змісту (і якості) на швидкість доставки. Крім цього загального принципу, при розгляді того чи іншого підходу до реалізації проєкту враховуються такі фактори:

• Ступінь пов’язаності функцій продукту між собою — наскільки та чи інша функція продукту може застосовуватися без застосування інших функцій.
• Ступінь деталізації (якості) технічного завдання на проєкт — низька деталізація несе ризик змін Змісту в процесі реалізації проєкту, що відразу призводить до необхідності застосування ітерацій під час створення кінцевого результату, а також до обмеження тривалості цих ітерацій.
• У разі, якщо проєкт виконується в рамках контракту, який тип контракту застосовується — контракт із фіксованою ціною, наприклад, передбачає, що технічне завдання деталізоване, і ризик змін у Змісті невеликий, але в такому випадку ітераційний підхід втрачає сенс.
• Який розмір команди проєкту — що більша команда, то складніше нею керувати, і виникає потреба в декомпозиції на менші групи, що ускладнює роботу з великою кількістю коротких ітерацій.
• Рівень якості кінцевого результату — що вищі вимоги до продукту і що критичніший він для Замовника, то важливіше обмеження за Змістом і тим небажаніші будь-які зміни до нього.

Рекомендації та обмеження щодо використання того чи іншого підходу:

Ідеальні умови для Agile-проєктів:

• Невизначений обсяг робіт (Зміст), тобто очікується велика кількість змін.
• Необхідність постачання кінцевого результату проєкту Замовнику у мінімальні терміни.
• Можливість постачання кінцевого результату проєкту Замовнику частинами.
• Проєкт виконується для внутрішніх потреб організації (контракт відсутній).
• Проєкт виконується для зовнішнього Замовника за контрактом типу «Оплата за фактом постачання» (Time & Materials).
• Кількість людей у проєктній групі – до 6 осіб.

Умови для Waterfall-проєктів:

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

У разі, якщо проєкт і його умови «пограничні», тобто присутні передумови і для першої, і для другої групи, такий проєкт може виконуватися за Гібридним типом:

• Визначені фази проєкту — за Agile, інші — за Waterfall.
• Частина функцій продукту — за Waterfall, частина — за Agile.

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

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

Оптимізуйте ваш бізнес за допомогою функціональності Project Management & Accounting у Microsoft Dynamics 365 Finance.

Дізнатися більше

Влад Березін

Business Development Manager, SMART business

20+ років у сфері управління бізнесом, проєктами та продажами. Президент Project Management Institute (PMI), Kyiv Chapter з 2007 до 2012 року. Практичний досвід реалізації проєктів із планування корпоративних ресурсів (ERP), людських ресурсів (HR), маркетингу, організацій, EPM, PPM, BPMS та бізнес-процесів (BP).