
- •Технологія програмування та створення програмних продуктів
- •(частина 2)
- •Візуальне моделювання на основі UML
- •MSF – Модель проектної групи (v. 3.1)
- •Анотація
- •1. Основи моделі проектної групи MSF
- •Основні принципи
- •Розподіл відповідальності при фіксації звітності
- •Наділення членів команди повноваженнями
- •Концентрація на бізнес-пріоритетах
- •Єдине бачення проекту
- •Прояв гнучкості і готовність до змін
- •Заохочення вільного спілкування
- •2. Ключові концепції
- •Команда соратників
- •Фокусування на потребах замовника
- •Націленість на кінцевий результат
- •Установка на відсутність дефектів
- •Прагнення до самовдосконалення
- •Зацікавлені команди працюють ефективно
- •3. Випробувані методики
- •Малі багатопрофільні проектні групи
- •Колективна робота
- •Загальна участь в проектуванні
- •4. Огляд моделі команди MSF
- •Задоволені замовники
- •Досягнення результату в рамках проектних обмежень
- •Створення продукту відповідно до специфікації
- •Схвалення випуску продукту лише після того, як всі дефекти виявлені і відлагоджені
- •Підвищення споживчої цінності продукту
- •Безпроблемне впровадження і супровід продукту
- •Ролеві кластери моделі проектної групи
- •I. Ролевий кластер "Управління продуктом"
- •Області компетенції
- •1. Планування продукту
- •2. Бізнес-віддача
- •3. Представлення інтересів замовника
- •4. Маркетинг
- •II. Ролевий кластер "Управління програмою"
- •Області компетенції
- •1. Управління проектом
- •2. Вироблення архітектури рішення
- •3. Контроль виробничого процесу
- •4. Адміністративні служби
- •III. Ролевий кластер "Розробка"
- •Області компетенції
- •1. Технологічне консультування
- •2. Проектування і здійснення реалізації
- •3. Розробка програмних рішень
- •4. Розробка інфраструктури
- •IV. Ролевий кластер "Тестування"
- •Області компетенцій
- •1. Планування тестів
- •2. Розробка тестів
- •3. Звітність про тести
- •V. Ролевий кластер "Задоволення споживача"_
- •Області компетенцій
- •1. Загальнодоступність
- •2. Інтернаціоналізація
- •3. Забезпечення технічної підтримки
- •4. Навчання користувачів
- •5. Зручність експлуатації (ергономіка)
- •6. Графічний дизайн
- •VI. Ролевий кластер "Управління випуском"
- •Області компетенції
- •1. Управління випуском
- •2. Інфраструктура
- •3. Супровід
- •4. Бізнес-процеси
- •Масштабування моделі проектної групи
- •Групи напрямів
- •Функціональні групи
- •Об'єднання ролей
- •Ескалація і підзвітність
- •Модель проектної групи немає організаційної структури
- •Зовнішня координація – на кому лежить відповідальність?
- •Висновок
- •MSF: Модель процесів
- •Анотація
- •Короткий огляд методології
- •Введення
- •Інші моделі процесів
- •Краще з двох світів
- •Базові принципи MSF
- •Єдине бачення проекту
- •Проявляйте гнучкість – будьте готові до змін
- •Концентруйтеся на бізнес - пріоритетах
- •Заохочуйте вільне спілкування
- •Ключові концепції моделі процесів MSF
- •Замовники
- •Зацікавлені сторони (учасники)
- •Що є рішення?
- •Створення базових версій
- •Рамки проекту
- •Управління компромісами
- •Трикутник компромісів
- •Матриця компромісів проекту
- •Характеристики моделі процесів MSF
- •Підхід, заснований на віхах
- •Характеристики підходу, заснованого на віхах
- •Головні і проміжні віхи
- •Віхи як точки синхронізації
- •Віхи як орієнтири виробничої відповідальності
- •Провідні ролі різних фаз
- •Аналіз пройдених віх
- •Ітеративний підхід
- •Характеристики ітеративного підходу
- •Випуск версій
- •Створення "живої" документації
- •Ранні базові версії, відкладені підсумкові версії
- •Щоденні білди
- •Управління конфігураціями проекту
- •Рекомендації для випуску версій рішення
- •Створюючи плани, передбачайте версіонування
- •Перш за все, поставляйте базову функціональність
- •Вибирайте пріоритети, враховуючи ризики
- •Здійснюйте часті ітерації розробки
- •Інституціюйте процедури контролю змін в проекті
- •Цілісний погляд на розробку і впровадження
- •Переваги інтегрованої моделі процесів
- •Зосередження на потребах підприємства
- •Покращена підтримка розробки веб-приложений
- •Покращена підтримка веб-сервісів
- •Поліпшення взаємодії з командою супроводу
- •Зауваження про використання інтегрованої моделі процесів
- •Тривалість фаз не однакова
- •Діяльність може виходити за межі однієї фази
- •Проекти, обмежені розробкою застосування або впровадженням інфраструктури
- •Фази і віхи моделі процесів MSF
- •Фаза вироблення концепції
- •Введення
- •Віха "Концепція затверджена"
- •Результати
- •Основні завдання проектної групи на фазі вироблення концепції
- •Проміжні віхи, що рекомендуються
- •Ядро проектної групи сформоване
- •Чорновий варіант концепції проекту складений
- •Фаза планування
- •Введення
- •Віха "Плани проекту затверджені"
- •Результати
- •Основні завдання проектної групи на фазі планування
- •Проміжні віхи, що рекомендуються
- •Верифікація технологій
- •Базова версія функціональної специфікації створена
- •Базова версія звідного плану проекту створена
- •Базова версія звідного календарного графіка проекту створена
- •Середовища розробки і тестування розгорнені
- •Фаза розробки
- •Введення
- •Віха "Розробка завершена"
- •Результати
- •Основні завдання проектної групи на фазі розробки
- •Проміжні віхи, що рекомендуються
- •Концепція підтверджена
- •Білд n завершений, білд n+1 завершений...
- •Фаза стабілізації
- •Введення
- •Віха "Готовність рішення затверджена"
- •Результати
- •Основні завдання проектної групи на фазі стабілізації
- •Проміжні віхи, що рекомендуються
- •Точка конвергенції
- •Точка досягнення нуля
- •Версії-кандидати
- •Контрольне тестування завершене
- •Тестування прийнятності для споживачів завершене
- •Пілотне впровадження завершене
- •Фаза впровадження
- •Введення
- •Віха "Впровадження завершене"
- •Результати
- •Основні завдання проектної групи на фазі впровадження
- •Проміжні віхи, що рекомендуються
- •Ключові компоненти розгорнені
- •Впровадження на місцях завершене
- •Упроваджене рішення стабілізоване
- •Методики моделі процесів MSF, що рекомендуються
- •Стимулювання винахідливості для розширення функціональності й обмеження ресурсів
- •Фіксування календарного графіка
- •Календарне планування на невизначене майбутнє
- •Використання паралельно працюючих компактних команд
- •Розбиття великих проектів на реальні частини
- •Отримання уроків з пройдених віх
- •Використання прототипіювання
- •Використання частих білдів і швидких тестів
- •Часті ітерації розробки і впровадження
- •Уникання розповзання рамок проекту
- •Оцінка з низу до верху
- •Інтеграція представлених проектною групою оцінок
- •Застосування A
- •Зміни в порівнянні з попередньою версією MSF
- •Висновок
- •Література
- •Анотація
- •Введення
- •Основні відомості про ризики
- •Базові принципи:
- •1. Гнучкість і постійна готовність до змін
- •2. Вільне спілкування
- •3. Отримання зі всього уроків
- •4. Розподіл відповідальності при фіксації звітності
- •Ключові концепції:
- •Найбільш ефективним є превентивне управління ризиками
- •2. Заохочення до виявлення ризиків
- •3. Постійна оцінка ризиків
- •4. Підтримка відкритого спілкування
- •5. Постійний аналіз ризиків
- •6. Кількість ризиків не характеризує реальне положення речей
- •Планування управління ризиками
- •Процес управління ризиками
- •Загальне уявлення
- •Етап 1. Виявлення ризиків
- •Введення
- •Початкові дані
- •Кроки по виявленню ризиків
- •Структурований підхід
- •Класифікація ризиків
- •Формулювання ризиків
- •Результати
- •Етап 1. Аналіз і пріоритезація ризиків
- •Введення
- •Мета
- •Початкові дані
- •Процес аналізу ризиків
- •Вірогідність ризику
- •Загроза ризику
- •Очікувана величина ризику
- •Додаткові кількісні методики
- •Результати
- •Головна таблиця ризиків
- •Інші методи проведення аналізу
- •Документ опису ризиків
- •Список головних ризиків
- •Деактивація ризиків
- •Планування ризиків_
- •Введення
- •Початкові дані
- •Заходи
- •Дослідження
- •Ухвалення
- •Уникнення
- •Перенесення
- •Запобігання
- •Пом'якшення наслідків (реагування)
- •Календарне планування
- •Результати
- •Діяльність по управлінню ризиками
- •Документування планів
- •Оновлення плану і календарного графіка проекту
- •Моніторинг ризиків_
- •Початкові дані
- •Заходи щодо моніторингу
- •Звітність про стан ризиків
- •Результати
- •Коректування ситуації_
- •Мета
- •Початкові дані
- •Дії з коректування ситуації
- •Результати
- •Витягання уроків з ризиків
- •Введення
- •Типи отримуваних уроків
- •Управління витяганням уроків
- •Контекстна класифікація ризиків
- •База знань про ризики
- •Досягнення зрілості в управлінні знаннями про ризики
- •Управління ризиками як складова частина життєвого циклу проекту_
- •Управління ризиками на підприємстві
- •Створення культури управління ризиками
- •Управління портфелем проектів_
- •Висновок
- •MSF: Дисципліна управління проектами
- •Анотація
- •Введення
- •Базові принципи MSF
- •Пр.1: Розподіл відповідальності при фіксації звітності
- •Пр.2: Наділення членів команди повноваженнями
- •Ключові концепції
- •1) Дисципліни MSF
- •2) Поняття управління проектом
- •3) Менеджмент проекту і менеджер проекту
- •4) Управління проектами і специфічні IT-процеси
- •Особливості управління проектами в MSF
- •Роль менеджера проекту покладається на кластер "Управління програмою"
- •Взаємодія "Управління програмою" з лідерами командних ролей
- •A. Функціональні групи
- •B. Групи напрямів
- •Масштабування функцій управління проектом
- •Обов'язки по управлінню проектами
- •Лідери груп
- •Кластер "Управління програмою"
- •Управління великими і складними проектами
- •Адміністративні служби проекту
- •Звітність перед замовником
- •Рекомендації проектним групам
- •Управління рамками проекту
- •Визначення рамок на етапі вироблення концепції
- •Рамки рішення і рамки проекту
- •Визначення рамок (scope definition)
- •Управління змінами рамок (scope change control)
- •Підготовка планів
- •Повторне використання документів
- •Плани проекту
- •Ієрархічна структура робіт
- •Відповідність між WBS, функц. специфікаціями і зведеним планом
- •Створення WBS
- •Рекомендації по декомпозиції роботи
- •Оцінка знизу вгору
- •Інтеграція представлених проектною групою оцінок
- •Формування реалістичних очікувань
- •Невизначеність і точність оцінок
- •Оцінюйте завдання нижнього рівня декомпозиції
- •Аналіз PERT
- •Рекомендації по складанню календарного графіка
- •1) Впорядкування завдань
- •2) Обмеження часу
- •3) Вибір пріоритетів, з врахуванням ризиків
- •Створення часових буферів
- •Висновок
- •MSF: Дисципліна "Управління підготовкою"
- •Анотація
- •Вступ
- •Базові принципи
- •Пр.1: Заохочення вільного спілкування
- •Пр.2: Інвестування в якість
- •Пр.2: Отримання уроків
- •Пр.3: Гнучкість та готовність до змін
- •Ключові концепції
- •1) Інвентаризація наявних знань
- •2) Прагнення до самовдосконалення
- •3) Підготовка повинна бути перманентним процесом
- •Випробувані методики
- •1) Планування підготовки
- •Оцінка і моніторинг професійного рівня і індивідуальних цілей
- •Відноситеся до пропусків в підготовці як до ризиків
- •Огляд процесу Управління підготовкою
- •1) Визначення:
- •2) Оцінювання:
- •3) Коригування:
- •4) Осмислення:
- •Превентивне Управління підготовкою
- •Підготовка впродовж життєвого циклу ІТ
- •Кроки процесу Управління підготовкою
- •Крок 1: Визначення
- •Скл. 1: Проектні сценарії
- •Скл. 2: Кваліфікаційні вимоги
- •Скл. 3: Професійні навики
- •Крок 2: Оцінювання
- •Оцінка знань, умінь, здібностей
- •Специфікація процесу оцінювання
- •Збір і обробка даних
- •Обробка результатів оцінювання
- •Аналіз невідповідностей
- •Створення планів навчання
- •Крок 3: Коригування
- •Навчання
- •Моніторинг прогресу
- •Крок 4: Осмислення
- •Аналіз результатів
- •Управління знаннями
- •Вимоги до професійних навиків проектних ролей
- •Створення планів підготовки
- •Висновок
Базові принципи MSF
Дисципліна управління проектами використовує всі базові принципи MSF, хоча не кожен з них тут явно фігурує. Нижче наведено два основні принципи, безпосередньо пов'язані з управлінням проектами.
Пр.1: Розподіл відповідальності при фіксації звітності
Модель проектної групи MSF ґрунтується на унікальності внеску в проект кожної проектної ролі і неможливості одночасного виконання однією людиною функцій всіх ролей. Проте замовник зазвичай потребує єдиного компетентного і відповідального джерела інформації про стан проекту, хід роботи і виникаючі складнощі. Для вирішення цієї дилеми проектна група повинна забезпечити чітку схему звітності перед замовником при необхідності розподілу відповідальності за загальний успіх.
Кожен ролевий кластер звітує за результати діяльності після досягнення своїх окремих цілей.
Кожен член проектної групи відповідальний за загальний успіх проекту і якість створюваного рішення. Мається на увазі також, що члени проектної групи діляться своїми ідеями і спостереженнями навіть з приводу питань, що не входять в зону їх безпосередньої відповідальності.
Наприклад.
На кожен з ролевих кластерів покладається певна відповідальність за широкий спектр завдань, пов'язаних з управлінням проектом. Сюди входять питання управління ризиками, управління якістю, управління календарним графіком, управління кадрами і так далі
Пр.2: Наділення членів команди повноваженнями
У ефективно працюючій команді кожен її член має необхідні повноваження для виконання своїх обов'язків і впевнений, що отримає від колег все необхідне. З іншого боку, замовник може бути впевнений в результатах роботи команди і будувати свої плани виходячи з цієї упевненості. У противному випадку, замовника потрібно негайно (в найкоротший строк) повідомити про затримку або про зміну в ході виконання проекту.
Проектна група MSF наділяє своїх членів необхідним для роботи рівнем повноважень. Це робить сильний вплив на процес моніторингу ходу проекту. Без наявності у членів проектної групи повноважень і відповідального відношення до роботи менеджерам команди довелося б постійно перевіряти, чи не відбувається у кого-небудь з працівників затримок або накладок. Якщо ж менеджери упевнені, що про всі складнощі буде відомо з самого моменту їх виникнення, тоді їх функція міняється. Їх основною функцією стає - консультативна допомога членам команди в оцінці ситуації. А моніторинг прогресу розроблення ПП проводиться всією командою.
Ключові концепції
Для розуміння підходу MSF до управління проектами, необхідно познайомитися з наступними концепціями і термінами:
1) Дисципліни MSF
MSF включає 3 базові дисципліни:
1)управління ризиками (risk management),
2)управління проектами (project management),
3)управління підготовкою (readiness management).
Врамках цих дисциплін розроблені ефективні практичні методики, що є плідними не тільки лише у сфері інформаційних технологій, але також і в широкому спектрі інших галузей. Часто ці методики застосовні до використання і супроводу ITсистем і інших бізнес-процесів в тому ж ступені, що і до розробки ITпроектів. Не створюючи цей
118
інструментарій з нуля, MSF узагальнює знання відповідних дисциплін, необхідні проектним командам для успішної роботи, і збагачує їх цінним досвідом, накопиченим майкрософтом за минулі роки.
Для забезпечення ефективності роботи кожен з лідерів ролевих кластерів повинен мати адекватний рівень знань кожній з дисциплін MSF.
2) Поняття управління проектом
Перш за все, незалежно від типу проекту, необхідно розуміти, що таке управління
ним...
Проект (project) – це обмежена часовими рамками діяльність, мета якої полягає в створенні унікального продукту або послуги.
Управління проектами (project management) – це область знань, навиків, інструментарію і прийомів, використовуваних для досягнення цілей проектів в рамках узгоджених параметрів якості, бюджету, термінів і інших обмежень.
У деяких компаніях і країнах під терміном програма (program) розуміється скоординована група проектів. Щоб уникнути плутанини з найменуванням ролевого кластера "Управління програмою" група проектів іменуватиметься портфелем проектів
(project portfolio).
MSF виділяє наступні області відповідальності, навиків і діяльності по управлінню проектами:
Область управління |
|
|
|
Опис |
|
|
проектами |
|
|
|
|
|
|
Планування і |
моніторинг |
Інтеграція і синхронізація планів проекту; |
||||
проекту, контроль за змінами в |
організація процедур і систем управління і |
|||||
проекті |
|
моніторингу проектних змін |
|
|||
(Project planning / Tracking / Change |
|
|
|
|
|
|
Control) |
|
|
|
|
|
|
|
|
|||||
Управління рамками проекту |
Визначення і розподіл об'єму роботи (рамок |
|||||
(Scope Management) |
|
проекту); управління компромісними рішеннями в |
||||
|
|
проекті |
|
|
|
|
|
|
|
||||
Управління |
календарним |
Складання календарного графіка виходячи з |
||||
графіком |
проекту |
оцінок трудовитрат, впорядковування завдань, |
||||
(Schedule Management) |
|
співвідношення доступних ресурсів із завданнями, |
||||
|
|
застосування статистичних методів, підтримка |
||||
|
|
календарного графіка |
|
|
||
Управління |
вартістю |
Оцінки вартості виходячи з оцінок часових |
||||
(Cost Management) |
|
витрат; звітність про хід проекту і його аналіз; аналіз |
||||
|
|
витратних ризиків; функціонально-вартісний аналіз |
||||
|
|
(value analysis) |
|
|
|
|
|
|
|
||||
Управління |
персоналом |
Планування ресурсів; формування проектної |
||||
(Staff Resource Management) |
команди; вирішення конфліктів; планування і |
|||||
|
|
управління підготовкою |
|
|
||
Управління |
комунікацією |
Комунікаційне планування (між проектною |
||||
(Communications Management) |
групою, |
|
|
замовником/спонсором, |
||
|
|
споживачами/користувачами, ін. |
зацікавленими |
|||
|
|
особами); звітність про хід проекту |
|
|||
|
|
|
||||
Управління |
ризиками |
Організація процесу управління ризиками в |
||||
(Risk Management) |
|
команді |
і |
сприяння |
йому; |
забезпечення |
|
|
документообігу управління ризиками |
|
|||
|
|
|
|
|
||
Управління |
постачанням |
Аналіз |
цін постачальників |
послуг і/або |
||
|
|
|
|
|
|
119 |

(Procurement) |
|
апаратного/програмного забезпечення; підготовка |
||
|
|
документів про ініціацію пропозицій (requests for |
||
|
|
proposals – RFPs), вибір постачальників і |
||
|
|
субпідрядників; складання контрактів і переговори |
||
|
|
про їх умови; договори; замовлення на постачання і |
||
|
|
платіжні вимоги |
|
|
|
|
|
|
|
Управління |
якістю |
Планування |
якості, |
визначення |
(Quality Management) |
|
використовуваних |
стандартів, |
документування |
|
|
критеріїв якості і процесів його вимірювання |
||
|
|
|
|
|
Хоча в цьому документі не може бути представлені вичерпне керівництво по кожній з перерахованих областей, нижче описуються окремі методики управління проектами MSF.
3) Менеджмент проекту і менеджер проекту
Термін "менеджмент" може відноситися як до ролі/посади, так і до області професійних навиків і знань. Наприклад, можна сказати: "Наш менеджмент хоче, щоб це було зроблено", – або "Менеджмент проектів космічних агентств винен знаходиться на високому рівні".
Дана відмінність істотна, оскільки в управління проектами, як діяльність, може бути залучено багато людей, що не є менеджерами за посадою!
У MSF термін управління проектами (project management) завжди вказує на специфічну область знань і навиків, згаданих вище, а не на роль або посаду.
Однак, термін менеджер проекту (project manager) вказуватиме на фахівця в області управління проектами.
4) Управління проектами і специфічні IT-процеси
Вцілому, управління ІТ-проектами вимагає знань і методик, які широко застосовуються в різних галузях. Кожна з них (наприклад, аеронавтика, будівництво, інформаційні технології і так далі) має специфічний набір процесів, фаз, ролей і методик, що найкраще працюють в цій індустрії. Тому, для успіху вузькогалузевих проектів потрібне підкріплення цих специфічних процесів за допомогою загальних методик управління проектами.
ВMSF (стосовно IT-проектів) співвідношення між MSF і дисципліною управління проектами (ДУП) ілюструється на рис. 1.
Рисунок 24. Зв'язок між MSF і дисципліною управління проектами
В цьому випадку специфічною моделлю ІТ-галузі є п'ятифазова модель процесів MSF. Прикладом такої специфічної галузевої діяльності – є моніторинг помилок (bug tracking).
120