Чем отличается менеджер проектов от менеджера проектов? Почему одинаковая вакансия может означать разные профессии

Последние 3,5 года моей основной ролью был Delivery Manager. Формально должность при этом называлась вполне привычно — «Менеджер проектов», и пока я работал внутри одной компании, особой проблемы в этом не видел. Команда понимает, чем ты занимаешься, коллеги знают твою зону ответственности, а название должности постепенно превращается просто в строчку в HR-системе.

Проблема стала гораздо заметнее, когда я вышел на рынок и начал искать следующую работу. Открываешь вакансию Project Manager, а дальше каждый раз начинается небольшое расследование: в одной компании нужен классический руководитель проекта, в другой — руководитель команды разработки, в третьей — Delivery Manager, а в четвёртой хотят одновременно получить Project, Delivery, Product и People Manager.

Название одно, а содержание работы может отличаться очень сильно. И после нескольких месяцев просмотра вакансий у меня появился вопрос, который в итоге и стал названием этой статьи:

Чем вообще отличается менеджер проектов от менеджера проектов?

Вообще-то Project Manager существует не только в IT

Когда мы обсуждаем Project Manager на Хабре, очень легко автоматически поместить эту профессию внутрь разработки. Но управление проектами появилось не вместе с Jira, Scrum и продуктовыми командами, а сам руководитель проекта совершенно не обязан работать в IT.

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

В этом смысле классический руководитель проекта достаточно хорошо переносится между индустриями на уровне базовой модели работы. Конкретные инструменты, технологии и предметная область будут отличаться, но вопрос остаётся примерно тем же: как довести проект от точки старта до согласованного результата в существующих ограничениях.

А вот когда Project Manager попадает внутрь современной продуктовой разработки, всё становится заметно интереснее. Там рядом уже существуют Product Manager, Delivery Manager, Team Lead, Engineering Manager, Scrum Master, Agile Coach и другие роли, а компании начинают по-разному распределять ответственность между ними.

И именно здесь одинаковое название должности начинает означать совершенно разную работу.

Когда название должности почти ничего не говорит

До поиска работы я, конечно, понимал, что Project Manager в разных компаниях может заниматься разными вещами. Но одно дело — знать об этом теоретически, и совсем другое — открыть несколько десятков вакансий подряд и увидеть, насколько сильно отличаются ожидания от кандидата при практически одинаковом заголовке.

В моём случае контраст был особенно заметен, потому что я искал работу, близкую к Delivery Management. Мне интересны процессы поставки, взаимодействие внутри продуктовой команды, поиск узких мест, работа с Lead Time, Cycle Time, WIP, предсказуемостью и улучшением самой системы разработки.

Но значительная часть вакансий Project Manager была вообще не про это. Где-то искали классического проектного менеджера, где-то фактически руководителя разработки, а где-то под одним названием был собран набор обязанностей сразу из нескольких профессий.

В результате поиск постепенно превратился не столько в фильтрацию вакансий по названию, сколько в попытку каждый раз ответить на другой вопрос:

А кого вы на самом деле ищете?

В одной компании «менеджеры проектов» тоже могут делать разную работу

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

В нашем направлении основное внимание было связано с процессом поставки и работой продуктовой команды. Мы занимались потоком задач, ограничениями системы, зависимостями, взаимодействием между ролями и тем, насколько предсказуемо команда способна поставлять результат.

В проектном офисе могли идти, например, внутренние интеграционные проекты, в том числе связанные с корпоративными системами вроде 1С. У такого проекта есть конкретная задача, план, участники, ограничения и состояние, в котором можно сказать: внедрили, приняли, закрыли.

Продуктовая команда в этот момент никуда не закрывается. После релиза появляется следующая функциональность, меняются бизнес-приоритеты, возникает технический долг, появляются новые ограничения и узкие места.

Формально и там, и там могут работать люди с должностью «Менеджер проектов». Но один в первую очередь управляет конкретным проектом, а другой — системой, через которую непрерывно проходит работа.

Project Manager №1: классический руководитель проекта

Это самое привычное понимание роли. Есть конкретный проект, у него есть цель, начало, предполагаемое завершение, заинтересованные стороны, сроки, риски, зависимости и обычно набор ограниченных ресурсов.

Такой менеджер работает с планом проекта, управляет изменениями, синхронизирует участников, отслеживает риски и помогает довести всё до согласованного результата. В зависимости от компании сюда же могут входить бюджетирование, работа с подрядчиками, отчётность перед заказчиком и управление scope.

Его основной вопрос можно сильно упростить до одного:

«Как довести этот проект до результата в заданных ограничениях?»

Это совершенно нормальный Project Manager. Просто далеко не каждый человек с таким названием должности занимается именно этим.

Project Manager №2: Delivery Manager

Это уже гораздо ближе к тому, чем последние годы занимался я. Здесь обычно нет одного проекта, после которого команда завершает работу, а есть продуктовая команда и постоянный поток изменений.

Из-за этого меняется и объект управления. Менеджеру важно не только понимать, успеет ли конкретная задача к конкретной дате, но и видеть, как вообще работа проходит через систему: где возникают очереди, сколько времени задача проводит в ожидании, насколько велик Work in Progress, где появляются постоянные блокировки и насколько предсказуемо команда поставляет результат.

В моём случае именно здесь появлялись Lead Time, Cycle Time, throughput, WIP и работа с самим процессом поставки. Например, в одной из команд мы проходили путь от крупных функциональностей с Lead Time 519 и 666 дней до диапазона примерно 90–120 дней, постепенно меняя декомпозицию, работу с WIP и взаимодействие внутри команды.

Основной вопрос такого менеджера уже другой:

«Как сделать поставку ценности более быстрой, устойчивой и предсказуемой?»

Это тоже управление, и довольно часто такого человека продолжают называть Project Manager.

Project Manager №3: руководитель команды

Следующий вариант, с которым я регулярно сталкивался во время поиска, — Project Manager, который по содержанию вакансии был гораздо ближе к Team Manager, People Manager или руководителю разработки.

В описании появлялись найм, развитие сотрудников, one-to-one, performance review, формирование команды, распределение ответственности между людьми и решение кадровых вопросов. Иногда к этому же добавлялась необходимость глубокой технической экспертизы.

Такой человек при этом вполне может продолжать отвечать за сроки, поставку и взаимодействие со стейкхолдерами. Но существенная часть его работы связана уже не с проектом и не с потоком задач, а непосредственно с управлением людьми и развитием команды.

У Delivery Manager прямые подчинённые при этом могут вообще отсутствовать. Поэтому два человека могут открыть вакансии с одинаковым названием Project Manager, узнать в них знакомую профессию, а на первом же содержательном интервью обнаружить, что речь шла о совершенно разных ролях.

Project Manager №4: Product + Project

Ещё один распространённый вариант — роль на границе Project и Product Management. В таком случае человек не только организует выполнение работы, но и участвует в формировании самого продукта: работает с приоритетами, требованиями, пользовательскими проблемами и тем, что вообще нужно делать.

Само по себе такое совмещение не выглядит чем-то странным. Особенно в небольшой компании один менеджер вполне может закрывать сразу несколько зон ответственности, и это может быть осознанной организационной моделью.

Проблема снова появляется не в совмещении, а в ожиданиях. Если кандидат читает «Project Manager» и предполагает работу со сроками, рисками и координацией, а компания ждёт от него ещё и самостоятельного определения продуктовой стратегии, выяснить это желательно раньше третьего этапа собеседования.

Project Manager №5: соберём всё, что осталось

И есть вакансии, которые я для себя начал относить к отдельному жанру. Название обычно выглядит вполне безобидно: «Project Manager» или «Senior Project Manager», но дальше начинается список обязанностей.

Нужно управлять сроками и бюджетом, выстраивать процессы разработки, развивать команду, работать с метриками, проводить Agile-мероприятия, общаться с заказчиком, участвовать в продуктовой проработке, помогать аналитикам и тестированию. Иногда к этому добавляется техническая экспертиза, а в особенно интересных вариантах — ещё и возможность самостоятельно залезть в код или провести Code Review.

Отдельно мне встречались роли, в которых смешивались Delivery Management, Scrum Master, Process Manager и задачи PMO — Project Management Office, то есть проектного офиса. В итоге компания фактически ищет человека, отвечающего одновременно за поставку, процессы команды и часть организационной системы управления проектами.

Я не считаю такие роли автоматически неправильными. В определённом бизнес-контексте совмещение может быть вполне оправданным, а у меня самого за карьеру регулярно пересекались зоны ответственности нескольких менеджерских ролей.

Но название Project Manager в такой ситуации почти перестаёт что-либо объяснять.

Реальные вакансии только усилили это ощущение

Во время поиска мне регулярно попадались вакансии, где само название уже пыталось честнее показать гибридность роли. Например, вместо обычного Project Manager компания могла прямо написать Senior Project/Delivery Manager или Product/Project Manager.

Такие названия выглядят немного громоздко, но для кандидата они даже полезнее. Уже по заголовку понятно, что внутри роли есть несколько зон ответственности и стоит внимательно разобраться, где между ними проходит граница.

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

Именно поэтому со временем я практически перестал воспринимать название вакансии как точное описание профессии. Для меня это скорее указатель на дверь, после которого всё равно нужно посмотреть, что находится внутри.

До нескольких этапов собеседования — и всё ещё можно говорить о разных профессиях

Самая неприятная часть такой неопределённости в том, что описание вакансии не всегда позволяет разобраться сразу. У меня был процесс, в котором мы дошли примерно до четвёртого этапа общения, и только по мере интервью становилось всё очевиднее: компании нужен человек гораздо ближе к классическому Project Manager, чем к той Delivery-роли, которую искал я.

Я не считаю, что кто-то в такой ситуации пытался кого-то обмануть. Скорее мы просто начали разговор с одинакового словосочетания Project Manager, но вкладывали в него разные наборы ответственности.

В результате время уже потратил кандидат, несколько человек со стороны работодателя провели интервью, а совпадения по самой роли практически не оказалось. Для меня это и есть главная практическая проблема всей истории с названиями должностей: не спор о том, кто из менеджеров «настоящий», а вполне конкретная стоимость неправильного взаимопонимания.

Если положить роли рядом

Границы между ролями всё равно будут зависеть от компании, но для себя я стал разделять их примерно так:

Это намеренно упрощённая картина. В конкретной компании один человек вполне может занимать сразу несколько строк этой таблицы, а часть ответственности может быть распределена совсем иначе.

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

Почему нельзя просто договориться о названиях?

После всего этого довольно естественно предложить простое решение: давайте правильно назовём каждую профессию и перестанем путаться. Мне кажется, на практике это почти невозможно.

У компаний разный масштаб, устройство команд, история и бизнес-контекст. Где-то нет смысла выделять отдельного Delivery Manager, потому что эту функцию выполняет Project Manager; где-то Engineering Manager одновременно занимается people management и delivery; где-то Product Manager действительно отвечает ещё и за значительную часть проектной работы.

Вне IT картина тоже будет другой, потому что там может вообще не существовать большей части привычного нам набора продуктовых и Agile-ролей. При этом классический руководитель проекта никуда не исчезает и вполне нормально продолжает выполнять свою работу.

Поэтому универсального справочника, в котором написано, как правильно называть каждую роль, я бы не ждал. Гораздо полезнее научиться быстрее понимать, что конкретная компания вложила в конкретное название.

На что я теперь смотрю в вакансии раньше названия

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

Отдельно я смотрю, о каких инструментах и метриках говорит вакансия. Milestones, бюджет, риски и проектный план обычно ведут в одну сторону; Lead Time, throughput, WIP и улучшение потока — в другую; найм, one-to-one и performance review добавляют третью плоскость.

Ещё полезнее понять, какие роли уже существуют рядом. Если в команде есть отдельные Product Manager, Engineering Manager, Scrum Master и аналитики, зона Project Manager будет одной; если этих ролей нет, очень вероятно, что часть их ответственности окажется внутри той же вакансии.

Именно после такого разбора иногда оказывается, что вакансия Project Manager очень хорошо подходит человеку с Delivery-опытом. А в другом случае роль с названием Delivery Manager по содержанию оказывается довольно классическим проектным управлением.

Само название помогает найти вакансию в поиске, но окончательный ответ находится всё-таки внутри.

Меня беспокоят не разные названия

После поиска работы я стал спокойнее относиться к тому, что компании по-разному называют роли. На мой взгляд, это неизбежно: бизнесу необязательно строить организацию строго по учебнику, а набор необходимых функций всё равно будет зависеть от конкретной ситуации.

Меня беспокоит другое: каждый по-разному понимает одно и то же название, вследствие чего возникают трудности и у кандидата, и у работодателя. Компания может получать десятки резюме людей, которые формально подходят по названию должности, но вообще не совпадают с реальной ролью; кандидат может проходить несколько этапов и только потом понять, что искал совершенно другую работу.

Мой собственный опыт хорошо это показывает. Несколько лет я формально был менеджером проектов, но значительная часть моей реальной работы была Delivery Management, а рядом могли существовать другие менеджеры проектов с совсем другой зоной ответственности.

И нельзя сказать, что кто-то из нас был «неправильным» менеджером проектов. Мы просто выполняли разные роли под одним названием.

Проблема начинается не тогда, когда компании по-разному называют должности. Проблема начинается тогда, когда кандидат и компания думают, что одинаково понимают название, хотя на самом деле говорят о разной работе.

Вместо вывода

Поиск работы неожиданно напомнил мне довольно простую вещь: профессию очень легко попытаться определить через название должности, хотя само название — всего лишь ярлык. За Project Manager может скрываться классический руководитель проекта, Delivery Manager, руководитель команды, гибрид Product + Project или человек, которому отдали значительную часть обязанностей сразу нескольких ролей.

Поэтому сейчас фраза «я Project Manager» для меня звучит примерно как «я разработчик». Она задаёт общее направление, но почти ничего не говорит о том, чем именно человек занимается каждый день.

И когда я вижу очередную вакансию Project Manager, мой главный вопрос уже не «подхожу ли я на Project Manager?». Мне гораздо важнее понять другое:

Что именно в этой компании делает человек, которого вы называете Project Manager?

После ответа на этот вопрос уже можно нормально обсуждать совпадение опыта, навыков и ожиданий.