Контрольні відмітки етапів робіт

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

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

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

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

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

Графік робіт

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

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

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

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

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

Мал. Процес складання графіку робіт

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

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

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