- •Технологія програмування та створення програмних продуктів
- •(частина 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 поєднує розподіл відповідальності за виконувану роботу із строго певною звітністю про її виконання.
Модель проектної групи MSF ґрунтується на твердженні про рівноправність ролей в команді. Кожен ролевий кластер представляє унікальну точку зору на проект, і в той же час ніхто не в змозі успішно представляти всі можливі погляди, що відображають якісно різні цілі. Для розв'язку цієї дилеми команда соратників (команда рівних учасників, team of peers), що працює над проектом, повинна мати чітку форму звітності перед зацікавленими сторонами (stakeholders) при розподіленій відповідальності за досягнення загального успіху.
В рамках проектної групи кожен ролевий кластер звітує перед всією командою (як і перед всією організацією) про досягнення своєї мети. Кажучи інакше, кожен ролевий кластер звітує за свій внесок в остаточний результат. Відповідальність розподіляється серед членів команди, які взаємозалежні по двох причинах:
-по-перше, діяльність кожного з ролевих кластерів не може бути ізольована від роботи останніх;
-по-друге, команда ефективніша, якщо кожному її членові зрозуміла повна картина того, що відбувається.
Цей взаємозв'язок диктує необхідність для всіх членів команди висловлювати свою думку і вносити певний внесок до вирішення питань, лежачих поза областю їх звітності, забезпечуючи повноцінне використання всього спектру знань, компетенції і досвіду команди. Всі члени команди відповідають за успіх проекту; вони розділяють честь і славу у разі позитивного результату і повинні удосконалювати свій професійний рівень, працюючи над уроками менш вдалих проектів.
Наділення членів команди повноваженнями
У ефективно працюючій команді кожен її член має необхідні повноваження для виконання своїх обов'язків і упевненість в отриманні від колег всього необхідного. З іншого боку, замовник може бути упевнений в результатах роботи команди і будувати свої плани виходячи з цієї упевненості. У гіршому разі, замовник повинен бути в найкоротший строк повідомлений про затримку, що відбувається, або зміну.
Проектна група MSF наділяє своїх членів необхідним для роботи рівнем повноважень.
Авзамін вона чекає від своїх співробітників наступне:
•готовність приймати на себе зобов'язання перед іншими;
•чітке визначення тих зобов'язань, які вони на себе беруть;
•прагнення докладати належних зусиль до виконання своїх обов'язків;
•готовність чесно і негайно інформувати про загрози виконанню своїх обов'язків.
Увипадках, коли для здійснення якого-небудь кроку потрібна спільна робота декількох членів команди, внесок кожного з них залежатиме від дій інших. Проте люди не можуть витрачати час на контроль всіх залежностей, що впливають на їх діяльність. У ефективних проектних групах співробітники упевнені в тому, що вони можуть покластися на роботу своїх колег, які володіють всіма необхідними повноваженнями і слідують загальній меті.
Можна розглянути аналогію з естафетною командою бігунів. Коли другий учасник команди починає бігти, він не сповільнюється для того, щоб озирнутися і побачити, як близько знаходиться його попередник. Замість цього він прагне щонайшвидше набрати швидкість і потім просто витягає назад руку, щоб узяти
17
естафетну паличку. При цьому він упевнений, що паличка дійсно буде передана. Ця упевненість ґрунтується на тренованості, досвіді і довірі.
При роботі над складними проектами члени проектних груп повинні виробляти подібний рівень упевненості один в одному, що зміцнюється кожного разу при виконанні зобов'язання (нехай навіть невеликого), узятого на себе членом команди. Ось деякі прості рекомендації по зміцненню довіри в команді:
•Наділяйте членів проектної групи повноваженнями, необхідними для виконання їх обов'язків. Це означає, що у членів проектної групи є ресурси, необхідні для їх роботи, відповідні повноваження і розуміння їх меж. При цьому члени проектної групи повинні знати про наявні шляхи ухвалення рішень по питаннях, що виходять за рамки їх компетенції.
•Будьте готові приймати зобов'язання перед іншими. Така готовність включає усвідомлення і розуміння наслідків ухвалення зобов'язань і їх впливу на поточну завантаженість і ресурси. Як результат, ухвалення великих зобов'язань не повинне відбуватися перш, ніж всі їх наслідки стануть добре зрозумілими. Тому, члени
проектної групи повинні брати менші зобов'язання, суть яких є добре зрозумілою.
Наприклад, перш ніж узятися за велике завдання співробітник може попросити час на її обдумування. Успішне виконання малих зобов'язань додає членам команди упевненість один в одному.
•Чітко визначайте узяті зобов'язання. Це дозволяє уникнути нерозуміння, яке може пошкодити упевненості членів команди один в одному.
•Прикладайте максимум виправданих зусиль для виконання узятих на себе зобов'язань.
Якщо проектна група включає людей з різних організацій, їх розуміння виправданості
може відрізнятися.
Наприклад, деякі члени проектної групи можуть вважати прийнятними роботу в вихідні дні. А інші можуть допускати це тільки в крайніх випадках, або мати складнощі з роботою в неурочний час.
•Коли виконання обов'язків знаходиться під загрозою, слід прямо говорите про це.
Неминуче виникатимуть випадки, коли ситуація міняється. Це може трапитися із-за зміни пріоритетів або непередбаченої події; або ж просто виконання поставленого завдання зажадає більше часу, чим передбачалося. Раннє попередження дозволяє іншим членам команди, залежним від вашої роботи, скоректувати свої плани. Можливо, вони навіть зможуть запропонувати підхід до рішення виниклої проблеми.
Убагатьох організаціях такі принципи поведінки є невід'ємною частиною корпоративної культури, і їм слідують так чітко, що їх майже ніколи не доводиться
обговорювати. Проте практикуючим MSF проектним групам доводиться час від часу працювати з організаціями, в яких працівники не до кінця розуміють і признають ці цінності. У таких організаціях часто існує дуже недоброзичлива атмосфера, що обмежує вільний потік інформації. У подібних випадках керівники проектних груп повинні чітко роз'яснювати прийняті в команді принципи колективної роботи і допомагати новим членам в засвоєнні MSF-підходу до виробничого процесу.
Концентрація на бізнес-пріоритетах
Модель проектної групи MSF відстоює необхідність ухвалення рішень проектною групою на основі повного розуміння бізнесу замовника і при активній його участі в реалізації проекту.
Ролевий кластер "управління продуктом" (product management) діє по відношенню до проектної групи як представник замовника і часто формується із співробітників організаціїзамовника. Цей кластер представляє бізнес-сторону проекту і забезпечує його узгодженість із стратегічними цілями замовника. В обов'язки кластера "Управління продуктом" входить контроль за повним розумінням інтересів бізнесу при ухваленні ключових проектних рішень.
Ролевий кластер "Управління випуском" (release management) безпосередньо відповідальний за безперешкодне впровадження проекту і його функціонування. Цей ролевий кластер бере на себе зв'язок між розробкою рішення, його впровадженням і
18
подальшим супроводом, забезпечуючи інформованість членів проектної групи про наслідки їх рішень.
Єдине бачення проекту
MSF відстоює необхідність вироблення єдиного бачення (shared vision) проекту, що формує цілісний підхід проектної групи до розробки IT-рішення.
Необхідно чітко розуміти цілі і завдання проекту або процесу, оскільки це основа всіх допущень про функціонування рішення в рамках організації замовника. Це стосується і проектної групи, і самого замовника. Загальне бачення чітко окреслює зроблені припущення і забезпечує єдність мети всіх зацікавлених сторін. Це одна з основ моделі проектної групи .
Коли всі учасники проекту розуміють це і виробляють єдине бачення, вони набувають можливості погоджувати свої дії із спільною командною метою.
Не маючи такого бачення, члени проектної групи можуть керуватися такими поглядами, що суперечать один одному, що значно утруднить роботу команди як єдиного цілого. І навіть у разі успіху члени команди навряд чи зможуть оцінити свій внесок, оскільки ця оцінка залежить від точки зору, що приймається.
Прояв гнучкості і готовність до змін
MSF виходить з того, що все навколо безперервно міняється. Неможливо ізолювати ITпроекти від цих змін. Від початку до завершення проекту модель проектної групи MSF гарантує присутність всіх командних ролей і їх участь в процес ухвалення рішень, обумовлених змінами, що відбуваються. Ця модель заохочує гнучкість (agility) при роботі в умовах постійного виникнення нових завдань і потреб. Участь всіх ролей в процесі ухвалення рішень забезпечує розгляд питань з урахуванням повного спектру точок зору.
Заохочення вільного спілкування
Традиційно більшість організацій будували свою діяльність на основі обмеження інформованості співробітників до мінімуму, необхідного для виконання роботи (need-to-know). Часто такий підхід приводить до непорозумінь і знижує шанси команди на досягнення успіху.
MSF проповідує відкритий і чесний обмін інформацією як всередині команди, так і з ключовими зацікавленими особами поза нею. Вільний обмін інформацією не тільки скорочує ризик виникнення непорозумінь і невиправданих витрат, але і забезпечує максимальний внесок всіх учасників проектної групи в зниження невизначеності, що існує в проекті.
Формування команди соратників (команди рівних учасників) припускає залучення всіх існуючих ролей до ухвалення ключових рішень. Тому єдине бачення – неодмінна умова досягнення успіху, на якому, до речі, базується і прийнятий в MSF підхід до управління ризиками. Він припускає залучення всіх членів проектної групи до виявлення і аналізу ризиків, а також створення позитивної, доброзичливої атмосфери для заохочення цієї діяльності. Відкрита, чесна дискусія про наявний позитивний досвід і про можливі напрями роботи над недоліками дає основу тієї культури самовдосконалення, яку проповідує MSF.
Існують чинники, здатні обмежити відвертість обміну інформацією в команді, наприклад, конфіденційність відомостей приватного або комерційного характеру. Проте при ухваленні рішення про обмеження інформації потрібно оцінити, чи дійсно ця секретність є такою важливою? Якщо в команді вироблена атмосфера довіри, то в тих окремих випадках, коли обмеження розповсюдження інформації дійсно необхідне, буде нескладно пояснити своїм колегам його причини і отримати взамін їх довіру і упевненість у виправданості обмежень.
19