评论

#yzhz 发表于2007-08-07 11:59:09  IP: 121.0.31.*

如果项目的成员都觉得这个需求变更流程简单、明确，操作性强，我想这个流程的目的就达到了。

#bbbian 发表于2007-08-07 17:38:54  IP: 219.137.233.*

1是否需要变更，做出判断
2如果需要变更，会产生那些影响，做出相应的变更计划，包括可能影响的项目范围，进度，费用，质量等计划
3确定变更的负责人
4通知变更可能影响的相关人员
5按照变更后的计划实施项目，并进行检查
这才是变更管理的流程

#laifangsong 发表于2007-08-08 11:31:43  IP: 218.66.59.*

好文章啊，谢谢作者。

#laifangsong 发表于2007-08-08 11:48:45  IP: 218.66.59.*

我还觉的：

对需求变更，还应该详细了解客户要变的根源是什么。一定要弄清楚哪些是必要功能，哪些是锦上添花的。有些客户可能是突然看到一个很酷的效果，他就也想有一个。类似这样的，这次帮他做了一个，下次就接二连三地想要这种“酷”的效果，把他贯坏了，那就麻烦了。你下次不给他做，他会这样说：“就做成上次那样嘛，不是也没花多少时间，很快就做好了”。要命的事，做的这些事都可能是没钱的。

就算是必改或必须要加的功能，也要剥离出里面的核心，没必要全步实现这个功能。

有必要的话，要适当夸大需求变更产生的影响。可以从项目延期、增加项目费用方面来说，要以为他省时间、省钱的这种“软”态度来小吓他一下。

#laifangsong 发表于2007-08-08 11:50:38  IP: 218.66.59.*

我订阅了您的博客，希望你经常更新啊：）

#yzhz 发表于2007-08-09 14:37:05  IP: 121.0.31.*

回复bbbian：
谢谢你的回复。

1是否需要变更，做出判断
我的文章中提到：项目经理收到变更申请后，项目经理可以召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。

2如果需要变更，会产生那些影响，做出相应的变更计划，包括可能影响的项目范围，进度，费用，质量等计划
我的文章中提到：项目经理可以召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。
对于确认的变更，会有需求变更记录表来描述该变更，当然你说的变更计划应该是非常全面，但对于web项目要求的时间性考虑，我觉得一张表格也可以说明问题，简单明了。

3确定变更的负责人
需求变更的决策者应该由项目经理承担，具体的操作者是SQA来承担，比如基线控制，变更记录，通知相关人员。我的文章中有遗漏，没有明确这个人的角色。

5按照变更后的计划实施项目，并进行检查
对，变更后的实施反馈没有在我的变更流程中，这一点我是有考虑，但想到大部分需求的变更最终都要经过测试环节，所以我就没专门提到。变更后的实施反馈还是比较重要的，我想还是根据项目的实际情况对这块裁剪比较好。

#yzhz 发表于2007-08-09 15:08:48  IP: 121.0.31.*

回复laifangsong ：
你说的非常对，看来是对这块有深刻体会的人。
更新的频率我尽量吧，因为我希望我的文章是有质量的，同时文章的内容不会误导读者，所以对发表的内容我会仔细斟酌。这样会对更新速度有点影响。呵呵。