Базові принципи MSF

Модель процесів MSF тісно пов'язана з наступними чотирма базовими принципами:

Єдине бачення проекту

Успіх колективної роботи над проектом немислимий без наявності у членів проектної групи і замовника єдиного бачення (shared vision), тобто чіткого, і, найголовніше, однакове, розуміння цілей і завдань проекту. Як проектна група, так і замовник спочатку мають власні припущення про те, що повинне бути досягнуте в ході роботи над проектом. Лише наявність єдиного бачення здатна внести ясність і забезпечити рух всіх зацікавлених в проекті сторін до загальної мети.

Формування єдиного бачення і подальше проходження йому є такими важливими, що модель процесів MSF виділяє для цієї мети спеціальну фазу (фаза "Виробітку концепції"), яка закінчується відповідною віхою.

Проявляйте гнучкість – будьте готові до змін

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

Концентруйтеся на бізнес - пріоритетах

Незалежно від того, чи націлений продукт, що розробляється, на організації або індивідуумів, він повинен задовольнити певні потреби споживачів і принести в деякій формі вигоду або віддачу. Відносно індивідуумів це може означати, наприклад, емоційне задоволення – як у разі комп'ютерних ігор. Що ж до організацій, то незмінним цільовим чинником продукту є бізнес - віддача (business value).

Зазвичай продукт не може приносити віддачу до того, як він повністю упроваджений. Тому модель процесів MSF включає в свій життєвий цикл не тільки розробку продукту, але і його впровадження.

Заохочуйте вільне спілкування

Історично багато організацій будували свою діяльність на основі зведення інформованості співробітників до мінімуму, необхідного для виконання роботи (need-to-know). Часто такий підхід приводить до непорозумінь і знижує шанси команди на досягнення успіху.

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

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

Ключові концепції моделі процесів MSF

Для опису моделі процесів MSF використовуватимуться наступні концепції і терміни:

48

Замовники

MSF розрізняє терміни "замовник" (customer) і "споживач" (користувач, user)

продукту (Що б підкреслити ця відмінність, пару термінів "customer/user" в російських версіях документів по MSF ми переводили переважно як "замовник/споживач", хоча іноді і як "замовник/користувач").

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

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

•Участь замовника. Залученість замовника є необхідною умовою успішності IT-проектів. Модель процесів MSF надає замовникові широкий спектр можливостей для уточнення і модифікації проектних вимог і установки контрольних крапок (віх) для моніторингу роботи над проектом. У свою чергу, це вимагає витрат часу з боку замовника і узяття ним на себе певних зобов'язань.

•Внутрішні і зовнішні замовники. В деяких випадках проектна група і замовник можуть представляти різні організації. Наприклад, замовник може бути покупцем, що укладає угоду із зовнішнім постачальником (яким може бути співтовариство різних організацій-партнерів).

•Контракти. MSF визнає першорядну вагу договірних і юридичних відносин між замовником, його постачальниками і проектною командою і необхідність управління цими відносинами. Точка зору MSF на управління постачаннями (Procurement management) відбита в "Білій книзі" дисципліни управління проектами MSF. Проте існує безліч інших літературних джерел, що висвітлюють вказану наочну область, тому в даному документі тема управління постачаннями досконально не досліджується.

Зацікавлені сторони (учасники)

Зацікавлені сторони (stakeholders) – це особи або групи осіб, чиї інтереси зачіпаються результатами проекту (Слід врахувати, що в MSF визначення термінів іноді декілька відрізняються від

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

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

Ось приклади зацікавлених сторін, представлених зазвичай в IT-проектах:

•Начальники відділів, чий персонал і режим роботи будуть змінені в результаті впровадження рішення, що розробляється.

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

•Функціональні керівники (functional managers), що забезпечують проектну групу необхідними ресурсами.

49

Що є рішення?

Уповсякденному сенсі рішення – це просто стратегія або метод, що дозволяють вирішити проблему. На жаргоні IT-індустрії "рішеннями" все частіше називають програмні продукти. Тому час від часу виникає нерозуміння або навіть скептицизм відносно того, що насправді розуміється під рішенням.

УMSF термін "рішення" (solution) має дуже специфічне значення. Це скоординоване постачання набору елементів (таких як програмно-технічні засоби, документація, навчання і супровід), необхідних для задоволення деякої бізнес - потреб конкретного замовника. Хоча

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

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

На рис. 4 представлені основні елементи успішного рішення.

Рисунок 8. Елементи рішення

Проекти можуть відрізнятися по рівню складності розробки і впровадження. У простих випадках без деяких елементів, показаних на рис. 4, можна обійтися. Проте в складніших і великомасштабних проектах, мабуть, буде потреба у всіх з них.

На додаток до цього:

•Програмно-технічні засоби /спеціально код (custom code), що розробляється, можуть бути як новими, так і вдосконаленими версіями раніше розроблених компонент (в т.ч. що містять елементи, що знов додаються).

•Програмно-технічні засоби можуть включати апаратне забезпечення, програмне забезпечення, периферійні пристрої, мережеві компоненти і тому подібне Код, що спеціально розробляється, – це програмні компоненти, що розробляються для потреб конкретного проекту.

50

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

•Документація покриває всю інформацію, необхідну для установки, підтримки, супроводу і використання рішення.

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

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

•Впровадження включає процедури установки/видалення впроваджуваного апаратного і програмного забезпечення, автоматизовані інструменти впровадження і сценарії

"відкоту" (rollback) в аварійних ситуаціях.

Створення базових версій

У моделі процесів MSF базова версія (baseline) – це відомий і зафіксований стан чогонебудь, використовуване для подальшого порівняння. Це поняття зустрічається в MSF вельми часто. Програмний код, конфігурації серверів, плани і календарні графіки, специфікації, керівництво користувачів і бюджет – ось лише частина тих складових проекту, для яких MSF рекомендує використовувати базові версії. Не маючи базових версій, немає можливості управляти змінами.

Рамки проекту

Рамки (scope) – це сума всіх складових проекту, які повинні стати результатом роботи над ним, а також всі послуги, що надаються, мають відношення до проекту. Рамки проекту визначають, що повинне бути зроблене для реалізації єдиного бачення. Вони є результатом компромісу між сформульованими цілями і умовами реальності і відображають пріоритезацію замовником наявних вимог до створюваного рішення. Частиною процесу визначення рамок проекту є винесення менш важливої функціональності з поточного проекту в плани на майбутнє.

Чітке окреслювання рамок надає можливість:

•Розбиття довготривалих планів на досяжні складові.

•Визначення функціональності, що додається в кожну з версій рішення, що випускаються.

•Гнучкості в плануванні і реалізації рішення.

•Створення базису для вироблення компромісів.

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

Термін "рамки" має два аспекти: рамки рішення і рамки проекту. Не дивлячись на те, що між ними є тісний взаємозв'язок, вони не тотожні один одному. Розуміння відмінностей між ними допомагає ефективному управлінню календарним графіком і вартістю проекту.

Рамки рішення (solution scope) визначають функціональність рішення і його можливості (включаючи ті, що не відносяться до програмного забезпечення). Можливість (функціональність, складова, feature) – це необхідний або бажаний аспект програмного або апаратного забезпечення. Наприклад, попередній перегляд перед друком може бути можливістю текстового процесора; шифрування поштових повідомлень – можливістю поштової програми. Супровідне керівництво користувачів, інтерактивні файли допомоги, операційне керівництво і навчання також можуть бути складовими (features) рішення.

51