Популярні методології управління проєктами: від гнучкої Аgile до вимогливої PRINCE2

Що таке методологія в проєктному управлінні та чому вона важлива?

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

Використання вибраної методології в проєктному управлінні дозволяє:

• мати спільне для усієї команди розуміння процесів, обов’язків, ролей — робота за методологією (будь-якою) передбачає прозорість в колективі;
• точніше визначати ресурси та прогнозувати кінцевий результат — на старті ведення проєкту в межах методології визначаються обсяги робіт, необхідних для виконання — відразу зрозуміло, яких співробітників слід залучити, скільки коштів та часу виділити. Навіть якщо це супергнучкий Scrum, все одно є певні обмеження та орієнтири;
• підвищити продуктивність співробітників — адже коли в проєкті мінімум неприємних несподіванок, ясно до чого прагнути та як цього досягти, процес закриття завдань стає легшим, а люди працюють із більшим задоволенням;
• швидше та краще закривати робочі питання — знову ж таки завдяки чіткому розподіленню ролей і компетенцій кожного залученого до проєкту, розумінню задач, цілей, необхідних кроків для їх досягнення. Дефіциту інформації немає в жодного з членів команди — від trainee-тестувальника до провідного UI/UX-дизайнера;
• зростати професійно — зокрема, project-менеджеру. Коли команда працює в рамках методології, процеси налагоджені і є чітка послідовність дій, координація та контроль співробітників проходять легше. Це дозволяє цілком зосередитись на успішній реалізації продукту. Крім того, робота за методологією дає PM-у цілісне розуміння проєкту, що дозволяє глибше «бачити» і аналізувати всі процеси;
• покращити загальну атмосферу в команді та згуртувати співробітників — в роботі за методологією відсутня невизначеність. Кожен співробітник чітко знає хто чим займається та за що відповідальний. Це сприяє зменшенню кількості конфліктних ситуацій в колективі; 
• не повторювати помилок, яких команда припускалась в минулих проєктах — використання методології дозволяє сформувати своєрідну культуру успішного проєктного управління — прописуються практики, що дають кращий результат та дії, яких слід уникати. 

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

Методологія, метод, методика — розбираємося в поняттях

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

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

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

Waterfall

Каскадна модель Waterfall або Водоспад є однією з найбільш традиційних і поширених методологій в проджект-менеджменті. Її основа — це послідовність. Тобто кожен етап проєкту «перетікає» в наступний, неухильно стікаючи вниз, як водоспад. Зазвичай Waterfall застосовується в проєктах, які можуть бути поділені на послідовні логічні частини. Наприклад кроки в ІТ-проєкті за методологією Водоспад виглядатимуть так:

1. визначення вимог проєкту та їх аналіз — проджект-менеджер збирає вимоги до майбутнього продукту, планує графік виконання робіт та оцінює можливі ризики;
2. проєктування — на цьому етапі готуються документи, в яких детально описується план реалізації попередньо сформованих вимог; команда створює прототип та дизайн-макети майбутнього продукту;
3. реалізація — втілення готового проєкту згідно із затвердженими планом, макетами та вимогами. Розробники працюють чітко за ТЗ;
4. тестування — реалізований продукт тестують та усувають помилки і недоліки;
5. впровадження — продукт офіційно запускають в роботу;
6. підтримка — надається технічна допомога після запуску комерційної експлуатації.

Джерело зображення: https://www.adservio.fr/post/waterfall-vs-kanban-principles

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

Через логічність та структурованість, Waterfall — оптимальна відправна точка для вивчення методологій управління проєктами. Вона найпростіша і у використанні — проджект-менеджер складає план, розробляє структуру, а далі його головне завдання — слідкувати, щоб цього плану дотримувалась команда чітко і у строк. Серед інших переваг Waterfall — стабільність завдань, реальна оцінка вартості та дати впровадження продукту. Хід проєкту легко відстежувати та контролювати. До того ж, зважаючи на те, що модель Водоспад в значній мірі спирається на документацію та записи в процесі розробки, це спрощує залучення нових учасників у проєкт. Наприклад, якщо старий співробітник звільнився, новачок зможе продовжити роботу майже миттєво — завдяки чіткій регламентації та наданим технічним матеріалам. 

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

Waterfall підійде:

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

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

Agile

Слово Agile перекладається як «гнучкий», «спритний», «верткий». Саме гнучкість і покладено в основу цієї методології. Загалом, модель Agile є своєрідною «відповіддю» на обмеження та жорсткий регламент Waterfall. Офіційно її було представлено у 2001 році в «Agile Manifesto», створеному 17 провідними розробниками спеціально для IT-галузі. Згідно з маніфестом, підхід Agile ґрунтується на чотирьох цінностях:

• Люди та взаємодія з ними важливіші за процеси та інструменти.
• Працюючий продукт (результат проєкту) важливіший за вичерпну документацію.
• Співпраця з клієнтами важливіша перемовин за договором.
• Готовність до змін важливіша за дотримання плану.

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

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

Аджайл характеризується постійним спілкуванням, взаємодією та наданням зворотного зв’язку всім причетним — від веб-розробників до клієнтів. При чому в команді всі рівні. Немає суворої регламентації і думка стажера-розробника така ж важлива, як досвідченого full-stack девелопера.

Переваги моделі Agile:

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

Звісно, є й недоліки. Наприклад, складно замінити когось із членів команди так як від кожного потрібна активна залученість до робочих процесів. Крім того, відсутність чіткого плану та структури, ускладнює управління ресурсами. Інколи, новачки-«проджекти», які працюють за Аджайлом, стикаються з тим, що проєкт перетворюється на каскад постійних та безрезультативних змін. Успішне впровадження цієї методології складніше, ніж моделі Waterfall, і PM-ам-початківцям без досвідченого наставника із досвідом роботи над проєктами за Agile — не обійтись. 

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

Фреймворки Agile

В реальності, в проєктному управлінні впроваджують не самостійну методологію Agile, а її фреймворки, які є частиною концепції — Scrum, eXtreme Programming (XP), Kanban, Scrumban. Всі вони відповідають гнучкості Agile і відрізняються окремими інструментами та підходами до управління. Ознайомимось з особливостями кожного фреймворка.

Scrum

Найпопулярніший фреймворк з філософією Agile. Багато компаній, які практикують скрам-підхід, навіть наймають в штат окремого фахівця — Scrum-майстра. Його основна задача — усунути всі перешкоди на шляху до більш ефективного виконання роботи. 

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

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

Методика Scrum спрямована на стимулювання гнучкості, креативності та надання високоякісних результатів. Завдяки розподіленню великої задачі на частини, метод дозволяє запобігти втоми та виснаження, а постійна взаємодія в колективі сприяє оперативному усуненню проблем та труднощів, що можуть завадити успішному закриттю завдань. Фреймворк Скрам актуальний для невеликих команд з 5-10 участниками.

Kanban

Канбан-фреймворк ще більш гнучкий, ніж Scrum. Його сенс полягає в візуалізації робочих процесів за допомогою канбан-дошок з картками, в яких описуються задачі. Відповідно до зміни статусу задачі, картки переміщуються у різні стовпці, наприклад від «Прийнято в роботу» до «Готово», а між цими етапами може бути ще декілька: «В роботі»,«Тестується» та ін. При цьому майже завжди картки пріоритизуються і найбільша увага приділяється таскам з позначкою «Високий пріоритет». Крім чітких критеріїв переходу задачі від стадії до стадії, Kanban передбачає обмеження в кількості завдань, не взятих до роботи. Це дозволяє уникнути неефективності багатозадачності. Спринтів в Канбані не передбачено.

Канбан-дошки формуються в спеціалізованих онлайн-інструментах — Trello, Jira та аналогічних. Особливо зручним є цей підхід для віддалених команд.

Scrumban

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

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

Scrumban використовує систематизацію складнішої методики Scrum і візуалізацію легшого у сприйнятті Kanban. Це дає змогу командам отримувати об’єднані переваги двох популярних підходів в управлінні IT-проектами.

Екстремальне програмування (eXtreme Programming, XP)

Ще один гнучкий підхід, який використовується для динамічних проєктів із стислими термінами. Ціль XP — впоратися зі швидкими змінами вимог до продукту — і в результаті підвищити якість і процесів, і результатів. Фреймворк передбачає свій набір цінностей, в який входять простота, комунікація, зворотний зв’язок і сміливість. А також — певні правила eXtreme Programming, що охоплюють всі етапи — від планування до тестування. 

Lean — фреймворк Agile чи окрема методологія?

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

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

Lean підійде: стартапам, оскільки ідеально «вписується» під теорію роботи в умовах невизначеності — коли потрібно працювати без прибутку та знизити витрати. Хоча загалом актуальна будь-якому бізнесу, де можна створити MVP — minimum viable product, мінімально життєздатний продукт. Наприклад, служба таксі планує розробити окремий застосунок виклику автівки. Компанія може запустити програму з простим дизайном та мінімальним функціоналом, зібрати зворотний зв’язок і випустити удосконалений додаток із врахованими побажаннями від клієнтів. 

PRINCE2

З PRINCE2, як і у випадку з Lean, також виникає плутанина. За рахунок жорсткої регламентації її інколи називають підвидом Waterfall. Насправді — це повноцінна, офіційна методологія, основана за каскадним типом. Вона була розроблена Центральним телекомунікаційним та комп’ютерним агентством (Central Computer and Telecommunications Agency — CCTA) Великої Британії у 1989 році як стандарт управління IT-проєктами, і наразі використовується здебільшого в соціальній сфері та для масштабних IT-ініціатив. Методологія PRINCE2 базується на 7 принципах, 7 темах та 7 процесах. Всі вони повинні вписуватися в 6 обмежень: час, гроші, ризики, вигоди, якість та зміст проекту. При чому принципи, теми та процеси в PRINCE2 пов’язані та взаємодіють один з одним. Принципи формують загальну основу управління проектом. Теми допомагають керувати важливими аспектами проєкту відповідно до цих принципів. Процеси, у свою чергу, забезпечують застосування цих принципів і тем у конкретних діях протягом усього проєкту. 

Ось, наприклад, сім принципів PRINCE2:

1. Постійна оцінка доцільності проєкту.
2. Врахування попереднього досвіду: аналіз кожного етапу проєкту, робота над помилками.
3. Чітко визначені ролі та обов’язки.
4. Поетапне управління.
5. Комунікація за необхідністю — немає потреби в постійних мітингах, обговореннях, взаємодії із командою — достатньо надати вичерпні завдання. Втручатись варто лише коли порушується якесь із шести обмежень.
6. Фокус на продукті. Головна ціль — кінцевий продукт та його якість. Кожен етап необхідно закінчувати проміжним результатом, щоб переконатись, що він відповідатиме початковому плану. 
7. Адаптація принципів методології в залежності від потреб кожного проєкту — з урахуванням його розмірів, кількості залучених співробітників і т.п.

Компоненти (теми) PRINCE2 — обґрунтування проєкту, організація, якість, ризики, плани, відстеження розвитку проєкту, зміни. 

Процеи в методології представлено на зображенні:

Сім процесів методології PRINCE2: початкок проєкту, управління, ініціація, контроль етапу, управління розробкою продукту, управління межами стадії (перехід на наступний етап), закриття проєкту. Джерело зображення: https://www.linkedin.com/pulse/download-best-prince2-project-management-2023-ali-usman/

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

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

Six Sigma

Методологія Шість Сигм зазвичай застосовується для контроля якості створення продукту, а не для управління проєктом. Основна ціль Six Sigma — постійне покращення процесів та усунення помилок. Впроваджується вона приблизно так: попередньо визначається, що має бути в майбутньому проєкті, і в процесі його реалізації відбувається пошук недоліків, їх виправлення та відповідно покращення продукту. Теорія Шести Сигм спирається на шість принципів:

1. Орієнтованість на клієнта — необхідно відслідковувати потреби клієнтів, аналізувати та враховувати їх.
2. Управління процесами на основі перевірених фактів — не можна покладатися на припущення.
3. Занурення в робочі процеси — щоб зрозуміти, що потребує покращення, спочатку потрібно вивчити принципи взаємодії процесів у проєкті.
4. Робота на випередження — продумувати хід проєкту, враховувати можливі наслідки та результати діяльності.
5. Залученість членів команди — максимальна прозорість в робочих процесах.
6. Постійне покращення і готовність до ризиків — власне на удосконаленні роботи і ґрунтується методологія. А ось з ризиками складніше — до них варто ставитися лояльно і не боятися допустити, при цьому долати невдачі, що виникають, і отримувати з них уроки.

Передбачені методологією Six Sigma і етапи:

1. Define — визначення. Формується об’єм проєкту і його цілі. 
2. Measure — вимір. Визначаються побажання та очікування замовника (кінцевого споживача), його вимоги. В подальшому зібрані дані допомагають ідентифікувати те, що потребує покращення.
3. Analyze — аналіз. Досліджуються всі проблеми у проєкті, потенційні недоліки продукту та варіанти їх рішення/усунення. 
4. Improve — покращення. Виявлені недоліки усуваються та удосконалюються бізнес-процеси.
5. Control — контроль. Після того, як проблеми виправленні, відбувається перевірка, наскільки це позитивно вплинуло на продукт.

Джерело зображення: https://www.sixsigma.co.uk/

Зважаючи на те, що Шість Сигм спрямована саме на процес, а не на проєкт, а в її основі — постійне удосконалення роботи, зазвичай її застосовують в поєднанні з моделлю Agile та називають — Agile Six Sigma. 

Метод критичного шляху (Critical Path Method, CPM)

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

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

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

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

Чи можна комбінувати та об’єднувати методології?

Можна. Більш того, в сучасному ІТ-світі ця тактика дуже часто практикується. Об’єднують не лише фреймворки, як у випадку із Scrumban, а й комбінують гнучкі та каскадні підходи. Наприклад, в проджект-менеджменті навіть виділяють окрему гідридну методологію з елементами Waterfall та Agile, яку ще називають «Структурованим Agile». В ній зібрані релельне планування, збір та аналіз вимог від першої, і можливість змін — від другої. 

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

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

Що варто враховувати при виборі методології управління проєктами?

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

• Сфера діяльності. Варто дослідити, чи є методології, загальноприйняті в галузі, і знайти відповідь чому саме вони. Тобто потрібно зважати на досвід компаній-лідерів в ніші, як позитивний, так і негативний. Наприклад, більшість ІТ-фірм користується фреймворками Agile за рахунок стрімких змін на ринку, а у промисловому секторі, де присутні давно сформовані стандарти, часто застосовують каскадні моделі, що передбачають багато документації, звітів і ретельний контроль.
• Бюджет. Чи є він фіксованим, чи можливо кошти можуть виділятися під кожен новий етап. 
• Складність проєкту та розмір команди. Деякі методології, наприклад PRINCE2, є недоцільними для простих та короткотривалих проєктів, тоді як популярний Scrum не підійде великим командам, в яких більше 10 співробітників.
• Комунікація. Важливо враховувати, наскільки тісними можуть бути контакти зі стейкхолдерами (виконавці, підрядники, замовники). Як часто є змога з ними спілкуватися та наскільки швидко вони готові реагувати на запитання та пропозиції. 
• Пріоритети проєкту. Зрозуміло, що кожен проєкт передбачає у підсумку випуск продукту чи вимірні результати. Але слід з’ясувати, що важливіше: дотримання бюджету та дедлайнів, а може доведений до ідеалу функціонал, експерименти та інновації чи точне врахування стандартів і умов замовника, однакова залученість всіх причетних або ж розподілення ролей з чітко розмежованою зоною відповідальності кожного учасника. Цінності та пріоритети методології і проєкту мають збігатися. 

Чи важливо новачкам у проджект-менеджменті розбиратися в методологіях?

Якщо коротко — так. «Проджектам»-початківцям потрібно розбиратися хоча б в найпопулярніших методологіях управління проєктами — Waterfall та Agile (і його фреймворках), і розуміти як їх застосовувати на практиці. Відповідні питання майже завжди присутні на співбесідах з кандидатами, які претендують на посаду Project Manager. Причому рекрутери можуть не просто запитати суху теорію на кшталт в чим відрізняються каскадний концепт від ітерактивного (гнучкого), а й змоделювати певні ситуації та запропонувати претенденту поміркувати як він буде діяти в рамках того чи іншого підходу. Від обраної методології буквально залежить хід проєкту: планування робочих процесів, взаємодія із командою і клієнтами, актуальні інструменти та ін. 

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