Иван Карякин

Полностью согласен. Любой исполнитель несёт ответственность за выполнение своей задачи. Но за результат по этапу, спринту, проекта в целом все же РП.

Мотивация и развития - 100%.

Все мы немного agile - )))

У бизнес-аналитика роль такая, которая предполагает общение с заказчиком. Повторюсь, здравый смысл не надо откидывать. И понимать все слова буквально и тоннельно не стоит.

Есть частные случаи. Вы привели момент, когда в проекте проблема. Для выяснения причины проблемы и разбора полетов - согласен, стоит собрать всю команду и пообщаться с ней.

Я хотел донести суть того что основную коммуникацию должен проводить руководитель проекта. Если заказчик будет активно коммуницировать с исполнителями, то может быть коллизия в задачах от РП и Заказчика. Плюс РП может быть и не проинформирован о каких-то дополнительных требованиях в такой ситуации, что может пагубно сказаться на сдаче проекта.

Опять же и на это можно сказать, что есть разные подходы к управлению проекта и какие-то из них предполагают непосредственное общение Заказчика со всей командой на постоянной основе. Такое тоже допустимо.

Я в своей статье рассказал те ошибки, которые я встречал при взаимодействии с руководителями проектов. Все ситуации конечно я не могу рассмотреть. Рассмотрел обобщённые моменты.

В любом случае есть исключения и каждый момент в управлении индивидуален и нет четкого правила как действовать в той или иной ситуации. Есть рекомендации. Я высказал свои. Никто не отменял здравый смысл и реакцию на ту или иную ситуацию проекта.

Максим, большое спасибо за вашу реакцию и комментарии. )

Максим.
1 - Есть реалии жизни. И многие менеджеры проектов допускают часто те ошибки, которые я описал. Думаю все с этим сталкивались. PMBOK - конечно прекрасный свод правил, но есть ещё куча реальных ситуаций, которых там нет.
2 - Человек-передаст - согласен, это аккаунт-менеджер или администратор проекта, но все-таки это не Руководитель проекта.

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

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

Есть два понятия: делегирование и постановка задачи.

При постановке задачи РП исполнителю не передается ответственность.
А вот при делегировании задачи одного РП другому - в этом случае уже второй РП берет на себя ответственность. Если не возьмет, то собственно делегирование не удалось.