Яка методологія управління проектом є правильною

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

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

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

Не кожен випадок так просто завершити. Давайте подивимося, як краще оцінити, яка методологія краща для вашого проекту.

Як виглядає водоспад?

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

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

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

Оцініть усе та підтвердьте очікуваний бюджет.

Розробити рішення. Проведіть кілька зустрічей із зацікавленими сторонами. Створюйте різні документи та дозволяйте зацікавленим сторонам переглядати їх. Підтвердити та затвердити остаточний функціонально-технічний проект.

Впровадити рішення на основі дизайну. Тут ви розробляєте повний кінцевий продукт.

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

Розгорніть рішення у виробничому середовищі. Саме тут цільові користувачі починають використовувати кінцевий і завершений продукт.

Заплануйте етап підтримки, під час якого команда розробників виправляє потенційні помилки рішення.

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

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

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

Як виглядає Agile?

Тепер ось як проект може працювати в налаштуваннях Agile:

Визначте бізнес-бачення кінцевого продукту. Приблизно, але з чіткими бізнес-вимогами та очікуваннями щодо того, що продукт має виконувати для користувачів.

Створіть список функціональних епох і технічних засобів, які охоплюють бачення.

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

Створіть scrum-команду та заплануйте спринти в межах періоду часу. Розбийте епопеї на особливості та історії разом із командою. Оцініть історії та сплануйте їх для майбутніх спринтів на основі пріоритету функцій та історій.

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

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

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

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

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

Agile проти Waterfall

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

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

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

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

Резюме підходу Agile проти Waterfall.

FeatureWaterfall ApproachAgile ApproachHandling Вимоги користувача. Зміна розглядається як формальний процес (запит на зміну). Роботу може знадобитися переробити, що вплине на витрати та терміни. Охоплює зміни як частину стандартного процесу, без суттєвого впливу на витрати чи терміни. Планування та масштаб проекту. Визначає масштаб на початку та дотримується його. Фази є жорсткими та дотримуються початкового плану. Має чітке бачення кінцевого продукту, але допускає зміни. Робота організована за спринтами з можливістю гнучкого виконання завдань. Відстеження прогресу проекту Відстежує прогрес на кожному етапі. Затримки на одній фазі можуть вплинути на весь проект. Відстежує прогрес за допомогою демонстраційних сеансів наприкінці кожного спринту. Зосереджено на працездатному продукті. Командна співпраця. Різні люди на різних етапах проекту, обмежена взаємодія. Міжфункціональна команда з постійним спілкуванням між членами команди та зацікавленими сторонами. Управління ризиками. Відстеження статусу на основі прогресу фази. Реагує на ризики ретроспективно, дотримуючись плану. Зосереджується на випереджальному вирішенні залежностей між командами та видами діяльності. Адаптація плану для усунення прогнозованих ризиків. Структура впровадження. Традиційна методологія. Вимагає практик трансформації для адаптації до гнучкого підходу. Передбачає зміну звичок і мислення.

Цей вибір, однак, визначатиме кілька аспектів властивостей виконання проекту.

#1. Вимоги до проекту та управління змінами

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

У проекті водоспаду всі вимоги визначені та підписані зацікавленими сторонами на початку; якщо виникає будь-яка зміна цього стану, проект розглядає це як запит на зміну. Його потрібно знову перевірити, узгодити та підтвердити.

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

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

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

#2. Планування та обсяг проекту

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

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

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

#3. Відстеження прогресу проекту

Проект водоспаду відстежує хід виконання плану в межах фаз проекту. Фаза проектування не може розпочатися до завершення фази аналізу, тестування не може розпочатися до завершення всієї збірки тощо.

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

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

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

#4. Командна співпраця

Мова йде про суворо відокремлені дії водоспаду проти постійної співпраці з усіма сторонами гнучкої команди.

У проекті водоспаду зазвичай працюють різні люди, які працюють на різних етапах проекту. Вони можуть певною мірою переповнювати один одного, але все одно це різні групи людей. Майже силос, можна сказати.

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

#5. Управління ризиками

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

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

Гнучкий проект тут також відрізняється. Ви насправді не відстежуєте прогрес у досягненні мети. Швидше, ви вирішуєте залежності між різними командами та видами діяльності. Мета полягає в тому, щоб жодна команда не чекала на іншу команду з прогресом.

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

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

#6. Структура впровадження

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

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

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

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

Заключні слова

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

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

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

Далі перегляньте детальну статтю про життєвий цикл Agile-тестування.