Что делает проджект-менеджер каждый день
Проджект-менеджер (PM) — это человек, который в первый день проекта садится с заказчиком, выясняет, что именно нужно получить на выходе, и сразу начинает разбивать это на конкретные задачи, назначать ответственных и выставлять контрольные точки. PM не пишет код, не рисует макеты и не настраивает рекламу — он выстраивает систему, в которой каждый участник знает свою задачу, видит зависимости и получает обратную связь вовремя.
Типичный рабочий день PM выглядит так:
- Планирование и декомпозиция. Разбивает крупные цели на задачи, расставляет приоритеты, строит дорожную карту с вехами.
- Стендапы и синхронизация. Проводит короткие встречи с командой, снимает блокеры, фиксирует статус.
- Управление рисками. Выявляет угрозы заранее, готовит планы реагирования — не ждёт, пока проблема станет кризисом.
- Коммуникация со стейкхолдерами. Переводит технический прогресс на язык бизнеса, управляет ожиданиями заказчика и спонсора.
- Контроль бюджета и сроков. Следит за отклонениями, при необходимости пересогласовывает scope или ресурсы.
- Документирование. Ведёт протоколы решений, реестр рисков, статус-отчёты — чтобы у всех участников был единый источник правды.
Ключевое отличие PM от исполнителя: он не делает работу сам, а создаёт условия, в которых команда делает её хорошо и предсказуемо.
Чем проджект-менеджер отличается от продакт-менеджера, тимлида и руководителя
Это главная точка путаницы для новичков. Разграничение простое:
| Роль | Отвечает за | Горизонт |
|---|---|---|
| Project Manager | Как и когда доставить результат | Проект (начало–конец) |
| Product Manager | Что строить и зачем — ценность для пользователя | Продукт (непрерывно) |
| Тимлид | Техническое качество и рост людей в команде | Команда и код |
| Руководитель отдела | Ресурсы, найм, развитие сотрудников | Функция / подразделение |
На практике в небольших компаниях эти роли часто совмещены в одном человеке. Но понимать разницу важно: если PM начинает диктовать технические решения — он залезает в зону тимлида; если принимает решения о фичах без данных о пользователях — он подменяет продакта.
Ключевые навыки и компетенции PM
Навыки PM делятся на три группы:
Управление процессом
- Планирование: WBS, диаграммы Ганта, дорожные карты.
- Контроль бюджета и scope.
- Работа с методологиями: Waterfall, Scrum, Kanban, гибридные подходы.
- Управление рисками и изменениями.
Коммуникация и стейкхолдер-менеджмент
- Умение говорить с разработчиком и с финансовым директором на их языке.
- Управление ожиданиями: вовремя сообщать о проблемах, а не скрывать их.
- Фасилитация встреч и принятия решений.
Работа с неопределённостью
- Умение действовать при неполных данных.
- Приоритизация в условиях конкурирующих требований.
- Эмоциональный интеллект: держать команду в рабочем состоянии под давлением дедлайнов.
Soft skills весят не меньше hard skills: PM с отличным планированием, но слабой коммуникацией, будет регулярно получать сюрпризы от стейкхолдеров.
Как стать проджект-менеджером и сколько зарабатывают в 2025
В PM приходят из самых разных специальностей: разработки, аналитики, тестирования, маркетинга, операционного управления. Технический бэкграунд полезен в IT-проектах, но не обязателен — важнее системное мышление и навык коммуникации.

По данным Хабр Карьера (обзор зарплат за 2024–2025), медианные зарплаты проджект-менеджеров в IT в России:
- Junior PM: около 90–110 тыс. ₽
- Middle PM: около 150–180 тыс. ₽
- Senior PM: около 230–300 тыс. ₽
Разброс внутри каждого грейда объясняется отраслью, регионом и уровнем ответственности: IT-компании в Москве платят заметно больше, чем производственные предприятия в регионах. Актуальные данные можно проверить на hh.ru/salary и Хабр Карьера.
Основные сертификации:
- PMP (Project Management Professional, PMI) — международный стандарт, требует подтверждённого опыта и сдачи экзамена; котируется в крупных компаниях и международных проектах.
- PRINCE2 — популярен в госсекторе и европейских компаниях.
- PSM / PSPO (Scrum.org) — практичны для Agile-команд, сдаются онлайн.
На российском рынке PMP повышает доверие работодателя, но не является обязательным условием найма — реальный опыт управления проектами ценится выше сертификата без практики.
Эволюция роли: от контролёра сроков к менеджеру ценности
Ещё десять лет назад PM воспринимался прежде всего как «надзиратель за дедлайнами»: его задача — проследить, чтобы задачи были закрыты вовремя и в рамках бюджета. Сегодня ожидания изменились.
Согласно отчёту PMI Pulse of the Profession, проекты становятся сложнее год от года, а от PM всё чаще ожидают не только контроля задач, но и управления бизнес-ценностью. Современный PM работает с метриками результата, участвует в приоритизации портфеля инициатив и отвечает не только за «сделано вовремя», но и за «принесло ли это нужный эффект».
Эта трансформация описывается как переход к роли менеджера потока ценности (Value Stream Manager): PM всё больше работает с Agile-подходами, метриками и стратегическим контекстом проекта, а не только с планом и бюджетом.
На практике это означает, что PM, который умеет связывать результаты проекта с бизнес-целями и говорить с руководством на языке метрик, становится значительно более ценным, чем тот, кто просто закрывает задачи в трекере.
- Проект длится дольше нескольких недель и в нём участвуют три и более человека из разных функций.
- Есть внешний заказчик или стейкхолдер, которому нужно регулярно отчитываться о прогрессе.
- Бюджет и сроки зафиксированы — и за их соблюдение кто-то должен отвечать явно.
- Задачи между участниками зависят друг от друга и требуют координации, а не просто параллельного выполнения.
- Команда работает в условиях меняющихся требований или высокой неопределённости.
- Команда из 1–2 человек с коротким и понятным заданием — накладные расходы на PM-процессы превысят пользу.
- Работа носит операционный, повторяющийся характер без начала и конца — это не проект, а процесс.
- Все участники находятся в одной функции и сами синхронизируются без посредника.
- Организация работает по продуктовой модели с непрерывными итерациями — там роль PM частично берёт на себя Product Manager или Scrum-мастер.
- Ресурсов на выделенного PM нет, а задачи можно покрыть простым чеклистом и еженедельной встречей.
Кейс 1. Запуск нового IT-сервиса в финтех-компании. Команда из восьми человек (разработчики, дизайнер, аналитик, маркетолог) должна была выпустить мобильное приложение за четыре месяца. PM провёл кик-офф, разбил проект на спринты, выстроил реестр рисков и назначил еженедельные статус-встречи со спонсором. На третьей неделе выяснилось, что интеграция с банковским API займёт вдвое больше времени, чем планировалось. PM зафиксировал риск, пересогласовал scope с заказчиком и перераспределил ресурсы. Приложение вышло на две недели позже изначального плана, но в рамках бюджета и без скрытых компромиссов по качеству — заказчик был предупреждён заранее, а не поставлен перед фактом в день релиза.
Кейс 2. Редизайн корпоративного сайта в агентстве. Проект с фиксированным бюджетом и жёстким дедлайном: клиент хотел новый сайт к отраслевой конференции. PM вёл реестр правок от клиента, контролировал, чтобы каждое новое пожелание проходило через процедуру оценки влияния на сроки и стоимость. Когда клиент попросил добавить раздел с видеогалереей за три дня до сдачи, PM показал, как это сдвигает дедлайн, и предложил альтернативу — добавить раздел в следующей итерации после конференции. Сайт был сдан вовремя, отношения с клиентом сохранились.
Кейс 3. Внедрение CRM в производственной компании. Проект затрагивал отделы продаж, IT и логистики. Без PM каждый отдел тянул в свою сторону: продажи хотели быстрый запуск, IT — полное тестирование, логистика — интеграцию со складской системой. PM организовал матрицу стейкхолдеров, провёл серию рабочих сессий для согласования приоритетов и зафиксировал единый план с чёткими ответственными. Проект был завершён за пять месяцев вместо изначально обсуждавшихся восьми — за счёт того, что конфликты интересов были сняты в начале, а не тормозили работу на каждом этапе.
Совет от Shtab. Одна из ключевых PM-задач — держать реестр рисков живым, а не превращать его в документ, который заполнили на старте и забыли. Создайте в Shtab отдельный список задач с тегом «Риск», добавьте поля «Вероятность», «Влияние» и «Владелец». Каждый выявленный риск — отдельная карточка с ответственным и датой следующей проверки. Так на еженедельном статус-звонке вы открываете не таблицу в Excel, а живой список с актуальными статусами — и стейкхолдер видит, что риски под контролем, а не просто задекларированы.