Різниця між класичним та гнучким управлінням проектами (частина 1) - спрощення проектів
Класичний чи спритний - дві методології в управлінні проектами, які не можуть бути більш різними: Звичайно, кожен менеджер проекту хоче привести свій проект до успіху, але основні ідеї та підхід двох підходів здаються абсолютно протилежними. Це виражається не в останню чергу в гострих суперечках щодо того, який із методів є «кращим». Але чи існує ця ковдра «краще»? Навряд чи це можливо! Загальновідомо, що інструменти працюють лише в тому випадку, якщо вони підібрані відповідно до цілі. У статті «Agile, classic & Co: Коли яка методологія управління проектами підходить?» Ви можете дізнатись більше про правильний вибір методології.
То як ви обираєте той чи інший підхід? Перш за все, вам потрібно знати, у що ви потрапляєте з кожним методом. Зокрема, це означає: Що означає зобов’язання для вашого проекту та чим відрізняються два підходи. Щоб вам було простіше, наступна стаття є першою в серії з 4 статей, в яких ми пояснюємо відмінності між ними класичний і спритний дійти до дна.
На початку серії ми починаємо з трьох дуже принципових відмінностей:
Небезпека: За умовами класичний і спритний Багато різних моделей процесів, фреймворків та реалізацій приховано. На практиці існує ряд змішаних підходів з найрізноманітнішими характеристиками. Отже, класично організований проект може містити гнучкі підпроекти. Навіть якщо проект офіційно відповідає тому чи іншому навчанню на 100% і рамки закріплені, кмітливий менеджер проекту часто знаходить прагматичне рішення для вирішення виникаючих проблем. У цій серії ми не вдаємось до таких змішаних форм та обхідних шляхів, але навмисно розглядаємо крайні форми "класичного" та "спритного" для кращого розуміння.
Пізній відгук проти раннього відгуку
З точки зору клієнта, відмінності між класичними та спритними процедурами стають особливо очевидними, коли Час і частота зворотного зв'язку враховувати: коли може або повинен (або може) клієнт (клієнт, кінцевий користувач, ...) дати свій відгук про результат проекту/продукт?
Класичне управління проектами:
Часто результат представляється замовнику лише в кінці проекту. Це може бути, наприклад, продукт, розроблений в рамках проекту. Щоб це не пішло не так, і що цей продукт насправді відповідає очікуванням замовника, потрібно бути дуже обережним при визначенні вимог на початку проекту. Зазвичай створюється специфікація вимог, яка складає основу для прийняття замовником в кінці проекту. Отже, зворотній зв’язок надходить лише в самому кінці.
Приклади:
- Насос на замовлення для очисних споруд з чіткими технічними вимогами та специфікаціями
- Реалізація маркетингового заходу для представлення нового смартфона
- Навчання працівників органу влади на тему "нові правила захисту даних"
Небезпека: У класичному управлінні проектами, звичайно, є також можливість надати клієнту можливості для зворотного зв'язку під час реалізації проекту. Приклади, будь ласка?
- У наведеному вище проекті розробки консультації з клієнтом можуть проводитися після закінчення фази проектування.
- На прикладі навчання працівників розроблена концепція навчання може бути представлена керівництву влади на затвердження.
У класичному управлінні проектами такі точки зворотного зв’язку в основному використовуються для перевірки того, чи проект все ще на шляху, щоб запобігти гіршим ситуаціям. Якщо в такий момент необхідна корекція курсу, це зазвичай тягне за собою значні зусилля з перепланування - проект часто є дорогим і затримується.
Швидке управління проектами:
Клієнт отримує підфункції або збільшення продукту для оцінки регулярними циклами - зворотній зв'язок та зауваження чітко вітаються. Це працює лише в тому випадку, якщо результат проекту можна розбити на кроки, які можна генерувати один за одним, а потім перевірити/оцінити. Яскравим прикладом є розробка програмного забезпечення - сфера, в якій виникає спритна ідея.
На малюнку показана процедура на прикладі фреймворку Scrum в гнучкому управлінні проектами:
У небезпечних середовищах із мінливими вимогами перевага очевидна: замість того, щоб розробляти цілісний продукт протягом тривалих періодів часу, усі залучені отримують регулярне розуміння прогресу проекту. Вимоги можна регулювати та визначати наступні кроки. Таким чином, подальші великі коригування автоматично усуваються. На відміну від класичного управління проектами, немає ризику, що зміни вимог не виявляться, або, в гіршому випадку, продукт буде обійдений на ринку.
Приклади:
- Розробка веб-сайту з Інтернет-магазином та безліччю інших детальних функціональних можливостей
- Розробка програмного забезпечення управління для нової конструкції двигуна
- Планування односімейного будинку архітектурним бюро
Визначені процеси проти інновацій
Будівництво тринадцятого збірного будинку "поза кілочком" надзвичайно відрізняється від розробки інноваційного додатка, незважаючи на всі варіанти конфігурації - і тому процедура також буде суттєво відрізнятися:
Класичне управління проектами:
Класично заплановані та реалізовані проекти особливо придатні для проектів, які слідують визначеним процесам, в яких використовуються добре зрозумілі детальні рішення/компоненти і з яких повинен вийти передбачуваний результат. Перевірені та визначені кроки призводять до наперед визначеного результату.
Приклади:
- Будівництво односімейного будинку "поза кілочком"
- Оновлення серверного ландшафту в компанії
Швидке управління проектами:
Швидке управління проектами часто використовується в динамічних середовищах: при розробці продуктів, дослідженнях та розробці програмного забезпечення. Часто неможливо чітко передбачити, як буде детально виглядати результат і які підходи дадуть найкраще рішення - спочатку просто ніхто не знає. Даний план або процес мало сенсу, врешті-решт, слід створити щось нове. Якщо потрібно створювати новаторські інновації, немає стандартного рецепту, який можна застосовувати безпосередньо.
Приклади:
- Оптимізація дисплея ноутбука за допомогою нових технологій, які ще не повністю зрозумілі
- Розробка інноваційного додатка для схуднення
Послідовний розвиток проти ітеративного розвитку
Попередньо визначеними послідовними кроками до мети - або короткими циклами? Тут методології управління проектами значно різняться. Цей момент тісно пов'язаний з частотою зворотного зв'язку (див. Вище):
Класичне управління проектами:
У традиційно реалізованих проектах певні етапи обробляються одна за одною на початку. Коли етап або блок завдань завершено, починається наступний. В принципі, фази також можуть перекриватися, але принаймні в рамках підпроекту вони ніколи не обробляються приблизно паралельно, а по суті одна за одною.
Цей підхід базується на припущенні, що вся інформація доступна на початку проекту. Вони упаковані у вимоги та конструкції, після чого починається впровадження.
Приклад: Лише коли дизайн веб-сайту буде повністю закінчений, почнеться програмування.
Швидке управління проектами:
В гнучкому управлінні проектами на початку не все детально визначено. Основна ідея: люди не можуть заздалегідь побачити всі деталі, і навіть клієнти не знають, що саме вони хочуть і які варіанти доступні на початку. З цієї причини впроваджуються невеликі блоки, які перевіряються та, якщо потрібно, вдосконалюються.
Ітеративний:
Ітераційний підхід базується на передумові, що на першому кроці багато речей часто неправильно або не ідеально вирішуються до того, як помилки будуть виправлені на наступному кроці. Якщо прямо сказати: перше кидання стосується сміттєвого ящика, але ми можемо на ньому навчитися і спиратися на нього. Або ще: Перший кидок - це пропозиція для клієнта. Тому багаторазові спроби не розглядаються як помилки, а скоріше плануються як частина процедури з самого початку.
приклад: Замість того, щоб безпосередньо подати детальний проект нового веб-сайту з усіма його деталями, створюються приблизні ескізи, попередні версії, які поступово вдосконалюються за погодженням із замовником.
Додаткові:
При поступовому підході великі фрагменти розбиваються на підзадачі, і вони виконуються одна за одною. Передумови: Якщо побудовано невелику частину, знання можна отримати і застосувати до інших функцій.
Приклад: Замість того, щоб проектувати всі підсторінки присутності нової компанії, спочатку створюється лише початкова сторінка.
Висновок
Вибір правильного інструменту для кожного застосування часто є фокусом! У цій статті ви ознайомилися з першими трьома відмінностями між класичним та гнучким управлінням проектами. Вам цікаво дізнатись більше? Частина 2 продовжується!