Проектний план Планування проекту. Основні поняття. Кумулятивний метод розрахунку ризиків є методом оцінки факторів ризику, які можуть завадити отримати запланований дохід. При побудові ставки дисконту за даним методом за основу беруть безризикову норму.

Планування – фундамент, на якому будується будь-який проект. І чим він міцніший, тим більша ймовірність, що проект буде успішним. Для цього і існує project management plan, що складається з трьох блоків: активностей (цілей, концепції проекту, ресурсні призначення тощо), завдань та ресурсів (люди, обладнання, гроші тощо).

Що таке план керування проектом?

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

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

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

Зазвичай у проекті задіяно два плани управління:

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

Навіщо він потрібний?

Хороший план має відповідати на базові питання:

• Чому?— Яку проблему вирішує проект, у чому його цінність? Чому проект спонсорується?
• Що?— Які основні продукти (доставки) проекту? Що потрібно зробити для успішного завершення?
• Хто?— Кого залучити до роботи над проектом і за що відповідатиме кожен із учасників? У якому форматі вони будуть організовані?
• Коли?— Які часові рамки проекту? Коли будуть виконані ключові моменти – віхи?

Віха (milestone) - контрольна точка під час проекту (наприклад, перехід до нової ітерації).

Завдання Project Management Plan такі:

Ключові складові плану управління проектом

Складати плани по одному шаблону не вдасться, але існує набір базових елементівзнаючи які, легко побудувати каркас майбутнього проекту:

• короткий опис плану— пара абзаців про ключові елементи проекту, які розкриваються в плані.
• стратегічне та організаційне вирівнювання— сюди включаються результати аналізу стейкхолдерів та організаційні цілі, які будуть підтримані під час проведення проекту.
• визначення галузі проекту— до цього пункту входять такі елементи: завдання та цілі, очікувані результати, інструменти PBSі WBS. У розділі також важливо вказати специфікації якості — критерії ефективності продукту або послуги з точки зору клієнта.

PBS (product breakdown structure) – інструмент для аналізу, документування та передачі результатів проекту. PBS - частина методики планування на основі продукту (один з головних методів моделі проектного менеджменту PRINCE2).

WBS (work breakdown structure) - ієрархічна розбивка проектної роботибільш дрібні завдання (операції) до рівня, коли зрозумілі способи виконання, є можливість оцінки та планування.

• оцінка здійсненності та плани на випадок непередбачених обставин— містить оцінку економічної, технічної та організаційної здійсненності проекту, визначення та аналіз ризиків, пропонує плани дій у критичних ситуаціях для усунення факторів ризику.
• обмеження- список відомих обмежень, що накладаються середовищем або керівництвом (фіксований бюджет, нестача ресурсів тощо).
• вимоги до проектній команді - Визначення організації проектної команди, ролі та відповідальність учасників. Тут же прописуються вимоги до навчання.
• матеріальні вимоги- включає елементи місця, програмного забезпечення, обладнання та інші ресурси для завершення проекту.
• графік та віхи— у цьому розділі визначаються віхи та графік активностей проекту, включаючи три ключові елементи: доставки (результати роботи), дати або тривалість та критичні залежності.
• бюджет (кошторис)- Очікувані витрати зазвичай діляться на три типи: капітальні (купівля складу під зберігання продукції), видаткові (щотижневі закупівлі матеріалів для заготівель) та трудові (виплата зарплат учасникам команди)
• управління ризиками— докладний опис процесу управління ризиками: від ідентифікації (через мозковий штурм, інтерв'ювання, SWOT-аналіз) до вибору системи моніторингу (про- або реактивна).
• управління змінами— схоже на попередній пункт, лише стосується можливих змін (а їх буде багато). Тут слід прописати алгоритм проведення змін, методології управління (ADKAR, AIM та інші), формулу обчислення ймовірності успіху змін та ін.
• управління комунікаціями- Пункт стосується і команди, і стейкхолдерів. Проектний менеджер у цьому розділі має описати систему комунікацій, яка використовуватиметься, та канали передачі документації щодо продуктивності проекту сторонам проекту.
• вкладення— сюди можуть потрапити будь-які документи: від окремих нотаток до презентацій та сертифікатів.

Список розділів плану доповнюється залежно від особливостей проекту.

Базовий та робочий плани проекту

Під час роботи над проектом проектний менеджер, учасники команди та стейкхолдери працюють із двома видами планів:

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

У ході розвитку проекту можна порівняти базовий та робочий плани,зрозуміти, де «провисає» робота, а де навпаки — виконання проекту йде швидше (економніше) задуманого. В рідких випадках зміни по ходу проекту вносяться до базового плану управління.

У Worksection діаграма Ганта дозволяє побачити різницю між базовим та робочим планом
(синє - загальний час, червоне – прострочені завдання, зелене – вчасно завершені завдання)

Розробка плану управління проектом

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

Ми сконструювали просту покрокову процедуру написання плану, що складається з 16 пунктів:

1. Визначте стартові умови розробки плану— важливо зрозуміти, з ким ви його розроблятимете (один, за участю керівництва, стейкхолдерів), де і коли тощо. Важливо заздалегідь прописати методики (наприклад, брейнштормінг) та програмне забезпечення (типу Microsoft Visual Studio), які будуть використовуватись у створенні плану – це значно заощадить час та спростить завдання.
2. Визначте стартові умови проекту- Тут описується зміст проекту, список вимог до результатів та його управління. Наприклад, задуманий проект із продажу якісних неонових спіннерів із принтами супергероїв. Внаслідок успішної реалізації річного проекту має бути продано 100 000 одиниць товару за 12 місяців зі старту проекту, після чого пройде продаж бізнесу. Структура управління проектом складатиметься з генерального проектного менеджера у центральному офісі та відповідних відділів у регіональних представництвахпроекту.
3. Розмежуйте дії, що виконуютьсяна такі, що робитимуться силами проектної команди, та аутсорсинг.
4. Створіть WBS проекту, розбивши його на менші керовані шматки.Це схоже на Agile підхід, коли повний код ділиться на багато маленьких робочих шматків.
5. Пропишіть набір завдань для виконання кожної частини WBS та побудуйте залежність між ними.Так, завдання купівлі та облаштування регіонального складу для зберігання спіннерів може бути виконано тільки після аналізу ринку та продажу певної кількості товару у конкретній області.
6. Визначте необхідні компетенціїдля виконання кожного завдання.Тут важливо не підганяти необхідні знання та навички під потенційних учасників проекту, а зосередитись на «ідеальних» вимогах.
7. Оцініть тимчасові та грошові витративиконання завдань.
8. Розробте проект.Методика хороша саме для продуктового бізнесу, і її легко відобразити через схеми (наприклад, діаграму Ганта).
9. Створіть календарний планпроекту- Початкова, проміжні, кінцева дати. Наприклад, спрощена схема: 1 листопада запускається проект, 1 грудня – старт продажів до Нового року, 31 грудня – підбиття підсумків новорічних продажів, 15 січня – запуск спеціалізованої лінійки до Дня святого Валентина, 20 лютого – підбиття підсумків тощо.
10. Розрахуйте вартість проекту(у нашому випадку — скільки обійдеться успішна реалізація 100 000 спіннерів і продаж бізнесу).
11. Уточніть вимоги до якості(Наприклад, прописані стандарти якості виготовлення спіннерів).
12. Призначте відповідальними конкретних людей завдання.Тут вам і стане в нагоді п. 6, зі списком якого ви пов'язуватимете компетенції членів команди.
13. Розплануйте формат роботи зі стейкхолдерами- підберіть канали зв'язку, визначте ступінь їхнього залучення в роботу над проектом і т.д.
14. Прорахуйте ризики (наприклад, за формулою кумулятивного методу).У прикладі зі спіннерами це може бути банальне перенасичення ринку, порушення умов договору експедиторами тощо. Під час аналізу ризиків використовуйте дані з попередніх пунктів.
15. Запишіть обмеження проекти та з їх урахуванням внесіть дані до плану управління проектом.У нашому випадку деталі спіннерів доставляють із Китаю, складання відбувається в Україні, а це вже обмежує можливість жорсткого контролю якості матеріалів та швидкого переналагодження.
16. Пройдіть ще раз по всіх пунктах плану, щоб досягнути дзен. Залишилося доопрацювати список закупівель та вимог до них, погодити з зацікавленими особами- І у вас на руках готовий плануправління проектом.

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

У Владислав Гагарський як приклад наводить таку схему затвердження:

1. Керівники проектних груп надсилають спільно розроблений план керівнику проекту.
2. Керівник затверджує план управління проектом або у разі помилок організовує внесення змін.
3. Проектний керівник передає затверджений план керівникам проектних груп для її подальшої реалізації.

Але ця схема більше підходить готовим колективам, що виконують один за одним кілька проектом або змінили профіль діяльності. Для тих, хто «з нуля» вирішив написати та затвердити project management plan, методика не підійде. У таких випадках базовий проектзатверджується керівником компанії чи проекту (замовником) з подачі проектного менеджера.

Вердикт

непаличка-виручалочка.

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

Але план це той старт, який визначить 50% успішності проекту.

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

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

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

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

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

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

У плані проекту докладно аналізуються методи забезпечення збалансованості. проектних витрат, термінів реалізації, розкладу та якості.

На етапі планування проекту вирішуються такі завдання:

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

Укрупнена структура плану управління проектом

Основні етапи планування

Формування цілей

У межах планування ставляться дві групи цілей.

Формальні ціліє критерієм оцінки корисності діяльності та стану проекту, що виводиться із мотивації діяльності осіб, які приймають рішення.

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

Аналіз проблем

Аналіз проблем включає наступні кроки:

• визначення фактичного стану (аналіз становища);
• прогноз становища;
• ідентифікація проблем за допомогою протиставлення системи цілей та результатів аналізу та прогнозу становища;
• структурування проблем

У ході структурування проблем спочатку їх необхідно розбити на дві групи:

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

Потім необхідно проблеми, віднесені до другої категорії, розбити на два класи:

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

Ці проблеми розглядаються у процесі перспективного планування та прогнозування.

Пошук альтернатив

Під альтернативами розуміються взаємовиключні варіанти рішень.

Під час здійснення довгострокових проектів важливе місце займає прогнозування. При цьому слід розрізняти два види прогнозів.

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

Оцінка альтернатив

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

У ході реалізації проекту має виконуватися актуалізація плану з урахуванням поточного стану та змін, що вносяться. Таким чином, план проекту стає основою оцінки прогресу, досягнутого під час виконання цього проекту.

Для забезпечення реалізованості та точності плану проекту менеджер проекту має вирішити такі завдання.

1. Залучення основних учасників проекту до процесу планування, забезпечення відповідальності за плановані параметри.
2. Досягнення узгодженого розуміння структури та обсягу робіт проекту та потреб у ресурсах із замовником та основними учасниками проекту.
3. Планування організаційної структуриреалізації проекту та забезпечення залучення необхідних ресурсів на проект.
4. Погодження відповідальності на основних учасників за результати.

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

Існують простіші варіанти, такі як зробити Landing Page за допомогою сервісу LP Generator або подібного до нього. Можна не обмежуватись односторінником і зробити повноцінний сайт на конструкторі сайтів. Це робочі варіанти, я нікого не відмовляю від них. Все залежить від цілей, які ви ставите перед сайтом і, відповідно, ваших вимог. Я пропоную план проекту багатосторінкового сайту із орієнтацією на SEO просування без використання конструктора сайтів.

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

Завдання розробки сайту включає різні етапи, в яких задіяні різні фахівці. Я починаю з визначення основних великих блоків. У цей момент план виглядає так:

1. Класичний маркетинг: знайомство з продуктом, конкурентами, розробка УТП
2. Підбір семантики
3. Розробка структури сайту
4. Прототипування
5. Дизайн
6. Верстка
7. Програмування
8. Тестування
9. Запуск

Картинка стає чіткішою, але не вистачає деталей, тому дроблю великі завдання на дрібніші.

Приблизна кількість та типи сторінок

Для розрахунку плану проекту я складаю орієнтовний список сторінок сайту та типи завдань, які необхідні для даної сторінки. Це допомагає мені робити розрахунок за робочими годинами по завданням. Список сторінок, швидше за все, в ході роботи буде змінюватися, але на даному етапі для розрахунків буде достатньо. Табличка виглядатиме приблизно так.

Сторінки (маски)	Кількість сторінок	Зібрати СЯ	ТЗ від SEO спеціаліста	Текст	Прототип	Дизайн	Верстка	Програмування
Головна	1	1	1	1	1	1	1	1
Корпоративним кліентам	1	1	0	1	1	1	1	1
Послуги (сторінка розділу)	1	1	1	1	1	1	1	1
Розділ послуги	3	3	3	3	2	2	2	2
Підрозділ послуги	7	7	7	7	1	1	1	1
Запитання та відповіді (FAQ)	1	0	1	0	1	1	1	1
Сторінка окремої статті	х	х	х	х	1	1	1	1
Контакти	1	0	1	1	1	1	1	1
Про компанію	1	0	1	1	1	1	1	0
Ціни	1	0	1	0	1	1	1	1
	17	13	16	15	11	11	11	10

Деталізація списку завдань

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

Завдання	Виконавець	Годинник	Коментар
Виділення основних послуг та визначення конкурентів	Маркетолог	6	Важливо розуміння обсягу сайту. Після вивчення конкурентів список може бути скоригований.
Експрес-аналіз сайтів конкурентів	Маркетолог	24	Залежно від знання ринку та складності проекту, час може бути скоригований.
Формулювання переваг та розробка УТП	Маркетолог	8	На основі інформації про компанію та конкурентів виробляємо основну пропозицію та тезово відповідаємо на запитання: «чому треба купити у нас».
Початкове планування структури сайту	Маркетолог	2	Тільки після цього можна скласти базову структуру сайту, що виглядає на даному етапі як список сторінок.
Збір семантичного ядра та сегментування	SEO-спец	26	SEO-фахівець збирає повний список запитів та об'єднує їх у смислові групи. Час я розраховую приблизно по 2 години на кожну сторінку попередньої структури сайту (для яких актуальним є SEO, зрозуміло). Якщо вже існує сайт, слід врахувати запити, за якими сайт вже знаходиться в пошуковій видачі.
Узгодження та затвердження сем. ядра	Маркетолог	8	Краще семантичне ядро ​​погодити і із замовником, щоб уникнути непорозуміння надалі.
Коригування структури сайту з урахуванням сем.ядра	SEO-спец	6	Пропозиції SEO-фахівця зі списку сторінок, навігації.
Доопрацювання та узгодження структури сайту з урахуванням сем.ядра	Маркетолог	4	На цьому етапі ми отримуємо скелет сайту. Далі я припускаю наявність типових сторінок. Наприклад, всі сторінки різних послуг виконані по одному шаблону.
Базові рекомендації SEO за контентом для сторінок	SEO-спец	8	Щоб не довелося переробляти прототипи або навіть готові сторінки, я рекомендую отримати SEO побажання вже на цьому етапі. Цей пункт про блоки на сторінці. Я закладаю 0,5 годин на 1 стор.
SEO ТЗ на контент сторінок	SEO-спец	30	Даний пункт про рекомендації щодо текстів, які мають бути на сторінках. Я закладаю по 2:00 на кожну сторінку.
Написання текстів	Копірайтер/Маркетолог	90	Якщо вам пощастило знайти хорошого копірайтераможете довірити написання текстів йому. Найчастіше тексти для сторінок послуг, оригінальних сторінок нібито «Про компанію», «404», «Контакти» тощо. я пишу сама. Час беру за своїми мірками, тому закладаю по 6:00 на 1 стор. Але від проекту до проекту може змінюватися.
Прототипування сторінок	Маркетолог	82	Закладаю також по 6 годин на 1 сторінку, плюс 2 робочі дні на головну, тому що необхідно підготувати розмітку макета, шапку та підвал. Мені зручно робити прототипи паралельно із написанням текстів.
Підготовка ТЗ дизайнеру	Маркетолог	13	Хоча прототипи в Axure RP є досить наочними, за деякими пунктами дизайнеру необхідно дати окремі рекомендації, особливо на початку. Описати стиль, колірну гаму. Мені зручно надіслати приклади стилю і обговорити усно, щоб бути впевненою, що ми говоримо про те саме.
Дизайн головної сторінки + рекомендації на адаптив	Дизайнер	16	Оскільки зараз неможливо жити без мобільного сайту, то раджу подумати про адаптивну версію вже на цьому етапі. Показала себе робочою схемою, коли дизайнер готує не кілька варіантів дизайну, а пише рекомендації. Часу витрачається менше, а результат однаковий.
Дизайн решти сторінок + рекомендації на адаптив	Дизайнер	66	Я рахую по 6 годин на сторінку. Десь може бути більше, десь менше. У цей час закладаю і підготовку верстальнику рекомендацій для адаптивної верстки.
Затвердження та узгодження дизайну	Маркетолог	14	На затвердження макетів завжди витрачається час, особливо коли йдеться про затвердження стилю і дизайну перших сторінок. Раджу закласти у плані час на це.
Підготовка оптимізованих метатегів та H1	SEO-спец	16	Загалом цей пункт можна включити будь-якої миті до запуску сайту, але не забуваємо!
Складання ТЗ на верстку та програмування	Маркетолог	17	Оскільки я розглядаю варіант сайту послуг, то не передбачаю складних у реалізації модулів. Тому закладаю 1,5 години на сторінку.
SEO рекомендації для етапу верстка та програмування	SEO-спец	6	Знову ж таки, щоб не переробляти, краще відразу готувати сайт з урахуванням подальшого просування у пошукових системах.
Верстка (адаптивна)	Верстальник	104	Тут все залежить від складності макетів. Я припускаю 2 дні на розгортання інфраструктури, підготовку до роботи та по 8 годин на 1 стор.
Затвердження та узгодження верстки	Маркетолог	24	Можна не включати цей пункт, але перевіряти верстку, писати правки та приймати все одно доведеться. Залежно від команди та проекту на це може піти чимало часу. Тому я рекомендую закласти його у проект.
Програмування	Програміст	80	Складання розрізнених сторінок у готовий сайт. Виведення у CMS модулів для подальшого керування контентом сайту без участі розробника.
Затвердження та узгодження програмної частини	Маркетолог	15	Щиро кажучи, здається, що я мало часу закладаю на це завдання. Без цього етапу ви 100% не обійдетесь, залишайте на нього час.
Тестування та налагодження	Маркетолог	40	Це завдання натиснути на всі кнопочки, подивитися всі сторінки, спробувати всі функції CMS і перевірити сайт в різних браузерах і на різних пристроях. Якщо проект невеликий, то можливо достатньо перевірки самотужки, для складних підключаємо тестувальників.
Запуск бойової версії сайту	Програміст	8	Досі всі перевірки йшли на тестовому майданчику. Тільки зараз переходимо на відкритий сайт для користувачів.
Підключення аналітики+CallTouch+налаштування цілей	Маркетолог/Програміст	16	Опціональний пункт, який починає стає нормою, тому що без аналітики неможливо зрозуміти, наскільки сайт справляється зі своїми завданнями.
Рекомендації щодо первинної SEO-оптимізації	SEO-спец	8	Уважно слухаємо, що нам каже SEO-фахівець та виконуємо його рекомендації. Якщо спочатку сайт готувався за поточним планом, то доробок має бути мінімум, але robots.txt та карту сайту готуємо лише зараз.
Реалізація SEO-рекомендацій	Верстальник/Програміст	16	Розраховую 2 робочі дні.
Перевірка застосування SEO-рекомендацій на тестовому майданчику	Маркетолог	4
Застосування SEO-рекомендацій на основному сайті	Програміст	3

Розрахунок термінів проекту

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

Таблиця велика, тому даю посилання на Google таблицю, де можна переглянути готовий результат.

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

Також додаю загальну таблицю щодо термінів проекту.

	Годинник	Дні
Разом на проект:	760	62
Робочих днів у міс		20
Термін проекту (міс.)		3.1

Я розумію, що 62 дні не дорівнює 760 годинам. Різниця обумовлена ​​за рахунок одночасного виконання частини завдань різними фахівцями.

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

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

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

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

• за обсягом робіт,
• за пріоритетом,
• на вибір методик управління,
• за нормами якості,
• за формою підтримки зв'язку із зацікавленими особами,
• за критеріями виміру продуктивності та ін.

1. Передісторія проекту.
2. Завдання та цілі.
3. Масштаб.
4. Кордони (обмеження).
5. Припущення (допущення).
6. Впливи та залежності.
7. Ризики та проблеми.
8. Стратегії та методики.
9. Кошти та засоби контролю часу, ресурсів, якості, масштабу.
10. комунікації.
11. Графік поставок.
12. Продуктивність та її вимір.
13. Реалізація вигод.

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

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

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

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

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

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

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

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

Структурна декомпозиція робіт (СДР)

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

1. Виконання робіт верхнього рівня досягається шляхом виконання робіт нижнього рівня.
2. Батьківський процес може мати кілька дочірніх робіт, виконання яких автоматично завершує батьківський процес. Але для дочірньої роботи існує лише одна батьківська.
3. Декомпозиція батьківського процесу на дочірні роботи проводиться за єдиним критерієм: або за ресурсами, або за видами діяльності, або за етапами життєвого циклу та ін.
4. На кожному рівні мають бути зібрані рівнозначні дочірні роботи. Критеріями виявлення їх однорідності можуть, наприклад, виступати обсяг і час виконаних робіт.
5. При побудові структури загалом необхідно застосовувати різні критерії декомпозиції різних ієрархічних рівнях.
6. Послідовність для критеріїв декомпозиції вибирається те щоб максимально більша частина взаємодій і залежностей між роботами виявилася нижніх рівнях ієрархічної структури. Роботи вищих рівнів- Автономні.
7. Декомпозиція робіт вважається завершеною, якщо роботи нижнього рівня зрозумілі менеджеру та учасникам проекту, зрозумілі способи досягнення кінцевого результатута його показники, однозначно розподілено відповідальність за виконання робіт.

На основі СДР створюється список робіт проекту. А далі визначається послідовність їх виконання, взаємозв'язку за допомогою організаційно-технологічних моделей та тривалість робіт.

Тривалість робіт

Тривалість робіт визначається з урахуванням нормативів, з урахуванням особистого досвіду (коли є приклад аналогічних робіт), з урахуванням розрахункових методів планування проектів. До таких методів відноситься, наприклад, метод подійного аналізу PERT, що застосовується при невизначеності оцінки тривалості операцій. Існують, однак, різні способи керування проектним часом.

• PERT. Метод розглядається як середньозважена трьох видівпрогнозів: оптимістичного, очікуваного та песимістичного. Після встановлення тривалості за кожним прогнозом (із застосуванням формули та/або із залученням експертів) розраховується ймовірність кожного з прогнозів. А потім значення кожного з прогнозів та їхньої ймовірності перемножуються, а величини складаються.
• Мережева діаграма. Мережевою діаграмою називається відображення робіт та залежностей між ними у графічному вигляді. Найчастіше вона представлена ​​у вигляді графіка, вершинами якого стають проектні роботи, які послідовність і взаємозв'язок демонструється сполучними стрілками.
• Діаграми Ганта. Це горизонтальна діаграма з відображенням проектних робіт як відрізків, орієнтованих за календарем. Довжина відрізка відповідає тривалості роботи, а стрілки між відрізками – взаємозв'язок та послідовність робіт.

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

Трудові ресурси проекту

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

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

Вартість проекту

У плануванні вартості проекту можна виділити кілька етапів:

1. На першому етапі визначається вартість використання ресурсів, кожної проектної роботи та проекту загалом. Вартість проекту тут стає сукупність цін ресурсів і виконання робіт. До факторів, що враховуються, входять вартості обладнання (у тому числі – взятого в оренду), працю штатних співробітників та найнятих за контрактом, матеріали, перевезення, семінари, конференції, вартість навчання та ін.
2. Другий етап передбачає складання, погодження та затвердження кошторису проекту. Кошторис проекту тут – це документ, в якому міститься обґрунтування та розрахунок загальної вартості проекту. Виготовляється він, як правило, на основі величини необхідних ресурсів, обсягів робіт та ін.
3. Третій етап включає складання бюджету, його погодження та затвердження. Бюджет вводить обмеження на ресурси та складається у вигляді:

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

У цьому управління бюджетними ризиками у окремому розділі проектного планування.

Планування ризиків

У цьому розділі описуються процеси, пов'язані з визначенням, аналізом, оцінкою ризиків та розробкою заходів реагування на них. Ризики характеризуються трьома параметрами:

• ризиковою подією,
• ймовірністю настання ризикової події,
• розміром втрат у разі реалізації фактора ризику.

Простий метод планування ризиків реалізується з дотриманням наступної послідовності дій:

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

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

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

Основні функції плануваннянаведено далі.

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

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

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

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

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

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

Група процесів планування

Управління людськими ресурсами проекту

Планування

Розробка плану управління людиною- ними ресурсами

Визначення

Управління термінами проекту

Визначення

операцій

Управління

цілісністю

Планування закупівель

Управління вартістю проект^

Оцінка вартості

Управління якістю проекту

Розробка плану управління проектом

Визначення

послідовності

операцій

ресурсів операцій

Планування

якості

тривалості

операцій

Розробка

розклади

Управління ризиками проекту

Визначення

Планування

управління

ризиком

Проведення якісного аналізу ризиків

Проведення кількісного аналізу ризиків

Планування відповідей на ризики

Рис. ЗЛО. Процеси планування

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

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

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

Планування полягає у складанні наступних планів:

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

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

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

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

Мережевий план із кількома проектами (для вищого керівництва)

Рівень 1

Рівень 3

Рівень 2

Мережевий план із ключовими етапами (віхами)

Детальний мережевий план

Рис. 3.11.Багаторівневі мережеві плани

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

Стратегічне плануванняє процес розробки стратегічних, укрупнених, довгострокових планів.

Детальне (оперативне, тактичне) плануванняпов'язано з розробкою тактичних, детальних планів (графіків) на основі ієрархічної структури робіт (ІСР) для оперативного управління

лише на рівні відповідальних виконавців.

Планування управління змістом.Одна з найпоширеніших «хвороб» програмних проектів називається «повзучий фіче-ризм»,коли до спочатку спроектованої будки для улюбленого собаки спочатку прилаштовують сарай для зберігання садового інвентарю, а потім і будиночок у кілька поверхів для її господаря. І все це намагаються побудувати на тому самому фундаменті і з тих самих матеріалів. Такий підхід став причиною смерті багатьох проектів розробки ПЗ. Тому відразу, як тільки вдалося стабілізувати та узгодити ІСР – ієрархічну структуру робіт, необхідно розробити план управління змістом проекту, Для чого слід:

• визначити джерела запитів зміну;
• встановити порядок аналізу, оцінки та затвердження/відхилення зміни змісту;
• визначити порядок документування змін утримання;
• визначити порядок інформування про зміну змісту. Перше завдання, яке необхідно вирішити під час аналізу запиту

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

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

• систему робочих взаємин між робочими групами проекту;
• систему звітності;
• оцінки ходу виконання проекту;
• систему прийняття рішень.

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

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

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

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

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

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

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

План управління якістюповинен включати наступні роботи:

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

Уточнення змісту та складу робіт.Уточнення змісту (декомпозиція) проекту – одна з найважливіших складових частиндисципліни управління проектами Деталізація дозволяє оцінити, наприклад, загальну вартість проекту через сукупність вартості окремих його робіт. Результат деталізації змісту проекту є структура декомпозиції робіт(Work Breakdown Structure – WBS). Найчастіше така структура є ієрархічною. При цьому сам процес деталізації – це структурна декомпозиція робіт, тобто. діяльність із створення деталізованої структури робіт чи завдань проекту.

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

Виконувати декомпозицію робіт проекту можна по-різному. Наприклад, ГОСТ 19.102-77 передбачає каскадний підхідта визначає наступні стадії розробки програмної системи

• 1) технічне завдання;
• 2) ескізний проект;
• 3) технічний проект;
• 4) робочий проект;
• 5) Використання.

Якщо дотримуватися цього стандарту, то на першому рівні ІСР повинні знаходитись саме ці проектні продукти. Якби довелося розробляти АСУ для управління ядерним реакторомабо пілотованим космічним апаратом, то саме так і слід було чинити. Однак у комерційній розробці ПЗ такий підхід неефективний.

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

Виділення компонентів, що становлять програмний продукт, - це елемент високорівневого проектування, яке має виконуватися на фазі планування проекту, не чекаючи на опрацювання всіх функціональних вимог до розроблюваного ПЗ. Компонентами можуть бути як прикладні підсистеми, так і інфраструктурні або ядерні, наприклад, підсистема аутентифікації, безпеки, бібліотека візуальних компонентів графічного інтерфейсу (GUI). При складанні базового плану робіт не варто прагнути максимально деталізувати всі роботи ІСР, достатньо 3-5 рівнів.

У контексті деталізації часто використовуються терміни «завдання» та «роботи» як взаємозамінні. Все ж таки коректніше говорити, що завдання визначає досягнення проміжного результату, а роботи є комплексами дій для досягнення цих результатів. Оскільки будь-яке завдання вимагає проведення певних робіт при заданих обмеженнях, безумовно, можна говорити про безперечне «відображення» (mapping) завдань на роботи і навпаки. Це і є причина взаємозамінності термінів повсякденному житті. У той самий час розуміння відмінностей між цими поняттями дозволяє відчути нюанси процесного погляду створення продукту, отже, і життєвий цикл проектів, зокрема і проектів програмних систем.

В загальному випадкуможна говорити про деталізації: «програма – проект - завдання – операція».На рис. 3.12 наведено приклад такої деталізації (показані тільки операції Завдання А).

Рис. 3.12.Приклад застосування термінів: програма, проект, завдання, операція

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

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

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

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

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

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

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

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

Загальна вартість проекту визначається досвідченими фахівцями із похибкою до 10%. Оцінка витрат може виконуватися «згори донизу», «знизу догори» або виходити із вартості раніше виготовленого проекту. Експерти проводять песимістичну, оптимістичну та реальну оцінку шляхом опитування всіх членів робочої групита корекції кожної оцінки для отримання найбільш правдоподібної. У деяких робочих групах песимістична та оптимістична оцінки можуть сильно відрізнятися.

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

Існують різні емпіричні підходи до оцінки вартості проекту, наприклад, вартість проекту пропонується визначати за формулою

ВАРТІСТЬ = (а + Ь?) т (Х),

де 5 - деяка оцінка обсягу системи; а, Ь, с -емпіричні константи; X - вектор факторів вартості розмірності пт -регулюючий множник, що ґрунтується на витратних факторах.

Більш спрощена оцінка, отримана експериментальним шляхом, виражається у такому вигляді:

ВАРТІСТЬ = 5,255 0,91.

Ці оцінки були отримані на основі аналізу проектів, де програми мали розмір від 4000 до 467 000 рядків коду та були написані 28 різними мовами програмування для 66 комп'ютерів. На розробку було витрачено від 12 до 11758 чол.-міс. Відомі та інші техніки емпіричного моделювання.

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

Базовою моделлю експериментальної оцінки вартості проекту на сьогоднішній день є наступне рівняння:

ВАРТІСТЬ = bS c m(X),

де bS c -первинна оцінка, яка коригується за допомогою вектора вартості т(Х)та обліку числа старих та нових об'єктів; з- параметр, який змінюється від нуля до одиниці для першої стадії ведення проекту та від 1,01 до 1,26 – для інших стадій.

При формалізованому підході виконання оцінки проекту ґрунтується на використанні LOC- та FP-метрик.

Конструктивна модель вартості(СОСОМО - Constructive cost model), запропонована Б. Боемом, об'єднала у собі найвідоміші формалізовані техніки оцінки проекту - LOC-оцінки(LOC - Lines of Code), що базуються на числі рядків програмного коду. У процесі застосування цієї моделі формуються попередні оцінки, що дозволяють пред'явити замовнику коректні вимоги щодо вартості та витрат на розробку ПП, а також забезпечується можливість складання плану ПП.

Функціонально-орієнтовані FP-метрикизамість підрахунку LOC-оцінки опосередковано вимірюють програмний продукт. Розглядається не розмір, а функціональність чи корисність продукту. Автором цієї метрики є А. Албрехт. Визначення функціонального розміру складається з кількох кроків і починається з ідентифікації функцій, які мають додаток. Міжнародна група користувачів функціонального виміру (IFPUG – International Function Point Users Group) опублікувала критерії, за якими визначаються функції програми. Під час розрахунку FP-метрики використовуються п'ять інформаційних характеристик: кількість зовнішніх вводів; кількість зовнішніх висновків (висновки означають звіти, екрани, роздруківки, повідомлення про помилки); кількість зовнішніх запитів; кількість внутрішніх логічних файлів; кількість зовнішніх інтерфейсних файлів

Після збору всієї необхідної інформації приступають до розрахунку метрики -визначають кількість функціональних покажчиків FP (Function Points) за якоюсь формулою, де значення вхідних коефіцієнтів регулювання складності (кожен коефіцієнт може приймати значення: 0 - немає впливу; 1 - випадкове; 2 - невелике; 3 - середнє; 4 - важливе; 5 - основне) вибираються емпірично в внаслідок відповідей на 14 питань, що характеризують системні параметри програми.

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

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

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

За допомогою стандартних таблиць FP-оцінки можна легко перерахувати на LOC-оцінки, тобто. за функціональним розміром обчислити кількість рядків коду. Однак результати перерахунку залежать від мови програмування, що використовується для реалізації ПЗ (наприклад, Java одна одиниця функціонального розміру дорівнює 53 рядкам вихідного коду). У свою чергу кількість рядків коду дозволяє визначити загальну трудомісткість, виражену в чол.-міс., і терміни проекту.

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

Приклад 3.1. Розглянемо порядок виконання процедури оцінки робіт з урахуванням ШС-метрики.

Етап 1. Область призначення проектованого продукту розбивається на ряд функцій/i,/2,/3, кожну з яких можна

оцінити індивідуально

Етап 2. Для кожної функції/ планувальник формує найкращу LOC n , найгіршу ЮС Хі ймовірну ЮС Воцінки. У процесі формування оцінок використовують досвідчені дані з метричного базису або інтуїтивні уявлення планувальника. Діапазон можливих значень оцінок відповідає мірі передбаченої невизначеності.

Етап 3. Для кожної функції f t визначається очікуване значення оцінки:

ЮС Я + ЮС Х + 4 ЬОС^ож = 6"

юс.

Етап 4. Обчислюється значення ШС-продуктивності розробки функції відповідно до одним із трьох правил.

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

ПР, = ПР порівн; / = 1, 2, ..., п.

Правило Б.Для /-ї функції на основі метрики середньої продуктивності обчислюється величина продуктивності, що настроюється:

ыс ср

МС ож ’

де ЮС порівн -середня ЬОС-оцінка, взята з метричного базису (відповідає середній продуктивності).

Правило У.Для /-й функції величина продуктивності, що налаштовується, обчислюється за обраним аналогом (взятому з метричного базису):

ЬОСднІ

мс ожі

Використання на подальших етапах правила А забезпечує мінімальну точність при максимальній простоті обчислень. Правило дозволяє досягти максимальної точності при максимальній складності обчислень.

Етап 5. Обчислюється загальна оцінка витрат (чол.-міс.) на проект, якщо використовується правило А:

якщо використовується правило Б або В:

Ь1У ^ож/

Етап 6. Обчислюється загальна оцінка вартості проекту, якщо використовується правило А або Б:

ВАРТІСТЬ = УДСТ ср?юС 0Ж/;

якщо використовується правило:

ВАРТІСТЬ = УДСТ ан/ ^ЮС 0Ж/ ,

де УДСТ ср – метрика середньої вартості одного рядка програмного коду; УДСТ ан - метрика вартості одного рядка аналога (обидві метрики беруться з метричного базису).

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

Базовий розклад здебільшого є елементом договору із замовником. Контрольні точки (віхи)служать точками аналізу стану проекту та прийняття рішення у форматі "§ або по1 §о", тому вони повинні зримо демонструвати статус проекту. Висуваються певні вимоги до вибору та формування контрольних точок, наприклад контрольна точка «Проектування завершено» є малоінформативною, більш ефективним підходом вважається метод послідовних поставок: вищеназвана контрольна точка формулюється у формі «Завершено тестування вимог 1, 3, 5 та 7».

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

Розробка плану робіт з термінами їх виконання може здійснюватися методом критичного шляху СРМ або методом аналізу та оцінки програм PERT. План проекту наводиться у термінах етапів: «Планування», «Проектування», «Кодування», «Тестування» і «Супровід». Планування зачіпає визначення специфікацій, бюджету та розкладу, а також розвиток плану проекту в цілому.

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

При виконанні проекту керівник насамперед повинен звертати увагу на виконання завдань критичного шляху і стежити за появою інших критичних шляхів. Існує практична рекомендація: на критичному шляху повинні стояти роботи з нежорсткими зв'язками, які можна перепланувати, якщо виникає загроза зриву термінів. Графік робіт складається за схемою, показаною на рис. 3.13.

Вимоги Графік

до проекту

Рис. 3.13.Кроки складання графіка робіт на проекті

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

Послідовність точок-віх, визначених менеджером, часто називається планом з віх (за подіями).Визначення плану досягнення відповідних віх утворює календарний план на основі віх.

На етапі планування можуть використовуватися також мережна розбивка робіт та діаграма Ганта.

Мережеве розбивання робіт(СРР) – це ієрархічна структура декомпозиції завдань проекту на підзавдання. На нижньому рівні знаходяться роботи, деталізовані на елементи діяльності в мережевій моделі СРР

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

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

План робіт у вигляді графа СРР містить фази (етапи), кроки та діяльність, включаючи початкову та кінцеву діяльність на процесі (рис. 3.14).

Фаза і

Крок 1 Крок 2

Рис. 3.14.Покроковий граф плану проекту

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

Рис. 3.15.

вершини і входить у заключну вершину, відповідає часова позначка «нуль».

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

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

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

План проекту			Ь Ельвест К., Горічова Р., Іваннікова О., Плотнікова О.
Специфікація вимог
2.1. Первинний перелік вимог				Горічова Р.
2.2. Моделі вимог			Плотнікова О.
2.3. Високоврівнева архітектура системи				до Сорокіна О., Ельвест До.
2.4. Критерії атестації системи				Іваннікова О.
2.5. Міфологічна модель бази даних				Счетчікова А.
2.6. Глосарій				Горічова Р., Плотнікова О.
Документація проектування
3.1. Проект архітектури			Н Ельвест До.
3.2. Проект інтерфейсу користувача			| Счетчикова А., Плотнікова О.
3.3. Проект підсистем			I Сорокіна О.
3.4. Модель бази даних			Н Іваннікова О.
3.5. План тестування				Ь Горічова Р.
Документ реалізації
4.1. Огляд реалізації					Счетчикова О., Сорокі		ша О., Іва
4.2. Посібник користувача					Ельвест К., Горічова
Документ про виконання тестування
5.1. Тестування методом білої скриньки				Н Счетчикова А.,			Сорокіна
5.2. Інтеграційне тестування		1^ Ельвест К					Тесляр
5.3. Атестаційне тестування							чева Р., ІІ
Завершення та здавання проекту							Лічильник

Рис. 3.16. Діаграма Ганта

Група процесів виконання

Групи процесів правління проектом

Управління якістю проекту

Забезпечення

якості

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