Изучаю новую для меня науку управления ИТ проектами.
Совсем запутался в понятиях.
Может ли кто-нибудь объяснить мне — в чем разница между
"управлением требованиями" и "управлением изменениями"?
Re: разница между управлением требованиями и управлением изм
Здравствуйте, samovar, Вы писали:
S>Изучаю новую для меня науку управления ИТ проектами. S>Совсем запутался в понятиях. S>Может ли кто-нибудь объяснить мне — в чем разница между S>"управлением требованиями" и "управлением изменениями"?
Изменениями? Всегда думал, что поддержкой, т.е. maintainence management vs task management.
Re[2]: разница между управлением требованиями и управлением
Здравствуйте, Maxim Korotkov, Вы писали:
MK>Здравствуйте, samovar, Вы писали:
S>>Изучаю новую для меня науку управления ИТ проектами. S>>Совсем запутался в понятиях. S>>Может ли кто-нибудь объяснить мне — в чем разница между S>>"управлением требованиями" и "управлением изменениями"?
MK>Изменениями? Всегда думал, что поддержкой, т.е. maintainence management vs task management.
Да есть в общем такая дисциплина "Change management".
Термин уже давно устоялся и не только в IT
Можно считать, что управление требованиями — это частный случай управлениями изменений,
со своими специфическими особенностями.
Re[3]: разница между управлением требованиями и управлением
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Maxim Korotkov, Вы писали:
MK>>Здравствуйте, samovar, Вы писали:
S>>>Изучаю новую для меня науку управления ИТ проектами. S>>>Совсем запутался в понятиях. S>>>Может ли кто-нибудь объяснить мне — в чем разница между S>>>"управлением требованиями" и "управлением изменениями"?
MK>>Изменениями? Всегда думал, что поддержкой, т.е. maintainence management vs task management.
B>Да есть в общем такая дисциплина "Change management". B>Термин уже давно устоялся и не только в IT B>Можно считать, что управление требованиями — это частный случай управлениями изменений, B>со своими специфическими особенностями.
Почитай De Marco/Lister (Peopleware, Deadline, Dancing with Bears). Определений таких там может и не найдешь, но подобные вопросы задавать перестанешь. А если хочешь формальные знания получить, то смотри PMI документы.
Re[4]: разница между управлением требованиями и управлением
Здравствуйте, Maxim Korotkov, Вы писали:
MK>Почитай De Marco/Lister (Peopleware, Deadline, Dancing with Bears). Определений таких там может и не найдешь, но подобные вопросы задавать перестанешь. А если хочешь формальные знания получить, то смотри PMI документы.
Вообще-то я вопросов не задавал...
Re: разница между управлением требованиями и управлением изм
Здравствуйте, samovar, Вы писали:
S>Может ли кто-нибудь объяснить мне — в чем разница между S>"управлением требованиями" и "управлением изменениями"?
Грубо говоря, управляя требованиями, ты управляешь тем, что хотелось бы получить в продукте.
Управляя изменениями — управляешь тем,что и когда реально будет сделано.
Здравствуйте, samovar, Вы писали:
S>Изучаю новую для меня науку управления ИТ проектами. S>Совсем запутался в понятиях. S>Может ли кто-нибудь объяснить мне — в чем разница между S>"управлением требованиями" и "управлением изменениями"?
В нашей компании я определяю цели данных процессов так:
Цель процесса RM: Произвести анализ выявленных требований, а также обеспечить управляемость требованиями к разрабатываемому решению (продукту) и идентифицировать противоречие между требованиями, планом проекта и артефактами.
А цель CM: Достигнуть уверенности в том, что любые изменения, инициированные как заказчиком, так и проектной командой, адекватно интегрируются в разработку проекта и четко контролируются.
Без працы не бенды кололацы
Re: разница между управлением требованиями и управлением изм
От:
Аноним
Дата:
18.01.07 09:07
Оценка:
Здравствуйте, samovar, Вы писали:
S>Изучаю новую для меня науку управления ИТ проектами. S>Совсем запутался в понятиях. S>Может ли кто-нибудь объяснить мне — в чем разница между S>"управлением требованиями" и "управлением изменениями"?
Изучая PMBoK, тоже задавался таким вопросом. Поскольку обсудить этот вопрос было не с кем, склонился к мнению, что требования — это частный случай того, что имеет свойство меняться со временем. Другими словами, управление изменениями включает в себя управление требованиями, как и управление другими сущностями, обладающими тем же свойством.
Re[5]: разница между управлением требованиями и управлением
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Maxim Korotkov, Вы писали:
MK>>Почитай De Marco/Lister (Peopleware, Deadline, Dancing with Bears). Определений таких там может и не найдешь, но подобные вопросы задавать перестанешь. А если хочешь формальные знания получить, то смотри PMI документы.
B>Вообще-то я вопросов не задавал...
Ну, ты получил ответ на свой незаданный вопрос Такое бывает
Re: разница между управлением требованиями и управлением изм
S>Может ли кто-нибудь объяснить мне — в чем разница между S>"управлением требованиями" и "управлением изменениями"?
ИМХО, простой пример на пальцах:
1. Вн начале проекта было выявлено и выполнено требование к какой то функциональности (управление требованиями)
2. Ближе к концу при разработке другого требования "зацепили" первое. Инициировали переработку формулировки первого требования. Так как функциональность по первому требованию уже была реализована, необходимо учесть изменение и назначить за внесение этого изменения ответсвенного разработчика. (управление изменениями).
Re[2]: разница между управлением требованиями и управлением
От:
Аноним
Дата:
18.01.07 12:03
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, samovar, Вы писали:
S>>Изучаю новую для меня науку управления ИТ проектами. S>>Совсем запутался в понятиях. S>>Может ли кто-нибудь объяснить мне — в чем разница между S>>"управлением требованиями" и "управлением изменениями"?
А>Изучая PMBoK, тоже задавался таким вопросом. Поскольку обсудить этот вопрос было не с кем, склонился к мнению, что требования — это частный случай А>того, что имеет свойство меняться со временем. Другими словами, управление изменениями включает в себя управление требованиями, как и управление А>другими сущностями, обладающими тем же свойством.
Как говорится, хорошая мысля приходит опосля Если вспомнить определение процесса — последовательность изменений ...(эту часть пока можно опустить) — тогда ответ на вопрос становится понятен (не знаю, очевиден ли). Теперь определение в целом (на точность не претендую): процесс — это последовательность изменений некоторых свойств некоторого объекта. В случае разработки программного продукта он (продукт) и является объектом, свойства которого меняется в течение процесса. Например, меняется представление этого продукта — спецификация требований -> ... -> исходный код -> ... -> конечный продукт. Хотелось бы узнать мнение на счет того, не ослеплен ли я очевидностью такого ответа?