Российский рынок ПО для управления проектами достиг ₽6 млрд в 2024 году — рост на 11% за год, а доля отечественных решений перевалила за ₽4,4 млрд и продолжает расти (TAdviser, обзор рынка PM-систем в России)). Десятки вендоров, сотни функций, и каждый второй называет себя «лучшим решением для вашего бизнеса». Ошибка выбора стоит дорого: месяцы адаптации команды, потерянные данные при миграции, деньги за лицензию системы, которую никто не открывает.

Эта статья — структурированный чек-лист из 27 критериев, сгруппированных в 7 блоков, по которому можно оценить любую PM-систему — на демо, в пилоте или при пересмотре текущего инструмента.

Чек-лист написан для трёх ролей: руководитель проекта, операционный директор, владелец процесса. Критерии разные по весу — для кого-то безопасность стоит на первом месте, для кого-то методологическая гибкость. Логика блоков помогает расставить приоритеты под свой контекст, а не оценивать всё одинаково.

Почему «просто хороший сервис» — это не критерий выбора

Типичная история выглядит так: руководитель смотрит подборки «топ-10 PM-систем», читает отзывы, выбирает ту, у которой красивый интерфейс и много звёздочек на G2. Через три месяца выясняется, что в системе нет ресурсного планирования, а команда из 40 человек ведёт реальную работу в трёх параллельных чатах.

Самая частая ошибка — искать «просто хороший сервис», а потом обнаружить, что он не решает основную проблему компании. Инструмент сам по себе не плохой. Просто его выбирали не под проблему, а под впечатление.

Три сценария, которые встречаются чаще всего:

Купили «тяжёлую» систему для команды из 15 человек. PPM-платформа с портфельным управлением, бюджетированием и матрицей рисков — а пользуются только доской задач. Половина функций закрыта, потому что никто не понимает, зачем они нужны. Adoption падает, люди возвращаются в Telegram.

Взяли лёгкий таск-трекер для портфеля из 40 проектов. Нет ресурсного планирования, нет сводной аналитики по загрузке, нет зависимостей на Ганте. Всё это «решается» вручную в Excel — и операционный директор тратит по пять часов в неделю на сборку отчётов, которые устаревают к моменту встречи.

Выбрали по интерфейсу — через полгода упёрлись в отсутствие интеграций. Система не подключается к корпоративному мессенджеру, нет API для выгрузки в BI, а интеграция с календарём — «в роадмапе на следующий квартал».

Рецепт прост, хотя и требует дисциплины: до начала поиска зафиксировать 3–5 конкретных проблем. Срываются сроки — почему? Непрозрачная загрузка — у кого? Разрозненные данные — между какими системами? Каждый инструмент потом проверяется именно по этому списку, а не по общему ощущению от демо.

27 критериев выбора: полный чек-лист, сгруппированный по 7 блокам

27 критериев выбора PM-системы: 7 блоков для руководителя
27 критериев выбора PM-системы: 7 блоков для руководителя

Блок 1 — Безопасность и комплаенс (критерии 1–4)

Для компаний, работающих с персональными данными или имеющих государственные контракты, этот блок — юридическое требование, а не формальность. По прогнозам TAdviser, к 2025 году доля российских решений на рынке достигнет 81% — во многом именно потому, что вопрос локализации данных перестал быть абстрактным.

  1. Хранение данных на территории РФ — уточните, где физически расположены серверы; для соответствия 152-ФЗ это обязательно, если система обрабатывает персональные данные.
  2. Ролевая модель доступа с гранулярными правами — проверьте, можно ли настроить права до уровня конкретного проекта или задачи; подрядчик не должен видеть бюджеты других клиентов.
  3. Аудит-лог действий пользователей — попросите показать, как выглядит история изменений: кто, что и когда изменил в задаче или проекте.
  4. Шифрование данных в покое и при передаче — уточните наличие сертификатов (ФСТЭК, ФСБ или аналогов) и протоколов передачи данных.

Блок 2 — Импортозамещение и инфраструктурная устойчивость (критерии 5–8)

Риск блокировки зарубежного сервиса или отключения платёжной инфраструктуры — уже не гипотетический сценарий. Для частного бизнеса требования мягче, но инфраструктурная зависимость от AWS или Stripe остаётся операционным риском.

  1. Включение в Реестр отечественного ПО — обязательно для госсектора и компаний с госучастием; для остальных снижает регуляторный риск.
  2. Оплата в рублях без зависимости от зарубежных платёжных систем — проверьте, работает ли биллинг через российские эквайринги.
  3. Независимость от зарубежной облачной инфраструктуры — уточните, на каких дата-центрах работает SaaS-версия.
  4. Наличие on-premise или частного облака — для сценариев с повышенными требованиями к безопасности или медленным интернетом на объектах.

Блок 3 — Методологии и гибкость процессов (критерии 9–13)

Компании всё активнее уходят от «чистого» Waterfall или Agile к гибридным моделям — по данным Kaiten, тренды проектного управления 2025, это одна из ключевых тенденций года. Часть проекта ведётся по фиксированным этапам, часть — итеративно. Система, которая поддерживает только один подход, вынуждает команду подстраиваться под инструмент вместо того, чтобы инструмент подстраивался под процесс.

  1. Поддержка Kanban — настраиваемые колонки, WIP-лимиты, фильтрация по исполнителям и тегам.
  2. Диаграмма Ганта с зависимостями и критическим путём — попросите на демо сдвинуть дедлайн задачи с тремя зависимостями и посмотреть, как система пересчитывает связанные задачи.
  3. Поддержка Scrum — спринты, бэклог, burndown-chart; важно, если у вас есть хотя бы одна итеративная команда.
  4. Гибридный режим — возможность вести часть проекта по Waterfall, часть по Agile в рамках одного пространства.
  5. Настраиваемые стадии и воркфлоу без разработчика — проверьте, сколько кликов нужно, чтобы добавить новый статус задачи или изменить логику перехода между этапами.

Блок 4 — Ресурсы, загрузка и планирование (критерии 14–18)

Ваш тимлид говорит, что перегружен. Вы верите ему на слово — или можете проверить за 30 секунд? Этот блок чаще всего «проваливается» при выборе лёгких таск-трекеров. Видеть, кто перегружен, а у кого есть свободная ёмкость — базовая функция для любой команды больше 10 человек.

  1. Визуализация загрузки команды — кто перегружен, кто свободен, как распределены задачи по исполнителям в текущем периоде.
  2. Плановое и фактическое время с отклонением — система должна показывать не только «сделано/не сделано», но и сколько часов потрачено против плана.
  3. Ресурсное планирование на уровне портфеля — можно ли увидеть загрузку конкретного сотрудника по всем его проектам одновременно.
  4. Учёт нерабочих дней, отпусков, частичной занятости — проверьте, влияет ли отпуск сотрудника на автоматический расчёт сроков его задач.
  5. Трекинг времени — встроенный таймер или интеграция с внешним инструментом; важно для команд, которые выставляют счета по часам или контролируют маржинальность.

Блок 5 — Цели, стратегия и OKR (критерии 19–21)

Задача без связи со стратегической целью — это просто работа ради работы. Если система позволяет видеть, как конкретная задача влияет на квартальный OKR, команда понимает приоритеты без ежедневных объяснений от руководителя. Тем, кто ещё выбирает модель целеполагания, стоит сначала разобраться с различиями подходов — об этом подробно написано в сравнении OKR, KPI и MBO.

  1. Связь стратегических целей с операционными задачами — проверьте, можно ли привязать задачу к OKR или KPI и видеть прогресс в реальном времени.
  2. Визуализация прогресса по целям — дашборд с процентом выполнения целей, обновляемый автоматически по мере закрытия задач.
  3. Каскадирование целей — от уровня компании до команды и конкретного сотрудника; важно для компаний с несколькими подразделениями.

Блок 6 — Интеграции и экосистема (критерии 22–25)

Вопрос, который стоит задать себе до демо: в каких системах команда проводит 80% рабочего времени? PM-система, которая живёт в изоляции от этих инструментов, создаёт новый силос вместо того, чтобы устранять старые. Проверяйте не количество интеграций, а их глубину: поверхностный коннектор, который просто дублирует уведомления, не считается.

  1. Интеграция с мессенджерами — Telegram, VK Teams, корпоративные чаты; уведомления о задачах должны приходить туда, где команда уже работает.
  2. Связка с календарями — Google Calendar, Яндекс Календарь; дедлайны задач должны автоматически появляться в расписании исполнителя.
  3. API и вебхуки — для кастомных сценариев: выгрузка данных в BI, синхронизация с CRM, автоматизация через n8n или аналоги.
  4. Встроенная аналитика или интеграция с BI — собственные дашборды или возможность подключить Power BI, Tableau, Yandex DataLens.

Блок 7 — UX, адаптация и масштабирование (критерии 26–27)

Самый недооценённый блок. Система с идеальным набором функций, которую команда не использует ежедневно, стоит ноль. Если хотите сравнить конкретные инструменты по этому критерию, есть смысл изучить подборку приложений для планирования — там разобраны различия в подходах к UX.

  1. Time-to-value — сколько дней нужно команде, чтобы начать реально работать в системе; хороший ориентир: через 5 рабочих дней после старта пилота 50%+ задач должны создаваться внутри системы.
  2. Масштабируемость — как система ведёт себя при росте с 20 до 200+ пользователей: производительность, тарифная модель, возможность разграничить пространства по подразделениям.

Что на самом деле показывает демо — и что оно скрывает

Демо показывает лучшее — проверяйте на реальных данных
Демо показывает лучшее — проверяйте на реальных данных

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

Чтобы увидеть систему в боевых условиях, приходите на демо со своим сценарием. Вот вопросы, которые стоит задать:

  • «Покажите, как выглядит отчёт по загрузке при 50+ задачах и 15 исполнителях» — не скриншот из презентации, а живая демонстрация.
  • «Как настроить права доступа так, чтобы подрядчик видел только свой проект и не видел бюджеты?»
  • «Что произойдёт, если я сдвину дедлайн задачи с тремя зависимостями на Ганте — покажите прямо сейчас?»
  • «Какие функции сейчас в роадмапе, а не в продакшене — и когда они выйдут?»
  • «Можно ли загрузить наши реальные данные на период пилота, а не работать с тестовыми?»

Разница между «фичей в роадмапе» и «фичей в продакшене» — принципиальная. Если ключевой для вас критерий находится в роадмапе на «Q3», это означает, что на момент внедрения его может не быть. Всегда уточняйте статус каждой функции, которая вошла в ваш чек-лист.

Обязательно просите пилотный период с реальными данными. Тестовые проекты не показывают ни реальной производительности системы, ни того, как команда с ней взаимодействует.

Как строительные компании выбирают PM-систему: уроки из обзора 12 вендоров

В строительстве управление проектами — это одновременное управление сроками, бюджетом, подрядчиками, документами, нарядами на работы и проектной документацией. Иногда — в условиях отсутствия стабильного интернета на объекте.

По данным обзора IaaSSaaSPaaS, 12 российских PM-систем сравнивались более чем по 80 критериям: планирование и сроки, ресурсы и бюджет, документооборот, аналитика, коммуникации, технологические возможности. Решающими для строительных компаний оказались не интерфейс и не количество шаблонов, а четыре конкретных блока: управление бюджетом с отклонениями план/факт, документооборот с версионированием, мобильный доступ при слабом сигнале и интеграция с BIM-системами.

Вывод для любой отрасли: чек-лист критериев должен вытекать из ваших реальных процессов. Если у вас строительство — добавьте документооборот и бюджетирование. Если IT-аутсорс — трекинг времени и интеграцию с системами выставления счетов. Если маркетинговое агентство — управление несколькими клиентами в одном пространстве с разграничением доступа.

Сначала опишите процессы — потом ищите систему под них.

Контр-интуитивный вывод: больше функций ≠ лучший выбор

Половина российского рынка PM-систем — комплексные платформы: ₽3 млрд из ₽6 млрд по данным TAdviser. Соблазн купить «всё в одном» понятен, но на практике руководитель хочет полноту функций, а команда саботирует сложный инструмент и возвращается в чаты. Люди реагируют на когнитивную перегрузку предсказуемо: если для создания задачи нужно заполнить семь обязательных полей, задачи перестают создавать в системе.

В профессиональном сообществе этот спор хорошо известен. ITGLOBAL.COM ставит вопрос прямо: функциональная полнота против «не перегружать команду». Для холдинга с сотнями разработчиков нужна платформа PPM-класса. Для команды из 20 человек такая платформа превратится в обузу.

Здесь работает критерий time-to-value из блока 7. Если через две недели пилота команда не работает в системе ежедневно — система не подходит, какой бы полной ни была её функциональность. Она может быть отличной — но не для вашей команды в её текущем состоянии.

Практическая рекомендация: выбирайте систему, которая закрывает 80% потребностей «из коробки» и позволяет наращивать сложность постепенно. Лучше начать с канбан-доски и трекинга времени, а через квартал добавить ресурсное планирование, чем сразу развернуть платформу с модулями, которые никто не откроет.

ИИ и автоматизация в PM-системах: что реально работает в 2026, а что — маркетинг

По прогнозу Tinkoff/Secrets, к 2030 году значительная часть рутинных задач проектного управления — обновление статусов, формирование отчётов, распределение по приоритетам — может быть автоматизирована ИИ. 2026 год — этап перехода: ИИ-функции уже есть в продуктах, но качество сильно варьируется.

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

Что пока не работает надёжно: полностью автономное планирование без участия PM, замена менеджера в принятии решений об эскалации, «умное» перераспределение ресурсов в реальном времени без ручной проверки.

Критерий для чек-листа простой: на демо спрашивайте не «есть ли у вас ИИ», а «какие конкретные действия система выполняет без участия человека — и как вы это измеряете». Если ответ расплывчатый — перед вами AI-washing, а не реальная автоматизация.

Пример применения чек-листа: как Shtab закрывает ключевые критерии

Чтобы чек-лист не остался абстрактным, покажем, как конкретные критерии реализованы в одной из российских систем — Shtab. Используйте этот разбор как шаблон: задавайте те же вопросы любому вендору, которого рассматриваете.

Критерий 2 (ролевая модель). В Shtab настраиваемые роли работают на уровне каждого проекта: пользователь может быть администратором в одном проекте и обычным участником во всех остальных. Подрядчик видит только то, что ему нужно.

Критерий 10 (Гант с зависимостями). Диаграмма Ганта с автопланированием и критическим путём: при сдвиге сроков одной задачи автоматически пересчитываются все связанные. Это именно тот вопрос, который стоит задавать на демо у любого вендора.

Критерий 13 (настраиваемые стадии). Стадии проекта настраиваются без разработчика — через интерфейс, за несколько минут. Задачи группируются по этапам, воркфлоу меняется под процесс команды, а не наоборот.

Критерии 14–15 (загрузка и отклонение). Сводный отчёт показывает плановое и фактическое время по каждой задаче, процент отклонения от плана, фильтрацию по исполнителям, проектам и пространствам. Это данные, по которым можно принять решение прямо на встрече — без дополнительных выгрузок в Excel.

Для тех, кто хочет разобраться в методологической базе управления проектами до выбора инструмента, рекомендуем статью о 8 принципах управления проектами — она помогает сформулировать требования к системе на языке процессов, а не функций.

Data-driven управление: почему дашборды — критерий отсева, а не приятный бонус

По данным Kaiten, в 2025 году 67% компаний, внедривших PM-систему, назвали аналитические дашборды основным инструментом принятия решений на еженедельных встречах. ADVANTA фиксирует аналогичный сдвиг: руководители проектов переходят от интуитивных оценок к метрикам.

Минимальный набор аналитики, который должен быть в любой системе: загрузка по людям, прогресс по проектам, просроченные задачи, отклонение план/факт по срокам и времени. Если этого нет «из коробки» — система не соответствует требованиям 2026 года.

Принципиальный вопрос: приводят ли данные на дашборде к конкретному действию? Руководитель смотрит на экран и понимает: «Иван перегружен — нужно перераспределить три задачи». Или: «Проект А отстаёт на 20% — нужна эскалация». Если дашборд показывает красивые графики, но никто не меняет решения на их основе — вы платите за декорацию.

Проверка на демо: попросите показать, как выглядит дашборд при 30+ активных задачах, и спросите, какие действия система рекомендует на основе отклонений.

Четыре шага после выбора: как не потерять результат на внедрении

Выбор системы — это примерно 30% успеха. Остальные 70% — пилот, обучение, миграция данных и формирование привычки у команды.

Шаг 1: пилот на одном реальном проекте. 2–4 недели, один проект, измеримые критерии успеха. Например: «К концу пилота 80% задач команды создаются и закрываются внутри системы, а не в чатах». Меньше двух недель — не покажет реальных проблем. Больше месяца — затянет решение и даст команде возможность «подождать, пока само пройдёт».

Шаг 2: обучение команды. Выделите 2–3 часа на воркшоп с реальными сценариями: как создать задачу, как отследить дедлайн, как посмотреть свою загрузку. Без этого шага даже интуитивная система будет использоваться на 20% возможностей. Назначьте «чемпиона» — человека в команде, который отвечает на вопросы коллег и собирает обратную связь.

Шаг 3: миграция данных. Заранее проверьте, есть ли импорт из текущего инструмента — CSV, API, ручной перенос. Узнайте точные сроки. Миграция из Jira или Trello в новую систему занимает в среднем 3–5 рабочих дней для команды из 20–30 человек при наличии инструментов импорта; без них — до трёх недель.

Шаг 4: ритуал adoption. Еженедельная встреча первые 2 месяца, где команда разбирает: что работает, что мешает, что нужно настроить. Без этого даже хорошая система превращается в «ещё один мёртвый сервис» — как это происходит с большинством инструментов, которые «внедрили и забыли». О том, как связать выбор инструмента с реальной практикой распределения работы, читайте в статье о делегировании задач.

Итог

Если последний пересмотр вашего PM-инструмента был больше 18 месяцев назад — пройдите хотя бы блок 1 чек-листа прямо сейчас: требования 152-ФЗ обновились, реестр отечественного ПО расширился, а ряд зарубежных сервисов ограничил доступ для российских компаний.

Сохраните чек-лист и используйте его на ближайшем демо. Особенно блок 7 — time-to-value и масштабируемость. Именно там чаще всего обнаруживается разрыв между тем, что обещает вендор, и тем, что происходит в первые недели реальной работы.

FAQ

Сколько времени закладывать на пилот PM-системы?
2–4 недели на одном реальном проекте. Меньше — не покажет реальных проблем с производительностью и adoption. Больше месяца — затянет решение, и команда привыкнет работать «в тестовом режиме», что искажает результат.

Обязательно ли наличие в Реестре отечественного ПО?
Для госсектора и компаний с госучастием — да, юридически обязательно. Для частного бизнеса — не обязательно, но снижает риск блокировки и упрощает работу с корпоративными службами безопасности.

Можно ли совмещать Agile и Waterfall в одной системе?
Да, и это становится нормой. Часть проекта ведётся по Ганту с фиксированными этапами, часть — на канбан-доске итеративно. Главное — убедиться на демо, что система поддерживает оба режима в рамках одного проекта, а не только как отдельные шаблоны.

Что важнее — количество интеграций или качество API?
Качество API. 5 глубоких интеграций с реально используемыми сервисами ценнее, чем 50 поверхностных коннекторов. Проверяйте: можно ли через API выгрузить любые данные, настроить вебхуки на нужные события и синхронизировать статусы в реальном времени.

Как понять, что команда действительно приняла новый инструмент?
Метрика: через 3 недели пилота 80%+ задач создаются и закрываются внутри системы, а не в чатах или таблицах. Если через три недели команда всё ещё «дублирует» задачи в Telegram — это сигнал либо к дополнительному обучению, либо к пересмотру выбора инструмента.