Гнучкі моделі управління командною роботою інжинірингових проектів

Размещено на http://www.allbest.ru/

Гнучкі моделі управління командною роботою інжинірингових проектів

В. Приймак, канд. екон. наук, доц.

Б. Корж, екон.

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

Ключові слова: гнучкі методи управління, Agile, Scrum, Kanban, проект, проектна команда, управління проектами.

управління інжиніринговий kanban

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

Дослідження актуальної проблеми формування адаптивної Agile-системи управління командною роботою зумовлено рядом факторів, зокрема [1, 11]: максиміза- ція продуктивності праці; оптимізація рівня самостійності та автономії командної роботи задля формування відчуття командної відповідальності за результат; зниження ймовірності впливу негативних ризиків командної роботи; прогнозування успішності досягнення кінцевого продукту; підвищення якості продукту та процесу його створення; прискорення операційних і логістичних біз- нес-процесів; реінжиніринг вітчизняних підприємств на інноваційний тип, орієнтованих на глобальний ринок (відповідно до євроінтеграційних процесів) згадно з інноваційно-інвестиційним кліматом тощо.

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

Аналіз останніх досліджень і публікацій. Гнучкі підходи почало формуватись у 30-х рр. ХХ ст., коли фізик і статистик Уолтер Шухарт із Лабораторії Белла почав застосовувати цикли PDCA (Plan-Do-Check-Act) для вдосконалення продуктів і процесів. Надалі У. Шухарт передав основи такої ітеративно-інкрементної розробки своєму учневі, Вільяму Демінгу, який популяризував модифікований метод PDSA (Plan-Do-Study-Act) під час відновлення Японії після Другої світової війни. Залучення Е. Демінга в організаційний процес виробництва компанії "Toyota" привело до створення особливої системи "Toyota Production System", що в подальшому стала базисом низки методологій, зокрема: бережливого управління (Lean Management), виробництва "точно в строк" (just-in-time, JIT), кайзен (Kaizen), загального обслуговування (Total Productive Maintenance, TPM), теорії обмежень (Theory of Constraints, TOC) тощо [6, 13].

Вивчаючи компанії, які лідирували на ринку інновацій і випереджали своїх конкурентів, було виявилено коман- дно-орієнтований підхід, який повністю змінював класичний процес розробки продукту. У цьому підході, замість класичної "естафети" з передачою товару за етапами від одного функціонального фахівця до іншого, застосовувався підхід командної роботи, коли кожен учасник постійно задіяний у процесі розробки продукту. Основною причиною еволюції зміни методології стали трансформації кожної високотехнологічної сфери. Із поширенням технології комп'ютерних обчислень, удосконалення аерокосмічних та автомобільних сфер, постало питання кардинальної зміни каскадної моделі управління проектними командами. У 1993 р. Джефф Сазерленд стикну- вся з доволі важким завданням: компанія "Easel Corporation", яка займалася розробкою програмного забезпечення (ПО), мала за шість місяців розробити абсолютно нову лінійку програмних продуктів, орієнтованих на великих клієнтів, таких, як "Ford Motor Company". Компанія "Easel Corporation" використовувала каскадну модель, яка полягала у фіксуванні матеріалу на гігантських діаграмах Г анта, де терміни виконання вимірювались по годинах, а етапи виконання мали різнокольоровий вигляд. Детально промальовані малюнки були дуже гарними, проте не мали ніякого сенсу. Тож, Джефф Сазерленд почав досліджувати питання щодо розробки нової системи управління командами. Під аналіз підпала стаття "The new product development game" Х. Такеучі та

І. Нонаки, де стверджувалось, що провідні кампанії світу (Honda, Fuji-Xerox, 3M) давно перейшли на паралельний процес розробки продукту [2, 7, 11]. Основною метою даного методу було надання автономності та свободи прийняття рішення самим учасникам команди, а завданнями керівництва були організаційна підтримка автономного й самокерованого функціонування проектних команд. Цей підхід виявився дуже ефективним, тому в 1995 р., у межах наукової конференції Асоціації обчислювальної техніки, Д. Сазерленд і К. Швабер представили доповідь "SCRUM Development Process", у якій прописали основні правила функціонування нового підходу [3, 7]. Проте в той час така система управління не набула широкого розповсюдження. Каскадна модель продовжила своє існування на багатьох високотехнологічних підприємствах. Дана проблема зібрала навколо себе однодумців (штат Юта, США, 2001), де офіційно (маніфест Agile) було зафіксовано основні постулати методології Agile [5, 15, 16]: головний базис - люди і взаємозв'язки, а не процеси та інструменти; дієвий продукт важливіший, аніж вичерпне документування; процес співробітництва із клієнтами є важливішим за обговорення умов контракту; готовність до змін пріоритет ніше, аніж чітке дотримання планів. На основі цих чотирьох постулатів почала розвиватись культура гнучких моделей функціонування проектних команд.

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

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

Результати. Гнучкими методами управління (Agile- менеджмент - концепція застосування підходів теорії складності до управління командною роботою із застосуванням гнучких методик: Rapid Application

Development (RAD), еволюційне управління розробкою (Evo), Scrum, розробка динамічних систем (DSDM), методи Crystal, екстремальне програмування (XP), керована розробка функціональністю (FDD), прагматичне і адаптивне проектування (2000) та інші [3, 8, 10, 14]). Проектними командами прийнято вважати технології, які орієнтовані на продукт та замовника і дозволяють виконати значні обсяги роботи з високою якістю за короткі терміни проектів. Традиційний каскадний підхід програє гнучким методам, оскільки вимагає значно більших затрат часу та ресурсів (табл. 1), тому зростає популярність Agile-методів.Таблиця 1. Порівняння гнучкої та каскадної методологій

Джерело: складено авторами.

13-й щорічний світовий звіт із імплементації Agile-методик проілюстрував основні причини переходу на Agile- методологію, зокрема [15-17]: прискорення роботи у сфері інформаційних технологій - 74 %, пріоритетна мобільність - 62 %, покращення стану ведення бізнесу - 50 %, підвищення якості програмного забезпечення та логістика - 43 %, удосконалення інженерної дисципліни - 23 %. Контраст порівняно з минулим роком показали такі причини: підвищення продуктивності праці (51 % порівняно з 55 % минулим роком), покращення морального стану команди (34 % порівняно із 28 %), зниження ризику проекту (28 % порівняно із 37 %) та зменшення витрат на проект (41 % порівняно із 24%). Водночас можна спостерігати, що поява та розвиток Agile-методологій у IT-сфері спричинило стрімке розповсюдження даних методик у суміжні сфери, що функціонують на основі проектних команд. Респонденти визначили найпопулярнішу Agile-методику - Scrum (54 %), проте такі методики, як Kanban та Lean Management отримали доволі малу частку у цьому дослідженні (відповідно 5 % та 2 %) [12, 15]. Scrum та Kanban є ефективними методами, однак між ними існують принципові відмінності як концептуальні (табл. 2) так процесні й технологічні.

Реалії вітчизняних інжинірингових компаній, що десятиліттями працюють за каскадною моделлю, використовуючи малоефективні у динамічному бізнес-середо- вищі діаграми Ганта, указують на можливі труднощі, з якими вони можуть стикнутися у радикальному переході до Agile-технології. Такі проблемні зони зумовлені як специфікою інжинірингової діяльності (інженерно- консультаційні послуги дослідного, проектно-конструкторського, розрахунково-аналітичного характеру, підготовка техніко-економічних обґрунтувань проектів, вироблення рекомендацій у сфері організації виробництва та управління, тобто комплекс комерційних послуг з підготовки та забезпечення процесу виробництва і реалізації продукції, у проектуванні, модернізації, обслуговуванні й експлуатації промислових, інфраструктур- них та інших об'єктів [4]), так і застарілі організаційно- управлінські підходи, зокрема: високий рівень бюрократизації, формалізації та документування; надмірний постійний контроль; значна кількість проектів, що ведуться однією командою одночасно; постійна плинність персоналу через відсутність належної системи винагороди та мотивування; надмірний вплив топ-менеджменту (адміністративно-командна диктатура) стосовно управління ресурсним забезпеченням, унаслідок чого між проектами створюється конкуренція за ресурси; значні витрати на стадії розробки та планування проекту; персонал звик працювати за встановленими правилами і не готовий адаптуватися під нові цілі; відсутність єдиного розуміння, що таке проектне управління інжиніринговими проектами; недосконалість методів та інструментів планування; відсутність делегування повноважень, достатнього рівня автономії та самокерованості проектних команд; відсутність інструменту для належного контролю якості; проблеми, пов'язані із завантаженістю як проектних команд, так і окремих співробітників, а також нераціональне використання робочого часу, що призводить до понаднормової роботи тощо.Таблиця 2. Порівняння Scrum та Kanban-методологій

Джерело: складено авторами.

Внаслідок унікального набору переваг і недоліків, специфіки основної діяльності та продуктів/послуг кожної окремо взятої інжинірингової компанії, доцільно всі підприємства сфери інжинірингових послуг згрупувати за критерієм рівня організаційної зрілості до провадження Agile-технологій (рівень організаційної зрілості можна визначити за допомогою [6, 8]: Organizational Project Management Maturity Model (OPM3); Project Management Maturity Model (PMMM) Г. Керцнера; Project Management Process Maturity Model (РМ2); Portfolio, Programme and Project Management Maturity Model (Р3М3) тощо) на: командно-орієнтовані (достатньо зрілі), зрілі (левова частка у сфері інжинірингових послуг), недостатньо зрілі (або початківці).

Так, для достатньо зрілих інжинірингових підприємств можна рекомендувати Scrum-метод, який ітера- ційно та інкрементно реалізується такими етапами (рис. 1) [3, 7]:

Етап 1. Визначення складу Scrum команди. Оптимальна кількість учасників - 5-9 осіб. Кожен член команди має володіти широким набором компетенцій та навичок задля активної допомоги один одному в процесі розробки продукту. Сама команда є відповідальною за кінцевий якісний продукт. Класичний Scrum має три основні ролі: Product Owner, Scrum Master, Development team. До обов'язків Scrum master входить організація нарад, контроль ефективності процесів, усунення перепон у період реалізації спрінта та мотивація учасників команди. Product Owner (PO) виконує роль посередника поміж командою та замовником. Завдання PO - максимальне збільшення цінності продукту роботи команди. Основним інструментом для цієї ролі у процесі Scrum є Product Backlog (PB) - список, що формується на початку проекту і включає задачі, які відсортовані у пріоритетному порядку.

Рис. 1. Гнучкі технології управління інжиніринговими проектами

Джерело: складено авторами.

Етап 2. Створення Product Backlog. За Майком Коном [11], кожен елемент беклогу має бути: описаний із відповідним рівнем деталізації (метод "набігаючої хвилі"), а саме: поточні елементи деталізовано описані з метою закінчення їх у найкоротші терміни, натомість віддалені елементи не потребують деталізації (горизонт планування визначається ситуативно); адекватно оцінений. З метою ефективного планування використовується система критеріїв і показників оцінювання як результатів, так і процесів їх досягнення ("метрики якості"), а також допустимі межі точності. У процесі розробки продукту відбуваються зміни самого беклогу, адже за допомогою прямого контакту із замовником інкрементно уточнюються його очікування і сподівання. Принцип ранжу- вання може визначатися відповідно до типу проекту чи очікувань/сподівань зацікавлених сторін (напр., максимі- зація цінності продукту). Обов'язковими елементами Product Backlog є спеціальні User Story, кожна з яких має спеціальний ідентифікаційний ID-код, та опис продукту за такими елементами: важливість (кількісний показник рівня важливості продукту на думку його власника); попередня оцінка (вимірюється у Story Point); спосіб демонстрації функціональності продукту. Окрім обов'язкових елементів РВ можуть бути додані додаткові, зокрема: категорійні, компонентні, дефектні тощо. Існує декілька варіантів створення Беклогу продукту: 1) один PO і один PB. PO розподіляє завдання з PB у порядку важливості і команди починають розбирати собі завдання у такому самому порядку. Розподіл зазвичай відбувається за тематикою (для цього зручно використовувати відповідну графу в PB); 2) один PO і декілька PB. Усе відбувається аналогічно, проте завдання для команди формує сам PO. Завдяки такому підходу підготовка і формування Sprint Backlog відбувається значно швидше; 3) два PO, що розробляють декілька PB (використовується для вузькоспеціалізованих модульних проектів, синтез модулів яких відбувається на завершальній стадії).

Етап 3. Планування спрінта і Sprint Backlog. На етапі планування необхідно визначити та оптимізувати тривалість спрінта шляхом усереднення обраних критичних значень (перевагами короткого спрінта є можливість швидкого фідбеку та виявлення помилок, проте довгі спрінти дозволяють більше заглибитись командам у процес створення продукту. В інжинірингових проектах рекомендується використовувати двотижневі спрінти) та визначити ролі проектної команди (кожен учасник команди виконує певну функцію. На Scrum Master покладено відповідальність за технічні та організаційні аспекти проведення зустрічей і забезпечення можливості команді зосередитись на найважливішому - плануванні та визначенні основних завдань). На цьому етапі виявляється взаємодія власника продукту (визначає пріоритет завдань) і Scrum-команди (визначення потреби у ресурсах). Водночас відбувається відбір за рівнем пріоритетності, елементів Product Backlog та переведення їх до Sprint Backlog (SB) відповідно до їх тривалості у Story Point. Набір SB формується таким чином, щоб кожна історія була успішно реалізована до кінця спрінту. При цьому необхідно дотримуватись принципу SMART (Specific, Measurable, Achievable, Realistic, and Timely Enough) - кожна виокремлена мета має бути специфічною, вимірюваною, реалістичною, обмеженою в часі та досяжною.

Етап 4. Процес розробки та робота над спрінтом. Кожного дня проводяться Stand-Up (до 15 хв), де обговорюються найважливіші аспекти процесу розробки продукту. Процес може розподілятися на три блоки: "Заплановано", "У процесі" і "Готово". Завдання спрінта переміщуються з одного блоку в інший у міру їх виконання. Результатом кожної наради є Burndown-діаг- рама (вісь X - дні роботи над спринтом, вісь Y - загальна кількість Story Points для даного спринта), що ві- зуалізує темпи роботи команди та дозволяє скоригу- вати кількість завдань наступного спрінта.

Етап 5. Тестування. Кінцева мета спрінта - бета-ве- рсія продукту, яка демонструється замовнику, з метою отримання швидкого фідбеку. Команда проекту має бути готова до конструктивної критики від замовника, що буде продемонстрована у процесі тестування.

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

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

Водночас, для недостатньо зрілих інжинірингових підприємств, існує більш адаптивна та "м'яка" для впровадження методологія Канбан, яка дозволяє поступово вводити в організаційну культуру та свідомість співробітників поняття "гнучкого управління". Операційний процес практично не координується, мало регламентується, і результат на 90 % залежить від команди, а не від менеджера. Необхідно зазначити, що Канбан-система не формує спеціальні команди з розподіленими ролями, над продуктом можуть працювати різні внутрішньофірмові структури, які володіють необхідними знаннями та практичними навичками [2]. Канбан-методика реалізується такими етапами [11]:

Етап 1. Розробка Product Backlog. Проектна команда формує РВ, при цьому відсутня окрема роль, відповідальна за формування набору задач.

Етап 2. Оптимізація і візуалізація. Завдання візуалі- зуються за допомогою спеціальної дошки (Jira, Trello, Hygger, Meister Task, Favro, Kanbanchi, Asana тощо) та розподіляються на три блоки: "Заплановано", "У процесі" і "Готово". Проте, на відміну від Scrum-методології, завдання обмежені у процесі виконання: за часом - виконання завдання (Lead Time) мінімізується; за процесом - виконання завдання оптимізується за критерієм макси- мізації прогнозованості успішності результату.

Етап 3. Виконання поставлених завдань. Досягнення результатів реалізується одним потоком, а політика процесу є достатньо формалізованою.

Організаційно зрілі інжинірингові компанії уже пройшли певний шлях щодо організування та управління командною роботою і зрозуміли, що процес реорганізації системи управління на засадах Agile-методології потребує певних організаційних зусиль, ресурсів та часу. Водночас, можливі організаційні бар'єри ефективного функціонування підприємства з командним типом роботи, зокрема небажання власників бізнесу, топ-менеджменту або співробітників організації сприйняти та імплементу- вати інноваційні принципи функціонування проектних команд. Тим самим існує певний супротив щодо зменшення рівня бюрократизації і підвищення рівня довіри та самостійності працівників. Проте основним бажаним результатом є підвищення якості продукції чи послуги; відсутність адаптивної системи поступового введення принципів функціонування гнучких команд (для впровадження Scrum-моделі необхідно визначити ролі Scrum Master та Product Owner. На початковому етапі існує потреба у запровадженні менторства або коучінгу з метою імплементації цих ролей у процес функціонування проектних команд); брак інформації щодо найкращих практик та ефективності впровадження гнучких методик у конкретній сфері діяльності (за винятком ІТ-сфери).

З метою уникнення такого роду перешкод та поступового впровадження гнучких методологій у систему управління на організаційно зрілих підприємствах сфери інжинірингових послуг (слід зазначити, що інжиніринговим підприємствам, як правило, притаманні проектно- орієнтовані організаційні структури) розроблено адаптивну модель Kanban-Scrum, яка дозволяє поступово переорієнтуватись із традиційної каскадної на Agile-модель управління командною роботою. Для цього, по-перше, необхідно сформулювати основні принципи комбінованої адаптивної моделі Kanban-Scrum, а саме: концептуальний базис моделі - маніфест Agile [5]; візуалізація (принцип є однаковим як для Scrum, так і Kanban, проте інтерпретація різна) - поступова імплементація ві- зуалізації процесів із використанням звичайних дошок з подальшою їх автоматизацією (рекомендовано ПЗ Jira або Trello, де можна розміщувати картки із завданнями на електронних дошках). У масштабних проектах дошок може бути декілька. По-друге, визначити організаційно- технологічну структуру моделі, яка ітераційно-інкремен- тно реалізується такими етапами (рис. 1) [3, 7]:

Етап 1. Ідентифікація проектної команди. Рекомендований склад команди (доцільно використовувати методику формування командних ролей за Белбіним

): Scrum Master, організатор процесу Kanban-Scrum (KS), інші фахівці відповідно до специфіки проекту. Проте роль Product Owner (із повноваженнями особи, що приймає рішення (ОПР)) відсутня на початкових ітераціях KS-процесу і поступово, за потребою чи відповідно до рівня організаційної зрілості підприємства, вводиться у проектну команду.

Етап 2. Створення Product Backlog. Команда проекту створює Product Backlog (функція поступово передається Product Owner відповідно до процедури його появи у команді проекту). З метою забезпечення "м'якої" системи контролю, рекомендовано використовувати спрі- нти з одиничним процесом внесення задач на початку періоду розробки (за умови постійного додавання задач рівень контролю виконання може суттєво змінюватись, проте, можуть бути певні винятки із правил). Так, при дискретному виробництві доречніше використовувати Канбан-метод із застосуванням принципу "Just-in-Time", а за умови розробки нового продукту/послуги - Scrum.

Етап 3. Планування спрінта. Специфіка запропонованої KS-методики полягає у процесі розподілу ролей у проектній команді. З метою адаптації вітчизняних інжинірингових компаній до концепції гнучкого управління необхідно врахувати особливості їх функціонування та ресурсного забезпечення, зокрема наявність вузькопрофільних спеціалістів, що виконують обмежений спектр функцій. Оскільки у рамках методології Scrum кожен член команди має володіти широким набором компетентностей та виконувати перехресні ролі, це може стати психологічним бар'єром на етапі впровадження Agile-технологій. Тому доцільно використовувати принципи Канбан, де кожен член проектної команди може виконувати обмежену кількість завдань, при цьому вибір завдань він здійснює самостійно. Тому на початковому етапі під час спрінта за кожним учасником закріплюється обрана конкретна роль. Водночас, даний підхід передбачає певний рівень автономії та са- мокерованості команди проекту при прийняття рішень, за винятком часових обмежень спрінта (2-3 тижні).

Етап 4. Виконання спрінта. Протягом фіксованого періоду часу (2-3 тижні) завдання проходять через певні стани: "Заплановано", "У процесі" і "Готово". Проте можливість змінювати завдання на попередніх етапах імплементації KS-методики є обмеженою, адже відповідальність за кожне завдання протягом спрінта покладено на конкретного працівника. Кожного дня має проводитись Stand-Up з метою інформування про стан виконання завдання і труднощів під час його виконання (у Scrum - допомога у вирішенні проблем/відхилень). Одночасно рекомендовано використовувати Burndown-діаграму протягом кожного спрінта.

Етап 5. Тестування та Етап 6. Ретроспективний аналіз та планування наступного спрінта. Етапи є аналогічними до Scrum-методології. При цьому, за взаємодію із зацікавленими сторонами на попередніх етапах введення KS-методики відповідає Scrum Master.

Висновки

Однією із причин переходу із традиційних на гнучкі моделі управління проектними командами є орієнтація останніх на продукт та людей, а не на необхідність високого ступеня документації процесу розробки. Загалом, одним із ключових критеріїв ефективної роботи проектної команди є постійна комунікація із зацікавленими сторонами, автономія та самокерованість при прийнятті рішень у процесі виконання окремого завдання. Водночас, в останні десятиліття Agile-технології стали доволі популярними та поширеними в усьому світі. Проте вітчизняні компанії ще й досі застосовують традиційну малоефективну високоформалізовану модель управління проектними командами. Основними причинами небажання імплементації гнучких моделей є: супротив у процесі зменшення рівня бюрократизації і підвищення рівня довіри та самостійності працівників; брак інформації на вітчизняному ринку щодо ефективності впровадження гнучких методів; відсутність адаптивної технології поступового впровадження гнучких принципів функціонування проектних команд. Зважаючи на це, розроблено комбіновану гнучку технологію, що поєднує поступову імплементацію Agile-методології та адаптивний підхід до впровадження принципів командної роботи. Зокрема, виокремлено першочергову необхідність вибору Scrum Master із організаційно-розширеними рольовими функціями (додано повноваження Product Owner, який комунікує із замовником). Основною рушійною силою при виконанні конкретного завдання виступає проектна команда на чолі зі Scrum Master (на відміну від традиційної Scrum-методології, адаптивна Scrum-Kanban-техно- логії направлена на надання проектній команді самостійності та автономії). На наступних ітераціях упровадження Scrum-Kanban-технології поступово формуватиметься уявлення про роль Product Owner, який надалі матиме інкрементний спектр повноважень (виокремлення завдань беклогу продукту; високий рівень взаємодії із клієнтом тощо). У процесі розробки першого продукту на основі гнучких методологій можуть самостійно виокремлюватись суб'єкти процесу, що матимуть змогу надалі зайняти роль Product Owner. При цьому вибір завдань залишатиметься за командою проекту, які матимуть змогу встановити певні обмеження та конкретизувати завдання на початкових етапах упровадження гнучкої методології з метою чіткого контролю процесу розробки продукту. Ідея щоденного моніторингу у вигляді 15-хвилинного Stand-Up залишається незмінною, як і в методі Scrum. Задля усвідомлення доречності власних дій та рішень необхідно імплементувати принцип самоаналізу в процес розробки продукту. Використання Burndown діаграми є необхідною складовою для усвідомлення об'єму виконаної роботи. Тестування продукту закріпляється за обов'язками Scrum Master і відбувається на основі взаємодії із замовником продукту. Останній етап - ретроспективний аналіз та планування наступного спрінта здійснює команда проекту, яка й надалі працюватиме з проектом самостійно.

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

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

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

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

Pryimak V. Teambuilding: synergy of team work. Менеджмент XXI століття: глобалізаційні виклики: моногр. / V. Pryimak, I. Faichak. - Полтава: вид-во "Сімок", 2017. - 728 с.

Приймак В. М. Управління знаннями : підруч. / В. М. Приймак. - Київ : КНУ імені Тараса Шевченка, 2019. - 240 с.

Вольфсон Б. Гибкое управление проектами и продуктами / Б. Вольфсон. - СПб.: Питер, 2015. - 144 с.

Лоренц В. Даешь инжиниринг! Методология организации проектного бизнеса / В. Лоренц, В. Кондратьев. - Изд. 2-е, перероб. и доп. - М.: ЭКСМО, 2007. - 568 с.

Плескач В. Л. Інформаційні системи і технології на підприємствах / В. Л. Плескач, Т. Г. Затонацька. - Київ: Знання, 2011. - 718 с.

Приймак В. М. Управління проектами: навч. посіб. / В. М. Приймак. - Київ: КНУ імені Тараса Шевченка, 2017- 465 с.

Сазерленд, Дж. Scrum. Революційний метод управління проектами / Дж. Сазерленд. - Москва: Манн, 2016. - 288 с.

A Guide to the Project Management Body of Knowledge (PMBOK Guide). Agile Practice Guide. Sixth edition. Newtown Square, PA: Project Management Institute. 2017. - 800 p.

Belbin R. M. Team Roles at Work. / R. М. Belbin. - USA : Routledge; 2nd Revised edition, 2010. - 168 p.

Jurgen Appelo Management 3.0. Leading Agile Developers, Developing Agile Leaders. Addison-Wesley Professional. 2011. - 464 p.

Кон М. Succeeding with Agile: Software Development Using Scrum

[Електронний ресурс]. - Режим доступу: https://www.ozon.ru/

context/detail/id/4844907.

Пушкарев А. Гибкая методология разработки "Scrum" / А. Пушкарев [Електронний ресурс]. - Режим доступу: https://habrahabr.ru/ post/247319.

Сазерленд Дж. Авторитетний посібник зі Скраму: Правила Гри // Дж. Сазерленд, К. Швабер [Електронний ресурс] - Режим доступу: http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide- UA.pdf.

Эффективный Kanban: мифы и реальность [Електронний ресурс]. - Режим доступу: https: //habrahabr.ru/company/scrumtrek/blog/292914.

Електронний ресурс. URL: http://www.agilemanifesto.org/iso/ru/ principles.html.

Agile Alliance [Електронний ресурс]. - Режим доступу: https://www.agilealliance.org.

13th Annual State of Agile [Електронний ресурс]. - Режим доступу: https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-

agile-report/473508.

References (in Latin): Translation / Transliteration / Transcription:

Pryimak V., Faichak I. 2017. Teambuilding: synergy of team work. XXI Century Management: Globalization Challenges, 728 p.

Pryimak, V. 2019. Knowledge management: textbook. Kyiv, 240 p.

Wolfson, B., 2015. Flexible project and product management. Saint Petersburg, 144 p.

Lorenz, V., 2007. You give engineering! Methodology of project business organization. 2nd ed. Moscow, 568 p.

Pleskach, V., 2011. Information systems and technologies at enterprises. Kiev, 718 p.

Pryimak, V., 2017. Project Management: Textbook. Kyiv, 465 p.

Sutherland, J., 2016. Scrum. Revolutionary Project Management Method. Moscow, 288 p.,

A Guide to the Project Management Body of Knowledge (PMBOK Guide). Agile Practice Guide. Sixth edition. Newtown Square, PA: Project Management Institute. 2017. 800 р.

Belbin R.M. 2010. Team Roles at Work. USA: Routledge; 2nd Revised edition, 168 p.

Jurgen Appelo Management 3.0. Leading Agile Developers, Developing Agile Leaders. Addison-Wesley Professional. 2011.464 p.

Kon, M. 2012. Succeeding with Agile: Software Development Using Scrum. Available through: ARU Library website <https://www.ozon.ru/context/detail/id/4844907/> [Accessed 2012].

Pushkarev, A. Flexible Scrum Methodology. Available through: https://habrahabr.ru/post/247319/ [Accessed 2018].

Sutherland, J., Schwaber K. 2009. Authoritative Guide to Scram: The Rules of the Game. Available through: http: //www. scrumguides. org/docs/scrumguide/ v 1 /Scrum-Guide- UA.pdf [Accessed 2012].

Effective Kanban: Myths and Reality [online] Available at: <https: //habrahabr.ru/company/scrumtrek/blog/292914//> [Accessed 2016].

Agile Manifesto [online] Available at: <http://www.agilemanifesto.org/iso/ru/ principles.html> [Accessed 2007].

Agile Alliance [online] Available at: <https://www.agilealliance.org> [Accessed 2004].

13th Annual [online] Available at: <https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508> [Accessed 2018].

Размещено на Allbest.ru