Здравствуйте, samovar, Вы писали:

S>Изучаю новую для меня науку управления ИТ проектами.
S>Совсем запутался в понятиях.
S>Может ли кто-нибудь объяснить мне — в чем разница между
S>"управлением требованиями" и "управлением изменениями"?

В нашей компании я определяю цели данных процессов так:

Цель процесса RM: Произвести анализ выявленных требований, а также обеспечить управляемость требованиями к разрабатываемому решению (продукту) и идентифицировать противоречие между требованиями, планом проекта и артефактами.

А цель CM: Достигнуть уверенности в том, что любые изменения, инициированные как заказчиком, так и проектной командой, адекватно интегрируются в разработку проекта и четко контролируются.

Здравствуйте, Maxim Korotkov, Вы писали:

MK>Почитай De Marco/Lister (Peopleware, Deadline, Dancing with Bears). Определений таких там может и не найдешь, но подобные вопросы задавать перестанешь. А если хочешь формальные знания получить, то смотри PMI документы.

Вообще-то я вопросов не задавал...

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, Maxim Korotkov, Вы писали:

MK>>Почитай De Marco/Lister (Peopleware, Deadline, Dancing with Bears). Определений таких там может и не найдешь, но подобные вопросы задавать перестанешь. А если хочешь формальные знания получить, то смотри PMI документы.

B>Вообще-то я вопросов не задавал...

Ну, ты получил ответ на свой незаданный вопрос Такое бывает

Здравствуйте, samovar, Вы писали:

S>Может ли кто-нибудь объяснить мне — в чем разница между
S>"управлением требованиями" и "управлением изменениями"?

Грубо говоря, управляя требованиями, ты управляешь тем, что хотелось бы получить в продукте.
Управляя изменениями — управляешь тем,что и когда реально будет сделано.

Здравствуйте, 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 документы.

Изучаю новую для меня науку управления ИТ проектами.
Совсем запутался в понятиях.
Может ли кто-нибудь объяснить мне — в чем разница между
"управлением требованиями" и "управлением изменениями"?

Здравствуйте, samovar, Вы писали:

S>Изучаю новую для меня науку управления ИТ проектами.
S>Совсем запутался в понятиях.
S>Может ли кто-нибудь объяснить мне — в чем разница между
S>"управлением требованиями" и "управлением изменениями"?

Изменениями? Всегда думал, что поддержкой, т.е. maintainence management vs task management.

Здравствуйте, Maxim Korotkov, Вы писали:

MK>Здравствуйте, samovar, Вы писали:

S>>Изучаю новую для меня науку управления ИТ проектами.
S>>Совсем запутался в понятиях.
S>>Может ли кто-нибудь объяснить мне — в чем разница между
S>>"управлением требованиями" и "управлением изменениями"?

MK>Изменениями? Всегда думал, что поддержкой, т.е. maintainence management vs task management.

Да есть в общем такая дисциплина "Change management".
Термин уже давно устоялся и не только в IT
Можно считать, что управление требованиями — это частный случай управлениями изменений,
со своими специфическими особенностями.

Здравствуйте, samovar, Вы писали:

S>Изучаю новую для меня науку управления ИТ проектами.
S>Совсем запутался в понятиях.
S>Может ли кто-нибудь объяснить мне — в чем разница между
S>"управлением требованиями" и "управлением изменениями"?

Изучая PMBoK, тоже задавался таким вопросом. Поскольку обсудить этот вопрос было не с кем, склонился к мнению, что требования — это частный случай того, что имеет свойство меняться со временем. Другими словами, управление изменениями включает в себя управление требованиями, как и управление другими сущностями, обладающими тем же свойством.

S>Может ли кто-нибудь объяснить мне — в чем разница между
S>"управлением требованиями" и "управлением изменениями"?

ИМХО, простой пример на пальцах:
1. Вн начале проекта было выявлено и выполнено требование к какой то функциональности (управление требованиями)
2. Ближе к концу при разработке другого требования "зацепили" первое. Инициировали переработку формулировки первого требования. Так как функциональность по первому требованию уже была реализована, необходимо учесть изменение и назначить за внесение этого изменения ответсвенного разработчика. (управление изменениями).

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, samovar, Вы писали:

S>>Изучаю новую для меня науку управления ИТ проектами.
S>>Совсем запутался в понятиях.
S>>Может ли кто-нибудь объяснить мне — в чем разница между
S>>"управлением требованиями" и "управлением изменениями"?

А>Изучая PMBoK, тоже задавался таким вопросом. Поскольку обсудить этот вопрос было не с кем, склонился к мнению, что требования — это частный случай
А>того, что имеет свойство меняться со временем. Другими словами, управление изменениями включает в себя управление требованиями, как и управление
А>другими сущностями, обладающими тем же свойством.

Как говорится, хорошая мысля приходит опосля Если вспомнить определение процесса — последовательность изменений ...(эту часть пока можно опустить) — тогда ответ на вопрос становится понятен (не знаю, очевиден ли). Теперь определение в целом (на точность не претендую): процесс — это последовательность изменений некоторых свойств некоторого объекта. В случае разработки программного продукта он (продукт) и является объектом, свойства которого меняется в течение процесса. Например, меняется представление этого продукта — спецификация требований -> ... -> исходный код -> ... -> конечный продукт. Хотелось бы узнать мнение на счет того, не ослеплен ли я очевидностью такого ответа?

P.S. Предыдущий пост мой.