Резюме 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». Это: цель, ограничение, ваши действия, чем кончилось.
- Что поставляли (релиз, внедрение, миграция, интеграция) и для кого.
- Ограничения: срок, люди, внешний вендор, легаси, параллельные стримы.
- Что делали вы лично: карта зависимостей, статус, эскалация, пересбор скоупа, риск-лог.
- Чем кончилось: уехало / уехало с вырезанным скоупом / сдвинули и почему это было правильнее.
Плохо: «Успешно реализовал внедрение 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» без каденции в опыте лучше не тащить на первый экран.