5 ошибок руководителей проектов
Сразу скажу: я не претендую на объективность. Это мой топ-5 ошибок руководителей проектов, в результате которых хочется совершить греховные деяния по отношению к этим самым руководителям.
Сразу скажу: я не претендую на объективность. Это мой топ-5 ошибок руководителей проектов, в результате которых хочется совершить греховные деяния по отношению к этим самым руководителям.
Видимо наболело) Только вот с этим не согласен "ответственность нельзя передать, её можно только взять." Если задача правильно делегирована, но с ней передается и ответственность за задачу.
Есть два понятия: делегирование и постановка задачи.
При постановке задачи РП исполнителю не передается ответственность.
А вот при делегировании задачи одного РП другому - в этом случае уже второй РП берет на себя ответственность. Если не возьмет, то собственно делегирование не удалось.
Джим Кемп (кн. Сначала скажите «нет») пишет (выдержка из саммари):
"Беседой всегда управляет тот, кто слушает. Если вы хотите максимально контролировать ситуацию, позвольте противнику говорить. Хорошие вопросы начинаются с вопросительного слова, а не с глагола. Это открытые вопросы. Они помогают и противнику, и нам увидеть то, чего мы не увидели и не поняли раньше.»
Ваш тезис «Задавая вопрос, ты должен знать на него ответ» противоречит вышеизложенному. Предположу, что это зависит от специфики вопроса.
Автор, что вы думаете об этом?
Иван, здесь я рассматриваю взаимодействие РП с Заказчиком. Как правило коммуникация сводится к выявлению требований. Заказчик чаще всего не знает что хочет и ему сложно формулировать свои мысли и отвечать на открытые вопросы.
Поэтому для эффективной коммуникации предлагаю схему, когда РП задает вопрос и далее предполагает возможные варианты ответов и предлагает их Заказчику. Заказчик выбирает тот вариант, который к нему ближе. Или генерирует свое решение.
Формулируя варианты решения на возникший вопрос, РП глубже погружается в предметную область, что тоже положительно влияет на ведение проекта.
хрень какая-то для детей. что должен и чего не должен РП написано в основе основ управления проектами - PMBOK. То что вы после долгих размышлений выяснили, что РП должен быть ответственным - это конечно ноу хау.
Человек-передаст на проекте кстати очень даже может быть. Роль называется "администратор проекта".
Максим.
1 - Есть реалии жизни. И многие менеджеры проектов допускают часто те ошибки, которые я описал. Думаю все с этим сталкивались. PMBOK - конечно прекрасный свод правил, но есть ещё куча реальных ситуаций, которых там нет.
2 - Человек-передаст - согласен, это аккаунт-менеджер или администратор проекта, но все-таки это не Руководитель проекта.
Повторюсь, полная пурга. Взять хотя бы "Исполнитель не должен участвовать в коммуникации с заказчиком" - это вы откуда взяли?
Если например проблемы на проекте, участвует несколько подрядчиков, включая вас, плюс it отдел заказчика. Заказчик собирает на разбор полётов, все приходят с программистами и только с вашей стороны один рп будет, как он будет отдуваться?
Есть частные случаи. Вы привели момент, когда в проекте проблема. Для выяснения причины проблемы и разбора полетов - согласен, стоит собрать всю команду и пообщаться с ней.
Я хотел донести суть того что основную коммуникацию должен проводить руководитель проекта. Если заказчик будет активно коммуницировать с исполнителями, то может быть коллизия в задачах от РП и Заказчика. Плюс РП может быть и не проинформирован о каких-то дополнительных требованиях в такой ситуации, что может пагубно сказаться на сдаче проекта.
Опять же и на это можно сказать, что есть разные подходы к управлению проекта и какие-то из них предполагают непосредственное общение Заказчика со всей командой на постоянной основе. Такое тоже допустимо.
Я в своей статье рассказал те ошибки, которые я встречал при взаимодействии с руководителями проектов. Все ситуации конечно я не могу рассмотреть. Рассмотрел обобщённые моменты.
В любом случае есть исключения и каждый момент в управлении индивидуален и нет четкого правила как действовать в той или иной ситуации. Есть рекомендации. Я высказал свои. Никто не отменял здравый смысл и реакцию на ту или иную ситуацию проекта.
Максим, большое спасибо за вашу реакцию и комментарии. )
Исполнитель тоже несёт ответственность за свою работу. Невозможно контролировать все - в команде из 8ми человек голова пойдёт кругом, если погружаться во все нюансы))
Ещё один важный фактор - это постоянная работа с командой над мотивацией и развитием. В этом ещё одна функция РП.
Гибкость...)) все мы должны быть немного agile)))