Процес контролю змін. Управління незапланованим ростом об’єму

Управління незапланованим ростом об’єму

Незапланований ріст об’єму ставить під загрозу:

- 80% проектів по розробці систем управління інформацією:

- 70% проектів по розробці військових систем ПЗ;

- 45% проектів по створенню ПЗ, що виконуються за контрактом.

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

Вимоги до системи управління інформацією, як правило, збільшуються на 1% на місяць (Jones, 1996b). Темп приросту може складати до 3,5% у місяць для комерційного ПЗ, при цьому темпи зростання інших типів проектів входять у цей показник.

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

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

Інша стратегія – це уміння говорити «Ні». психологія більшості людей побудована таким чином. Що їм важко відмовляти, і в даному випадку може виникнути стан постійного пресингу. К Вігерс пропонує пом’якшити цей підхід, замінивши «Ні» на «Не зараз» (вимога обов’язково буде виконана, але не в поточній версії).

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

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

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

Якщо запропонована зміна не настільки важлива, щоб зацікавлена ​​в проекті
особа витратила пару хвилин на передачу її через стандартні, прості канали, то варто замислитися про її цінності взагалі. Процес управління повинен бути ретельно задокументований, максимально простий і, що найважливіше, ефективний.
Після реєстрації запиту на зміну слід прийняти рішення про його подальшу
долі. Рада з управління змінами (change control board, CCB) (іноді її
називають радою з управління конфігурацією) була визначена кращим практичним рішенням при розробці ПЗ.

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

При прийнятті рішення за запитом необхідно виходити: а) зі ступеня важливості запиту для Замовника, і б) з його вартості для Розробника. Вартість визначається на підставі аналізу впливу зміни.

Дата добавления: 2014-01-11