УПРАВЛІННЯ ПРОЕКТАМИ В ІТ СФЕРІ

Анотація

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

Ключові слова: управління, ІТ-проєкт, методологія, Agile, Scrum, Kanban. Аналіз сучасних умов світового розвитку вказує на невпинне зростання обсягів цифрових технологій, які застосовуються у сферах виробництва, в науці та бізнесі, що зумовлює нові вимоги до моделювання та управління проєктами. Поява на ринку України великої кількості конкурентних компаній в сфері IT бізнесу, що займаються розробкою програмних продуктів, безперервний розвиток інформаційних технологій, інтенсивний розвиток програмного забезпечення, збільшення ступеня невизначеності та ризику – усе стало передумовами для вдосконалення методів управління проєктами, пошуку нових способів організації управлінської діяльності та зумовило потребу в переході на гнучкі методології. Метою статті є дослідження управління ІТ-проєктами з використанням гнучких методологій Agile, Scrum, Kanban. Під гнучкою методологією розробки (англ. Agile software development, agile – методи) будемо розуміти серію підходів до розробки програмного забезпечення, орієнтованих на використання ітеративної розробки, динамічне формування вимог і забезпечення їх реалізації в результаті постійної взаємодії всередині самоорганізованих робочих груп, що складаються з фахівців різного профілю [1-3]. ІТ-проєкти, на відміну від інших проєктів, які реалізуються у різних сферах діяльності, виробництва, бізнесу тощо, характеризуються тим, що проєктне управління має притаманні лише йому чинники, які впливають на успішність виконання завдань проєкту. Окрім властивих звичайним проєктам обмежень щодо часу, бюджету, якості та ресурсів, ІТ-проєкти потребують вирішення унікальних технологічних завдань, які пов’язані з особливостями використання програмного забезпечення, операційних систем, апаратних засобів, забезпечення інформаційної безпеки та ін., що значно підвищує складність реалізації проєктів та призводить до вищого ступеня ризиків. Відтак, управління ІТ-проєктом повинне враховувати усі вищезазначені обмеження та специфічні чинники, здійснювати керуючий вплив на них, застосовувати спеціальні для цього виду проєктів інструменти управління та ефективні практики організації праці. Вибір методів управління проєктом тісно пов'язаний з життєвим циклом проєкту, що включає такі основні фази як ініціація, планування, виконання, завершення [3; 8]. Однак, при управління ІТ-проєктами, яким притаманна мінливість, необхідною є докладна деталізація етапів життєвого циклу з подальшим вибором адекватної моделі управління. Традиційною моделлю для управління проєктами довший час залишалася каскадна (водоспадна) модель (Waterfall model), представлена у роботі W. Royce [1-5], яка передбачала, що кожен етап розробки проєкту, який відповідає певному життєвому циклу, продовжує попередній. Відтак, перехід на новий етап міг відбутися тільки після завершення попереднього етапу. Така методологія унеможливлювала внесення змін до закінчення розробки продукту, а також мала формальний підхід до послідовності процесу роботи. На сьогодні великого поширення та популярності набули гнучкі методології Agile-сімейства, до складу якого входить Scrum, Kanban, Lean та інші методи [1;7]. Сучасні ІТ-компанії для управління ІТ-проєктами використовуються ті чи інші гнучкі (ітеративні) методології в залежності від: специфіки та складності проєкту, поставлених цілей, потреб стейкхолдерів, вимог замовників, рівня професійності команди проєкту, бюджету проєкту, особливостей організації тощо. Але вибір методології не є універсальним рішенням і зміна проєкту можливо потребуватиме іншої методології, орієнтованої саме на реалізацію цього конкретного проєкту. Широке використання Agile методологій в процесі управління ІТ-проєктами відбулося після розробки та прийняття в США Agile Manifesto («Маніфесту гнучкої методології розробки програмного забезпечення») [3-9], який став альтернативою існуючим практикам розробки програмного забезпечення та визначав основні цінності та принципи, якими повинні керуватися команди розробників для успішної реалізації ІТ-проєктів. Agile не містить конкретних практичних порад, а визначає цінності і принципи, якими керуються успішні команди. В основі цих принципів лежать 4 основні ідеї: 1) люди та взаємодія важливіші за процеси та інструменти; 2) працюючий продукт важливіший за вичерпну документацію; 3) співпраця з замовником важливіша за узгодження умов контракту; 4) готовність до змін важливіша ніж дотримування початкового плану [4; 5]. Найбільш поширеною моделлю, заснованою на принципах гнучкого управління, є Scrum [1-4]. Scrum – це Agile-методологія, яка була розроблена для складних проєктів, що потребують швидкої адаптації до змін. В основі Scrum методології лежить sprint (від англ. sprint – забіг) – це короткочасний цикл розробки, що зазвичай триває від 1 до 4 тижнів. Розбивка проєкту на частини або як їх прийнято називати спринти, дозволяє з меншою кількістю людей та за менший час дати значно більший результат кращої якості, без витрачання великих коштів [2-4]. Відтак, великий проект може виконуватися невеликою ІТ-командою (5-7 чоловік), яка працює короткими проміжками часу (ітераціями) на невеликих робочих ділянках, і після завершення одного спринту та його релізу, команда переходить до наступного. Кожному спринту присвоюється свій пріоритет і наприкінці кожного спринту повинен бути працездатний і більш досконалий ІТ-продукт.

Scrum методологія базується на трьох основних принципах:

1) адаптація, яка передбачає, що Scrum може легко пристосовуватись до проєкту, який змінює тактичні напрямки в процесі реалізації; 2) прозорість, яка дозволяє команді чітко орієнтуватися в процесах розробки проєкту; 3) інспекція, яка ґрунтується на тому, що члени команди постійно контролюють та перевіряють етапи виконання проєкту, а за рахунок ефективної комунікації та миттєвого зворотного зв’язку є можливість швидко виправити помилки, що розвиває культуру вдосконалення. Однак варто зауважити, що Scrum методологія не є ефективною для проєктів, які мають строго регламентовані та нормовані області. Ще однією методологією, яка широко використовується в ІТ-проєктах, є Kanban, продовжує розвиватися в ширших колах. Ця методологія орієнтована на невеликі проекти, які не потребують багато часу на планування, але також може використовуватись і для довгострокових проектів, які не передбачають чіткої специфікації, а завдання формуються в процесі розробки [1-7]. Для роботи з Kanban необхідно визначити етапи потоку операцій (workflow) і визначити їх пріоритет. Варто зазначити, що на відміну від Scrum, ця методологія не передбачає обмежень за часом ітерацій і кожен етап виконання поточного завдання може бути призупинений, якщо змінився його пріоритет. Основне завдання Kanban методології – збалансувати різних вузькопрофільних фахівців всередині команди проєкту, при цьому кількість команд для роботи над завданням не є обмеженою [6; 7]. Kanban представляє собою візуальний метод управління проєктами, так як в його основі фізична або цифрова дошка (наприклад, Trello, Jira та ін.), на якій фази виконання проєкту розділені на стовпці, а завдання фіксуються на картках, які по мірі виконання завдань проєкту переміщаються з однієї колонки до іншої, аж доки завдання повністю не буде виконано. Картка може містити ім’я відповідального виконавця, а виконавці на дошці можуть об’єднуватись в команди. Перевагами Kanban є підвищення наочності виконання проєкту, швидкості виконання робіт внаслідок розумного розподілу кількості завдань між членами команди, узгодженість між бізнес-цілями, ключовими результатами та роботою з виконання. Разом з тим, Kanban є непридатним для проєктів, терміни виконання яких чітко обумовлені. Показником ефективності команди в Kanban є середній час проходження одного завдання по дошці, відтак члени команди не зосереджуються на виконанні конкретних завдань, вони стежать за тим, щоб середній час виконання був мінімальним [7-10]. ІТ-галузь впродовж останніх років показує стабільні темпи зростання і за останні 3 роки зросла по експорту більше ніж удвічі. Створені найкращі можливості для розвитку ІТ-бізнесу [5-8]. Не зважаючи на військові реалії, ІТ-галузь швидко адаптувалась, працює та показує фінансову стабільність. Для реалізації проектів ІТ-компанії застосовують різні інструменти розробки та методології управління проектами. Вибір методології управління роботою команди впливає на якість та ефективність реалізації проекту. Отже, прийняття рішення про вибір методу має велике значення для реалізації проектів в ІТ-сфері і, відповідно, це питання має більш активно і глибоко вивчатися в науковому плані. Аналіз останніх досліджень. Методології управління проектами нині досить широко розкриті і розвинені у наукових працях науковців[1-9] Д. Смолича, В. Галушка, А Степанова, Е. Коена, К. Швабера, Д. Сазерленда. У них подано характеристику інноваційних методів [3-7]. Обґрунтовано науково практичні концептуальні рекомендацій теорії управління проектами [1-7]. Роботи розкривають проблеми організації проектів в ІТ-сфері [4-7], а робота[8-10] є фундаментальним описом методології SCRUM та її використання [3-9].

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

Метою даної статті є виділення пріоритетів та формування порядку вибору методології управління проектом на основі аналізу особливостей, переваг і недоліків їх різних видів. Виклад основного матеріалу. Проект – це розв’язання та реалізація конкретного завдання в межах обмеженого часу та ресурсів. Термін проект часто використовується у різних напрямках діяльності, зокрема й у виробничій сфері. Термінологія управління проектами прийшла в Україну з англомовних країн і на сьогодні є стандартною. Управління проектами, або проектний менеджмент, розглядається як універсальна мова спілкування між учасниками проекту. Методологія управління проектами – це набір керівних принципів та процедур для управління проектом [1-7]. При виборі методології управління для конкретного проекту необхідно спиратись на особливості методологій, їх сильні та слабкі сторони і стратегії, які сприяють успішній реалізації проекту. Ретельно підібрана методологія враховує особливості проекту, визначає принципи та методи управління командами проекту, контролю та оцінки результатів. Дане дослідження було спрямоване на визначення особливостей методів управління проектами, їх переваг і недоліків, а також сфер та ситуацій для кращого їх використання. Аналіз методологій управління проектами, проведений на основі матеріалів наукових публікацій [1, 3, 6, 9], зокрема Waterfall, Agile, Гібридної методології, Scrum, Методу критичного шляху (CPM), Методу критичного ланцюга (CCPM), Інтегрованої системи управління проектами (ІРМ), PRiSM, PRINCE2, Kanban, дозволив виділити їхні сильні та слабкі сторони Вибір методології управління проектами для команди має важливе значення. В опублікованому організацією Project Management Institute документі «Implementing Organizational Project Management: A Practice Guide» [2-8] звертається увага на такі фактори при оцінці методології управління проектами: стратегічні цілі та базові цінності організації; ключові бізнес-фактори; обмеження; зацікавлені особи; ризики; складність; масштаб та вартість проекту; оцінка методологій керування проектами Простота використання – модель проста для розуміння та використання. Поділ на етапи інтуїтивний, легкий в оволодінні. Структура - чіткий поділ на етапи дозволяє організувати та розподілити роботу. Необхідно чітко виконувати кожен етап. Документація – модель Waterfall спирається на документацію розроблену на основі збору та розумінню вимог. Виконавцям проекту легше влитися в процес реалізації проекту. Підвищений ризик – жорстка методологія визначає неможливість зміни проекту. При необхідності змін чи при виявленні помилки проект необхідно розпочинати спочатку, що може призвести до того, що проект може не завершитися вчасно. Складність першого етапу – все залежить від правильного розуміння та аналізу вимог. Помилка на цьому етапі призводить до необхідності починати все спочатку. Agile Гнучкість та свобода - не потрібно чітко позначати етапи та наголошувати на вимогах, у виконавців проекту є можливість експериментувати та вносити зміни поступово. Знижений ризик - методологія Agile - це регулярне отримання зворотного зв'язку від зацікавлених учасників та подальше внесення змін, що значно скорочує ризик провалу проекту, оскільки необхідні ресурси залучені до процесу. Відсутність чіткого плану – реагування на зміни відбувається тоді, коли ці зміни виникають. Відсутність чіткого плану ускладнює управління ресурсами та планування. Складність взаємодії – відсутність чіткого плану означає, що всім зацікавленим сторонам і замовникам, і спонсорам, доведеться працювати у набагато тіснішій співпраці, щоб кожен учасник проекту знав про всі зміни, завдання та їх актуальність. Велика гнучкість − гібридній методології властива значно більша гнучкість (окрім етапу планування,), ніж методу Необхідність компромісів – необхідно підтримувати баланс між двома абсолютно протилежними підходами Waterfall. Якщо вимоги не будуть значно змінюватися, до проекту можна буде вносити зміни за необхідності. Велика структурованість – запозичивши етап початкового планування з Waterfall, гібридна методологія вирішує одну з основних проблем підходу Agile - недостатню організованість та відсутність плану.

Таким чином, ця методологія поєднує у собі найкраще від цих підходів. та шукати компроміси щодо вимог і гнучкості. Поєднання найкращого – методологія, поєднує в собі все найкраще від двох підходів, але позбавлена гнучкості Agile та стабільності Waterfall. Будь-які внесені зміни повинні відповідати бюджету та плану, визначеним заздалегідь. Scrum Спринти − підход Scrum акцентується на однодвотижневих спринтах, або відрізках часу. Так, команда проекту поділяє список кінцевих цілей на невеликі завдання, а потім працює над ними впродовж однодвотижневих періодів із щоденними зборами. Завдяки такому підходу простіше долати великі складні проекти. Динамічність − завдяки розбивці роботи на однодвотижневі періоди зі щоденними зборами розробка та внесення змін відбуваються динамічно. Командна робота − самоорганізація команди , учасники чіткіше розуміють проект, лідери можуть самостійно розставляти пріоритети відповідно до своїх знань та можливостей. Гнучкість − швидке внесення змін та регулярний зворотний зв'язок із зацікавленими сторонами. Неконтрольоване розширення масштабів − оскільки дата завершення проекту не встановлена і відсутній менеджер проекту, який би займався плануванням та бюджетом, Scrum може спричинити неконтрольоване розширення масштабів проекту. Підвищений ризик − оскільки команда проекту займається самоорганізацією, збільшується ризик провалу, якщо команда недисциплінована та невмотивована. Якщо у команди недостатньо досвіду, робота в рамках Scrum з великою ймовірністю закінчиться провалом. Недостатня гнучкість − акцент на команді проекту означає, що відхід будь-якого ресурсу вплине на результат. Також цей підхід недостатньо гнучкий для великих команд. Детальне планування − завдяки акценту на тривалості активностей та взаємозв'язках між ними можна краще спланувати завдання. Якщо для виконання завдання X спочатку потрібно завершити завдання Y, CPM допоможе вам визначити заздалегідь і розпланувати все належним чином. Розміщення пріоритетів − успіх методу залежить від Відсутність досвіду планування − будь-який досвідчений менеджер з управління проектами скаже, що на все завжди йде більше часу, ніж планувалося. За відсутності реального досвіду планування, напевно, час на виконання завдань буде розрахований неправильно. Відсутність гнучкості − як і у Waterfall, перший етап роботи громіздкий, потрібно все розпланувати. Якщо 70 визначення та планування критичних важливих завдань та завдань другорядного значення. Визначивши завдання, можна оптимально розподілити ресурси. з'являться зміни, весь план буде не важливий, тому ця методологія не підходить для проектів із змінними вимогами. Висока ефективність ресурсів, завдяки акценту на правильному управлінні ресурсами метод критичного ланцюга − одна з найбільш ресурсоефективних методологій. Однозадачність також чудово підкреслює сучасне розуміння несприятливих ефектів багатозадачності. Зосередженість на кінцевій меті − ставить за мету пошук найбільш сприятливого вирішення проблеми. Пріоритет віддається пошуку рішень, які допомагають досягти кінцевої мети. Оскільки робота будується від кінцевої мети, CCPM зазвичай дозволяє досягти кращих результатів у складних проектів. Однозадачність − не підходить для кількох одночасних проектів, оскільки метод значною мірою зосереджений на ресурсах, застосовується лише в однопроектному середовищі. У багатопроектному середовищі ресурси можуть бути задіяні у кількох проектах. CCPM не підтримує сценарій розподілу ресурсів між кількома проектами. Затримки − CCPM враховує буфери – часові проміжки між завданнями – у загальному часі завдань. Теоретично це може призвести до переоцінки ресурсами своєї ефективності. Це призводить до невиправданих затримок. Інтегрована система управління проектами (ІРМ) Прозорість − впровадження однакових процесів у всій компанії дозволяє збільшити прозорість в організації. Передбачає, що члени проектної команди ведуть документацію та регулярно зустрічаються, завдяки чому вони завжди в курсі ситуації. Підзвітність − завдяки комплексному підходу вся команда відповідає за проект. Оскільки жоден працівник не працює ізольовано від інших, IPM дозволяє покращити підзвітність. Детальне планування − в рамках підходу IPM вам доведеться докладно планувати роботу заздалегідь і стежити за тим, щоб усі процеси були правильно інтегровані. Це суттєво збільшує ваше завантаження та може призвести до затримок завершення проекту. PRiSM Орієнтованість − охорона навколишнього середовища − підхід PRiSM дуже актуальний для сучасних проектів, в яких облік витрат на охорону навколишнього середовища та стійкість є ключовими критеріями успіху. PRiSM – це конкурентна ідеологія управління проектами для великих проектів, у яких особлива увага приділяється скороченню Орієнтованість − охорона навколишнього середовища, тому PRiSM не підійде проектам, для яких вплив на навколишнє середовище не є проблемою, наприклад, з розробки програмного забезпечення або творчим проектам. Стійкість − для успішного застосування підходу PRiSM енергоспоживання, утилізації відходів та зменшенню впливу на навколишнє середовище. необхідно, щоб усі члени робочої групи проекту, а також зовнішні замовники та зацікавлені сторони були готові дотримуватися принципів стійкості, що рідко зустрічається у сучасних організаціях. PRINCE2 Структура − методологія описує процедури координації людей та завдань в проєкті, як створювати / планувати проєкт та що робити, якщо проєкт потребує внесення змін через невідповідність фактичного стану виконання проєкту плану його виконання. Кожний процес зазначено з ключовими вхідними та вихідними даними, а також з специфічними цілями та завданнями, які необхідно виконати, що загалом дає можливість контролю відхилень від плану. Контроль − поділ методу на частини, що підлягають управлінню, забезпечує ефективний контроль ресурсів, завдяки чому можливо здійснювати контрольований та організований моніторинг проекту. PRINCE2 забезпечує єдину термінологію для всіх учасників проекту. Різноманітні ролі управлінців та зони відповідальності повністю описані та можуть бути адаптовані відповідно до складності проекту та компетенцій організації. Документація − детальна документація, яка ведеться при використання цього методу, може виявитися дуже корисною для довгострокового планування та контролю продуктивність, дозволяє знизити ризики. Документація − важко адаптуватися до змін проекту, оскільки на кожному етапі процесу дуже багато зусиль вкладається у створення та ведення документації та реєстраційних журналів. Kanban Наочність − методологія допомагає командам розуміти, на що насправді витрачається їхній час, і це дозволяє збільшити ефективність Стабільність – часті зміни та відсутність чітких термінів можуть зробити Kanban неефективним. Розмір команди – велика команда викликає складність контролю виконання завдань. *Складено автором за результатами вивчення і узагальнення літературних джерел [6-11] Кожна з методологій пропонує унікальні принципи ведення проекту на всіх етапах, від початку до завершення. При виборі методології, необхідно звертати увагу на: - розмір та стиль роботи колективу; - пріоритети та цілі проекту; - сферу діяльності, яка впливає на послідовність реалізації проекту і, залежно від неї, обирається гнучка або жорстка методологія; - складність проекту - деякі методи, наприклад, методологія критичного шляху, не підходять для роботи над складними проектами; спеціалізація ролей – для команд з вузькою спеціалізацією учасників необхідна методологія, яка враховує спеціалізацію учасників команди; - розмір організації та команди – деякі методи, такі як Agile, Kanban є універсальними для будь-яких команд, а інші краще підходять для невеликих команд (наприклад, метод критичного шляху). Після визначення критеріїв та оцінювання методологій управління проектами переходять до вибору найкращої методології для конкретного проекту. Проаналізовані матеріали статей авторів Е. Коен [3-7], А. Степанова [4-9] та електронних ресурсів [10, 11] дозволили виділити пріоритетні ситуації для вибору тієї чи іншої методології управління проектом в ІТ-сфері. Пріоритети при виборі методології управління проектом В ІТ-галузі в проектах розробки програмного забезпечення методологію Waterfall найкраще застосовувати для невеликих нескладних проектів; проектів з чіткими, прописаними вимогами; проектів з ресурсами, що змінюються в залежності від детальності документації. Agile Гнучкість підходу Agile дозволяє адаптувати його до проектів різного типу. Особливо, її застосування виправдано коли нема чіткого бачення результату, але є загальне уявлення про продукт; коли проект необхідно швидко підлаштовувати під зміни; коли планування неможливе, а є лише взаємодія та комунікація. Гібридна методологія Найкраще використовувати в проектах з розмитими вимогами, в яких важливі планування і гнучкість. В основному це проекти середнього обсягу з високою складністю та фіксованим бюджетом. Це проекти, де є певне уявлення про кінцеву мету, але можливі експерименти. Із зацікавленими сторонами потрібна тісна взаємодія, особливо після етапу планування. Scrum Методології властиві всі переваги та недоліки Agile. Її можна застосовувати для роботи над великими проектами, але вона не підходить командам із багатьма учасниками. Використання Scrum підійде для розробки складного програмне забезпечення з досвідченою командою. Метод критичного шляху (CPM) Найкраще підійде проектам, які мають взаємозалежні частини; або, якщо необхідно виконати завдання одночасно; або необхідно завершити одне завдання перед тим, як перейти до іншого. Добре підходить для складних проектів, у яких часто повторюються завдання та дії, наприклад, для промислових. Для динамічних проектів, наприклад, творчих, вона підходить меншою мірою. Метод критичного ланцюга (CCPM) Найкраще працює для команд з обмеженими ресурсами та у випадках, коли всі ресурси зайняті в одному проекті. Інтегрована система управління проектами (IPM) Ідеально підходить для креативних агенцій, для великих агентств із різноплановими командами та процесами, для складних творчих проектів, у яких задіяні ресурси з різних команд та відділів, для організації взаємодії. PRiSM Можна використовувати у великих та складних проектах у сфері нерухомості та промисловості, для яких стійкість є вирішальним фактором. PRINCE2 Методологія PRINCE2 найкраще підходить великим та складним проектам із чіткими вимогами. Kanban Див. Agile. Особливо ця методологія підходить віддалених команд. *Складено автором за результатами власного дослідженням Кожна методологія управління проектами має свої сильні і слабкі сторони, тому можна одночасно використовувати кілька методологій, виходячи з унікальної природи проекту, його цілей та організаційної структури. У процесі дослідження було запропоновано порядок вибору методології управління ІТ-проектом, який апробовано на прикладі проекту з умовною назвою «New e-com platform». Цей проект впроваджує outsource ІТ-компанія в умовах невизначеності вимог до функціоналу окремих елементів, етапів проекту та шляхів їх реалізації, однак за наявності високорівневого загального уявлення про кінцевий продукт цього проекту. Характеристика ІТ-проекту – електронна комерція, зміна архітектурного рішення існуючого Online-маркетплейсу з використанням мікросервісної архітектури. Завданням проекту є перехід від монолітної на мікросервісну архітектуру з використанням сучасних хмарних технологій та алгоритмів обробки інформації. Метою проекту є розвиток динаміки бізнесу та підвищення стабільності роботи сервісу за рахунок впровадження мікросервісної архітектури протягом наступних двох років. У галузі розробки програмного забезпечення найчастіше використовуються такі методології управління проектами: Waterfall, SCRUM, Kanban, гібридна методологія та інші. На етапі попередньої підготовки, проект було оцінено як такий, що не може бути реалізований одразу, без змін, від початку до кінця. Були проаналізовані методології управління проектами, які використовуються цією ІТ-компанією, з ціллю вибору оптимальної для застосування на даному проекті. Класична методологія Waterfall з детальним технічним завданням, з точними етапами та датами виконання не підходить для цього проекту. Адже є ризик отримати не такий результат, який очікується на старті проекту та ризик необхідності перероблення проекту та додаткових витрат часових, фінансових і ресурсних. Гібридна методологія, яка приділяє особливу увагу первинному збору та аналізу вимог, не може бути використана для цього проекту через неможливість зібрати достатньо інформації на старті проекту для оцінки бюджету та термінів. Застосування методології Kanban, якій притаманна гнучкість та можливість змін у будь-якій фазі реалізації проекту, також недоцільно. Оскільки проект є великим, складним та багаторівневим з непередбачуваним масштабуванням кількості функціоналу. Тому дана методологія не підходить для конкретного проекту через вимоги, які часто і швидко змінюються. Методологія SCRUM передбачає концепцію ітерацій (спринтів). На основі результатів попередньої ітерації формулюється наступне завдання. Так розвивається проект і уможливлюється визначення та перегляд результату проекту в конкретний час, а не колись і майбутньому. Після завершення кожного етапу, що складається із спринтів, замовник отримує готовий протестований та інтегрований сервіс (продукт). Під час виконання етапу ведеться постійна взаємодія з замовником, у разі непередбачуваної зміни бажаного кінцевого результату зі сторони замовника методологія дозволяє швидко адаптувати проект під нові вимоги. Використання SCRUM підходить для розробки складного програмного забезпечення досвідченою командою. Саме тому доцільно обрати методологію управління проектами SCRUM, яка дозволяє бачити результат проекту в конкретний час, ефективно вирішувати завдання, які з’являються у процесі реалізації проекту, та рухатись до завершення проекту.

Висновок

Виділяють декілька найбільш використовуваних методології управління проектами, серед яких гібридна методологія, SCRUM, метод критичного шляху (CPM), метод критичного ланцюга (CCPM), інтегрована система управління проектами (IPM), PRiSM, PRINCE2 та Kanban. Усі вони мають свої переваги та недоліки, тому обрання конкретної методології для проекту має ґрунтуватися на системі визначених пріоритетів. Перш за усе на вибір методології, яка буде використовуватись для реалізації конкретного ІТ-проекту, впливає досвід і знання менеджерів ІТ-організації. Для підвищення результативності роботи команди ІТ-проекту можна комбінувати різні методології, при цьому потрібно знати і розуміти їх особливості. Висновки. Отже, кожна з сучасних гнучких методологій Agile-сімейства в управління ІТ-проєктами має свої переваги та недоліки і їх вибір не є універсальним, оскільки повинен враховувати специфіку та складність конкретного проєкту.

Список використаних джерел

1. Гвоздь М.Я., Злидник Ю.О. AGILE – нова методологія менеджменту: теоретичні аспекти. Електронний журнал «Інфраструктура ринку». 2018. № 25. С 230-234.

2. Демиденко М.А. Управління проектами інформатизації за методологією SCRUM : навч. посіб. ; Нац. гірн. ун-т. Д. : 2016. 80 с.

3. Довгань Л.Є., Мохонько Г.А., Малик І.П. Управління проектами: навчальний посібник до вивчення дисципліни для магістрів галузі знань 07 «Управління та адміністрування» спеціальності 073 «Менеджмент». Київ : КПІ ім. Ігоря Сікорського, 2017. 420 с.

4. Мартін Роберт. Чистий Agile: назад до основ / пер. з англ. В. Луненко. Харків : Вид-во «Ранок» : Фабула, 2021. 224 с.

5. Моделювання бізнес-процесів та управління ІТ-проектами : навч. посібн. / Є.М. Крижановський, А.Р. Ящолт, С.О. Жуков, О.М. Козачко. Вінниця : ВНТУ, 2018. 91 с.

6. Перит І.О. Перспективи впровадження Kanban в управління бізнесом вітчизняних суб'єктів господарювання. Бізнес Інформ. 2019. № 8. С. 218-228.

7. Чухліб В.Є, Ведута Л.Л. Сучасні методи управління проектами. Сучасні підходи до управління підприємством. 2018. №. 3. С. 234-243.

8. Sutherland J. Agile Can Scale : Inventing and Reinventing SCRUM in Five Companies. Cutter IT Journal 14, № 12 (2001): рр. 5-11.

9. Sutherland J. Scrum : The Art of Doing Twice the Work in Half the Time / New York : Random House, 2014. 256 p.

10. Галушка В. Теоретико-методичні засади управління проєктами. / В. Галушка. – Підприємництво, господарство і право. 2020. № 7. С. 430–434

11. Смолич Д. В., Iнноваційні методи управління проектами. / Д. В. Смолич. – Економічний форум. 2019. № 4. С. 50–53.

Автор курсу - Огірко Ігор Васильович.