Так я получил эту новую работу, которая является моей первой работой, полностью основанной на проектах.
Моя зарплата частично привязана к объективному соглашению. Это соглашение должно быть сделано. Мой менеджер дал мне свое предложение по этому соглашению, но я им не доволен, потому что оно не поддается измерению.
Поскольку у меня нет твердого образования в области управления проектами, я не знаю никакого метода разработки измеримого соглашения на основе проекта.
Какие методы существуют, чтобы сделать измеримыми проекты, которые не являются планируемыми на 100%? (Например: как работник проекта, я не могу гарантировать, что весь проект будет успешным, поскольку существует слишком много факторов, на которые я не могу повлиять)
Каких хорошо известных ловушек мне следует избегать?
Это, вероятно, слишком широко, но я постараюсь хотя бы ответить на следующее:
Какие методы существуют, чтобы сделать измеримыми проекты, которые не являются планируемыми на 100%? (Например: как работник проекта, я не могу гарантировать его успех, потому что слишком много фабрик, на которые я не могу повлиять)
По сути, когда дело доходит до планирования, вы всегда связываете фактор риска с запланированным временем, которое потребуется, в зависимости от рисков, вы потратите X часов, чтобы закончить его, но на самом деле вы запланируете Y часов, Y > X, тем больше рискованно, тем больше будет расти Y. По сути, вам нужен опыт, чтобы правильно настроить Y и познакомиться со своей командой.
Какие известные ловушки существуют, которых мне следует избегать?
Я отвечу, что мы говорим здесь о развитии ИТ, чтобы подчеркнуть мою точку зрения, хотя большая часть того, что я скажу, несомненно, верна везде.
Если вы всего лишь руководитель проекта без технических навыков (или недостаточных), доверяйте своей команде, когда они дают вам цифры (фактор риска/времени). Несмотря на то, что я довольно молод, я уже видел слишком много упущенной выгоды, потому что менеджер проектов сокращал время, которое разработчики оценивают для реализации функциональности.
Не стоит недооценивать фактор риска. Если вам или вашей команде нужны какие-то подсказки по этому поводу, погуглите «гибкий фактор риска». Даже если вы не пойдете с agile-методами, то, что сказано по этому поводу, все равно верно.
Иметь качественные измерения сложно, в основном это связано с опытом и знанием вашей команды. Я могу только привести пример из сферы ИТ: количество строк кода — наихудший способ измерения производительности .
Как менеджер проекта, вы являетесь отправной точкой команды, никто не должен позволять вашим людям отнимать время без вашего ведома, поэтому вы можете перепланировать задачи.
Окончательно :
Погуглите про диаграмму Ганта и проверьте метод критического пути . Первый — визуализировать ваше планирование, второй — как распределить какую-то задачу и определить среди разных путей критический (тот, который все задержит). Я думаю, что это основа управления проектами.
Читайте книги о 1-управлении проектами, 2-качестве, 3-коммуникациях/лидерстве, читать об ISO 9001 тоже полезно.
Какие методы существуют, чтобы сделать измеримыми проекты, которые не являются планируемыми на 100%?
Найдите какой-нибудь в принципе независимый источник, чтобы судить о достижении цели.
Например, об «успехе проекта» можно судить по увеличению продаж, достигнутому в результате завершения проекта, или по опросу удовлетворенности клиентов и т. д.
Многие объективные факторы находятся вне вашего непосредственного контроля. К сожалению, так обстоят дела.
Поработайте со своим менеджером, чтобы выработать подход к оценке выполнения вашей задачи, с которым вы оба можете согласиться.
пользователь8036
джаво
HLGEM