Контроль етапів робіт

ПЛАНУВАННЯ ПРОЕКТОМ. ПЛАН ПРОЕКТУ. КОНТРОЛЬ ЕТАПІВ РОБІТ. ГРАФІК РОБІТ.

Планування проекту

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

Структура плану створення ПЗ розглядається. Тут лише зазначимо, що, крім розробки плану проекту, на менеджера лягає обов'язок розробки інших видів планів. Ці види планів коротко описані в табл. 4.1.

Таблиця 4.1. види планів

У лістингу 4.1 показаний процес планування створення ПО у вигляді псевдокоду. Тут зроблено акцент на тому, що планування - це ітераційний процес. Оскільки в процесі виконання проекту постійно надходить нова інформація, план повинен регулярно переглядатися. Важливими чинниками, які повинні враховуватися при розробці плану, є фінансові та ділові зобов'язання організації. Якщо вони змінюються, ці зміни також повинні знайти відображення в плані робіт.

Лістинг 4.1. Процес планування проекту

Визначення проектних обмежень

Первісна оцінка параметрів проекту

Визначення етапів виконання проекту і контрольних відміток

While поки проект не завершиться, чи не буде зупинений loop

Складання графіка робіт

Початок виконання робіт

Очікування закінчення чергового етапу робіт

Відстеження ходу виконання робіт

Перегляд оцінок параметрів проекту

Зміна графіка робіт

Перегляд проектних обмежень

If (виникла проблема), then

Перегляд технічних або організаційних параметрів проекту

End if

End loop

Процес планування починається з визначення проектних обмежень (тимчасові обмеження, можливості персоналу, бюджетні обмеження і т.д.). Ці обмеження повинні визначатися паралельно з оцінюванням проектних параметрів, таких як структура і розмір проекту, а також розподілом функцій серед виконавців. Потім визначаються етапи розробки і те, які результати (документація, прототипи, підсистеми або версії програмного продукту) повинні бути отримані після закінчення цих етапів. Далі починається циклічна частина планування. Спочатку розробляється графік робіт по виконанню проекту або дається дозвіл на продовження використання раніше створеного графіка. Після цього (зазвичай через 2-3 тижні) проводиться контроль виконання робіт і відзначаються розбіжності між реальним і плановим ходом робіт.

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

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

План проекту

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

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

1. Введення. Короткий опис цілей проекту і проектних обмежень (бюджетних, часових і т.д.), які важливі для управління проектом.

2. Організація виконання проекту. Опис способу підбору команди розробників і розподіл обов'язків між членами команди.

3. Аналіз ризиків. Опис можливих проектних ризиків, ймовірності їх прояви і стратегій, спрямованих на їх зменшення. Тема управління ризиками розглянута в розділі 4.4.

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

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

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

7. Механізми моніторингу та контролю за ходом виконання проекту. Описуються надаються менеджером звіти про хід виконання робіт, терміни їх надання, а також механізми моніторингу всього проекту.

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

Контроль етапів робіт

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

При плануванні процесу визначаються контрольні мітки – межі, віхи, що відзначають закінчення певного етапу робіт. Для кожної контрольної мітки створюється звіт, який надається керівництву проекту. Ці звіти не повинні бути великими об'ємними документами; вони повинні підводити короткі підсумки закінчення окремого логічно завершеного етапу проекту. Етапом не може бути, наприклад, "Написання 80% коду програм", оскільки неможливо перевірити завершення такого "етапу": крім того, подібна інформація практично марна для управління, оскільки тут не відображається зв'язок цього "етапу" з іншими етапами створення ПЗ.

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

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

Рис. 4.1. Етапи процесу розробки специфікації

Графік робіт

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

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

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

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

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

Рис. 4.2. Процес складання графіка робіт

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

Існує хороше емпіричне правило: оцінювати часові витрати так, як ніби нічого непередбаченого і "поганого" не може трапитися, потім збільшити ці оцінки для обліку можливих проблем. Можливі, але важко прогнозовані проблеми істотно залежать від типу і параметрів проекту, а також від кваліфікації і досвіду членів команди розробників. Так як це правило емпіричне, дозволю дати раду, заснований на моєму досвіді. До вихідних розрахункових оцінок я завжди додаю 30% на можливі проблеми і потім ще 20%, щоб бути готовим до того, що я не можу передбачити.

Графік робіт за проектом зазвичай представляється у вигляді набору діаграм і графіків, що показують розбиття проектних робіт на етапи, залежності між етапами і розподіл розробників по етапах. Ці діаграми розглядаються в наступному розділі. Зазначу, що в даний час існує багато різних програмних засобів підтримки управління проектами, наприклад Microsoft Project.

1.