Войти
Личный опыт
«Про бизнес.» 1 декабря 2014 8

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

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

Фото с сайта www.scrum.orgФото с сайта www.scrum.orgФото с сайта www.scrum.org
Фото с сайта www.scrum.org

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии

Войдите, чтобы оставить комментарий

Max Yakubovich7.12.2014

Viktor Koptenkov
"Как понять когда следует разрабатывать свою собственную систему автоматизации, а когда все же покупать решение на стороне. Я думаю, что нередки случаи когда решение со стороны нужно дорабатывать столько же, а то и больше времени, чем новый продукт."

Я бы опирался на прогнозы экономической эффективности двух вариантов. Но если лень считать, то тогда на правило типа такого: Если в коробочном решении реализовано 80% от требуемого нам функционала, то эффективнее доработать коробку. В обратной ситуации - скорей разработка с нуля.

Max Yakubovich7.12.2014

Дмитрий Куликовский,
как говорят немцы: "Я-я, натурлих". О чем и писал в статье.

Max Yakubovich7.12.2014

Natallia Bondar,
@как убедить на начальной стадии планирования приобрести, выделить бюджет на ИСУП, тем более несколько и с доработками по интеграции?? @

Самым убедительным, на мой взгляд, будет расчет потерь в случае, если не внедрять ИСУП? Сколько денег потеряет компания от перерасходов бюджета, от срыва сроков проектов? (расчет можно сделать на основании статистики уже выполненных проектов)
@А какие еще примеры ИСУП вы бы посоветовали, наподобие MSProject?@

Наталья, я могу советовать продукт только после того, как понимаю процессы которые он автоматизирует. Этот point и стал базовым для написания статьи.

спасибо за вопросы )

Viktor Koptenkov7.12.2014

Хотел бы обсудить такой вопрос: Как понять когда следует разрабатывать свою собственную систему автоматизации, а когда все же покупать решение на стороне.
Я думаю, что нередки случаи когда решение со стороны нужно дорабатывать столько же, а то и больше времени, чем новый продукт.

Дмитрий Куликовский5.12.2014

Прежде чем браться за автоматизацию неплохо бы подумать о самих бизнес-процессах. Автоматизировать неэффективность - много ума не надо, мы это сплошь и рядом видим. Если структура и процессы в компании налажены налажены и действительно являются эффективными, то чаще всего они (структура и процессы) уникальны, поэтому нужны и уникальные решения - простой "коробкой" не обойтись, нужно или дописывать модули или свою прогу заказывать

Natallia Bondar5.12.2014

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

Max Yakubovich5.12.2014

Victor Belyavski, спасибо за точку зрения и за вопрос.
Вот Ваш вопрос:
"Существуют ли какие-либо критерии при отборе ИСУП, позволяющие оценить их способность бороться хотя бы с заведомо вопиюще-ложными входными данными?"
В ответ приведу ситуацию из собственного опыта:
Мы внедряли информационную систему, автоматизирующую основной процесс в экспедиторской компании. Одним из требований к системе было: обеспечить максимальную защиту от "дурака" (т.е. от ошибок оператора при вводе данных). По мере развития ИС мы изучали какие ошибки чаще всего допускают пользователи и придумывали всякие проверки на уровне кода программного продукта, чтобы он при вводе данных сообщал об ошибке ввода. Такая практика позволила несколько снизить долю ошибок, но они все равно остались.
В некоторых программных продуктах для управления проектами есть подобные проверки.Например, MS Project при назначении ресурса на работы проекта подсказывает о том, что ресурс перегружен.
Но мой опыт показывает,что защититься от всех ошибок ввода данных в современных ИС почти не возможно. Выход: обучение операторов и мотивация их на ввод корректных данных.
И, надеюсь, скоро появится новое поколение ИС, которые будут сами находить ошибки ввода данных и исправлять их )

Victor Belyavski5.12.2014

Среди ошибок упоминается выбор продукта, не имея представления о процессе управления проектом - по мне это попросту тупиковый путь (даже не ошибка). Вероятность получить вменяемый результат - не более 1%. А, скорей всего, будет разочарование в продукте и глубокая уверенность, что само управления проектами - это модная и бессмысленная фишка.
Проблема любой ИС - это качество входных данных. А это люди. Как говорит народная мудрость по этому поводу - "Г*но на входе - г*но на выходе". Существуют ли какие-либо критерии при отборе ИСУП, позволяющие оценить их способность бороться хотя бы с заведомо вопиюще-ложными входными данными?

Сейчас на главной

Новости компаний

Платный контент