8.1 KiB
notes to articles
1 Delivery Manager vs Project Manager
РП vs ГИП, комментарий к Delivery Manager и Project Manager в реальных кейсах
Есть суперРП – это ГИП \ Главный конструктор \ Настоящий руководитель проекта.
Супер Пример (как показательный): Королев (ракеты). Это реальный Главный конструктор (ГК) \ Главный инженер проекта (ГИП) плюс организатор / «пушер проекта» (pusher).
Второй пример - это оргРП - Берия (атомный проект), он только организатор / «пушер проекта».
Однако у обоих была полнота власти (ресурсы) и ответственность.
В подавляющем случае современных проектов РП (руководитель проекта) / Менеджер проекта (МП) – это совсем иное. Кроме того, выше были примеры РП со стороны разработчика.
Сейчас популярнее РП со стороны заказчика, которые как правило: не имеют технической экспертизы и не имеют полномочий, только "ответственность", но и та «не очень», т.к. что взять то «с него».
ПМ (РП) – это сейчас очень распространённый персонаж / массовая позиция и с достаточно «посредственными требованиями» («низким стартом»), хоть и с «громким названием».
Полнота власти РП\ПМ компенсируется тем, что в проект (компании заказчика) назначают кого-либо из ТОПов «куратором проекта» («смотрящим») или номинально ему дают в проекте звание «РП», но вводят еще позицию «менеджер проекта» (МП), которая фактически является Секретарь проекта \ Администратор проекта: вести бюрократию проекта, «выразительно» напоминать просрочникам на проваленные сроки и т.п.
Это рассказывал тут:
https://habr.com/ru/articles/715256/comments/#comment_25200666
Возможно это и нормально, когда РП «далек от техники» (не глубоко разбирается в проектных решениях), но наизусть знает PMBoK (или что-то из стопки подобного), но вот полномочия и (главное) ответственность – это ключевое условие.
https://habr.com/ru/articles/715256/comments/#comment_25202202
Хотя мне и не нравится такой подход. Он ведет к типовой ситуации, когда от заказчика низкоквалифицированный (рядовой) специалист пишет требования (бизнес-требования), а высококвалифицированный программист от подрядчика их реализует за большие деньги. Это типовой сценарий, когда не хотят типовые решения («коробки», но хорошие конечно), а хотят по «индивидуальным требованиям». А хотят так – «уникальное \ индивидуальное – как типа «самое лучшее»» почему-то почти всегда (типа «умнее» конкурентов).
Как вариант: когда РП \ ПМ с компетенцией ГИП \ ГК понимает недостатки предлагаемого подрядчиком проектного решения, но не навязывает своего собственного решения.
Но мы дальше углубим проблему. В большинстве случаев РП\ПМ не заинтересованы в результатах проекта. Вот тогда на сцену выходит Менеджер продукта \ Владелец продукта \ Delivery Manager. Для РП\ПМ – проект закрыт, продукт принят заказчиком, умываем руки и переходим к следующему проекту (в расчете на следующий бонусом). То, что проект закрыт, а работать с его результатом проблематично – это уже проблема других.
В советские времена было так: в официальный срок торжественно подписывали приемные акты (принято, но с замечаниями), отмечали событие, получали премии. Через пару дней тоже самое «изделие» снова закатывали обратно в цех на длительную доработку по замечаниям комиссии.
Соответственно на стадии проекта нужен «будущий» Владелец продукта (лучше в подразделении заказчика, но с техническими компетенциями), который бы по окончании проекта остался бы «на этом продукте». Обычно компетенций заказчика (будущего эксплуатанта системы) недостаточно для экспертизы разрабатываемого решения и его пост-проектной стадии. Delivery Manager \ будущий Владелец продукта – хоть какая-то гарантия.
В оборонке есть «Представитель заказчика» - не совсем точная аналогия с Владельцем продукта, но что-то общее есть. С него тоже потом спросят по окончании проекта почему результат «не тот», впрочем, как и за ведение самого проекта с него тоже спросят (это только у менеджера проекта «концы вводу» по окончании проекта).
Говорить, что разработчик продукта (подрядчик в проекте) всегда заинтересован в качестве продукта – я не буду. Работая в компании разработчика (системный интегратор) у нас было правило: как только договор на разработку подписан (договор проекта), то сразу лучшие силы бросались на следующий pre-sale, т.к. «эти деньги уже в кармане» (договор подписан и заказчику сложно «соскочить с крючка», а ему «и так пойдет»), а вот получить следующий заказ – это «нужно постараться» (конкуренция высокая).
Вообще, у Проектного менеджера как со стороны заказчика, так и подрядчика - главное это сроки проекта (лучше побустрее закрыть, получить бонус и бежать на следующий проект), а вот у Delivery Manager \ будущий владелец продукта - это скорее качество.