Методології управління проектами: виважена класика Waterfall та гнучкий Agile

Методологія управління проектами відповідає не тільки на питання «Що робити?», а й «Як робити?» — це стандартизація ведення проектів. Вибір методології визначає як буде працювати і взаємодіяти команда: вона враховує особливості проекту (BAS ERP тощо) і встановлює принципи управління, командної роботи, форму контролю, перевірки та оцінки результату. Від методології управління залежить якість планування та виконання проекту з впровадження ERP. 

У статті описані загальноприйняті методології ведення проектів: Waterfall, інкрементальний, ітераційний підходи, гнучкі методології (Agile): Scrum, KanBan. Їхні плюси та мінуси. Ми розглянемо основні тези цих методологій, порівняємо і наведемо приклади використання, щоб зробити для Вас наочним процес реалізації проекту автоматизації.

Деякі методології спрямовані на швидкість реалізації проекту впровадження BAS ERP і не тільки. Інші більше орієнтуються на охоплення його складових або управління співпрацею. Будь-яка методологія повинна бути адаптована під конкретний проект та його задачі.

Waterfall

Це класична каскадна методологія запуску проекту, яка ділиться на частини. Це фіксовані етапи, які є завжди, в будь-якому проекті. Waterfall йде строго поступово: спочатку збирається аналітика, описуються вимоги, далі розробка, тестування та запуск проекту з послідуючою підтримкою. iT.Artel обирає для роботи саме методологію Waterfall.

Коментар від Олексія Бардакова, керівника iT.Artel: Велика перевага методології Waterfall — це fixed cost. Виконавець відразу розуміє собівартість проекту, трудовитрати які очікуються і строки його виконання — всі етапи прописані, тож Замовник входить в проект вже розуміючи і чіткі терміни, і вартість. Чому це важливо: під час участі в тендерах всі замовники просять надати fixed cost. І тільки після озвученої вартості вже приймають рішення — йти у цей проект чи ні. І ось якщо вести проект по Waterfall, ми можемо цю вартість сказати. 

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

Для яких проектів рекомендується використовувати Waterfall

• Середні та великі проекти; 
• З декількома командами: дозволяє розділити задачі всередині проекту по декільком командам — ми маємо чітко розписані етапи, які не передбачають зміни, тож команди можуть виконувати задачі паралельно одна до одної. Таке розподілення роботи по Waterfall дозволяє втілювати дуже великі проекти;
• Коли цілі проекту зрозумілі на початку та не передбачається суттєвих змін; 
• Коли впроваджується тиражуєме рішення: системи, які відносяться до тиражуємих це — 1С:Підприємство, SAP,  Axapta, Битрикс тощо. Тобто системи функціонування та запуск яких зрозумілий можно успішно впроваджувати за допомогою Waterfall;

Проекти в яких вимагається “fixed cost“.

Інкрементальний підхід 

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

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

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

Ітеративний підхід

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

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

Agile — гнучкі методології 

Методології Agile розробили програмісти та створили перелік правил, які дозволяють  пришвидшити запуск ІТ проекту. Вони розраховані на те, щоб в будь-який момент можна було змінити ціль проекту та напрямок, в якому він рухається. І якщо Waterfall це — “домовились-запланували-діємо” зі встановленими термінами завершення та запуску, то в Agile ми постійно дороблюємо функціонал і безперервно випускаємо його.

Коментар від Олексія Бардакова: Розвивати проект, втілений методиками Agile після його умовного завершення (тому що проект може не отримати чіткого завершення та мати “відкриту кінцівку” з подальшим внесенням змін) зможе або виключно команда, яка працювала над ним, або ж вона вимушена буде витратити багато часу на передачу цього проекту тій команді, яка буде його далі підтримувати та розвивати. Також заміна окремих спеціалістів в команді або зміна всієї команди буде ускладненою через слабку документацію — все реалізується дуже швидко і упор йде на швидкість впровадження — документація на цій дистанції відстає. Цей момент потребує уваги. 

Для яких проектів рекомендується використовувати Agile

• Проекти-стартапи, коли розробляємо щось нове та не знаємо, що повинні отримати в кінці;
• Проекти по розробці власними силами “з нуля” або в ході яких передбачається глибока кастомізація рішення;
• В будь-якому разі тільки для проектів з відкритим бюджетом.

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

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

Scrum

Scrum, як і KanBan — це підвиди Agile. Вони відносяться до популярних методологій і часто використовуються. Життєвий цикл проекту по Scrum — це набір ітерацій, кожна з яких включає в себе міні-версію розробки проекту командами по методу Waterfall.

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

KanBan

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

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

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

Якщо хочете дізнатись більше про процес та результати впровадження проекту автоматизації, рекомендуємо матеріали:

1. Як автоматизація бізнес-процесів впливає на бізнес
2.  Хто відповідає за автоматизацію бізнес-процесів на підприємстві?
3. Методи впровадження ERP: які етапи очікують компанію на шляху та яким буде результат
4. Побудуй — автоматизуй! Чому побудова та автоматизація бізнес-процесів не одне й те саме

Виникли питання? Онлайн чи оффлайн — ми завжди поруч! Ви можете:

Замовити консультацію