
- •Технологія програмування та створення програмних продуктів
- •(частина 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 має на увазі, що проектна група постійно проводить виявлення і моніторинг ризиків. Група здійснює необхідні дії, що коректують, відповідно до розкладу і плану проекту, і при настанні пов'язаних з тригерами ризиків подій. Слід пам'ятати, що впродовж всього життєвого циклу проекту виникають нові ризики, і це вимагає проведення додаткових кроків аналізу і планування. Немає ніякої необхідності прив'язувати кроки управління ризиками до контрольних точок (віхам, milestones) проекту. Проте деякі проектні групи можуть починати виявлення і аналіз ризиків під час таких контрольних крапок, оскільки це зручний привід для оцінки стану проекту. Також у цей момент можна резюмувати уроки, що витягують.
В цілому, виявлення і моніторинг ризиків – безперервна діяльність. Члени проектних груп повинні постійно шукати ризики, що виникають в проекті, і надавати їх всією командою. Також члени проектних груп постійно повинні стежити за ходом виконання прийнятих відносно ризиків планів. Кроки аналізу (і повторного аналізу) ризиків, також як і внесення змін в плани по управлінню ризиками, найчастіше будуть періодичними заходами, що проводяться проектною групою. Іноді вони завчасно плануються (можливо, з прив'язкою до контрольних крапок проекту), а іноді є результатом несподіваної події (наприклад, виявлення нових ризиків під час кроків моніторингу або коректування). Заходи щодо витягання уроків з отриманого досвіду найчастіше плануються і проводяться незабаром після головних контрольних точок (віх) проекту і, обов'язково, після його закінчення.
По ходу проекту тип ризиків, яким приділяється увага, також повинен змінюватися. На ранніх етапах домінують ризики пов'язані з бізнесом, рамками проекту, вимогами до кінцевого продукту і проектуванням цього продукту. З часом починають грати важливу роль технологічні ризики, пов'язані з реалізацією проекту. Потім увага переходить до ризиків підтримки і супроводу. Для організації діяльності по виявленню ризиків в моменти основних фазових переходів корисно використовувати контрольні переліки (checklists) і класифікації ризиків.
Управління ризиками на підприємстві
Для отримання максимальної віддачі від витрат на управління ризиками важливо мати єдине бачення процесу управління ризиками в масштабі всього підприємства.
Створення культури управління ризиками
Хоча лише дуже небагато організацій заперечують необхідність управління ризиками в своїх проектах, більшість з них випробовують утруднення при спробах повноцінного впровадження превентивного підходу до управління ризиками. Часто вони можуть провести оцінку ризиків на початковому етапі кожного проекту, але виявляються не в змозі продовжити цей процес на подальших етапах.
Двома основними причинами цього є:
1.Напружений часовий графік роботи проектної групи.
2.Побоювання, що підвищена увага до ризиків понизить ентузіазм замовника або навіть створить у нього негативне враження.
113
Першопричина цих переконань проста: нерідко менеджери самі не розуміють того внеску, який управління ризиками вносить до проекту. В результаті вони не виділяють достатньо часу для управління ризиками (втім, такі менеджери часто не виділяють достатньо часу і для іншої управлінської діяльності). Потім, при виникненні додаткових тимчасових, бюджетних або інших обмежень, вони приносять в жертву перш за все згадані заходи щодо управління ризиками.
Тому особливо важливо упевнитися в тому, що всі зацікавлені сторони добре розуміють важливість управління ризиками. Це дає можливість сформувати культуру, в якій управління ризиками займає гідне місце. Практикою багатьох колективів підтверджена значущість наступних кроків, направлених на інституціалізацію управління ризиками на підприємстві:
•Забезпечте підтримку управління ризиками з боку спонсорів.
•Шукайте ради менеджерів, що володіють значним досвідом і глибокими знаннями в області управління ризиками.
•Поясните всім зацікавленим сторонам важливість управління ризиками і можливі втрати у разі його відсутності.
•Навчите ядро менеджерського складу управлінню ризиками. Ці люди зможуть запропонувати ролеві моделі і рекомендації для решти працівників. Ефективним підходом до навчання управлінню ризиками є поєднання теоретичних семінарів з практикою, що надається реальними проектами.
•Запрошуйте всі зацікавлені сторони на заходи щодо аналізу досвіду, пов'язаного з ризиками, і забезпечте їх доступ до всієї звітності.
•Введіть схему заохочення членів проектної групи, що ефективно виявляють ризики і/або що працюють над ними.
•Переконаєтеся, що проектні групи враховують ризики в календарному плануванні і при ухваленні ключових рішень.
•Збирайте відгуки зацікавлених сторін проекту про ефективність процесу управління ризиками. Регулярно аналізуйте і при необхідності переглядайте цей процес з метою забезпечення істотності і відчутності його внеску в проект.
•Винагороджуйте членів проектних груп, що виявляють ризики.
Управління портфелем проектів_
Організації, що здійснюють багато проектів, можуть значно виграти від процесу управління ризиками, що охоплює весь портфель проектів. Вигода зазвичай полягає в наступному:
•Ресурси і зусилля можуть бути розподілені між проектами відповідно до ризиків, що виникають в них.
•Кожен, хто здійснює управління ризиками на рівні проекту, має можливість ескалації своїх питань і отримання "зовнішньої" для проекту думки про його ризики.
•Використовуючи досвід колег, проектні групи можуть швидше самоудосконалюватися.
•Для кожного проекту здійснюється контроль процесу управління ризиками. Відмітимо, що аналіз ризиків в рамках всього портфеля доповнює оцінку ризиків,
вироблювану кожній з проектних груп. Провідна аналіз ризиків портфеля група не має належних знань про конкретний проект, щоб визначити його ризики. Також вона не володіє часом, необхідним для проведення мерів по запобіганню ризикам. Проте ця група може внести свій внесок до аналізу і планування ризиків.
Оскільки згадана аналітична група зазвичай складається з досвідченіших менеджерів, її члени можуть використовувати свої знання для допомоги проектним групам у визначенні значущості тих або інших ризиків в процесі пріоритезації. Ці менеджери можуть також
114