Резюме Project Manager в IT проигрывает, когда вместо поставок стоит календарь встреч. «Вёл стендапы в Jira, коммуницировал со стейкхолдерами, работал по Agile» не отличает вас от шаблона курса. Рекрутер ищет другое: что уехало в срок, что сорвалось, чей конфликт вы закрыли и какой объём вы реально держали.

Ниже — как собрать ПМ-файл под продуктовые и сервисные команды CIS 2026: заголовок без путаницы с Product, формулировки поставок и рисков, стейкхолдеры без воды, два примера и что выкинуть. Общая рамка CV — в как составить резюме. Соседняя роль продукта — в резюме Product Manager, её не копируйте в ПМ-файл.

Коротко:

  • Пишите поставки и ограничения, не ритуалы ритуала: Scrum сам по себе не достижение.
  • Один сорванный срок с выводом сильнее десяти «успешных запусков» без деталей.
  • Отделите Project от Product и от аккаунт-менеджмента. Смешение ролей путает отбор.
  • Цифры: объём (люди, стримы, релизы), не выдуманный ROI.
  • Перед рассылкой сверните текст через разбор резюме и живые вакансии Project Manager.

Кого нанимают под словом PM

В русскоязычных вакансиях «PM» бывает трёх зверей: project, product, program. Если вы держали срок, бюджет, зависимости и статус — вы project. Если приоритет бэклога и метрику продукта — product. Если несколько команд и портфель — скорее program, и это другой файл.

Заголовок должен совпасть с объявлением. «Project / Product Manager» в одном CV почти всегда значит «не понял сам». Вход в роль и типичный путь — в как стать project manager. Путаница с продуктом дорого стоит на скрининге: вас начнут спрашивать про discovery, которого не было.

Первый экран: роль, тип поставок (интеграции, релизы платформы, внедрение у клиента, внутренние стримы), масштаб. Без масштаба «вёл проекты» = пусто.

Заголовок и summary

Примеры рабочих заголовков: «Project Manager, поставки в B2B SaaS», «IT Project Manager, внедрения и интеграции», «Delivery Manager / PM, релизы платформы». Не пишите PMP в заголовке, если сертификат — единственное, что есть.

Summary на четыре строки: какой контур, какой объём, какой ваш рычаг (зависимости, риски, заказчик, команда разработки), какой формат. Без «результативный лидер». Формула блока — в как написать summary.

Английский укажите уровнем и каналом: письменный статус vs созвоны с заказчиком. Для удалённых команд CIS это фильтр. Шаблон удалённого файла — в резюме для удалённой работы.

Как описывать поставки

Пункт опыта ПМ — не «управлял проектом X». Это: цель, ограничение, ваши действия, чем кончилось.

  1. Что поставляли (релиз, внедрение, миграция, интеграция) и для кого.
  2. Ограничения: срок, люди, внешний вендор, легаси, параллельные стримы.
  3. Что делали вы лично: карта зависимостей, статус, эскалация, пересбор скоупа, риск-лог.
  4. Чем кончилось: уехало / уехало с вырезанным скоупом / сдвинули и почему это было правильнее.

Плохо: «Успешно реализовал внедрение CRM». Хорошо: «Вёл внедрение тикетницы у 4 команд поддержки; внешний вендор срывал среду; пересобрал скоуп на пилот двух команд, пилот уехал в срок, остальное — вторым релизом».

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

Риски, стейкхолдеры, инструменты

Риск в резюме — не слово «риски». Это конкретный класс: зависимость от вендора, один человек знает контур, нет среды, заказчик меняет скоуп каждую неделю. Напишите, что вы сделали: буфер, пилот, письменный change-запрос, эскалация спонсору.

Стейкхолдеры: роли, не имена. Заказчик бизнеса, техлид, поддержка, внешний интегратор, юристы. Покажите конфликт приоритетов и чем кончили. «Выстраивал коммуникацию» без конфликта — вода.

Jira, Confluence, Slack — гигиена, не навык. Имеет смысл писать, если вакансия явно фильтрует стек управления или вы поднимали процесс с нуля (шаблоны статусов, Definition of Done, ритуал демо). Иначе уберите из skills отдельным храмом. Про стек вообще — в как указать стек в резюме.

Пример 1. ПМ внедрений

Вакансия: Project Manager, внедрения B2B, несколько команд на стороне клиента, удалёнка.

IT Project Manager, внедрения и интеграции. 4 года, B2B, удалённо, CIS + англоязычный заказчик письменно.

Вёл внедрение личного кабинета у трёх клиентов параллельно. Типичный контур: 2 внутренних стрима разработки, аналитик, внешняя ДБО. Держал единый статус раз в неделю и отдельный риск-лог по средам. На одном клиенте среда заказчика отставала на месяц — вырезали интеграцию из пилота, пилот уехал, интеграция вторым этапом. Эскалацию спонсору оформили письменно, без «просто сдвинем».

Команда разработки не в прямом подчинении: влияние через техлида и прозрачный скоуп. Бюджет контракта не считал сам — вёл трудозатраты и предупреждал о выгорании скоупа.

Честные границы (бюджет не ваш, люди не подчинены) усиливают, не ослабляют. Рекрутер понимает, в какой модели вы уже работали.

Пример 2. Delivery в продуктовой команде

Вакансия: PM / Delivery, релизы своей платформы, не клиентские внедрения.

Project / Delivery Manager в продуктовой команде. Релизы платформы, 8–10 человек на контуре, 2 недели каденции.

Собрал карту зависимостей между backend, QA и фронтом после серии «релизов в пятницу с откатом». Ввели заморозку скоупа за 3 дня и чеклист релиза. За два квартала откаты по этому контуру перестали быть нормой — остались инциденты, но не из-за «не ту ветку».

Приоритет бэклога утверждал продукт, не я. Моя зона — срок, зависимости, готовность QA, коммуникация с поддержкой о окне релиза. Scrum-церемонии сам по себе в файл не выносил.

Разделение с Product здесь явное. Это спасает скрининг. Если вы на самом деле мешали роли — разведите два периода в опыте, не один абзац «делал всё».

Масштаб без фантазии

Пишите то, что можете защитить: число команд, длительность поставки, число внешних сторон, частота релизов, размер пилота. Не пишите «увеличил эффективность на 40%», если не было базовой метрики.

Деньги: бюджет, если вы им управляли. Маржа и выручка продукта — не ваш факт, если вы не product. Люди: штат / аутсорс / вендор. Для CIS-удалёнки полезен часовой пояс заказчика и язык статуса.

Сертификаты (PMP, PSM) — строка внизу, не замена поставкам. Курс «Agile» без каденции в опыте лучше не тащить на первый экран.

Как выглядит скрининг ПМ и чем файл должен помочь

На скрининге почти всегда просят один кейс: сложный стейкхолдер, сорванный срок или зависимость. Если в резюме только «успешные внедрения», рассказывать будет нечего — или придётся импровизировать. Лучше заранее выбрать кейс и отразить его пулей: ограничение, действие, исход. Тогда вопрос «расскажите про провал» не ломает вас. Заготовьте вторую историю короче: конфликт приоритетов между заказчиком и техлидом и чем кончили письменно. Две истории закрывают почти весь скрининг ПМ.

Вас спросят, кому вы подчинялись и кто был в команде. Напишите модель влияния в файле: прямое подчинение, матрица, вендор, продукт как заказчик скоупа. Скрытая матрица всплывает фразой «ну, я не мог им указывать» и звучит слабее, чем честная строка в CV.

Перед/после пули:

Было: «Организовывал работу кросс-функциональной команды по Agile, вёл церемонии, обеспечивал прозрачность статуса в Jira».

Стало: «Вёл интеграцию платежей с внешним провайдером: 2 внутренних стрима и вендор. Провайдер сдвинул песочницу на 3 недели — вырезали рекуррент из пилота, пилот уехал, рекуррент вторым релизом. Статус и change письменно, без устного “потом догоним”».

Инструмент исчез, появилась поставка. Так и должно быть. Jira можно оставить в skills одной строкой, если вакансия её фильтрует.

Для удалённых CIS-команд в 2026-м отдельный минус — файл без языка статуса. Если заказчик англоязычный, напишите: письменный статус на английском, созвоны — по факту. Если только русский — тоже напишите, чтобы не звали на daily на английском «потому что IT». Формат удалёнки — в резюме для удалённой работы.

Чек-лист: заголовок Project, не каша с Product; в summary есть масштаб; в пулях есть ограничение и исход; нет митингов как достижений; сертификат не на месте факта. Письмо указывает на одну поставку под объявление, каркас — в сопроводительном письме.

Чего не писать

  • «Организовывал митинги», «вёл коммуникацию», «работал в режиме многозадачности».
  • Копипаст манифеста Agile и список ценностей.
  • Смешение «нанимал разработчиков, рисовал макеты, писал код, продавал» — если это не три разные роли по годам.
  • Заголовок Senior Program Director при одном внутреннем релизе.
  • Инструменты: Excel, Zoom, почта — как навыки.

Формат: одна колонка, PDF текстом, без инфографики «колёсико компетенций». См. ошибки в резюме. ATS для ПМ тоже режет колонки — как пройти ATS.

Письмо и отклик

Сопроводительное указывает на одну поставку под задачу вакансии: внедрение, внутренний релиз, миграция. Не перечисляйте все сертификаты. Каркас — в что писать в письме.

Вилку в файл не ставьте наугад. Соберите ориентир по фильтрам вакансий Project Manager: грейд, домен, формат. На экране — спокойная вилка, как в ответе про зарплату.

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

Я совмещал ПМ и аналитика. Как писать?

Два блока внутри роли или две роли по периодам. Верхние пули — та роль, на которую откликаетесь. Смешанный абзац «аналитика + сроки + Jira» не читается ни одним отбором.

Нужно ли писать, что команда была на аутсорсе?

Да, это модель влияния. Скрытый аутсорс всплывает вопросом «как ставили задачи и кто принимал код». Честная модель сильнее.

Можно ли писать про «успех», если релиз сдвинули?

Можно, если вы объясняете решение: вырезанный скоуп, риск качества, зависимость. «Успешно сдвинули» без причины — слабая пуля.

Стоит ли слать ПМ-резюме на Scrum Master?

Только отдельной версией: фасилитация, каденция, улучшения процесса. Поставки и бюджет там не главные. Один файл на обе роли обычно не попадает никуда.

Как показать работу без цифр?

Масштаб и ограничение: «3 вендора, одно общее окно релиза», «пилот на 2 команды из 10». Это не ROI, но это проверяемый факт.

Нужен ли технический бэкграунд в skills?

Коротко: домен (биллинг, интеграции, мобильное приложение) и уровень, на котором вы читаете статус разработки. Не список Java/Kubernetes, если вы ими не пользовались. Иначе на скрининге разберут как техлида.

Что сделать сейчас

Выпишите три поставки: цель, ограничение, ваш рычаг, исход. Соберите из них 4–6 пуль и четырёхстрочный summary без Agile-мантры. Вычеркните митинги и Jira как достижения. Прочитайте файл вслух за минуту: если слышите только ритуалы, правьте ещё раз.

Сверьте заголовок с тремя объявлениями в каталоге Project Manager и прогоните файл в разборе резюме. Если после диагонали видно только «человек из Jira» — вы ещё не написали ПМ-резюме. Откликнитесь на одну вакансию своего типа поставки: внедрение к внедрению, внутренний релиз к внутреннему релизу. Смешение в одном письме снова превратит вас в «Agile-человека» без контура.