Хе, благодатная тема ... Ну давайте поговорим о рискам, и как ими управлять.
По моему, глупо говорить о том, что Пиэм видет риски один, и именно поэтому он должен глубоко разбираться в в предмете проекта.
Да, такой Пиэм не болванчик, но получается, что команда проекта - болванчики. Которые ничего не понимают, не соображают и как слепые котята тыкаются носом в стенку. При таком подходе проект наверняка завалится, ибо пиэму не уследить за всеми засадами на проекте.
Разве не правильно, собирать команду для обсуждения "куда мы плывем" и совместно принимать решения какие риски светят и как их обойти?

Во-первых: Вы уж больно радикальны в своих рассуждениях, если ПМ умный, команда болванчики, если команда хороша, то ПМ «нифига не понимает».
Во-вторых: Вы сами себе противоречите, если одна из сторон, как я понял вы упираете на ПМа «нифига не понимаешь и нет желание самому принять решение "как надо правильнее"», то как в таком случае «собирать команду для обсуждения "куда мы плывем" и совместно принимать решения какие риски светят и как их обойти?»
На мой взгляд, оптимальный вариант, когда ПМ понимает, что происходит не только на уровне графиков, но в тоже время ему хватает ума не лезть с желанием «порулить» к конкретным специалистам.
По-сути я согласен с Вашей фразой о «собирать команду для обсуждения "куда мы плывем" и совместно принимать решения какие риски светят и как их обойти?», но на мой взгляд для этого у ПМ должны быть знания и предмета и системы.

PS. На какой круг пошло это обсуждение???

Рискую быть забросанным помидорами, но хороший ПМ (если его задача - управлять, а не архитектуру разрабатывать\реализовать) с командой общается не в терминах "что и как нужно сделать", а "какой нужен результат" и "как проект обеспечить необходимым и создать условия для выполнения".

Для этого ПМу нужно не в системе разбираться, а в людях (например, он может убедиться, что исполнитель не гонит фуфло и имеет представление как наверстать упущенное) .
А прогресс конкретных людей в реализации того или иного функционала можно отслеживать по правильно созданным KPI.

Знание ПМом функционала системы не гарантирует, что Заказчик получит правильно автоматизированный процесс с корректными данными. Или ПМ будет за Заказчика будет выполнять предварительную приемку каждой функции/отчета?

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

Возьму на себя смелость и попробую обобщить сей топик.
Читая весь перечень тех или иных высказываний, не могу не согласиться с каждым из них. В любом из приведенных мнений в данной ветке есть здравый смысл, разница, как говориться, "в мелких пузырьках".

Заметно, что комрады постарше более осторожны в своих заключениях, чем младое племя и их высказывания ближе к мнению, что для ПМ наиболее важны организационные навыки, чем предметные знания. Опираясь на свой опыт и опыт моих ближайших коллег, могу сие явление объяснить следующим образом:

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

Потом проходит какое то время, происходят изменения, и ты замечаешь, что когда-то считающаяся прогрессивной технология, через каких то 3-4 года оказывается в корзине. И на смену ее приходит новая. Сначала, ты обявляеешь ее глупостью, потом присматриваешся (с современной индустрией маркетинга сложно спорить), и наконец берешь ее на вооружение, провожая страрую технологию в небытие.

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

ИМХО. Быть действующим РМ-ом и одновременно находиться на гребне волны технологического прогресса не просто затруднительно, но в принципе не реализуемо. Нельзя отправиться из Москвы в Спб, оказатья также и в Сочи.

Со временем начинаешь приходить к пониманию, что есть незыблимые вещи, которые были верны и 100 лет назад, верны и сейчас. Если раньше методика "берем в первую очередь почту, телеграф телефон" сработала на отлично, она сработает и через 50 лет и через 100 и через 200. Если Макиавелли написал своего "Государя" в 15 веке, то его читают и сейчас, а если Novell со своей технологией файл-серверов сдохла, то сдохла.

ИМХО. Предметная область является, как не прискорбно, второстепенным моментом в проекте. Мнение, что знание предметной области руководителем проекта позволит избежать провала или крупных ошибок, - является заблуждением, причем опасным. Если дать толковому архитектору-руководителю безмерный бюджет и неограниченное время и ресурсы, возможно когда то мы получим идеальное внедренное решение. Но мы живем в реальном мире, у нас реальные заказчики, которые имеют свои меркантильные интересы. Саграда де Фамилия в Барселоне строится уже не один век, но я думаю, если бы так строился ваш дом, в который вы вложились на стадии котлована, вы были бы крайне недовольны.
РМ оторванный от предметной области своей ролью в проекте является, как раз таки ограничивающим и одновременно стимулирующим фактором успешного завершения проекта. Это должен быть как раз таки тот человек, который обязан периодически возвращать из мечтательного поднебесья, как заказчика, так и исполнителей. И отсутствие или отрешенность от проблем в предметной области позволит ему это осуществить с меньшими душевными муками и сбольшей организованностью.

Markone, я рыдал над твоим постом от счастья, что кто-то смог облечь в словеса, то, что хочется сказать. Будь у меня "избранное", я бы это туда поместил.

Посему два вопроса:
1. Не собираетесь ли писать серьезную литературу: учебники, худ.лит., мемуары или что-то подобное
2. Где тут ставят респекты?

+1

Видимо, я останусь в меньшинстве со своим мнением, но меня это не убедило. Чем незнание предметной области спасает руководителя проекта от всех описанных напастей? К примеру, в строительстве подводных лодок я не понимаю ничего. Стало быть, мне надо рулить теми, кто строит подводные лодки и атомные реакторы, т.к. как руководитель саповских проектов я несу в себе угрозу срокам и бюджетам, поскольку кое-что смыслю в этом предмете? Но вот парадокс, саповские проекты я внедряю успешно, в рамках сроков и бюджетов. А вот строить подлодки или хотя-бы гаражи не возьмусь.

Хороший посыл!
Но давайте разберемся - "внедряю успешно", потому что сам делаю аналитику и принимаю решения по проекту, или я - успешный РП, знаю УП и поэтому делаю любые проекты успешно? Как получилось, что успешно?

Не понял - в чём конкретно будем разбираться? Если цели проекта достигнуты, сроки и бюджет соблюдены, акты подписаны, заказчик доволен и хочет продолжения, всем розданы пряники - проект можно считать успешным. Об этом вопрос?
ЛЮБЫЕ проекты успешно я не делаю, об этом я сказал. И знания одного лишь УП, пиэмбока и диаграммы Гантта для успеха проекта не достаточно. Во всяком случае, я не видел, чтобы сап внедрил некто со знанием одного лишь пиэмбока.

Предлагаю поиграть в следующую задачу:

Исходные данные по ситуации в живом клиентском проекте

- перед сдачей части результатов Заказчику Вы успели проверить в системе 9 контрольных примеров (для простоты будем их называть отчетами) из 10. Все 9 оказались на Ваш взгляд (как специалиста в SAP) готовыми к сдаче и Вы едете к Заказчику
- Заказчик на Вас наехал, т.к. один (не проверенный Вами) из 10 отчетов содержит явную пургу.
- Исполнитель говорит, что он не может (не умеет) сделать так как хочет заказчик

Теперь Вариант 1 - Вы знаете и можете сделать с этим отчетом то, что хочет Заказчик. Ваши действия?
а) вы делаете отчет сами, т.к. это быстрее всего и позволит уложиться в срок
б) учите исполнителя как нужно сделать
в) требуете у руководства замены, либо усиления состава исполнителей
г) боретесь с заказчиком, впаривая ему то, что получилось


Теперь Вариант 2 - Вы тоже не понимаете чего хочет заказчик и не знаете как это сделать. Ваши действия?
а) открываете гайды и читаете как это реализовать, одновременно запрашиваете экспертов в SAP. В общем, упираете в то, чтобы разобраться и сделать самому.
б) отшиваете Заказчика, т.к. Вы (как специалист) знаете, что реализовать это практически невозможно
в) эскалируете на руководство и требуете более сильного исполнителя (который получится умнее вас и, подозреваю с Вашей точки зрения может лучше управлять проектом)
г) создаете рабочу группу из состава своих исполнителей и представителей заказчика для уточнения постановки задачи и посика возможного технического решения

Мысль Astar ясна: в обоих вариантах пункт в) одинаков. И суть - типа если нет разницы, то зачем платить больше

Только в первом варианте выбрав пункт б) можно получить реальное усиление команды на будущее (думаю с минимальными собственными затратами времени). А выбрав в) - эскалацию конфликта с собственным коллективом, HR компании и другими РП (которые должны ослабить состав своих команд ради Вашей). Плюс не забывайте про "психологическиею травму" конкретного исполнителя, который может и уйти от обид (при этом идеально выполнив 9 из 10 пунктов поставленных задач).

Во втором же варианте легких и простых решений Вы вообще не оставили, ибо:
а) сорвете сроки
б) можно потерять заказачика
в) см. выше по первому варианту
г) единственный "неспорный", но очень итерационный подход, который может привестии к п. а)

все верно. единственное, что хочется добавить - все эти движения, быть на волне технологий, занимающих где-то лет многа:) порядка 10 и рождает его величество опыт и понимание как оно все-таки работает:) и именно на этом гребне - говоришь о вечном...

так что...

Большое спасибо всем комрадам, положительно оценившим мое "излияние". Я действительно глубоко тронут такой оценкой, причем не на каком нибудь Хламурном форуме, где все друг у друга "лапочки" и "прелести", а на достаточно суровом форуме реальных саперов.

To Vladdy
Я не говорю, что наличие опыта и наличие предметных знаний есть офигенная проблема для PM. Опыт это штука такая, что он или есть, или его нет., причем если он есть, - избавиться от него не реально. В кусты не забросишь.
В моем понимании работы РМ-а знание предмета далеко не первостепенная потребность. Возьмем крайний случай, нам нужно выбрать, кто станет руководить проектом внедрения со стороны консалтинга. Есть две кандидатуры, обоим по 30 лет. Одна кандидатура - бывший офицер армии, служивщий в спецподразделении, комисованный из-за ранения в Чечне. В IT ничего не понимает кроме базовых моментов обычного пользователя. Вторая кандидатура - "компьтерный гений", программист ABAP, действительно гениальный программист, уходящий в работу с головой, испытывающий профессиональный зуд при поиске багов и стремлений вылизать код до "окончательно завершенного вида". Любит пиво, чипсы и свой старый свитер.
Условия проекта по срокам жесткие, с возможностью выставлять пени исполнителю в случае срывов срока и поставки некачественных решений. В таких условиях, я однозначно выберу первую кандидатуру.
У обоих персонажей есть свой собственный опыт и свой багаж знаний. Несомненно, у обих компетенции для руководства проектом внедрения не полные, и тому и другому пришлось усиленно "подгребать" в ходе работы. Только у персонажа 1 багаж знаний и опыта больше соотвтетсвует требованию руководителя рискового проекта.

Бывают разные проекты и для каждого нужен свой РМ со своим багажом. Возможно знание предметной области будет необходимо в технически сложном проекте. В проекте с "малахольным" заказчиком более важна способность и умение договариваться. В проекте, где команда - это сброд оболтусов, - важны организационные навыки.
РМ-ы вякие нужны, РМ-ы всякие важны. Замечательно, когда твой опыт и знания полностью совпадает с форматом, поручаемого тебе проекта, - это везение. Но такое бывает не всегда, особенно, если работаешь в консалтинге.

------
ЗЫ, перечитал и задумался... А может и правда книжку написать?....

Опять радикализм во взглядах. Все- таки спор больше идет о том, что лучше, дорасти до ПМ получив знание системы и предмета (консультант, ставший ПМ) или ПМ который знает ПМбук, ASAP и т.д. (выпускник факультета управления, слушатель различных курсов). У обоих может быть опыт управления проектами, первый кандидат мог прочитать и прослушать те же курсы что и второй, вот только у консультанта опыта больше, того самого который в кусты не забросишь, а вот у второго этого нет. А Вы нам примеры офицеров и программеров приводите. Передергиваете уважаемый!
У такого ПМ, как офицер команды не стало при первом же завале, потому что, как решеют проблемы армии наверно догадываются многие, а я точно знаю ***найти, устранить и доложить** и голос чтобы при этом погромче был! А консультанты они люди нежные, да и уйти всегда есть куда. Так что проект и он бы провалил!!

ЗЫ. Книгу не книгу, а аналитические статьи с Вашей подписью я бы не пропускал .

Почему же сразу "передергиваете"? Жизнь настолько разнообразна своими проявлениями, что ничего придумывать не надо. Это реальный случай, за исключением того, что проект был не SAP-овский (но ERP-шный), а программист не ABAP-ер. Да и про офицеров бы лучше не обобщать, разные есть люди, в том числе и по здравости рассуждений огого какую фору могут некоторым "мыслителям от IT" дать.
Проект закончился успешно, правда тот офицер себя в ERP бизнесе не уютно чувствовал, перешел позже в телекомовскую сферу, там проекты ведет. Программист ушел во фриланс, сейчас, если не ошибаюсь, на офшорном программировании сидит.
Вобщем, каждый так или иначе находится на своем месте. А вот если тот программист стал руководить проектом, не поручусь за то, что он был бы успешно завершен. Может даже человек бы смог и сломаться. Давление заказчика на команду в том проекте было безпрецедентное. Команда , кстати, сохранилась только благодоря тому что РМ очень умело это давление стравливал. У нас сним была расхожая фраза "Солдат два раза на амбразуру не падает"