У нас есть один менеджер по технологиям и три менеджера по продуктам. Поскольку наш небольшой стартап вырос с 4 человек до почти 100, я предполагал, что наши новые менеджеры по продуктам также будут «менеджерами проектов». (Технические менеджеры выполняли роль «менеджеров проектов» до того, как у нас появился проектный менеджер.) Это не обязательно происходит. Слишком много дублирования и недостаточно четкой ответственности.
Наша команда выглядит так (количество человек в роли в конце):
Мы практикуем нежесткую agile-подобную методологию, но не являемся идеологами Scrum. Мы выделяем около 3 недель работы, оцениваем ее, помещаем в Jira и назначаем разработчикам. Но PM часто меняет требования в течение рабочего цикла.
Недавно я подумал, что, возможно, гибкость, которую нам это дает, имеет пагубный эффект, поскольку менеджеры по продуктам теперь имеют возможность настраивать требования, иногда на основе бета-тестирования с ранними последователями во время спринта. Это вызывает незначительное указание пальцем. Инженеры чувствуют, что PM продолжает что-то менять. PM чувствует, что разработчики, возможно, медленнее, чем должны быть. Генеральный директор не знает, хорошо ли мы справляемся с повышением ответственности и производительности.
Просить ваших менеджеров по продукту также выполнять роль менеджера проекта, вероятно, не самый мудрый курс. Обычно между этими двумя ролями возникает напряжение. И одному человеку крайне сложно выполнять обе роли одновременно. Как правило, если один человек пытается сделать и то, и другое, одна из двух сторон получит меньше внимания, чем следовало бы. Я говорю это как руководитель проекта, которому часто приходилось надевать шляпу менеджера по продукту (и я свободно признаю, что лучшими проектами, которыми я руководил, были те, в которых роль менеджера по продукту выполнял кто-то другой).
Давайте посмотрим на две роли.
Менеджер по продукту — обычно старается обеспечить поставку «наилучшего» продукта. Убедившись, что это дает хороший опыт клиентов. Сосредоточьтесь не на том, сколько времени это займет или какова будет стоимость. Я не говорю, что они не заботятся об этих вещах, просто они должны отойти на второй план по отношению к качеству и удовлетворенности клиентов, насколько это касается менеджера по продукту.
Менеджер проекта — обычно пытается помочь обеспечить выполнение проекта. И что это делается вовремя и в рамках бюджета с небольшим количеством дефектов. Акцент делается не на том, нравится ли клиентам конечный результат. Опять же, я не говорю, что менеджер проекта не заботится о клиентах, просто это обычно не их цель.
Между этими двумя ролями существует естественная взаимосвязь. Владельцы продукта хотят изменить область действия, основываясь на том, что, по их мнению, даст наилучший опыт конечным пользователям. Владельцы проекта возражают, указывая на влияние на бюджет и график. В хороших отношениях между ними они увидят, можно ли что-то еще сократить, или узнают, сможет ли другое решение удовлетворить обе потребности. Или изменить ситуацию... Менеджер проекта может увидеть, что график находится под угрозой, и обсудить с владельцем продукта, что можно безопасно сократить или упростить, чтобы уложиться в бюджет и график. Хотя один человек может сделать это самостоятельно, поддерживать баланс сложно.
Судя по предоставленной вами информации, наличие 6 владельцев продукта кажется излишним. Я бы предложил посмотреть, есть ли у одного из них способности (и интерес) к управлению проектами, и изменить их роль. Но так или иначе, вам нужен кто-то, кто сосредоточен на этой роли.
Неважно. Чего вам не хватает, так это сильных возможностей PM. Вам нужно законным образом назначить роль PM, дать этой роли необходимую отчетность, обязанности и полномочия, назначить на эту роль человека, который обладает необходимыми знаниями, навыками и способностями для выполнения, а затем нажмите GO.
Управление проектами — это отдельная роль и отдельный карьерный путь. Дело не в том, руководит ли вашим проектом менеджер проекта, скрам-мастер или великий дурак процесса; проблема в том, что вам нужны формальные элементы управления проектами и формальная роль для управления ими , если вы хотите, чтобы ваша организация вышла за рамки «управления проектами по принципу «поймай, как поймаешь».
Суть в том, что, по вашему мнению, ваш текущий процесс не работает. Продолжая следовать одному и тому же неформальному непроцессу, вы не получите улучшенных результатов, поэтому, вероятно, пришло время пересмотреть ваш процесс и структуру управления проектами, чтобы определить, что не работает для вашей организации, а затем сделать что-то другое.
Я не большой поклонник «названий должностей», однако меня больше интересуют навыки и компетентность человека, который выполняет эту роль. Вопрос скорее в том, «Может ли человек выполнять работу как менеджера по продукту, так и менеджера проекта, не будучи перегруженным и не конфликтуя?»
Я знаю людей, которые могут легко переключаться между двумя ролями и не влиять на проект, однако другие сильны в одной роли и слабы в другой, что негативно влияет на продукт.
Титул не означает компетентность, это просто ярлык на визитной карточке. Реальность такова, что если вы сравните какое-либо одно название в нескольких компаниях, вы быстро обнаружите, что все они совершенно разные. Позиция обычно трансформируется в то, что нужно организации.
МСВ
Скливвз
Том Демилль
Скливвз
Том Демилль