Как выбирать программный продукт для управления проектами

Чем руководствоваться, выбирая программный продукт, и каких типичных ошибок можно избежать, рассказывает наш эксперт в управлении проектами Максим Якубович.

– Уверен, многие из вас уже пробовали различные программы для управления проектами. Кого-то полученный от их использования результат устраивает, а кто-то находится в перманентном поиске «жемчужины».

Сначала хочу написать об ошибках, которые я наблюдал при выборе программного продукта для управления проектом.

Для чего руководителю проекта автоматизировать управление им в случае, если в компании еще нет Информационной системы для управления проектами (ИСУП)?

Есть несколько причин для инвестирования в это времени и денег:

• Мне трудно себе представить, как смоделировать расписание проекта с учетом имеющихся ограничений в Excel или на бумаге. Я знаю, что это можно, но зачем, если удобнее это сделать в специальном софте (к примеру, MS Project или Oracle Primavera)?
• Мне нужно каждый день иметь адекватную информацию о ходе проекта, делать прогнозы по завершению проекта и планировать корректирующие действия. Для этого мне нужно куда-то вносить фактические данные о ходе проекта и выявлять отклонения от плана.
• Мне нужно готовить отчеты о ходе проекта для заинтересованных сторон. Это можно делать вручную, но зачем, если есть продукты, автоматизирующие это?

Несколько раз у меня была ситуация, когда на проектах я использовал 2 программных продукта для управления проектом. Например, модель проекта я создавал в MS Project, но так как для создания одного из продуктов проекта использовался scrum, то для ведения product backlog, формирования спринтов и контроля их исполнения мне нужен был другой программный продукт. В качестве таких продуктов на одном проекте мы выбрали Jira, на другом был Devprom (в его облачной версии), а в третьем мы разработали и внедрили собственный продукт для работы по scrum.

Надо сказать, что результатами автоматизации я был почти доволен. Единственной проблемой был перенос данных по списку задач, плановым трудозатратам и срокам из MS Project во второй продукт и перенос обратно данных по фактическим трудозатратам из выбранного продукта в MS Project.

Мне еще ни разу не доводилось управлять проектами в компании, в которой к моему приходу уже была бы внедрена информационная система для управления проектами. Вот почему я считаю, что для руководителя проекта важно иметь опыт внедрения программных продуктов для автоматизации управления проектами – иногда мы приходим руководить проектом в компании, где нет ИСУП.

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

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

Итак, что же конкретно я могу посоветовать при выборе программного продукта? Для начала несколько соображений:

1. Любой софт автоматизирует какие-то процессы и инструменты. Поэтому прежде, чем выбирать софт, я должен понимать какие процессы и используемые в них методы и инструменты я собираюсь автоматизировать. После описания процессов и инструментов управления, нужно собрать бизнес-требования к ИСУП, после чего проверить их на наличие противоречий и найти решения для противоречий (если они есть). Для сбора бизнес-требований к программному продукту для управления проектами одним из перспективных подходов, на мой взгляд, является использование инновационных игр. Подробнее об этом планирую написать позже.

2. Методика отбора программы не должна быть слишком сложной. В своей статье Харви А. Левин, который имеет 38-летний опыт в управлении проектами и считается серьезным экспертом в выборе средств автоматизации пишет, что в его подходе к отбору ПО использовалось около 200 характеристик и элементов, которые необходимо было учитывать. На одном из своих семинаров он услышал от клиента такую реплику: «Это первый семинар, после посещения которого я ухожу с еще большим количеством вопросов, чем у меня было вначале».

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

При отборе программы я рекомендую, кроме списка требований к ней, разработать примерно такие критерии отбора:

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

Какой алгоритм выбора программы для автоматизации управления проектом я использую?

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

Однако, надеюсь, описанный подход поможет вам в размышлениях, с чего начать, и, уверен, вы придумаете, как этот подход можно улучшить.

Жду ваших соображений по теме. Успехов вам в выборе программного продукта!