Проскурін М. В. Специфіка контрактів у гібридній методології управління проектами // Міжнародний науковий журнал "Інтернаука". — 2018. — №14. https://doi.org/10.25313/2520-2057-2018-14-4107
Економіка
УДК 005.8:316.422
Проскурін Максим Вадимович
магістр
Київського національного університету імені Тараса Шевченко
Проскурин Максим Вадимович
магистр
Киевского национального университета имени Тараса Шевченко
Proskurin Maksym
Master's Degree of the
Taras Shevchenko National University of Kyiv
СПЕЦИФІКА КОНТРАКТІВ У ГІБРИДНІЙ МЕТОДОЛОГІЇ УПРАВЛІННЯ ПРОЕКТАМИ
СПЕЦИФИКА КОНТРАКТОВ В ГИБРИДНОЙ МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИ
SPECIFICITY OF CONTRACTS IN THE HYBRID METHODOLOGY OF PROJECT MANAGEMENT
Анотація. За весь час існування проектного менеджменту, було розроблено величезну кількість різних методологій і стандартів з управління проектами. Два основних напрямки – це традиційні водоспадні моделі і гнучкі методології. Також ці напрямки сформували два основні підходи до документації, а саме контракти з «жорстко фіксованим бюджетом» і «оплатою за фактом». Актуальність даної роботи полягає в необхідності вдосконалення методології управління проектами з урахуванням вимог сучасної глобальної економіки, заснованої на знаннях і принципах сталого розвитку. У статті описані основні принципи гібридної методології управління проектами, проведено аналітичний огляд існуючих контрактів в галузі управління проектами, а також проаналізувати можливість використання Agile-контрактів для гібридної методології.
Ключові слова: управління проектами, гнучкі методології, водоспадна модель, контракти з жорстко фіксованим бюджетом, контракти з оплатою за фактом, гібридна методологія.
Аннотация. За все время существования проектного менеджмента, было разработано огромное количество различных методологий и стандартов по управлению проектами. Два основных направления - это традиционные водопадные модели и гибкие методологии. Также эти направления сформировали два основных подхода к документации, а именно контракты с «жестко фиксированным бюджетом» и «оплатой по факту». Актуальность данной работы заключается в необходимости совершенствования методологии управления проектами с учетом требований современной глобальной экономики, основанной на знаниях и принципах устойчивого развития. В статье описаны основные принципы гибридной методологии управления проектами, проведения аналитический обзор существующих контрактов в области управления проектами, а также проанализировать возможность использования Agile-контрактов для гибридной методологии.
Ключевые слова: управление проектами, гибкие методологии, каскадная модель, контракты с жестко фиксированным бюджетом, контракты с оплатой по факту, гибридная методология.
Summary. During all time of project management existence, a huge number of different methodologies and standards for project management have been developed. The two main areas are traditional waterfall models and flexible methodologies. Also, these areas have formed two main approaches to documentation, namely, contracts with a "rigidly fixed budget" and "payment by fact". The urgency of this work is the need to improve the methodology of project management, taking into account the requirements of the modern global economy, based on the knowledge and principles of sustainable development. The paper describes the main principles of the hybrid project management methodology, analyzes the existing contracts in the field of project management, and analyzes the possibility of using Agile contracts for the hybrid methodology.
Key words: project management, flexible methodology, waterfall model, strictly fixed budget contracts, pay-as-you-buy contracts, hybrid methodology.
Аналіз останніх досліджень і публікацій. Початок наукового дослідження феномену гібридних методологій управління проектами було покладено у 1990-і рр. Багато наукові діячі в своїх працях розглядали дану проблематику. Наприклад, Джина Лідж [4] вважає, що у кожної з методологій є свої переваги, до того ж вони часто вважаються взаємовиключними. Але все ж деякі елементи обох методологій можуть бути об'єднані в єдиний процес для отримання кращих результатів. На думку Кейтлін Хасс [5], як у класичній методології, так і в гнучкій, в основі лежить основний принцип – задоволення потреб клієнта. Суть полягає в управлінні командою, в наданні вимірюваних результатів. Так само як і Джина Лідж вважає, що поєднання двох методологій може привести до найкращих результатів. Scaled Agile Framework (SAFe) - принцип Agile-розробки, розроблений Scaled Agile Inc., який є базою знань щодо реалізації ощадливої Agile-розробки в корпоративних масштабах, вперше був представлений у статті "Agile Contracts - Scaled Agile Framework" [2].
Мета – сформувати уявлення про гібридну методологію управління проектами, розглянути переваги та недоліки звичайних контрактів, а також розглянути перспективи застосування гібридних контрактів.
Формулювання цілей статті (постановка завдання). Описати основні принципи гібридної методології управління проектами. Провести аналітичний огляд існуючих контрактів в галузі управління проектами, а також проаналізувати можливість використання Agile-контрактів для гібридної методології.
Виклад основного матеріалу. Гібридна методологія за «Маніфестом гібридної методології управління проектами» [6] об'єднує водоспадні і Agile-методи, щоб створити новий метод управління проектами. Ця методологія використовує ретельність Work Breakdown Structure (WBS) зі швидкістю Agile для нового методу управління проектами, який є одночасно детальним і швидким. Більшість проектів відчують позитивний вплив від використання гібридного методу керування проектами. Тільки дуже невеликі проекти не вимагають гібридного методу.
Керівні принципи [1] гібридної методології:
Традиційно вимоги до продукту узгоджувалися заздалегідь, щоб переконатися, що клієнт отримає саме те, що хоче, і це було основою для укладення контракту. Але такі вимоги і архітектурні рішення обмежували розробників урізали їх можливості та гнучкість по відношенню до нової інформації, що надходила та могла б допомогти їм спроектувати більш грамотне рішення з точки зору економіки і приносить клієнту конкурентні переваги, бо їх стримував контракт.
Спроба керувати ризиками за рахунок докладного опису вимог на ранньому етапі мала зворотний ефект і приводила до втрат у ключових учасників проекту.
Щоб уникнути цієї проблеми, на зміну традиційному прийшов новий підхід, в якому учасники проекту поділяли загальні ризики і успіхи і в підсумку працювали краще в багатьох аспектах. Але навіть при такому підході звичне мислення в термінах фіксованих вимог найчастіше впливало на домовленості і очікування сторін.
І що дійсно було потрібно, так це більш гнучкий (Agile) [7] підхід до контрактів, в якому обидві сторони отримують вигоду як в найближчій, так і в довгостроковій перспективі.
Великі компанії використовують кілька підходів в роботі зі сторонніми вендорами, у яких вони замовляють складне програмне забезпечення. Зазвичай ці підходи варіюються між «жорстко фіксованим бюджетом» (Fixed Price) і «оплатою за фактом» (Time & Material), а також варіаціями, що знаходяться між цими крайнощами.
На лівій межі шкали знаходяться популярні контракти з жорстко фіксованим бюджетом. Зручність цього підходу полягає в припущенні, що клієнт отримає рівно те, що хоче, і готовий за це заплатити. Контракти з жорстко фіксованим бюджетом створюють «залізний трикутник», який складається з вимог замовника, заздалегідь визначених термінів та фіксованої вартості.
На перший погляд підхід виглядає логічним. До того ж він надає можливість оцінювати тендерні заявки, що затребуване і потенційно вигідно, так як контракт буде укладений з самим компетентним і ефективним постачальником. Однак цей підхід має суттєві недоліки:
Він передбачає, що потреби клієнта добре відомі задовго до впровадження рішення. Ці потреби повинні бути відображені в специфікації вимог і проект рішення, що призводить до необхідності детального проектування до початку розробки (BUFD, Big Design Up Front), каскадної моделі розробки та відповідної контрактної моделі.
Контракт зазвичай підписується з постачальником, що обіцяє найменшу вартість. Це може принести, а може і не принести покупцеві максимальну економічну вигоду в довгостроковій перспективі.
Крім того, щоб отримати фіксовану ціну, багато критичні рішення приймаються, коли проект ще знаходиться на ранньому етапі в конусі невизначеності.
Сторони зв'язали себе «залізним трикутником» фіксованого обсягу робіт, термінами і вартістю проекту. Але з часом обставини змінюються, а клієнт і постачальник виявляються міцно пов'язаними контрактом, де детально прописано рішення, яке вже ніхто не хоче ні впроваджувати, ні купувати. Тому решту часу боку витрачають на обговорення і узгодження змін в контракті, що призводить до великих втрат. Але найгірше те, що в момент підписання такого контракту економічні інтереси сторін стають протилежними:
Клієнт зацікавлений в тому, щоб отримати від постачальника якомога більше за якомога менші гроші.
Постачальник зацікавлений в тому, щоб поставити мінімальний функціонал, що задовольняє умовам контракту.
В результаті такий тип контракту часто встановлює між клієнтом і постачальником відносини «переможець-переможений», що впливає на подальші взаємини сторін і в кінцевому рахунку шкодить кожної з них.
Зрозуміло, чому багато в індустрії хочуть рухатися в праву сторону спектра. Але права межа, що представляє «оплату за фактом», яка з першого погляду може здатися виключно гнучкою і відповідної методології Agile, теж приховує в собі складності. Клієнт в даному випадку може розраховувати тільки на свою власну довіру. Довіра, безумовно, дуже цінна, і ми спираємося на неї в методології економною розробки (Lean), але в моменти непорозуміння між сторонами, змін на ринку або технічних умов, а також економічних моделей у клієнта або постачальника довіру можуть відсунути на задній план.
Плюс будь-який постачальник зацікавлений, щоб йому платили якомога довше. І це може розтягувати контракти на більш довгий термін, ніж це реально потрібно. Зв'язування цього підходу з процесом приймання по етапах (погодження розбіжностей між вимогами, проектування і т. д.), Де реальний прогрес стає зрозумілий тільки в кінці, посилює проблему.
Складнощі можуть виникнути і на стороні замовника. Наприклад, в ході розбору польотів за результатами провального проекту Стівен В. Уоррен відповідальний виконавець і директор з інформаційних технологій в департаменті у справах ветеранів США, зазначив, що, за словами керівника проекту, проект ніколи не був в кризі, так як кожен рік вони повністю витрачали свій бюджет, що дозволяло їм зберігати фінансування на наступний рік. Критерієм успішності для них було те, чи будуть вони продовжувати отримувати фінансування, а не те, чи будуть вони здатні поставити необхідний функціонал [3].
Такий тип Agile-контракту потенційно дозволяє:
З огляду на все сказане вище, індустрія може отримати більше, рухаючись в сторону контрактів, які наслідують Agile парадигму, коли контракт приносить економічну вигоду як замовнику, так і постачальникам системи.
Конструкція Lean-Aglie в SAFe пропонує один з таких підходів для подібних ситуацій - контракт з керованими інвестиціями на основі підходу SAFe. Перед інвестуванням істотних коштів в розробку складної системи з великим числом невідомих потрібне проведення попереднього аудиту та оцінки. На цьому етапі клієнт і постачальник працюють разом, щоб прийти до згоди щодо основи договору (Рис.1).
Рис. 1. Фаза попередніх угод для контракту з керованими інвестиціями на основі підходу SAFe
Прим. ред. Program Increment, PI або інкремент програми - це часовий інтервал, за який програма поставляє інкремент цінності у вигляді працюючих і протестованих програмного забезпечення і систем. Зазвичай триває від 8 до 12 тижнів.
В ідеалі на цьому етапі клієнтові потрібно донести до постачальника (або потенційних постачальників) глобальні цілі (місію) програми.
Постачальник теж робить свою частину попередньої роботи. Вона часто включає первинний аналіз здійсненності проекту, а також вирівнювання вимог, що диктуються рішенням з наявними у постачальника ключовими компетенціями. Крім того, необхідно розуміння потенційного обсягу ресурсів, який буде потрібно на початкових етапах проекту, і, можливо, навіть груба оцінка загальної трудомісткості. Однак подібні зобов'язання, в основному, є типовими для виконавців, і для більшої частини робіт можуть бути використані припущення на підставі попереднього досвіду.
Загальна ж відповідальність (в центрі) призводить клієнта і постачальника на шлях керованих інвестицій, підтримуваних безперервними доказами відповідності поставляється рішення вимогам клієнта. Відповідальність управлінського персоналу охоплює:
Що стосується інкрементального фінансування, від постачальника може знадобитися надання попередньої оцінки загальної вартості проекту. В інших же випадках може бути застосований підхід з оплатою по факту. Тоді на підставі домовленостей клієнт здійснює оплату постачальнику за перші інкремент програми по фіксованій ставці. Це характерно для періоду попередніх угод. Довжина цього періоду залежить від контексту, проте перші два інкремента (орієнтовно близько 20 тижнів) можуть бути розумною точкою для старту.
Залежно від контексту клієнт може проводити подібні обговорення паралельно з декількома потенційними постачальниками. Якщо проект вимагає серйозного аналізу технічної можливості бути реалізованим, подібні роботи можуть бути винесені в окремий контракт, за яким постачальник отримує компенсацію за зусилля, витрачені перед підписанням основного договору. Альтернативно подібні витрати можуть бути списані як звичайний етап попереднього продажу, що є частою практикою для постачальників програмного забезпечення.
Однак в якийсь момент клієнт все-таки може перейти до укладення основного контракту, а далі починається безпосередньо розробка (Рис.2).
Рис. 2. Виконання контракту з керованими інвестиціями по основі підходу SAFe
Цей процес триває до того часу, поки поставлений продукт не буде забезпечувати цінність, необхідну клієнтом, і, як тільки це сталося, клієнт починає згортати фінансування відповідно до домовленостей з постачальником.
Висновки. Описати основні принципи гібридної методології управління проектами. Провести аналітичний огляд існуючих контрактів в галузі управління проектами, а також проаналізувати можливість використання Agile-контрактів для гібридної методології.
Загалом, Agile-контракти можна застосовувати в гібридній методології, цей підхід складніше, вимагає більших навичок та згуртованості команди, але це може дати кращий рівень управління проектами та якісний результат.
Література
