doc/PM_BA/notes2articles.md

### notes to articles
#### 1 Delivery Manager vs Project Manager 
РП vs ГИП, комментарий к [Delivery Manager и Project Manager в реальных кейсах](https://habr.com/ru/companies/otus/articles/941002/)  
Есть суперРП – это ГИП \ Главный конструктор \ Настоящий руководитель проекта.  
Супер Пример (как показательный): Королев (ракеты).  Это реальный Главный конструктор (ГК) \ Главный инженер проекта (ГИП) плюс организатор / «пушер проекта» (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 \ будущий владелец продукта - это скорее качество.