Як вибирати програмний продукт для управління проектами
Чим керуватися, обираючи програмний продукт, і якихось типових помилок можна уникнути, розповідає експерт в управлінні проектами Максим Якубович.
– Упевнений, багато хто з вас уже пробував різні програми для управління проектами. Когось отриманий від їхнього використання результат влаштовує, а хтось перебуває у перманентному пошуку «перлини».
Спочатку хочу написати про помилки, які спостерігав при виборі програмного продукту для управління проектом.
Навіщо керівнику проекту автоматизувати управління ним у разі, якщо в компанії ще немає Інформаційної системи для управління проектами (ІСУП)?
Є кілька причин для інвестування в цей час і грошей:
Мені важко уявити, як змоделювати розклад проекту з урахуванням наявних обмежень в Excel або на папері. Я знаю, що це можна, але навіщо, якщо зручніше це зробити у спеціальному софті (наприклад, MS Project чи Oracle Primavera)?
Мені потрібно щодня мати адекватну інформацію про хід проекту, робити прогнози щодо завершення проекту та планувати коригувальні дії. Для цього мені потрібно кудись вносити фактичні дані про перебіг проекту та виявляти відхилення від плану.
Мені потрібно готувати звіти про хід проекту для заінтересованих сторін. Це можна робити вручну, але навіщо, якщо є продукти, які це автоматизують?
Кілька разів у мене була ситуація, коли на проектах я використав 2 програмні продукти для управління проектом. Наприклад, модель проекту я створював у MS Project, але оскільки для створення одного з продуктів проекту використовувався scrum, то для ведення product backlog, формування спринтів та контролю їх виконання мені був потрібен інший програмний продукт. В якостітаких продуктів на одному проекті ми вибрали Jira, на іншому був Devprom (у його хмарній версії), а у третьому ми розробили та впровадили власний продукт для роботи з scrum.
Треба сказати, що результатами автоматизації я майже задоволений. Єдиною проблемою було перенесення даних по списку завдань, планових трудовитрат і термінів з MS Project в другий продукт і перенесення даних по фактичних трудовитратах з обраного продукту в MS Project.
Мені ще жодного разу не доводилося управляти проектами в компанії, в якій до мого приходу вже було впроваджено інформаційну систему для управління проектами. Ось чому я вважаю, що для керівника проекту важливо мати досвід впровадження програмних продуктів для автоматизації управління проектами – іноді ми приходимо керувати проектом у компанії, де немає ІСУП.
Періодично я переглядаю інформацію про те, які програмні продукти управління проектами з'являються. Років зо два тому я прочитав, що продуктів, які позиціонуються для автоматизації управління проектами, вже стало більше сотні. А нещодавно знайшов інформацію, що їхня кількість у світі перевалила за п'ятсот. Автор статті пише про те, що в останньому огляді програмного забезпечення управління проектами виявлено понад 500 програмних продуктів, які задовольняютьнаступним мінімальним вимогам:
- Підтримка діаграми Ганта, яка чітко показує дати старту та фінішу кожного завдання та послідовність їх виконання. - Розрахунок тривалості завдань та проекту від обсягів робіт та даних про доступність ресурсів. - генерація графіків та даних, що дозволяють порівнювати реальну продуктивність з базовим планом проекту.
Отже, що саме я можу порадити під час виборів програмного продукту? Дляпочала кілька міркувань:
2. Методика відбору програми не повинна бути надто складною. У своїй статті Харві А. Левін, який має 38-річний досвід в управлінні проектами і вважається серйозним експертом у виборі засобів автоматизації, пише, що в його підході до відбору ПЗ використовувалося близько 200 характеристик. та елементів, які необхідно було враховувати. На одному зі своїх семінарів він почув від клієнта таку репліку: «Це перший семінар, після відвідування якого я йду з ще більшою кількістю питань, ніж я спочатку мав».
3. Програмних продуктів для вибору не повинно бути багато, інакше процес відбору стане занадто трудомістким і дорогим.
При відборі програми я рекомендую, окрім списку вимог до неї, розробити приблизно такі критерії відбору:
- Ступінь покриття вимог у програмному продукті. - Наявність та способи надання сервісу підтримки у постачальника програмного продукту. - Сукупна вартість володіння програмним продуктом (включає всі витрати на використання сервісу протягом його використання). - Наявність та вартість навчання роботі в програмному продукті. - Можливості інтеграції коїться з іншими програмними продуктами.
Який алгоритм вибору програми для автоматизації управління проектом я використовую?
Зрозуміло, що мій підхід – не єдиний можливий і не правильний. Багато хто з вас воліє зробити процедуру відбору простішою або виберуть продукт інтуїтивно.
Однак, сподіваюся, описаний підхід допоможе вам у роздумах, з чого почати, і, впевнений, ви придумаєте, як цей підхід можна покращити.