
- •Технологія програмування та створення програмних продуктів
- •(частина 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: Осмислення
- •Аналіз результатів
- •Управління знаннями
- •Вимоги до професійних навиків проектних ролей
- •Створення планів підготовки
- •Висновок

Планування ризиків_
Введення
Рисунок 20. |
Планування ризиків |
На етапі планування ризиків (третьому етапі процесу управління ризиками), ґрунтуючись на наявній таблиці головних ризиків, відбувається побудова планів конкретних дій. Планування (planning) включає розробку детальних стратегій і заходів відносно кожної з головних ризиків, пріоритезацію цих заходів і створення звідного плану управління ризиками. Подальше календарне планування (scheduling) включає інтеграцію завдань управління ризиками в загальний календарний графік проекту. Завдання з плану управління ризиками доручаються певним членам проектної групи, і їх виконання піддається активному моніторингу. Цей етап схематично зображений на мал. 5.
На цьому кроці в головній таблиці ризиків фіксується додаткова інформація про найбільш пріоритетні і значущі ризики. Іноді зручніше винести цю інформацію в окремі документи, використовувані членами проектної групи, відповідальними за відповідні ризики.
Цілі
Основна мета кроку планування ризиків – розробка детальних планів управління головними ризиками, виявленими під час аналізу, і забезпечення виконання цих планів за допомогою їх інтеграції в загальні процеси управління проектом.
Початкові дані
Дисципліна управління ризиками MSF припускає тісну інтеграцію процесу планування ризиків з іншими стандартними проектними процесами планування і засобами, що забезпечують їх. Початкові дані процесу планування ризиків включають не тільки
102
головну таблицю ризиків, список головних ризиків і базу знань про ризики, але також загальні проектні плани разом з календарними графіками проекту.
Заходи
При розробці планів по скороченню очікуваної величини ризиків:
•Концентруйте увагу на ризиках з великою очікуваною величиною;
•Для пониження вірогідності направляйте свою діяльність на причину ризиків;
•Шукайте першопричини, а не боріться з симптомами;
•Для скорочення загрози направляйте свою діяльність на наслідок;
•Після визначення першопричини, шукайте схожі ризики, які можуть виходити з аналізованої першопричини;
•Пам'ятаєте про взаємозалежностях і взаємодії ризиків. Деякі підходи, застосовні до скорочення ризиків:
•Використовуйте доступні ресурси для скорочення тих ризиків, з якими проектна група в змозі справитися сама;
•Для ризиків, що знаходяться поза контролем проектної групи, знайдіть можливі обхідні шляхи для їх скорочення або передайте управління цими ризиками особам, що мають необхідні повноваження (ескалація).
Плануючи конкретні дії, проектна група повинна розглянути шість наступних
можливих підходів:
•Дослідження (research). Чи достатньо ми знаємо про даний конкретний ризик? Чи винні ми краще вивчити його, щоб отримати про нього більше інформації і визначити його характеристики до того, як ми зробимо які-небудь дії?
•Ухвалення (accept). Чи можемо ми пережити наслідки ризиків, якщо вони все-таки наступлять? Чи можемо ми прийняти ризик і не робити із цього приводу ніяких подальших дій?
•Уникнення (avoid). Чи можемо ми уникнути ризику, змінивши спосіб дії?
•Перенесення (transfer). Чи можемо ми перенести ризик на інший проект, проектну групу, організацію або приватних осіб?
•Запобігання (mitigation). Чи можна зробити щось заздалегідь для зменшення вірогідності ризику або його загрози?
•Пом'якшення наслідків (реагування, contingency). Чи може загроза ризику бути зменшена шляхом планування деякої реакції на нього?
Дослідження
Багато який з ризиків пов'язаний з неозначеностями, породженими неповною інформованістю. Вони можуть бути ефективно дозволені після додаткового вивчення пов'язаної з ними наочної області. Наприклад, до закінчення складання плану проектна група може ухвалити рішення про проведення маркетингового дослідження, щоб більше дізнатися про тих, що є у користувачах базових навиках і про їх бажання використовувати нові технології. У разі рішення про проведення досліджень план управління ризиком повинен включати опис цих досліджень, включаючи формулювання гіпотез, що перевіряються, і питань, що вивчаються, необхідне кадрове забезпечення і лабораторне устаткування.
Ухвалення
Природа деяких ризиків така, що кращим рішенням є їх ухвалення для реалізації можливостей, що відкриваються ними, оскільки просто не існує ефективних превентивних або коректуючих засобів. Ухвалення немає бездіяльність. План управління ризиками повинен включати обґрунтування того, чому проектна група вибрала ухвалення ризику, а не вироблення мерів по його запобіганню і пом'якшенню наслідків. Має сенс продовжити моніторинг таких ризиків на випадок зміни їх вірогідності, загрози або появи нової
103
можливості управління. Для забезпечення моніторингу повинні бути виділені необхідні ресурси, і він повинен ґрунтуватися на метриках, встановлених в рамках процесу по управлінню ризиками проекту.
Уникнення
Можливо, виявлений ризик може бути дозволений найкращим чином деякими змінами в самому проекті (його рамках, scope), що виключають існування ризику. У такому разі план управління ризиками повинен включати обґрунтування зміни, і воно повинне бути також відбите в плані самого проекту. Крім того, повинні бути ініційовані заходи, необхідні для втілення прийнятої зміни в життя.
Перенесення
Іноді можливо передати управління ризиком третій стороні, що безпосередньо не бере участь в проекті. Прикладами таких випадків є:
•Страхування;
•Найм сторонніх консультантів з великим досвідом роботи;
•Покупка готовою компоненти замість її створення власними силами;
•Залучення зовнішніх субпідрядників.
Перенесення ризику не обов'язково означає його зникнення. У загальному випадку
перенесення ризику породить інші ризики, що вимагають превентивного управління, але що мають прийнятний рівень. Наприклад, залучення зовнішнього консультанта може перенести технологічні ризики за межі проектної групи, але породить ризики в областях управління і бюджетування.
Запобігання
План запобігання рисці описує заходи і заходи, здійснювані завчасно для запобігання рисці або скороченню його загрози або наслідків до прийнятного рівня. Запобігання рисці, на відміну від уникнення, концентрується на його зниженні до прийнятного рівня (уникнення означає зміна проекту з метою цей ризик обійти).
Головна мета запобігання рисці – зниження його вірогідності. Наприклад, деяка додаткова кількість підключень до internet скорочує ризик повної втрати доступу в глобальну мережу.
Не для кожного ризику є ефективна стратегія запобігання. У таких випадках доцільно спланувати заходи по пом'якшенню наслідків ризиків.
Пом'якшення наслідків (реагування)
Планування дій для пом'якшенню наслідків ризиків полягає в створенні запасних планів на випадок, якщо превентивні заходи по запобіганню негативним наслідкам не досягнуть мети. Такі плани необхідні для всіх ризиків, включаючи ті, для яких розроблені плани по запобіганню. Вони передбачають дії на випадок реалізації ризику і повинні мінімізувати вплив наслідків. Щоб бути ефективними, ці плани повинні бути розроблені завчасно. Проектна група може встановити тригер (trigger) (умова застосування плану реагування) на підставі типу самого ризику і того впливу, який він надає.
Існує два типи тригерів:
•Тригери моменту часу встановлюються в прив'язці до дат (зазвичай найпізнішим), аж до яких щось істотне повинне відбутися.
•Тригери рівня спираються на які-небудь вимірювані або спостережувані параметри. Проектна група повинна якомога раніше погоджувати трігери планів реагування з
керівництвом, щоб не виникли затримки з виділенням бюджетних і інших ресурсів для реалізації цих планів.
104
Календарне планування
Календарне планування (scheduling) діяльності, що відноситься до ризиків, повинне слідувати стандартним методикам, рекомендованим MSF для календарного планування проекту. Важливо, щоб проектна група розуміла, що заходи щодо управління ризиками – це невід'ємна частина всякого проекту, а не додаткова робота, здійснювана на добровільних засадах. Вся діяльність, пов'язана з ризиками, повинна бути включена в календарний план проекту і підкорятися стандартним процедурам звітності.
Результати
Результатом етапу планування ризиків повинен бути чітко побудований план дій, що використовує один з шести детально розглянутих вище підходів. Кроки, що реалізовують ці плани, повинні бути інтегровані в загальний план проекту і його календарний графік. Це включає специфікацію кількості ресурсів, що виділяються, розкладу і завдань, що визначають дії членів проектної групи. Головна таблиця ризиків повинна бути доповнена описами планів по запобіганню і реагуванню і іншою необхідною інформацією.
Діяльність по управлінню ризиками
Діяльність, що відноситься до ризиків, повинна реєструватися і контролюватися подібно до будь-якої іншої діяльності в проекті, оскільки її важливість не поступається важливістю якій-небудь іншої роботи.
Як і решта всіх заходів, що відносяться до ризиків завдання повинні мати дату обов'язкового завершення і бути розбиті на персональні завдання. Таким чином, не повинно виникати розбіжностей про той, хто за що відповідальний.
Документування планів
Проектна група повинна розробити уточнені плани для кожної з головних ризиків, що включають дії із запобігання і пом'якшення наслідків, трігери і детальний опис всіх необхідних кроків. Інформація, яку проектна група може взяти до уваги, документуючи плановані дії, включає наступне:
•Ідентифікатор ризику. Унікальне ім'я ризику (для моніторингу і звітності).
•Формулювання ризику. Опис ризику на природній мові, включаючи умову і самі ці втрати (наслідки), які виникнуть, що веде до втрат, якщо ризик перетвориться на проблему.
•Стратегія запобігання ризику. Один або два абзаци тексту, що описують стратегію проектної групи по запобіганню цьому ризику, включаючи всі зроблені допущення.
•Метрика запобігання ризику. Метрика, яка використовуватиметься проектною групою для визначення успіху заходів щодо запобігання ризику.
•Плановані дії. Список заходів, які проектна група повинна здійснити для реалізації стратегії управління ризиком, включаючи дати обов'язкового завершення цих заходів і інформацію про персональну відповідальність за них.
•Стратегія пом'якшення наслідків. Один або два абзаци, що описують стратегію команди у випадку, якщо заходи по запобіганню ризикам не дали належного ефекту. Ця стратегія реалізовуватиметься після спрацьовування тригера плану пом'якшення наслідків.
•Тригери планів реагування (пом'якшення наслідків). Критерії, використовувані проектною групою для визначення умов почала здійснення плану пом'якшення наслідків.
•Метрика реагування. Метрика, використовувана проектною групою для визначення ефективності стратегії реагування.
•Відповідальність. Ролевий кластер і окремі особи, відповідальні за здійснення запланованих дій.
105