Microsoft Project (або MSP) - програма управління проектами, розроблена та продається корпорацією Microsoft.

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

Під маркою Microsoft Project доступні відразу кілька продуктів та рішень:

Microsoft Project Standard - однокористувацька версія для невеликих проектів Microsoft Project Professional - корпоративна версія продукту, що підтримує спільне управління проектами та ресурсами, а також управління портфелями проектів за допомогою Microsoft Project Server.

Microsoft Project Web Access - Web-інтерфейс для звітності про виконання завдань, а також перегляд портфелів проектів Microsoft Project Portfolio Server - продукт для відбору проектів для запуску на основі збалансованих показників, увійшов до складу Microsoft Project Server з версії MS Project 2010.

Починаючи з 2013 року, Microsoft починає постачати хмарну версію Microsoft Project Online.

Microsoft Project є лише інструментом, для впровадження управління проектами потрібно вибрати методологію проектного управління. Як правило, методологія реалізується через «регламенти» проектного управління та галузеві доопрацювання MS Project.

Маючи 20 000 000 користувачів, Microsoft Project є монополістом.

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

Такий самий малий час навчання користувачів, як і з іншими програмами Microsoft Office

Багаті можливості налаштування в стилі формул Microsoft Excel (сам продукт витриманий в інтерфейсі, максимально наближеному до Microsoft Excel)

Можливість адаптувати продукт під свою специфіку шляхом програмування чи купівлі готових рішень, створених з урахуванням Visual Basic чи Microsoft.Net.

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

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

Microsoft вирішує цю проблему надійності Microsoft Project Server за допомогою цілого набору програм.

Через програму Microsoft ISV Royalty партнерам та клієнтам компенсується частина вартості посиленої технічної підтримки рішення.

Microsoft запрошує найсильніших експертів з клієнтів і партнерів, і в першу чергу критично налаштованих до якості Microsoft Project Server, взяти участь у програмі його розробки та тестування Microsoft Technology Adoption Program . Сервіс безкоштовної форумної консультації Microsoft забезпечує через програму «Найцінніший спеціаліст» (Microsoft MVP).

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

Налаштування та складання плану проекту в Microsoft Poject

Починати роботу в Microsoft Project слід з налаштування робочого часу. Для цього на панелі інструментів знаходимо вкладку "Файл" і вибираємо пункт "Параметри". У вікні параметрів необхідно перейти на вкладку «Розклад», «Додатково». На наступних малюнках показано налаштування робочого часу та налаштування відображення величин.

Малюнок 1 - Налаштування робочого часу

Рисунок 2 - Налаштування величин

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

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

Малюнок 3 - План проекту

Малюнок 4 - План проекту

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

Малюнок 5 - Аркуш ресурсів

• Tutorial

Невелике введення

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

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

Перед початком проекту

Перед початком проекту від керівника проекту зазвичай потрібно відповісти на два запитання:

1. скільки проект займе часу
2. скільки проект буде коштувати

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

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

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

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

Після завершення проекту

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

Що вміє MS Project

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

Розберемо коротко властивості сутностей.

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

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

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

Як це використовувати

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

Підготовка плану

Отже, маємо технічне завдання, і потрібно дати у відповідь три питання:

1. Скільки часу забере цей проект?
2. Скільки (і яких) фахівців для цього потрібно?
3. Які приблизно трудовитрати очікуються за цим проектом?

Для цього ми готуємо план виконання проекту в MS Project. Тобто. просто послідовно виписуємо завдання, які потрібно виконати. Методика перетворення техзавдання на набір завдань - це окрема історія, я не буду на ній зараз зупинятися.
Підготовка плану виконується у кілька етапів:

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

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

1. Не використовуємо сумарні завдання декомпозиції.
   Усі завдання поміщаємо до одного лінійного списку. Спочатку це може здатися незручним,
   зате позбавляє багатьох проблем надалі. Для управління структурою завдань
   використовуємо поля, що настроюються (див.нижче).
2. Найчастіше для управління залежностями завдань використовують Drag&Drop. Коли завдань багато це швидко стає незручно. Я рекомендую в цьому випадку не використовувати перетягування, а очевидно вказувати номери завдань-попередників. для цього можна додати в таблицю стовпець попередники і вписувати номери завдань вручну.
3. Термін кожного завдання не повинен перевищувати двох тижнів.
   Якщо термін завдання перевищує тиждень - це вже привід задуматися про його декомпозицію. Я дотримувався дуже простої методики оцінки: примітивне завдання – 2 дні, середньої
   складності – 1 тиждень, складне завдання – 2 тижні. У цьому складних завдань має бути багато. Такий підхід дає можливість підготувати план оцінювання досить швидко.
   З одного боку, отримана оцінка, звичайно, не буде точною, але, з іншого боку, - а яка з них точна? За досвідом практичного застосування можу сказати, що на
   Великі проекти похибки оцінок окремих завдань зазвичай нівелюються, але в малих часто можна (і треба!) використовувати і більш точні оцінки.
4. Усіми силами уникаємо завдань, які мають кілька виконавців. Для кожного завдання має бути призначений лише один виконавець. Двох виконавців має сенс призначати
   тільки якщо вони дійсно працюють удвох (наприклад, ви практикуєте парне програмування). В інших випадках краще декомпозувати завдання.
5. При призначенні виконавців керуємось їх професією та кваліфікацією, поки не турбуючись про рівномірність завантаження.
6. Використовуємо сумарні завдання поділу завдань на етапи. Ставимо залежності між етапами, щоб вони йшли послідовно. Поділ на етапи поки що досить приблизний.

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

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

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

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

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

1. Змінити виконавця завдання.

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

2. Перенести завдання на інший етап.

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

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

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

Облік ризиків

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

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

Із цим планом ми можемо:

1. Назвати терміни виконання проекту та його етапів. Аргументовано та з високим ступенем
   достовірності.
2. Оцінити зразкові трудовитрати за проектом

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

Робота з планом

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

1. Видавати завдання виконавцями
2. Відзначати виконані завдання у плані
3. Коригувати план у разі значних відхилень

Видача завдань виконавцями може виконуватись по-різному. Можна розбити виконання на короткі ітерації, формувати пул завдань ітерацію і після закінчення ітерації відзначати результати. Можна відразу озвучити власникам набір завдань на етап, видати кожному за екземпляром діаграми Ганта і періодично опитувати про прогрес. Можна використовувати інтеграцію MS Project та TFS та завантажити проект безпосередньо у TFS. Суть над коштами. Головне це регулярне оновлення плану. Я роблю це приблизно раз-два на тиждень. Це дозволяє досить швидко побачити проблемні ділянки.
Для визначення проблемної ділянки зручно використовувати різні угруповання - за виконавцями, за компонентами та ін. Часто може виявитися, що проект загалом іде навіть з випередженням, але у певному розрізі спостерігається відставання, наприклад, один із розробників несподівано уткнувся у серйозну системну проблему, яка привела до відхилень. Використання тільки середньої метрики не покаже цієї проблеми - вона спливе лише наприкінці етапу, коли щось робити буде вже пізно.

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

Є інша стратегія - внесення змін до термінів завдань, виштовхуючи невиконані завдання вперед. За такого підходу відстеження відхилень від плану можна використовувати іншу корисну функцію MS Project - базовий план. Базовий план – це просто збережений знімок стану задач. Його можна зробити на початку проекту. Для порівняння поточного плану з базовим відкриваємо «діаграму Ганта з відстеженням». Для динамічного плану, коли порядок виконання завдань часто змінюється, це може виявитися незручним, тому я вставляю в проект контрольні точки, що відображають деякі важливі результати проекту, і відстежувати відхилення від базового плану лише для них.

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

Я категорично рекомендую не використовувати сумарні завдання у MS Project для функціональної декомпозиції чи категоризації завдань. Справа в тому, що ієрархія завдань у MS Project сильно зав'язана на їхню послідовність. А часто хочеться подивитися на завдання у різній послідовності, при цьому вся структура «розсипається». Для керування структурою завдань я рекомендую використовувати Користувальницькі поля. MS Project має наперед визначений набір полів з невизначеною заздалегідь поведінкою, які ми можемо використовувати так, як нам зручно. Наприклад, для розбиття завдань по компонентам потрібно на основі текстового поля Текст1створити поле Компоненті задати йому список значень, відповідний компонентам системи.

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

Користувальницькі поля дозволяють розділяти завдання за кількома категоріями, наприклад, я розділяв завдання за типом робіт: Розробка, Тестування, Документування.
Згадаю для цікавих, що в MS Project можна також задати правила малювання діаграм на основі властивостей завдань. За бажанням, можна зробити так, що завдання по різних компонентах матимуть різні кольори, причому колір визначатиметься лише властивістю задачі, його не потрібно ставити вручну для кожного завдання. Такі параметри не вимагають написання сриптів, а робляться штатними засобами налаштування діаграм.

Використання користувачів полів, а також вбудовані в MS Project функції фільтрації, сортування та угруповання завдань дозволяють отримати різні уявлення, які дозволяють отримати відповіді на багато питань, які виникають у керівника проекту.

Завершення проекту

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

Висновок

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

Напевно, я щось упустив, не соромтеся ставити запитання.

Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче

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

Подібні документи

Принципи роботи Microsoft Project (програми управління проектами), її основні поняття: завдання, ресурси, призначення. Послідовність дій щодо створення нового проекту, введення завдань та залежностей між ними, введення ресурсів. Робота із календарями.

курсова робота , доданий 23.01.2011


Сучасна система управління проектами ProjectExpert та Microsoft Project 2007. Project Expert – розробка бізнес-планів та оцінка інвестиційних проектів, можливості програми. Управління проектом "ВАТ Ніф-Ніф" у програмному середовищі Microsoft Project.

курсова робота , доданий 14.05.2015


Методи керування складними проектами. Редагування властивостей проекту. Налаштування календаря проекту. Створення завдань у Microsoft Project та зміна їх властивостей. Вибір вільних ресурсів та їх використання. Складання зведення щодо проекту та звіту про бюджет.

лабораторна робота , доданий 01.03.2015


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

дипломна робота , доданий 28.06.2010


Основи управління проектами із використанням Microsoft Project. Аналіз модернізації виробництва надвисокочастотної техніки на НВП "Салют" із збільшенням виробництва монолітно-інтегральних, гібридно-монолітних приладів та електронних компонентів.

курсова робота , доданий 16.01.2014


Опис ключових характеристик проекту створення хлібопекарні, фази, завдання та необхідні для їх виконання ресурси. Аналіз та оптимізація плану проекту з використанням Microsoft Project, введення даних у програму. Автоматичне вирівнювання ресурсів.

контрольна робота , доданий 02.06.2010


Оцінка вартості проекту за допомогою функції Microsoft Project на прикладі створення техноробочого проекту комплексу завдань "Керування якістю продукції та послуг". Призначення та умови застосування програми, її характеристика та посібник користувача.

дипломна робота , доданий 20.03.2012