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

Опубликовано

Сколько проектов и команд, столько и подходов к управлению ими. Масло в огонь определённо подливает огромный выбор готовых систем управления, фреймворков и методологий. Как не сойти с ума и выбрать то, что действительно будет работать, а не отнимать дополнительные силы на интеграцию, обучение, обслуживание и прочее? Несмотря на то, что многие популярные зарубежные системы покинули российский рынок, ситуация с выбором легче не стала, так как появилось много локальных игроков, и у каждого свои нюансы.

Ниже наше руководство по критериям выбора и оценке различных систем управления для российского рынка. Это общий мануал, а не призыв выбрать что-то одно!

Для чего конкретно нужны системы управления проектами?

Любой прикладной софт или даже облачный сервис нужен для решения конкретных задач. Задача любой системы управления проектами – максимальный контроль бизнес-процессов.

Для начала освежим знания и вспомним основные задачи руководителя:

  1. Планирование (в зависимости от уровня руководителя).
  2. Организация и обеспечение (создание базы для успешного исполнения планов и связанных с ними задач).
  3. Мотивация (способность побудить подчинённых сконцентрироваться на исполнении задач).
  4. Координация и коммуникация (взаимодействие с внешним миром, другими отделами/службами и внутри команды/коллектива).
  5. Контроль (для своевременного обнаружения того, что текущая ситуация отклоняется от плана) и оценка результата (качественная и количественная).

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

Чем качественнее контроль, тем лучше и точнее реализуются планы. Но чем сложнее структура компании, её бизнес-процессов, чем больше подчинённых, тем сложнее контроль. Каждый новый уровень подчинённости добавляет свои искажения и препятствия при прохождении информации.

Как быть?

Как раз тут и помогают системы управления проектами, а также системы автоматизации. Часто обе сущности объединяются в одну или тесно интегрированы между собой.

Но общий критерий контроля слишком глобален. У каждого проекта или компании могут быть свои особенности и принципы управления. Одних только концепций – несколько десятков. А под каждую сильную концепцию нужен свой кастомизированный инструмент контроля.

По этой причине на рынке так много решений.

Чтобы немного облегчить выбор, проведём их классификацию.

Виды систем управления проектами

Условно основным критерием деления систем управления проектами (информационных систем) является их применимость внутри компаний:

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

Второй критерий – деление по вариантам и целям использования:

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

Не менее интересным критерием деления можно назвать формат предоставления лицензий на ПО:

  • Программы управления проектами могут работать на серверах предприятия (внутри контролируемого контура), то есть предполагается их локальная установка и обслуживание со всеми соответствующими рисками. Лицензии могут быть платными (с официальными гарантиями разработчиков) или бесплатными (в случае с ПО с открытым исходным кодом).
  • Программы управления проектами могут работать в облачной инфраструктуре (вне контролируемого контура). Но в этом случае за обновление, поддержку, балансировку нагрузки и за другие технические задачи отвечает владелец сервиса. Клиент (то есть компания) получает продукт в формате услуги по подписке.
  • Смешанный формат – когда облачное решение переносится на серверы предприятия, но доступа к настройкам и к коду всё равно нет, так как сервис работает в изолированной защищённой среде виртуализации. За поддержку и обновления по-прежнему отвечают разработчики ПО. Такой формат обычно подходит крупным компаниям, которым важна сохранность и конфиденциальность баз данных, то есть, чтобы они работали в подконтрольном периметре. Из бонусов – возможность сэкономить на покупке большого числа рабочих мест.

Ну и, конечно, не менее важна поддержка методологий управления. Обычно деление производится в привязке к конкретным концепциям управления, способам визуализации и возможностям настройки бизнес-процессов: наличие поддержки сетевых графиков (диаграмм Ганта), наличие сложной иерархии задач, цикличность выполнения и привязка к срокам, канбан-доски, поддержка разных статусов задач (предустановленных или с гибкой настройкой), расчёт KPI и управление стоимостью, делегирование, календарный вид, простые списки задач, поддержка планирования спринтов (из SCRUM), ведение бэклогов, хранение документов и многое другое.

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

Крупные проекты точно озадачатся наличием готовых интеграций и API для настройки взаимодействия систем управления проектом с другими информационными системами предприятия: CRM, CMS, ERP и пр.

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

Если мы напишем, что вам достаточно выбрать наш продукт, BPM-систему Projecto, и наш облачный сервис решит любые ваши проблемы, то мы вас обманем. Универсальных систем управления, подходящих для всех типов задач и целей применения, не бывает.

Алгоритм поиска идеального решения будет выглядеть заметно сложнее. Мы предлагаем придерживаться следующих шагов:

  1. Сначала вам нужно сформулировать чёткие технические требования к будущей системе. Для этого нужно как минимум описать:
    • Структуру вашего проекта и схему распределения прав между участниками (ролями). По каждой роли нужно изучить пределы полномочий, чтобы участники информационных систем случайно не получили лишних прав и не воспользовались ими для создания дополнительных проблем. Например, топ-менеджеры должны иметь возможность управления портфелями проектов и получать оперативную информацию о прогрессе с определённой периодичностью (например, раз в день и раз в неделю). У руководителей проектов должны быть свои инструменты управления: создание новых задач, делегирование, система напоминаний и прочее. Рядовые сотрудники должны иметь возможность оценки своего фронта работ на неделю или на день, знать чёткие сроки сдачи и т.д.
    • Схему связей между задачами и проектами (иерархические структуры). Всё это нужно для качественного планирования, дробления (детализации, декомпозиции) задач и контроля работы исполнителей.
    • Схему распределения ресурсов. Самый важный ресурс – это сотрудники. Это их нужно распределять по задачам и по отделам, службам и направлениям. Но ресурсы проекта не ограничиваются только людьми. Могут учитываться и другие типы ресурсов: время, деньги, помещения, производственные мощности и другое. Основная задача системы управления проектом – избежать одновременного доступа к одному и тому же ресурсу. То есть сотрудник не может выполнять две задачи одновременно. Руководитель не может поставить новые задачи, если сотрудник загружен. По аналогии должны контролироваться единые ресурсы, распределяемые между разными проектами и командами в портфеле проектов.
    • Схему обмена информацией. Кто, кому и по какому поводу может писать. Как и где обсуждаются входящие задачи, как можно дать обратную связь по прогрессу, как перенести сроки, как запросить дополнительные ресурсы, как отказаться от задачи и многое другое. На основе такой схемы будут формироваться участники общих обсуждений и чатов, вестись личные переписки, обрабатываться заявки и обратная связь от клиентов и заказчиков. Эта же схема задаёт ограничения. Простой пример: рядовой сотрудник должен коммуницировать по задаче с непосредственным руководителем, а не писать по любому пустяку гендиректору или владельцу бизнеса.
  2. Цифровые показатели и критерии для отслеживания статуса задач, а также отдельных бизнес-процессов. Обычно это решается системой метрик и KPI. Но могут внедряться и другие системы мониторинга, включая интеграции с различными системами автоматизации предприятия. Такие показатели должны стекаться в панель управления для отслеживания динамики и построения графиков.
  3. Требования к интеграции. Система управления проектами не может работать в сферическом вакууме. Чем крупнее проект, тем больше у него информационных систем. Все они должны работать как единое целое и способствовать реализации целей проекта, а не мешать им. Соответственно, система управления должна иметь программные интерфейсы (API, хуки, выгрузку файлов и данных), с помощью которых её можно включить в общее информационное поле проекта.
  4. Если вы достаточно изучили решения на рынке, то можно конкретизировать свои технические требования и обозначить:
    • Форматы визуализации задач (календарь, диаграммы, списки, доски, карточки, схемы связей и пр.).
    • Возможности настройки промежуточных статусов задач.
    • Возможности делегирования.
    • Форматы отслеживания работы над проектами и над портфелями проектов.
    • Требования к системе уведомлений по задачам.
    • Требования к хранилищу документов и контактов.
    • Требования к интеграциям (какие, сколько и т.п.).
    • Требования к чатам и личным перепискам (формат, доступ, хранение истории).
    • Возможности поиска информации и фильтрации результатов.
    • Наличие мобильных и десктопных приложений.
    • Формат и место хранения баз данных.
    • Наличие и возможности гостевого доступа (доступ для заказчиков и/или для наёмных сторонних исполнителей).
    • Возможности для кадровых служб (учёт времени, рабочих графиков, составления оргструктуры, ведение карточек сотрудников, учёт перемещений по должностям и пр.).
    • Инструменты удалённого контроля (для отслеживания активности персонала, задействованного вне офиса).
  5. Теперь нужно подобрать сервисы, подходящие под ваши технические критерии. Для этого можно пробежаться по специализированным рейтингам и каталогам софта. Сначала можно составить полный список ПО, чтобы потом заняться отсевом.
  6. Шаг детального изучения кандидатов и качественного отсева. Для этого потребуется сначала пройтись по каждому представителю (в этом помогут официальные сайты и документация), задать вопросы представителям, посмотреть демоверсии продуктов, заказать презентации, воспользоваться бесплатным периодом тестирования. На основе полученных данных нужно выявить максимальное соответствие претендентов вашим техническим требованиям. Если требования перекрываются частично, то система управления всё равно отбрасывается из списка. Зачем использовать продукт, который вам изначально не подходит и не может удовлетворить все потребности? В 99% случаев никто не будет заниматься доработкой под вас. Исключение – специальные гибкие решения, которые могут подгоняться под ваши бизнес-процессы.
  7. В списке должны остаться только те программы и сервисы, которые вас устраивают на 100% по всему необходимому функционалу.
  8. Далее считается стоимость использования каждого оставшегося сервиса. Это может быть разовая покупка корпоративных лицензий, оплата фиксированных пакетов с рабочими местами, гибкие тарифы и не только. Не стоит забывать о стоимости доработок, внедрения (включая обучение работе) и интеграций. Только так можно получить реальную картину вложений и точный бюджет расходов на внедрение новой информационной системы. Наверняка в вашем проекте есть минимальный и максимальный бюджет, который вы можете себе позволить и считаете приемлемым.
  9. Окончательный выбор должен опираться в первую очередь на:
  • бюджет внедрения — чем он меньше, тем лучше, 
  •  и потенциал роста — чем крупнее разработчик, чем дольше он на рынке, тем надёжнее его продукты и инфраструктура, тем больше «обкатано» его ПО и тем проще будет вырасти на его мощностях. Не лишним будет собрать обратную связь от состоявшихся пользователей – можно изучить отзывы в сети или опросить коллег по цеху, возможно, кто-то уже сталкивался с выбранным продуктом в реальных кейсах.

Более простой выход – спросить совет у коллег из своей отрасли (так называемое сарафанное радио), но у этого подхода есть существенный недостаток. Не факт, что решение, которое устроило условных конкурентов, на 100% подойдёт вам. Возможно, конкуренты тоже воспользовались чужим советом или рекомендацией, и теперь мучаются с неудобным софтом, так как ранее не захотели выделить время, чтобы протестировать разные решения на предмет удобства и совместимости со своими проектами.

Не будьте, как Петя, выбирайте инструмент для управления правильно!

Когда будете составлять общий список, не забудьте про нас – Projecto многое умеет. Специально для всестороннего тестирования имеется демо-режим и триал на 1 месяц (с возможностью бесшовного переноса тестового проекта в полноценную рабочую версию).