7 грехов владельца продукта

[@uzverkms]

Автор, для чего вы написали этот текст? Какую проблему пытаетесь решить? Проджект менеджер — это очень плохо?
У вас куча ошибок и противоречий в тексте. К тому же вы придумываете проблему, а потом героически её опровергаете.

в методологии PM BOOK

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

Роль менеджера проекта содержала в себе ряд противоречий и конфликтов интересов

Существует Кодекс профессиональной этики и поведения PMI pmi.ru/about/code.php И там сказано:

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

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

1. Менеджер проекта отвечал и за команду, и за отношения с заказчиком. К сожалению, интересы заказчика противоречат интересам команды.

Почему противоречат-то? Основная проблема — когда заказчик не может остановиться в формулировании своих желаний. И тут надо поступать в зависимости от задачи и контекста — либо принимать расширение задачи при увеличении бюджета и/или сроков, или изначально предлагать гибкие варианты разработки/контрактования. Тогда любой каприз — за счет заказчика. И команда довольна и заказчик.

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

Это важнейшее свойство project manager-а, не позволяющее проекту расползаться и в результате разваливаться. Проджект может не только создавать продукт, он может отвечать и за другие стадии жизненного цикла продукта.

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

3. Менеджер проекта не обязан знать, как продавать и продвигать продукт. От сюда столько провалившихся на рынке, но формально успешных (выполненных в срок и уложившихся бюджет) проектов.

Я понимаю о чём вы. Но PMBoK учит нас, что кроме бюджета, сроков и содержания работ было бы неплохо выяснить критерий успешности проекта для заказчика. Если в качестве критерия успешности внешнего коммерческого проекта обозначить получение прибыли (не менее x % или по какой-то другой метрике), то менеджер проекта будет очень заинтересован в продаже проекта.

[@SqPiglet]

Спасибо за указание на ошибки.

[@Yu_Sh]

На самом деле идея разделить управление продуктом и управление командой — достаточно древняя, не стоит говорить, что до Scrum ничего подобного не было. Ещё в MSF (1994) был «менеджер продукта».