Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
2014 Лекції ТСПП (8-14).pdf
Скачиваний:
90
Добавлен:
12.02.2016
Размер:
2.99 Mб
Скачать

Рамки проекту (project scope) визначають об'єм робіт, який повинен бути виконаний проектною групою для постачання замовникові кожного з елементів, визначеного рамками рішення. Деякі організації називають рамки проекту "Описом роботи" (statement of work - SOW).

Формулювання рамок проекту дозволяє проектній групі:

Сфокусуватися на тій роботі, яку необхідно виконати.

Полегшити розбиття об'ємних і нечітких завдань на менших, таких, що легко розуміються.

Виявити специфічну роботу, не пов'язану безпосередньо з реалізацією будь-якої складової проекту (наприклад, підготовка поточних звітів).

Полегшити розподіл фронту робіт серед субпідрядників і партнерів проектної групи.

Розмежувати ті частини рішення, за які несе відповідальність проектна група, від інших частин, за які вона відповідальності не несе.

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

Управління компромісами

Управління рамками проекту критично для його успіху. Невдачі багатьох IT-проектів, включаючи затягування термінів і перевитрату засобів, обумовлені поганою організацією управління їх рамками. Ця діяльність повинна включати раннє визначення рамок проекту, добре організовані моніторинг його ходу і управління змінами.

Через властиву IT-проектам невизначеності і ризикованої, одним з ключових чинників їх успіху є ефективні компромісні рішення (trade-offs).

Трикутник компромісів

Добре відома взаємозалежність між ресурсами проекту (людськими і фінансовими), його календарним графіком (часом) і можливостями, що реалізовуються (рамками). Ці три змінні утворюють трикутник, показаний на рис. 5.

Після досягнення рівноваги в цьому трикутнику зміна на будь-якій з його сторін для підтримки балансу вимагає модифікацій на іншій (два інших) сторонах і/або на спочатку зміненій стороні.

Рисунок 9. Трикутник компромісів

52

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

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

Функціональність, що реалізовується, повинна мати якість не нижче певного рівня. Параметр якості може бути зображений у вигляді четвертого вимірювання, що перетворює трикутник на тетраедр (трикутну піраміду). Хоча зниження порогу якості (quality bar) дає можливість скоротити ресурси/час, що витрачаються, і збільшити функціональність рішення, це веде, безумовно, до неминуче поганого результату.

Матриця компромісів проекту

Інший вельми корисний засіб для управління проектними компромісами – матриця компромісів проекту (project tradeoff matrix), показана на рис. 6. Вона відображає досягнуту на ранніх етапах проекту угоду між проектною групою і замовником про вибір пріоритетів в можливих в майбутньому компромісних рішеннях. У певних випадках з цієї пріоритезації можуть робитися виключення, але в цілому проходження їй полегшує досягнення угод по спірних питаннях.

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

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

Для ілюстрації використання матриці компромісів розглянемо наступну пропозицію (замість пропущених слів можуть бути вставлені "календарний графік", "ресурси" і "функціональність"):

Зафіксувавши ___________, ми погоджуємо ___________ і приймаємо результуючий

___________.

Рисунок 10. Матриця компромісів

Можливі такі логічні взаємозв'язки:

53

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]