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

Часовий відрізок між проміжною віхою "Упроваджене рішення стабілізоване" (Deployment Stable) і головною віхою "Впровадження завершене" (Deployment Complete) іноді називають "періодом затишшя" ("quiet period"). Хоча проектна група більше активно не працює, вона необхідна для реагування на ескалированые до неї проблеми. Зазвичай період затишшя складає від 15 до 30 днів.

Метою періоду затишшя є оцінка того, наскільки добре рішення працює в нормальних виробничих умовах і наскільки витратним буде його супровід. Організації, що використовують MOF, вимірюють кількість інцидентів, час простою і визначають експлуатаційні характеристики рішення. Ці дані допомагають команді супроводу, обслуговуючій угоди про рівень послуг (Service Level Agreement - SLA), сформувати оцінки об'єму річного рівня послуг. Для отримання подальшої інформації, див. MOF Operations

Guide for Service Level Management.

Методики моделі процесів MSF, що рекомендуються

Нижченаведені супровідні методики покликані допомогти проектним групам в застосуванні моделі процесів MSF в їх роботі.

Стимулювання винахідливості для розширення функціональності й обмеження ресурсів

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

Фіксування календарного графіка

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

Календарне планування на невизначене майбутнє

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

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

При виборі тимчасового буфера рекомендується враховувати наступне:

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

•Буферний час повинен виділятися нібито під додатково існуюче завдання. Зазвичай буфера створюються перед головними віхами, особливо пізнішими з них. Тимчасові буфера завжди повинні доповнювати критичний шлях проекту (project’s critical path).

75

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

•Використання буферного часу по ходу проекту повинне піддаватися жорсткому контролю.

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

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

Використання паралельно працюючих компактних команд

з частою синхронізацією зусиль.

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

Розбиття великих проектів на реальні частини

Фундаментальною стратегією майкрософту є розбиття великих проектів на багато версіонування випусків без (або з мінімально короткою) окремої фази супроводу.

Отримання уроків з пройдених віх

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

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

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

Використання прототипіювання

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

Використання частих білдів і швидких тестів

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

76