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

3.Контроль виробничого процесу,

4.Адміністративні служби.

Області компетенції

1. Управління проектом

Моніторинг і управління бюджетом.

Складання звідного плану і звідного календарного графіка проекту.

Організація управління ризиками.

Сприяння обміну інформацією і досягненню домовленостей усередині проектної групи.

Моніторинг прогресу і звітність про стан проекту.

Управління виділенням ресурсів.

Будучи відповідальним за календарний план, менеджмент проекту (project

management) стежить за всіма тимчасовими графіками усередині команди, контролює їх правомірність і інтегрує їх в звідний календарний графік проекту. Він, у свою чергу, піддається моніторингу, і звітність про хід його виконання прямує проектній групі і спонсорові проекту.

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

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

Детальнішу інформацію про область компетенції "Управління проектом" і підході MSF до управління проектами, див.

2. Вироблення архітектури рішення

Організація високо-рівневого проектування рішення.

Управління функціональною специфікацією.

Визначення рамок проекту і ключових компромісних рішень.

"Вироблення архітектури рішення" (solution architecture) – це область компетенції

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

Зони відповідальності "Вироблення архітектури рішення" включають:

a)Організацію високо-рівневого проектування рішення.

b)Управління функціональною специфікацією.

c)Визначення рамок проекту і ключових компромісних рішень.

Будучи відповідальною за логічний дизайн рішення, "Вироблення архітектури рішення" здійснює життєво важливий зв'язок між бізнес-стороною проекту (що представляється кластером "Управління продуктом" за допомогою концептуального дизайну) і технологічною його стороною (що представляється кластером "Розробка" за допомогою фізичного дизайну). Ця область компетенції "опікає" функціональну специфікацію. Вона прагне до досягнення внутрішньо-командного консенсусу про дизайн і обґрунтовує вибраний підхід перед зацікавленими в проекті сторонами. Дана область компетенції також відповідає за відповідність всіх елементів дизайну початковим вимогам (і,

30

зрештою, забезпечення бізнес-віддачі). Кожен елемент рішення повинен реалізовувати деяку вимогу: таким чином проектна група може оцінити наслідки будь-яких змін дизайну для бізнес-корисності кінцевого продукту.

Заходи, архітектуру рішення", що проводиться "Виробленням, включають:

a)Створення концепції рішення і його узгодження з архітектурою підприємства замовника; розробка стратегії версіонування продукту; вироблення рекомендацій до планів збору вимог.

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

c)Управління змінами функціональній специфікації; підтримка "карти" відповідності; роз'яснення специфікації іншим ролевим кластерам проектної групи і зовнішнім зацікавленим особам; зв'язок з іншими проектними групами для забезпечення інтероперабельності.

d)Участь в процесі пріоритезації; формування очікувань зацікавлених сторін.

e)Зв'язок з архітектурною групою підприємства; коректування вимог до майбутніх версій рішення.

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

3. Контроль виробничого процесу

Організація контролю виробничого процесу.

Вироблення рекомендацій по його вдосконаленню.

Область компетенції "Контроль виробничого процесу" (process assurance) ролевого

кластера "Управління програмою" забезпечує контроль за проходженням проектною групою виробничим процесам, націленим на досягнення високоякісного результату. При цьому основна увага приділяється виявленню і усуненню першопричин дефектів. "Контроль виробничого процесу" має дві основні зони відповідальності:

a)Визначення ключових виробничих процесів, використовуваних командою при роботі над проектом, і консультування команди по питаннях їх впровадження.

b)Проведення аналізу ефективності процесів, вироблення рекомендацій по їх вдосконаленню, моніторинг їх реалізації і адекватності.

c)Ця область компетенції здійснює наступну діяльність:

d)Розробка внутрішньо проектних виробничих протоколів і процесів.

e)Консультування по питаннях ефективного використання виробничих процесів; контроль реалізації процесів; визначення їх адекватності; вироблення рекомендацій по вдосконаленню процесів.

Співробітники, що працюють в даній області компетенції, повинні мати певну незалежність від проектної групи, можливість поглянути на проект " с сторони". Часто вони навіть підзвітні особі, що не входить безпосередньо до проектної групи.

31

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