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