Вимірювана мета
У нашому прикладі проект підійшов до кінця, але проект завершити в строк не вдається. Співробітник намагається здати проект, але замість цього з'являється нове завдання від замовника… Подібна ситуація є типовою ознакою втрати контролю. Це зрозумів і замовник, призначивши крайній термін здачі (Dead Line). У MS Project існує засіб для відмітки “Dead Line” і сповіщенні про підхід до нього.
Рис. 10. Встановлення ознаки “Dead Line” в MS Project.
Методи обчислення реальних термінів завдань
У нашому прикладі менеджер потрапив у важку ситуацію. Найнеприємнішим є те, що оцінки співробітників недостовірні і дізнатися повний склад робіт неможливо. Виходом є використання статистичних методів прогнозування. Розглянемо типові прийоми.
У Microsoft просто додають 30% до загальної тривалості планових завдань (Buffer time в 30%). Цей резерв витрачається на покриття рисок.
Метод Load Factor (або на скільки помножити слова програміста), що рекомендується групою XP. Статистичний аналіз проектів в малих групах розробки показав, що можна достатньо точно дізнатися реальний термін завдання, просто помноживши слова виконавцям на якийсь коефіцієнт. Ось орієнтовні значення коефіцієнта:
x2 - оптимістична оцінка
x3 - нормальний проект
x4-5 - застосування нестандартних технологій
Схема PERT обчислення реального терміну. Часто буває, що різні оцінки дають різні терміни; в цьому випадку можна застосувати метод розрахунок реального терміну по наступній формулі: Реальний_срок=(Оптімістічний_срок+4*ожідаємий_срок+пессимістічний_срок) /6 Коефіцієнти в даній формулі (4 і 6) отримані шляхом аналізу статистики великої кількості проектів. Слід зазначити, що схема PERT ефективна тільки в тому випадку, якщо дійсно є різні оцінки. Якщо менеджер хоче через PERT просто переконати себе, що його рішення єдине правильно, то підгонка статистики не дасть нічого, окрім позитивної відповіді. Про те, як використовувати засоби автоматизації PERT-вычислений в Microsoft Project мова піде нижчим.
Методика Монте Карло. Система моделювання ризиків на базі Монте Карло точніші чим PERT (точність вище приблизно на 10%), плюс такі засоби дозволяють задавати рівень риски в проекті. Прикладом такого засобу для Microsoft Project є Turbo Risk Manager.
Важливе зауваження. Приведені статичні коефіцієнти є лише орієнтуваннями. Необхідно накопичувати свою власну статистику по веденню проектів для того, щоб отримати специфічні для даної технології і даних виконавців калібрувальні коефіцієнти.
Що показує статистика?
Після завершення проекту необхідно обчислити статистичні показники для подальшого прогнозування термінів: співвідношення стадій, типова тривалість, вартості і так далі
Саме тому важливо розділити план на технологічні стадії, склад яких независит від виду проекту.
Приведемо типові статистичні показники Канера-фолка і прокоментуємо їх щодо нашого прикладу.
Продукт виходить в середньому через 8 внутрішніх і 3 зовнішніх версії. З цього виходить, що варто планувати 8 версій, і, швидше за все, буде потрібно декілька проектів. Про це ми вже говорили вище.
Для розробки ПО характерні наступні статистичні показники співвідношення технологічних стадій:
Розробка - 37% Супровід - 63%
Етап розробки розділяється на стадії з наступними пропорціями:
Постановка - 34% Кодування - 21% Тестування - 45%
Якщо розглянути наш приклад, то ми побачимо, що дана статистика працює. Проте якщо ми подивимося на первинний план, то побачимо невідповідність трудомісткості стадій плану середнім статистичним показникам.
Порада. Перевіряйте план на відповідність статистиці!