PMaaS (Project Management as a Service) — это аутсорсинг управления проектами: вы не нанимаете проджект-менеджера в штат, а “берёте управление в аренду” у провайдера, который ставит цели, выстраивает процессы, ведёт команду и отвечает за результат по SLA/договору.

На российском рынке PMaaS всплыл не потому что «так модно», а потому что бюджеты на ошибку стали меньше, сроки — короче, а хорошего PM/Delivery в штат быстро не найти. И да, если вы сейчас думаете «это ещё один консалтинг, который будет рисовать диаграммы», — иногда так и бывает. Поэтому ниже разложу, что такое PMaaS на практике, где он окупается, а где превращается в дорогую имитацию бурной деятельности.

Если вы меняете профессию на IT: относитесь к PMaaS как к “контейнерной доставке” управления. Вы покупаете не «человека-героя», а сервис: регламенты, ритм, отчётность, контроль рисков. Если вы уже в IT: PMaaS — это способ закрыть провал в delivery или разгрузить тимлида, когда продукт растёт быстрее, чем оргструктура.

Как устроен PMaaS в России: из чего состоит сервис

1) Что именно продают: не титул PM, а результат и управляемость

Тезис: pmaas — это не “проджект на удалёнке”, а пакет управленческих практик + ответственность по договорённостям.

Обоснование: в РФ чаще всего PMaaS покупают компании, где уже есть разработка (in-house или подрядчик), но нет устойчивого управления: срываются сроки, нет прозрачности по бэклогу, релизы живут по принципу “ну должно же уже работать”. PMaaS закрывает это архитектурой процесса: роли, регулярные события (планирование/демо/ретро), артефакты (бэклог, roadmap, risk register), метрики (lead time, throughput, прогноз).

Практический вывод: спрашивайте у провайдера не «какой у вас PM», а «какие артефакты и метрики появятся через 2–4 недели, и как вы докажете, что управление стало предсказуемее».

Подводный камень: если провайдер обещает «наведём порядок» без конкретики (какой порядок? в каких цифрах?), вы покупаете успокоительное, а не сервис.

2) Модели работы: “встраиваемся” или “берём на себя”

Тезис: в России PMaaS чаще живёт в двух режимах — “встроенный PM” и “delivery-ячейка”.

Практический вывод: если у вас 1 продукт и 1 команда — обычно достаточно встроенного PM. Если 2–3 команды, интеграции с 1С/CRM/СЭД и несколько директоров в роли «главного заказчика» — берите сервисную “ячейку”.

Подводный камень: пытаться купить “одного проджекта” на хаос уровня «у нас 5 начальников и ни одного единого бэклога». Один человек там будет не управлять, а вести кружок психотерапии.

3) Типовой процесс внедрения: что происходит в первые 30 дней

Тезис: нормальный аутсорсинг управления проектами начинается с диагностики, а не с митингов “познакомимся”.

1. Неделя 1: аудит контекста — цели, стейкхолдеры, ограничения, текущие артефакты (если они вообще существуют), карта рисков.
2. Неделя 2: настройка инструментов и ритма — YouTrack/Jira, Confluence/Notion-аналоги, регламент созвонов, каналы коммуникации, правила изменения объёма работ (scope).
3. Неделя 3: стабилизация планирования — бэклог, критерии готовности (DoR/DoD), внятная приоритизация, первые прогнозы по срокам.
4. Неделя 4: управляемость — регулярная отчётность, прозрачные зависимости, снятие блокеров, согласование roadmap на 1–3 месяца.

Практический вывод: если через месяц у вас не стало хотя бы (а) единого бэклога, (б) понятных приоритетов, (в) регулярного отчёта «что сделано/что мешает/что дальше» — это не PMaaS, а платная переписка в мессенджере.

Подводный камень: “мы всё делаем в Excel и созвонах” — можно, но тогда платите не за управление, а за иллюзию контроля. Excel хорош, когда у вас 20 строк, а не 200 зависимостей.

Где PMaaS реально окупается (и где нет)

Сценарии, где PMaaS приносит деньги, а не отчёты

• Нет времени нанимать: поиск PM в РФ может занять 1–3 месяца, плюс адаптация. PMaaS включается за 1–2 недели.
• Проект “горит”: сорванные релизы, конфликт заказчика и разработки, штрафные риски — внешний менеджмент иногда полезнее, потому что ему проще быть “плохим полицейским”.
• Нужна управляемость для инвестора/руководства: прозрачная картина по срокам, рискам и деньгам.
• Параллельные подрядчики: интеграции (например, 1С + веб + BI) и вечный вопрос «кто виноват».

Подводный камень: PMaaS не спасает продукт без владельца. Если у вас никто не принимает решения по приоритетам и не отвечает за ценность (Product Owner/владелец продукта), то проджект будет идеально планировать движение в никуда.

Сценарии, где PMaaS чаще разочаровывает

• Сверхмалые команды: 2 разработчика и дизайнер — дешевле и быстрее договориться напрямую.
• “Сделайте нам как у Яндекса” без бюджета и данных: будет много церемоний, мало результата.
• Токсичная политика: когда задача — не сделать, а “перекинуть ответственность”. PMaaS это вскрывает, и кому-то становится неприятно.

Деньги и условия: сколько стоит PMaaS в России и что обычно входит

Цены сильно зависят от уровня специалиста, отрасли и степени “пожара”. В РФ чаще встречаются такие вилки:

Практический вывод: сравнивайте не только цену, но и “ширину ответственности”. Если провайдер не готов фиксировать границы (что делаем/что не делаем) — потом вы будете платить за каждую фразу «а давайте ещё…».

Подводный камень: PMaaS иногда покупают, чтобы сэкономить на найме. Потом выясняется, что нужен ещё аналитик, а потом ещё релиз-менеджер. Экономия превращается в конструктор “собери франкенштейна”.

Кстати, на https://itokno.ru регулярно появляются разборы форматов работы в IT и карьерных стратегий — полезно сверять ожидания с рынком, чтобы не платить за красивые слова.

Кейсы из практики: как бывает в живой России

Кейс “взлетело”: e-commerce и вечный конфликт “маркетинг vs разработка”

Компания с интернет-магазином и 1С:УТ. Маркетинг хотел акции “вчера”, разработка отвечала “в следующем квартале”. Подключили PMaaS в режиме mini delivery office: PM + аналитик. За 3 недели собрали единый бэклог, ввели правило: никакой задачи без критериев приёмки и оценки трудоёмкости. Через 2 месяца бизнес получил прогнозируемый календарь релизов, а команда перестала жить в “срочно-срочно”.

Почему сработало: был владелец продукта, который реально принимал решения, и руководство согласилось на прозрачность (а это больно — сразу видно, кто тормозит).

Кейс “не взлетело”: “поставьте нам Scrum, чтобы быстрее”

Классика. B2B-сервис, 3 стейкхолдера, которые спорят даже о цвете кнопки. Купили pmaas аутсорсинг управления проектами и ожидали, что внешний PM “заставит” всех договориться. В итоге — много встреч, красивый board, ноль решений по приоритетам. Через 6 недель проект остановился, потому что никто внутри не хотел быть тем самым человеком, который скажет “делаем А, Б не делаем”.

Почему провалилось: PMaaS не заменяет управленческую волю заказчика. Он её усиливает, но не создаёт из воздуха.

Экспертный вердикт и инструмент: как понять, нужен ли вам PMaaS

Что такое PMaaS в здоровом виде: быстрый способ получить управляемость проекта без найма в штат. Но это работает, только если вы готовы играть по правилам: принимать решения, фиксировать договорённости и терпеть прозрачность.

Чек-лист: 7 вопросов, чтобы не купить “планёрки как сервис”

1. Кто у нас внутри принимает финальные решения по приоритетам? (Имя, должность, доступность.)
2. Какие метрики провайдер будет улучшать: сроки, предсказуемость, количество просроченных задач, качество?
3. Какие артефакты появятся через 2–4 недели: бэклог, roadmap, реестр рисков, регламент изменений?
4. Как выглядит SLA: время реакции на блокеры, формат отчёта, частота синков, ответственность сторон?
5. Что входит в стоимость, а что будет допсчётом: аналитика, документация, релиз-координация, управление подрядчиками?
6. Какие инструменты используем: YouTrack/Jira, Confluence, Битрикс24, МойОфис — и кто администрирует?
7. Как происходит выход из услуги: передача знаний, документации, обучение внутреннего PM?

Если вы “перебежчик” в IT: PMaaS — хороший способ увидеть, как устроено управление проектом в реальности (а не в курсах), но входить лучше через роли координатора/ассистента PM или junior PM в компании-провайдере: там быстрее набирается практика.

Если вы junior/middle IT: используйте PMaaS как ориентир по стандартам: какие артефакты должны быть, как выглядит нормальная коммуникация, что такое управление рисками, а не “ну мы надеемся”.

Частые вопросы