Можливо ви бачили вивіску у авто-майстерні: «Що вам потрібно: якість, швидкість чи дешевизна? Обирайте два з трьох». Попри всю жартівливість напису, його мудрість є підтвердженням компромісу. У нашому прикладі ви не отримаєте кожний бажаний параметр оптимальним.
Поняття такого «потрійного обмеження» або «залізного трикутника» з’являється при управлінні проектом. Проблема полягає у тому, що я бачив численні зображення трикутника з різніми параметрами – розмір, вартість, час або функція – з численними припущеннями, щодо того, що має лишатися незмінним. У визначенні класичного трикутника якість не зазначається явно. Чи означає це, що критерій якості – це очікування, яке не потребує обговорення, або що ймовірніше, ви отримаєте ту якість, яка може бути досягнута командою в рамках обмежень, які створюють інші параметри? На мій погляд, традиційне потрійне обмеження є хибним, але концепція обмежень і компромісів, безумовно, справедлива.
П’ять вимірів
Думаю, що ми маємо керувати проектами з точки зору п’яти вимірів (Рис. 1, адаптовано зі «Створюючи культуру інженерії програмного забезпечення»). По-перше, звісно, властивості (функції), які описують функціональні можливості продукту. Але важливим є відрізняти якість від функції. Я можу написати програмне забезпечення дуже швидко, якщо воно не повинно працювати правильно. Інші три виміри – час, який у нас є перед поставкою (графік), бюджет проекту (вартість) і персонал доступний для роботи на проекті.
Рис 1. П’ять вимірів проекту програмного забезпечення
Я не об’єдную персонал (або команду) і бюджет разом, називаючи це ресурсами, як це інколи робиться. Велика частина вартості проекту – це, дійсно, заробітна плата персоналу. Однак, я бачив ситуації, коли команда мала належне фінансування, але не могла найняти додатковий персонал. У такому випадку, можливо, проектний менеджер може використовувати наявні гроші різними способами, наприклад, аутсорсинг деяких задач, покупка автоматизованих тестових інструментів або залучення підрядників.
Для кожного проекту ми маємо визначити, які виміри є найважливіші та як збалансувати інші задля досягнення ключових цілей проекту. Компроміси між цими п’ятьма вимірами не такі прості і лінійні. Наприклад, якщо ви розширите персонал, терміни можуть скоротитися (хоча і не обов’язково) і вартість цілком може зрости. Поширений, але невдалий компроміс полягає у скороченні термінів або додаванні функцій, жертвуючи при цьому якістю. Кожен, хто ставав жертвою глючного програмного забезпечення, ставить під сумнів такі компромісні рішення, але вони існують.
Кожен із цих п’яти вимірів може виконувати одну з трьох ролей у будь-якому конкретному проекті: обмеження, рушійна сила або ступінь свободи. Обмеження визначають лімити, в рамках яких повинен працювати проектний менеджер. Гнучкість проектного менеджера обмежена дією цих лімітів. Якщо за проектом закріплена команда незмінно фіксованого розміру, персонал стає обмеженням. Вартість – це обмеження для проектів, що мають контракт з фіксованою ціною (принаймні з точки зору клієнта). Якість стане обмеженням для проекту по розробці програмного забезпечення для медичних пристроїв або для системи авіоніки літаків. Проекти перекодування дат були обмежені термінами виконання.
Рушійна сила – ключова мета або критерій успіху проекту. Для продуктів з бажаними маркетинговими можливостями, терміни – це рушійна сила. Часто для комерційних десктопних застосунків функції є рушійною силою. Проектний менеджер має невелику гнучкість щодо рушіної сили. Зазначений набір функцій може бути основною рушійною силою проекта, але функції – це обмеження, якщо набір функцій не підлягає обговоренню.
Будь-який вимір проекту, що не є ані рушійною силою, ані обмеженням є ступінню свободи. На цей фактор проектний менеджер має вплив у певних межах. Отже, задача менеджера – відрегулювати ступінь свободи задля того, щоб добитися успішного розвитку у межах, встановлених обмеженнями. Припустимо, що на якомусь проекті корпоративної інформаційної системи рушійною силою є функції і якість, а персонал є обмеженням, так ступені свободи стають графіками та вартістю. Наслідком для цього профілю є те, що всі функції, які вимагає клієнт, будуть додані, але час поставки продукту може бути відтермінований і вартість проекта може зрости в порівнянні з плановою.
У мене погана новина: проект з нульовим ступенем свободи, швидше за все, провалиться. Всі п’ять вимірів не можуть бути обмеженнями, і всі вони не можуть бути рушійною силою. Для досягнення ключових цілей необхідно щось віддати. За відсутністю ступенів свободи, перша ж додаткова вимога, перший же член команди, який захворів, перший ризик, який перетвориться на проблему, зруйнує графік, оскільки у проектного менеджера немає гнучкості, щоб відреагувати на ці зміни.
На курсі з проджект менеджменту, де я був викладачем, один студент якось сказав: «Наш проект має фіксований бюджет, ми не можемо більше додавати людей, всі функціх критичні, не можемо допустити жодних дефектів і ми повинні завершити вчасно». Той проект навряд чи був успішним.
Узгодження пріоритетів
Важливим аспектом цієї моделі є не те, які з п’яти вимірів є рушійними силами чи обмеженнями будь-якого проекту, а те щоб відносні пріорітети вимірів були заздалегідь обговорені проектною командою, клієнтами та менеджментом. Такий переговорний процес допомагає визначити правила і межі проекту. Наприклад, графік часто подається як обмеження, коли, насправді, це рушійна сила. Спосіб показати різницю, це запитати: «Гаразд, ви хочете, щоб це було доставлено 30 червня. Що трапиться, якщо це не буде зроблене до, скажімо, 14 липня?» Якщо відповідь – щось типу це не буде корисним для нас або на нас будуть накладені урядові або клієнтські штафні санкції, тоді так, розклад, справді – обмеження. Проте, якщо відповідь: «Ми б точно хотіли, щоб це було до 30 червня, але ми не помремо, якщо почекаємо ще пару тижнів», тоді графік – це рушійна сила. Якщо вимір має певну гнучкість, тоді він не обмеження. Невеличка гнучкість робить його рушійною силою, а велика – ступенем свободи.
Я би хотів проілюструвати як ідея п’яти вимірів працює на практиці. Якось я почув розмову між старшим менеджером і проектним менеджером про новий проект. Старший менеджер спитав:
– Яка тривалість проекту?
– Два роки, відповів проектний менеджер.
– Це занадто довго. У мене є шість місяців.
Знаєте, що відповів проектний менеджер? Він сказав: «Окей».
Що змінилося за ці кілька секунд? Нічого! Проект не скоротився в чотири рази, команда не стала в чотири рази більшою як і не стала, магічним чином, в чотири рази продуктивніше. Проектний менеджер просто сказав те, що хотів почути старший менеджер. (До речі, реалізація проекту тривала більше двох років).
Як по-іншому міг відповісти проектний менеджер замість того, щоб просто сказати «Окей»? Давайте розглянемо п’ять вимірів. Можливо, він міг би запитати, яка частина продукту однозночно повинна бути доставлена протягом цих пів року. Тобто, чи можемо ми скоротити функції у першому релізі? Проектний менеджер міг піддати сумніву таку тривалість проекту спитавши: «Що такого життєво необхідного в цих пів року?». Можливо, ця система замінює застарілу, що працює на антикварному комп’ютері і вони приберуть той комп’ютер з будівлі за пів року. Добре, це вагома причина. Або, можливо, немає нічого магічного у цих шести місяцях, але ми розуміємо, що є сильне бажання швидко запустити систему. У такому випадку, шестимісяцний термін – це рушійна сила, а не обмеження.
Ви можете аналізувати далі по списку з п’яти атрибутів. Чи можу я отримати більше людей чи більше грошей? Чи має програмне забезпечення працювати? Деякі організації дотримуються дат запланованих релізів, щоправда з серйозними порушеннями у функціональності і багатьма багами. Тим не менш, вони заявляють про перемогу та стверджують, що вони вклалися в графіки, навіть якщо те, що вони видали, не було корисним. Це просто маленька гра в яку вони грають. Обдумування цих п’яти вимірів – це кращий шлях зрозуміти пріорітети вашого проекту замість простого припущення, що кожний аспект проекту є критичним і не підлягає обговоренню.
Діаграми гнучкості
Візуально зобразити ступень гнучкості можна за допомогою діаграми Ківіата, яку також називають радарною діаграмою чи діаграмою-павуком. (Рис. 2). На діаграмі Ківіата ви зображуєте п’ять вимірів у колі і малюєте окрему вісь для кожного виміру, що виходить із загальної початкової точки в центрі. Всі осі мають однакову довжину та нормалізовані в одному масштабі. Кожна вісь показує якою гнучкістю володіє проектний менеджер у відповідному вимірі, тому я називаю ці малюнки «діаграмами гнучкості». Я використовую відносну шкалу від нуля до десяти для гнучкості. Нуль не показано в точному центрі початку координат, лише для зручності малювання графіка.
Рисунок 2. Діаграма гнучкості корпоративної інформаційної системи.
Нанесення точки на нуль вказує на те, що розмір для цієї осі є обмеженням без гнучкості. Якщо ви відкладаєте точку досить низько на осі, між нулем і двома або приблизно, це буде рушійною силою. Це показує, що проектний менеджер має маленьку гнучкість у цьому вимірі. Будь-який вимір означений на вищому рівні по його осі, показує ступінь свободи доступний для коригування. Якщо ви з’єднаєте п’ять точок п’яти вимірів, які ви накреслили, то отримаєте п’ятикутник неправильної форми, який візуалізує один профіль характеристик проекту.
На рисунку 2 показана діаграма гнучкості для інформаційної системи, яку колись розробила моя команда. Цей проект мав фіксований розмір команди, тому значення, відкладене на осі персоналу, дорівнює нулю і є обмеженням. Проект мав на меті бажану, але не критичну дату доставки, тому точка на осі розкладу також має невелике значення. Проект мав різний рівень гнучкості щодо функцій першого випуску, якості продукту та можливості перевитрат. Тому значення для цих ступенів свободи відкладені вище на відповідних осях.\
Зауважте, це не інструмент з високою роздільною здатністю або кількісний інструмент. Ми не збираємося обчислювати площу п’ятикутника чи щось таке. Але розмір п’ятикутника дає приблизне розуміння з яким рівнем гнучкості повинен працювати проектний менеджер. Якщо п’ятикутник невеликий, це означає, що у вас є численні обмеження або рушійні сили, через які керівнику проекту буде складніше прокласти шлях до успіху.
Різні типи проектів утворять дуже різні за формою діаграми гнучкості. На рисунку 3 діаграма гнучкості проекту, для якого якість є рушійною силою, а на осі графіка відкладене найбільше значення. Таке ви б побачили для продукту, розробленого для використання у середовищі з підвищеним ризиком. Зауважте, що ця діаграма не показує жодних обмежень; на жодній з осей не встановлене нульове значення. Добре. На відміну, профіль для комерційного програмного продукту у висококонкурентному середовищі може виглядати так, як показано на рисунку 4, у який має бути включений певний набір функцій (обмеження), графік обмежено визначеною датою доставки, а якість така, яка вийде.
Рисунок 3. Діаграма гнучкості для застосунку, орієнтованого на якість.
Рисунок 4. Діаграма гнучкості для конкурентного комерційного застосунку.
Форми п’ятикутників у цих прикладах візуально вказують на важливі аспекти кожного проекту. Якщо ви посунете точку на одній із осей усередину, щоб зменшити широту, яку має проектний менеджер в одному вимірі, вам, як правило, для компенсації, доведеться перелаштувати і інші виміри. Ви можете використовувати цей вид аналізу для поінформування керівництва про компроміси та рішення, які вони повинні прийняти, щоб досягти ключові цілі проекту, а також узгодити реалістично досяжні зобов’язання щодо кожного проекту.
Таблиця гнучкості
Ви також можете задокументувати пріоритети свого проекту у формі таблиці гнучкості, як показано на рисунку 5. Цей приклад має спрощений вид задля того, щоб показати як це працює. Для кожного обмеження проекту вкажіть межі, в яких повинен працювати проектний менеджер. Для кожного рушія успіху, описано мету, яку ви маєте намір досягти. Для кожного ступеня свободи опишіть допустимі відхилення або широту, які має проектний менеджер.
Рисунок 5. Зразок таблиці гнучкості.
Таблиця на рисунку 5 призначена для проекту, діаграма гнучкості якого показана на рисунку 2. Нагадаємо, що персонал був обмеженням. Протягом цього проекту у нас було лише п’ять штатних членів команди. Графік був рушійною силою. Ми хотіли, щоб перший реліз відбувся протягом чотирьох-п’яти місяців, але ми не мали фіксованої дати поставки. Інші три виміри мали більшу гнучкість. Оскільки проект був важливим, проектний менеджер міг перевищити початковий бюджет на розумну суму, перш ніж це когось засмутило б. У нас був ключовий набір високопріоритетних функцій, які ми повинні були випустити у першому релізі, але крім цього, ми могли відкласти деякі вимоги, якщо це необхідно.
Зверніть увагу, що кожен із п’яти вимірів має лише одну характеристику. Наприклад, графік є або обмеженням, рушійною силою, або ступенем свободи, а не двома чи трьома одразу. У вашій таблиці гнучкості кожний вимір матиме лише один запис у одному з стовпців.
Застосування п’яти вимірів
Суть цього аналізу полягає у тому, щоб допомогти проектному менеджеру прийняти рішення як реагувати на зміну умов або реалій проекту. Ви можете використовувати п’ятивимірну модель для повторних узгоджень, коли світ змінюється. Припустимо, що персонал обмежений. Якщо з’являються нові вимоги, які просто необхідно включити, єдині параметри, які можуть змінитися, це якість, вартість або графік. Ніщо не безкоштовне. Запитайте керівництво, які виміри скоригувати для задоволення цього запиту. Конкретна відповідь менш важлива, ніж дискусія, яка починається, коли проектні менеджери реагують на несподівані зміни в будь-якому з цих п’яти вимірів. Для прийняття правильних рішень, замовники та менеджери повинні розуміти вплив таких змін на інші параметри проекту.
Однією з характеристик здорової культури інженерії програмного забезпечення є та, що очікування та зобов’язання щодо проекту встановлюються шляхом переговорів. Щоб уникнути неприємних сюрпризів на пізній стадії життєвого циклу проекту, всі зацікавлені сторони повинні зрозуміти та погодити свої цілі та пріоритети. Не всі можуть бути задоволені результатами переговорів, але люди можуть взяти на себе зобов’язання щодо реалістичних графіків і досягнутих результатів лише за умови чесного обговорення всіх параметрів. Культурна група, в якій люди бояться сказати «ні», або відкрито обговорювати проблемні питання, ніколи не виправдає сподівань. Такі інструменти, як діаграма гнучкості, можуть сприяти цим відвертим і часто складним переговорам.
До теми – Про управління очікуваннями в проектній діяльності.
Оригінальна стаття – Rethinking the Triple Constraint: Five Project Dimensions, переклад – Олена Благий, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Оригінальна графіка від автора Karl Wiegers.