7.6 KiB
notes to articles
1 Delivery Manager vs Project Manager
РП vs ГИП, комментарий к Delivery Manager и Project Manager в реальных кейсах
Есть суперРП – это ГИП \ Главный конструктор \ Настоящий руководитель проекта.
Супер Пример: Королев (ракеты). Первый пример – это реальный Главный конструктор (ГК) \ Главный инженер проекта (ГИП) плюс организатор / «пушер проекта».
Второй пример - это оргРП - Берия (атомный проект), он только организатор / «пушер проекта».
Однако у обоих была полнота власти (ресурсы) и ответственность.
В подавляющем случае современных проектов РП (руководитель проекта) / Менеджер проекта (МП) – это совсем иное. Кроме того, это примеры РП со сторону разработчика.
Сейчас популярнее РП со стороны заказчика, которые как правило: не имеют технической экспертизы и не имеют полномочий, только ответственность, но и та «не очень», т.к. что взять то «с него».
ПМ – это сейчас очень распространённый персонаж / позиция и с «посредственными требованиями» («низким стартом»), хоть и «громким названием».
Полнота власти РП\ПМ компенсируется тем, что в проект (компании заказчика) назначают кого-либо из ТОПов «куратором проекта» («смотрящим») или номинально ему дают в проекте звание «РП», но вводят еще позицию «менеджер проекта» (МП), которая фактически является Секретарь проекта \ Администратор проекта: вести бюрократию проекта, «выразительно» напоминать просрочникам на проваленные сроки и т.п.
Это рассказывал тут:
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, т.к. «эти деньги уже в кармане» (договор подписан и заказчику сложно «соскочить с крючка», а ему «и так пойдет»), а вот получить следующий заказ – это «нужно постараться» (конкуренция высокая).