Comments 12
Было бы неплохо добавить — если проект умер, а контракт не завершен, умейте сказать заказчику — проект умер, работы вести бессмысленно, это будет просто трата денег, давайте закроем проект и придумаем, что делать дальше.
Мне всегда казалось, что это Заказчику решать — актуален его проект или нет. Ведь ему виднее — достиг этот проект тех целей на которые он был им рассчитан или нет.
Заказчик не всегда видит, что именно происходит с проектом.
Иногда ответственный менеджер со стороны заказчика, которому поставили задачу довести проект до конца заинтересован только в том, чтобы проект делался, чтобы на встречах были картинки и билды, чтобы были реализованы пункты ТЗ, а не в том, чтобы проект действительно решал поставленные задачи.
Или вы считаете такую ситуацию гипотетической?
Иногда ответственный менеджер со стороны заказчика, которому поставили задачу довести проект до конца заинтересован только в том, чтобы проект делался, чтобы на встречах были картинки и билды, чтобы были реализованы пункты ТЗ, а не в том, чтобы проект действительно решал поставленные задачи.
Или вы считаете такую ситуацию гипотетической?
Перед началом работ по проекту желательно узнать у Заказчика / представителя Заказчика цели проекта. Даже «просто что бы было» или «похвастаться перед коллегами» — это тоже цель. Согласен, бывают такие проекты, где на первую встречу приходит Заказчик, с ним оговариваются условия и цели проекта, а в конце встречи он сообщает, что весь проект будет вести его менеджер. Так вот в таком случае и менеджер Заказчика должен понимать какие цели стоят перед проектом, что бы адекватно работать со стороны Заказчика над проектом.
Заказчику в таком случае не обязательно знать, что происходит с проектом. Он заинтересуется им, только в том случае, если не была достигнута цель(-и) по проекту.
К примеру: крупный провайдер заказал у вас приложение для iPad для своих продажников. Цель этого проекта — увеличение продаж, за счет увеличения удобства работы продажников. Если цель достигнута (продажи выросли) — Заказчик не будет вникать, как делался этот проект, кто за него отвечал и кто его занимался его разработкой. Но вот если цель не будет достигнута — Заказчик будет разбираться, кто виноват и что делать дальше с проектом.
Заказчику в таком случае не обязательно знать, что происходит с проектом. Он заинтересуется им, только в том случае, если не была достигнута цель(-и) по проекту.
К примеру: крупный провайдер заказал у вас приложение для iPad для своих продажников. Цель этого проекта — увеличение продаж, за счет увеличения удобства работы продажников. Если цель достигнута (продажи выросли) — Заказчик не будет вникать, как делался этот проект, кто за него отвечал и кто его занимался его разработкой. Но вот если цель не будет достигнута — Заказчик будет разбираться, кто виноват и что делать дальше с проектом.
где на первую встречу приходит Заказчик, с ним оговариваются условия и цели проекта
А если заказчик имеет больше 10-ти сотрудников, например 100, нет 300, хорошо — 5к сотрудников и 132 отдела?
Кто к вам придет? Совет директоров полном составе? Учредители с генеральным директором?
В лучшем случае директор ИТ-департамента, с парой менеджеров.
Работать вы будете с кем? С менеджерами.
Что менеджеры знают о целях проекта?
Как показывает практика — практически ничего, а что их интересует? Сроки, следование букве ТЗ, оплата. Все.
Вот и будет проект оцениваться в процессе разработки только сроками и следованию ТЗ, а не достигнет он целей или нет.
Соответственно, если ПМ видит, что цели проект не достигает, он не сможет решить эту проблему с менеджером, ибо менеджеру глубоко на это плевать, проект должен быть сдан и точка, ибо сроки.
Сам ПМ должен взять на себя ответственность, пойти к тем, кто заинтересован в целях проекта и донести это до него.
Но вот если цель не будет достигнута — Заказчик будет разбираться, кто виноват и что делать дальше с проектом.
Я об этом и говорил, в итоге будет рожден проект который никому не нужен.
А хороший ПМ должен будет позаботиться об этом раньше, увидеть раньше.
А если заказчик имеет больше 10-ти сотрудников, например 100, нет 300, хорошо — 5к сотрудников и 132 отдела?
Кто к вам придет? Совет директоров полном составе? Учредители с генеральным директором?
В лучшем случае директор ИТ-департамента, с парой менеджеров.
Работать вы будете с кем? С менеджерами.
Что менеджеры знают о целях проекта?
Как показывает практика — практически ничего, а что их интересует? Сроки, следование букве ТЗ, оплата. Все.
Вот и будет проект оцениваться в процессе разработки только сроками и следованию ТЗ, а не достигнет он целей или нет.
Соответственно, если ПМ видит, что цели проект не достигает, он не сможет решить эту проблему с менеджером, ибо менеджеру глубоко на это плевать, проект должен быть сдан и точка, ибо сроки.
Сам ПМ должен взять на себя ответственность, пойти к тем, кто заинтересован в целях проекта и донести это до него.
Но вот если цель не будет достигнута — Заказчик будет разбираться, кто виноват и что делать дальше с проектом.
Я об этом и говорил, в итоге будет рожден проект который никому не нужен.
А хороший ПМ должен будет позаботиться об этом раньше, увидеть раньше.
Уважаемый mobilix, если не секрет, конечно — вы кто по должности будете?
Не секрет. Project-менеджер.
Если вы в компании, то мне не понятен пункт
Вы, как менеджер, можете выбирать проекты?
Не беритесь за проекты, если вы не уверены, что вы их доведете до конца
Вы, как менеджер, можете выбирать проекты?
У вас принимают решение о взятии проекта без согласования и предварительных расчетов (которые зачастую делают ПМы)?
Просто — «О! 10 млн, берем! Ну подумаешь, ОС новую написать, думаю справимся, не в первой.»?
Просто — «О! 10 млн, берем! Ну подумаешь, ОС новую написать, думаю справимся, не в первой.»?
Очень правильный вопрос.
Менеджер проекта не раб, конечно, но и его в компании назначают на проект.
Кроме того, очень странная позиция у mobilix. Понятно, что проект, в котором всё досконально понятно, не несёт никаких репутационных рисков. Но так не стать хорошим ПМом.
Действительно выгоду, опыт, навыки вам принесут только рискованные проекты. И этого не надо бояться: это и должно быть вашей стихией — работать в условиях неопределённости.
ДеМарко писал:
Избегать рисков — дело проигрышное. Раньше вы могли бы отнестись к проекту, свободному от рисков, как к неожиданному подарку судьбы и благодарили бы звезды за эту редкую удачу — легкий проект. Мы реагировали так же. Какими глупцами мы были! Проекты без риска — удел неудачников.
Риски и выгоды всегда ходят рука об руку. Компании, избегающие рисков и концентрирующие усилия только на том, что наверняка умеют делать хорошо, засевают поле для своих соперников. Проект полон рисков потому, что ведет вас нехожеными тропами. Он может расширить ваши возможности так, что это сведет с ума ваших конкурентов. В идеале — до такой степени, что конкурентам будет уже нечем ответить.
Менеджер проекта не раб, конечно, но и его в компании назначают на проект.
Кроме того, очень странная позиция у mobilix. Понятно, что проект, в котором всё досконально понятно, не несёт никаких репутационных рисков. Но так не стать хорошим ПМом.
Действительно выгоду, опыт, навыки вам принесут только рискованные проекты. И этого не надо бояться: это и должно быть вашей стихией — работать в условиях неопределённости.
ДеМарко писал:
Избегать рисков — дело проигрышное. Раньше вы могли бы отнестись к проекту, свободному от рисков, как к неожиданному подарку судьбы и благодарили бы звезды за эту редкую удачу — легкий проект. Мы реагировали так же. Какими глупцами мы были! Проекты без риска — удел неудачников.
Риски и выгоды всегда ходят рука об руку. Компании, избегающие рисков и концентрирующие усилия только на том, что наверняка умеют делать хорошо, засевают поле для своих соперников. Проект полон рисков потому, что ведет вас нехожеными тропами. Он может расширить ваши возможности так, что это сведет с ума ваших конкурентов. В идеале — до такой степени, что конкурентам будет уже нечем ответить.
Конечно, я лучше заранее сообщу руководству и заказчику, что не уверен, что управлюсь в срок или управлюсь вообще. Это избавит всех от проблем в будущем.
Sign up to leave a comment.
Основные правила Project-менеджера