Как должна называться эта должность PM?

• Менеджер ИТ-проектов
• Менеджер Agile-проектов
• Менеджер программных проектов
• Менеджер по доставке программного обеспечения
• Менеджер ИТ-программы (если все проекты соответствуют одному и тому же видению)

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

Вы всегда можете провести A/B-тестирование названий вакансий и посмотреть, какие резюме приходят от разных рекрутеров.

Дайте рекрутинговой компании A описание работы под заголовком «Менеджер ИТ-проектов», а рекрутинговой компании B — описание работы под заголовком Agile Delivery Manager. Затем сравните и сопоставьте уровень возврата и качество резюме.

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

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

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

Обязанности: Управление веб-проектами, базами данных и облачными проектами нескольких бизнес-систем.

• Управлять ими как? Управлять расписанием, ресурсами и бюджетом, что больше похоже на роль менеджера проекта, или повседневную работу разработчиков, которая больше похожа на роль технического руководителя? Я предлагаю перечислить конкретные обязанности, охватываемые термином «управлять».

Квалификация: Предыдущее программное обеспечение или опыт веб-управления проектами

• Это самое четкое требование, если вы ищете кого-то, кто применил бы те же навыки с той же ответственностью, что и на предыдущей должности. Если это правда, то я считаю, что вы ищете менеджера проекта.

Квалификация: Предыдущий опыт Agile-разработки

• Это опыт работы в качестве разработчика, PM или какой-то другой роли? Это имеет значение? Если это не имеет значения, то квалификация важна, но не говорит нам, как определить новую роль.

Квалификация: предыдущий опыт работы с SDLC

• Как и выше с Agile Development Experience.

Ответственность: кросс-функциональная коммуникация (технические команды/команды разработчиков и операции)

• Это важный аспект роли, но он может применяться к бизнес-аналитику, техническому руководителю, менеджеру проекта и т. д. Каков объем взаимодействия этого человека? Ретрансляция требований, предоставление отчетов о состоянии, согласование функций, включенных в конкретный выпуск? Ответы на эти вопросы определяют роль и соответствующее название должности.

Квалификация: Опыт работы с техническим ПО.

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

Это всегда сложный вопрос, поскольку он нервно перекрывается:

• Руководитель технической (разработки) группы
• Руководитель проекта
• Менеджер по разработке программного обеспечения

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

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

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

Я отношу себя к техническим менеджерам проектов и регулярно отказываюсь от контрактов на управление проектами (или не рассматриваю их), которые не связаны с программным обеспечением. Еще одна специализация, которую я регулярно вижу, — это «Менеджер инфраструктурных проектов», где поставки оборудования и инфраструктуры составляют значительную часть проекта.

TL;DR

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

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

Роль «Требования» не является обязанностью

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

В вашем перечне требований вы на самом деле перечислили только две фактические обязанности:

1. Управление веб-проектами, базами данных и облачными проектами нескольких бизнес-систем.
2. Межфункциональная коммуникация (технические группы/команды разработчиков и операции)

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

Проконсультируйтесь с вашим руководством и вашим отделом кадров

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

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

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

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

Некоторые организации используют «agile», не разбираясь в концепциях или методах. Если ваша организация внедрила Agile или scrum, обязательно укажите это недвусмысленно, желательно в названии должности. Если нет, не используйте модное слово, надеясь, что найм agile-команды чудесным образом преобразит вашу организацию. Agile PM и scrum masters очень осторожны и будут раздражены, если вы убедительно не заявите о стремлении вашей организации к изменениям. Некоторые с готовностью справятся с вызовом, но рассчитывают получить компенсацию за дополнительную боль; они будут вносить трансформационные изменения в вашу организационную культуру, которые выходят далеко за рамки магазина программного обеспечения. Если вы не agile/scrum, попросите опытных agile-менеджеров/scrum-мастеров просмотреть резюме и пройти собеседование. Ищите подражателей, которые видят в этом путь к Agile/Scrum.

Требование «Межфункциональное общение (технические команды/команды разработчиков и операции)» может подразумевать для некоторых, что вы, возможно, ищете опыт «devops». Подобно Agile и Scrum, devops — модное словечко, которое следует использовать с осторожностью при наборе персонала. DevOps также является трансформационным изменением в вашей организационной культуре, которое часто является логическим результатом успешной организации гибкой разработки. Будьте готовы ответить на вопросы о том, должен ли этот PM внедрять решения devops.