БИЗНЕС И ЦИФРОВИЗАЦИЯ

Project Manager в IT: одна вакансия, пять разных ролей

Одна должность Project Manager в IT может скрывать Delivery, тимлида или гибрид product/project: почему кандидатам надо читать вакансию глубже.

✍️ Редакция iTech News | 25.09.2026 | ⏱ 4 мин | Источник: Habr / Карьера
💼

Project Manager в IT всё чаще оказывается не профессией, а лотерейным билетом: под одним названием компании могут искать руководителя проекта, Delivery Manager, тимлида или гибрид сразу нескольких ролей. В материале Habr / Карьера автор разбирает это на собственном опыте: 3,5 года его должность называлась «менеджер проектов», хотя фактическая работа была ближе к delivery.

Проблема не в том, что HR «не умеют называть вакансии». Неприятнее другое: кандидат и работодатель могут долго обсуждать «Project Manager» и быть уверенными, что говорят об одном и том же. А потом на интервью выясняется, что один пришёл управлять потоком поставки, второй ждёт человека для найма, performance review, планов, подрядчиков, сроков, бюджета и ещё чуть-чуть продукта сверху.

Автор описывает ситуацию, знакомую многим менеджерам в разработке: пока человек работает внутри одной компании, название должности почти не мешает. Команда понимает, кто за что отвечает, коллеги знают границы роли, а запись в HR-системе живёт своей бюрократической жизнью. Но при выходе на рынок всё ломается. Вакансия Project Manager может означать классическое проектное управление, delivery в продуктовой команде, руководство командой разработки или позицию «соберите нам всё в одном человеке, желательно вчера».

Классический Project Manager — это человек вокруг проекта с началом, целью, ограничениями, заинтересованными сторонами и финальной точкой. У него есть план, риски, зависимости, изменения scope, иногда бюджет, подрядчики и отчётность перед заказчиком. Его главный вопрос: как довести проект до согласованного результата в заданных условиях. Такая роль существует не только в IT: проекты есть в строительстве, производстве, внедрении корпоративных систем, организационных изменениях. Jira тут не первопричина, а просто один из инструментов.

Delivery Manager работает с другой реальностью. В продуктовой разработке команда не закрывается после релиза: задачи продолжают идти потоком, приоритеты меняются, появляются технический долг, зависимости и узкие места. Поэтому фокус смещается с «закрыть проект» на «сделать поставку ценности быстрее и предсказуемее». В статье приводится конкретный пример: в одной из команд Lead Time по крупным функциональностям доходил до 519 и 666 дней, а после изменений в декомпозиции, WIP и взаимодействии внутри команды сократился примерно до диапазона 90–120 дней. Это уже не про красивый статус-репорт, а про механику работы системы.

Третий вариант — когда под названием Project Manager в IT ищут фактически руководителя команды. В описаниях таких вакансий появляются найм, развитие сотрудников, one-to-one, performance review, распределение ответственности, кадровые решения и иногда требование глубокой технической экспертизы. Такой менеджер может всё ещё отвечать за сроки и коммуникацию со стейкхолдерами, но значительная часть его работы лежит в people management. Для кандидата это принципиально: Delivery Manager может вообще не иметь прямых подчинённых, а здесь управление людьми становится центральной частью роли.

Есть и гибриды. Компании могут хотеть Product/Project-менеджера, который одновременно управляет сроками, общается с бизнесом, формирует roadmap, уточняет требования, приоритизирует бэклог и следит за поставкой. Иногда это осознанная организационная модель, особенно в небольших командах. Иногда — следствие того, что обязанности исторически сложились «как получилось». На бумаге вакансия выглядит знакомо, но внутри оказывается набор из нескольких профессий, склеенных общим словом manager.

Для кандидатов практический вывод простой: название вакансии надо читать последним, а не первым. Важнее смотреть на объект управления. Это проект с датой завершения, продуктовая команда с постоянным потоком задач, люди и их развитие, продуктовые решения или всё сразу? Полезно искать в описании маркеры: budget, scope, подрядчики и deadline тянут к классическому проектному управлению; Lead Time, Cycle Time, WIP и throughput — к delivery; найм, performance review и one-to-one — к руководству командой; roadmap, гипотезы и приоритизация — к product management.

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

Поделиться: Telegram X LinkedIn