Використання ms project для управління проектами з розробки по
Я хочу поділитися своїм досвідом використання MS Project для управління проектами з розробки програмного забезпечення. Я вже років 10 займаюся управлінням проектами,
і в результаті у мене народилася деяка методологія використання MS Project, яка дозволяє отримати від нього чималу користь і при цьому менше залежати від його недоліків.
невелике введення
Вся методологія - це просто набір простих методів і рекомендацій по використанню MS Project для вирішення прикладних завдань керівника проекту. Відразу обмовлюся, що методологія не претендує на універсальність, і може бути застосована тільки при деяких обмеженнях, які я буду згадувати по ходу розповіді.
Для початку, давайте згадаємо, що зазвичай потрібно від керівника проекту. Для досвідчених керівників це очевидно, а початківцям (або тільки збираються стати керівниками) буде корисно зайвий раз згадати. Отже, проект по розробці програмного забезпечення - це створення деякий унікального продукту. На різних етапах життєвого циклу проекту від РП потрібно вирішувати різні завдання.
Перед початком проекту
Перед початком проекту від керівника проекту зазвичай потрібно відповісти на два питання:
- скільки проект займе часу
- скільки проект буде коштувати
При цьому важливо розуміти, що нікого не цікавить відповідь виду «не раніше ніж через півроку». Потрібно якраз оцінка зверху.
Примітка. Мені ніколи не доводилося мати справи з явними грошовими оцінками проекту, і, як я зараз розумію, це серйозний недогляд. Всі проекти, якими я керував, виконувалися співробітниками компанії. Команда проекту формувалася на весь час проекту, деякі фахівці залучалися на певний час. Фактично, від мене вимагається оцінка кількості необхідних виконавців, а також терміни їх залучення. Як мені здається, це досить типова ситуація для компаній, що займаються розробкою програмного забезпечення. У підсумку все зводиться до оцінки трудовитрат, яка, з використанням емпіричних формул, перетворюється в оцінку вартості проекту. Як бачимо, присутня пряма залежність вартості проекту від його термінів.
В процесі виконання проекту
В умовах згаданих обмежень, основним завданням керівника проекту є забезпечити виконання проекту в заявлений термін, а це безпосередньо
впливає на його вартість. Непередбачені обставини, які обов'язково супроводжують будь-якого проекту, можуть привести до зриву термінів. Строго кажучи, терміни проекту можуть несподівано і скоротитися, але, чесно кажучи, я такого ніколи не бачив. Від керівника потрібно своєчасно реагувати на такі події, щоб зменшити негативні наслідки. Єдиний відомий мені спосіб вирішення цього завдання - це акуратне планування, регулярне відстеження насуваються проблем і коригування планів.
При завершенні проекту
При завершенні проекту керівник зазвичай озирається назад і підводить підсумки проекту. Частіше за все потрібно оцінити наскільки проект вибився з планових графіків і чому це сталося.
Що вміє MS Project
Незважаючи на зовнішню складність, MS Project дуже простий в ідейному плані. Він оперує трьома сутностями - завдання, ресурси, календар і зв'язку між ними. По суті - це база даних, призначений для користувача інтерфейс для створення і редагування сутностей і мінімальна, досить проста автоматизація (то, що Project робить сам, у відповідь на введені дані).
Розберемо коротко властивості сутностей.
Завдання має тривалість, об'єм, призначений ресурс і ще чортову купу різних властивостей. Якщо вбудованих властивостей не вистачає, можна додати свої - цим ми потім скористаємося. Завдання можуть бути пов'язані між собою різними відносинами (попередники, послідовники і т.п.).
Ресурс має багато описових властивостей, але найголовніше - для нього можна
задати доступність в часі, для цього використовується календар. Ресурс може бути
призначений на завдання.
На основі цих даних Project вміє робити різні уявлення з використанням
фільтрів, угруповань, сортувань і т.п. Крім цього він вміє за певним алгоритмом
обчислювати терміни початку і закінчення завдань з урахуванням доступності призначених ресурсів
і зв'язків між завданнями. Ось, власне, і майже всі що він вміє.
Давайте подивимося, яку користь можна з цього отримати
Як це використовувати
Примітка Щоб було зрозуміліше, я уточню деякі загальні властивості проектів,
з якими я працював. Отже, мова йде про проекти з розробки програмного забезпечення,
які складаються з декількох етапів. В кінці кожного етапу ми повинні отримати певний
відчутний результат, який буде пред'явлений замовнику, тому для нас важливо оцінити
термін не тільки проекту в цілому, а й кожного етапу. Повторюю, єдиний вид ресурсів
який потрібно - це люди, причому ми не наймаємо фахівців з боку, а використовуємо
можливості вже працюючих співробітників.
підготовка плану
Отже, перед нами лежить технічне завдання, і потрібно дати відповідь на три питання:
- Скільки часу займе цей проект?
- Скільки (і яких) фахівців для цього буде потрібно?
- Які приблизно трудовитрати очікуються за цим проектом?
Для цього ми готуємо приблизний план виконання проекту в MS Project. Тобто просто послідовно виписуємо завдання, які необхідно виконати. Методика перетворення техзавдання в набір завдань - це окрема історія, я не буду на ній зараз зупинятися.
Підготовка плану виконується в кілька етапів:
- Готуємо список завдань
- Виставляємо залежності між завданнями
(Результат якої задачі необхідний для переходу до наступної?). - Призначаємо виконавців завдань
- Вирівнюємо завантаження ресурсів
- Балансуємо те, що вийшло
загальні рекомендації
При підготовці плану дотримуємося наступних рекомендацій:
- Чи не використовуємо сумарні завдання для декомпозиції.
Всі завдання поміщаємо в один лінійний список. Спочатку це може здатися незручним,
але зате позбавляє від багатьох проблем в подальшому. Для управління структурою завдань
використовуємо настроюються поля (див.нижче). - Дуже часто для управління залежностями завдань використовують DragDrop. Коли завдань багато це швидко стає незручно. Я рекомендую в цьому випадку не використовувати перетягування, а явне вказувати номери завдань-попередників. для цього можна додати в таблицю стовпець «попередники» і вписувати номери завдань вручну.
- Термін кожного завдання не повинен перевищувати двох тижнів.
Якщо термін завдання перевищує тиждень - це вже привід задуматися про її декомпозиції. Я дотримувався дуже простий методики оцінки: примітивна завдання - 2 дня, середньої
складності - 1 тиждень, складне завдання - 2 тижні. При цьому складних завдань не повинно бути багато. Такий підхід дає можливість підготувати оцінний план досить швидко.
З одного боку, отримана оцінка, звичайно, не буде точною, але, з іншого боку - а яка з них точна? За опитку практичного застосування можу сказати, що на
великих проектах похибки оцінок окремих завдань зазвичайнівелюються, а на малих часто можна (і потрібно!) використовувати і точніші оцінки. - Всіма силами уникаємо завдань, у яких кілька виконавців. Для кожного завдання повинен бути призначений тільки один виконавець. Двох виконавців має сенс призначати
тільки якщо вони дійсно працюють удвох (наприклад, ви практикуєте парне програмування). В інших випадках краще декомпозировать завдання. - При призначенні виконавців керуємося їх фаху та кваліфікації, поки не турбуючись про рівномірності завантаження.
- Використовуємо сумарні завдання для поділу завдань на етапи. Ставимо залежності між етапами, щоб вони йшли послідовно. Поділ на етапи поки досить приблизне.
Список завдань, розділений на етапи
балансування проекту
Найголовнішим в методиці є саме балансування. Мета цього процесу - підготувати план, в якому роботи досить рівномірно розподілені між виконавцями на всьому протязі.
Угруповання завдань за виконавцями
Примітка. Теоретично, для оцінки завантаження покладається використовувати графіки
завантаження користувачів. Ці графіки хороші (напевно) для начальства, коли вони
оцінюють готовий проект. Але вони непридатні на етапі створення плану, так як показують
що все погано, але зовсім не дають інформації чому це так і що можна зробити.
Далі починається магія балансування. Потрібно мінімізувати терміни виконання кожного етапу шляхом забезпечення більш-менш рівномірного навантаження на всіх учасників проекту. Для цього ми виконуємо наступні дії:
- Змінити виконавця завдання.
а в іншого є явні «дірки», причому він може взяти на себе деякі роботи у
першого.
Завдання, яке призводить у подовженню терміну етапу, але при цьому не є необхідною
для отримання результату етапу може бути перенесена на етап пізніше. І навпаки,
якщо в етапі присутні «дірки» в завантаженні виконавців, а змінити виконавців
не виходить, то можна спробувати взяти завдання з наступного етапу.
Робити все це, на жаль, доводиться вручну, виконуючи вирівнювання завантаження ресурсів після кожної зміни. Незважаючи на гадану складність, цей процес зазвичай займає кінцевий час. Проект на рік з 8 учасників, розбитий на 4 етапи я упорядковував менш ніж за годину.
Тепер ще раз уважно дивимося на проект, переконуємося, що зв'язку між завданнями розставлені правильно, що нічого не забуто, а призначення виконавців відповідають їх спеціальностями і кваліфікації.
облік ризиків
Тепер - останній штрих: облік ризиків. Чесно зізнаюся, я не займався серйозним управлінням ризиками, але враховую можливість виникнення певних форс-мажору (таких як хвороби виконавців, забуті роботи і т.п.). Для цього я додаю в кожен етап фіктивну завдання з мінімальним пріоритетом, під назвою «інші роботи» для кожного ресурсу. Після вирівнювання ресурсів ці завдання виявляються в кінці етапу. Тривалість цих завдань залежить від імовірності виникнення і ступеня Вляна ризиків, вона залежить від способу визначення оцінок тривалості завдань, здоров'я членів команди і ступеня параної керівника проекту. Зазвичай я виставляв тривалість «інших робіт» приблизно від третини до чверті довжини етапу.
В результаті всіх перерахованих маніпуляцій у нас виходить план виконання проекту, з яким можна працювати.
З цим планом ми можемо:
- Назвати терміни виконання проекту і його етапів. Аргументовано і з високим ступенем
достовірності. - Оцінити приблизні трудовитрати по проекту
Примітка. Часто трапляється так, що термін виконання виходить досить великий, і виникає резонне питання, чи можна його зменшити за рахунок залучення додаткових виконавців. Для того щоб відповісти на це питання, я балансував новий план, використовуючи той же набір завдань, але змінюючи склад виконавців. Відповідь не виходив миттєво, але це не займало багато часу.
Робота з планом
Коли проект запускається в роботу, вихідний план, який використовувався для оцінки, можна використовувати і для відстеження виконання проекту. Від керівника проекту потрібно регулярно виконувати такі дії:
- Видавати завдання виконавцями
- Відзначати виконані завдання в плані
- Коригувати план в разі значних відхилень
Видача завдань виконавцями може виконуватися по різному. Можна розбити виконання на короткі ітерації, формувати пул завдань на ітерацію і після закінчення ітерації відзначати результати. Можна відразу озвучити лнітелям набір завдань на етап, видати кожному по примірнику діаграми Ганта і періодично опитувати про прогрес. Можна використовувати інтеграцію MS Project і TFS і завантажити проект безпосередньо в TFS. Суть не в коштах. Головне - це регулярне оновлення плану. Я роблю це приблизно раз-два в тиждень. Це дає можливість досить швидко побачити проблемні ділянки.
Для визначення проблемної ділянки зручно використовувати різні угруповання - по виконавцями, за компонентами та ін. Часто може виявитися, що проект в цілому йде навіть з випередженням, але в певному розрізі спостерігається відставання, наприклад один з розробників несподівано уткнувся в серйозну системну проблему, яка привела до відхиленнями. Використання тільки середньої метрики буде непереливки цієї проблеми - вона спливе тільки в кінці етапу, коли щось робити буде вже пізно.
Відстеження виконання з угрупованням по компонентам
Примітка. Зазвичай я не рухаю завдання по календарю, а тільки відзначаю наскільки вони виконані. Відхилення від плану я відстежую по відхиленню сумарною завдання проекту від поточного моменту.
Є інша стратегія - внесення змін у строки завдань, «виштовхуючи» невиконані завдання вперед. При такому підході для відстеження відхилень від плану можна використовувати іншу корисну функцію MS Project - базовий план. Базовий план - це просто збережений знімок стану завдань. Його можна зробити на початку проекту. Для порівняння поточного плану з базовим, відкриваємо «діаграму Ганта з відстеженням». Для динамічного плану, коли порядок виконання завдань часто змінюється, це може виявитися незручним, тому я вставляю в проект контрольні точки, що відображають деякі важливі результати проекту, і відслідковувати відхилення від базового плану тільки для них.
Діаграма Ганта з відстеженням
Управління структурою завдань за допомогою призначених для користувача полів
Створення призначеного для користувача поля
Після цього ми отримуємо можливість вказати для кожного завдання компонент, до якого вона належить, і, використовуючи угруповання завдань по компонентам, відстежувати як йдуть справи.
Використання користувальницьких полів, а також вбудовані в MS Project функції фільтрації, сортування та групування завдань дозволяють отримати найрізноманітніші уявлення, які дозволяють отримати відповіді на багато питань, які виникають у керівника проекту.
завершення проекту
В кінці проекту ми отримуємо план, в якому всі завдання виконані. Зазвичай я намагаюся зберігати також і вихідний план, хоча б в якості базового. Чесно кажучи, на цьому етапі від MS Project мало пуття, так як цікавлять не планові значення, а фактичні. Якісь вирішення цієї проблеми пропонує MS Project Server, там є можливість враховувати фактичні трудовитрати, але це вже за межами даної статті.
висновок
Я спробував узагальнити свій досвід використання MS Project для практичного вирішення завдань, які виникали переді мною, коли я керував проектами з розробки ПЗ. Описана методика не претендує не універсальна, але вона, як мені здається, досить проста і логічна, при цьому дозволяє вирішувати практичні завдання керівника проекту.
Використання цього підходу дозволило мені успішно і вчасно завершити не один проект.
Правда, траплялися і збої. Це відбувалося, як правило, тоді, коли погано була проведена підготовча частина проекту, а саме - постановка задачі. Тобто в результаті проекту виходило не зовсім те, що потрібно, а розуміння цього приходило занадто пізно.
Напевно я щось упустив, не соромтеся задавати питання.