Комментарии 6
Обратная связь: Как количественно оценивать результаты работы отдельных сотрудников на программном проекте? Как и какие именно риски Вы оцениваете в ходе проекта (после инициации) и как их предупреждаете? Нужен ли тайм-трекинг на проекте? Как решаете проблемы неравномерности нагрузки на сотрудников? Вы ведёте учёт потерь на проекте? Если да, то каких именно и как?
Дзен №4: "Начинайте проповедовать Устав вашего проекта сразу после официального запуска проекта. Идите с этой Библией к вашей Пастве."
100% согласен с этим утверждением, потому что любое дело или проект всегда начинается с единомышленниками. Но, чтобы проект не потерпел на старте крах - нужно донести понимание о идеологии и философии проекта, и не только стейкхолдерам и команде, но и первым клиентам. Нужно из проекта делать целый бренд со своими смыслами и четко придерживаться их. Все люди хотят быть частью бренда или чего-то огромного! А чтобы огромное получилось надо сформировать философию с собственным манифестом.
Смыслы, философия, идеология проекта - это большая часть стратегии.
Это что ни на есть - ВРЕДНЫЕ советы.
Графоманство чистой воды, никакого отношения к проектному менеджменту не имеющее. Инфантильная позиция слабо разбирающегося в предмете человека.
Всё разумно. Права, Устав на проектах никто не учит, но если менеджер проекта старается всё делать в соответствии с правилами Устава, то и остальные втягиваются.
При этом хорошо бы сделать Устав компактным, до 50 страниц. В идеале: 20 - 30 стр. Тогда есть шанс, что его будут читать. Тома от 100 страниц вообще всех отпугивают :)
«Не вредные советы для Лидера Проекта». Часть 2 — Запуск проекта. Как правильно выстроить иерархию власти в Гриффиндоре