51Testing软件测试论坛

标题: 如果项目已经结项，一段时间后客户提出很小的需求变更 [打印本页]

作者: tracyhuang 时间: 2006-5-10 10:26
标题: 如果项目已经结项，一段时间后客户提出很小的需求变更
如果项目已经结项，一段时间后客户提出很小的需求变更，把它立入维护项目又太小，感觉没有必要，把它当作需求变更，但项目已经结项，照例说不属于项目里面的事情了。大家有没有遇到这种情况过，又是怎么处理的？

作者: tracyhuang 时间: 2006-5-10 13:55
斑竹给点意见呢。

作者: Tender 时间: 2006-5-10 14:07
我估摸着比较难说。

作者: lierbo 时间: 2006-5-11 09:36
我做的项目中也经常遇到这样的情况，例如，项目已经结束，用户偶尔会让你修改某处字体大小，这样的修改可能1分钟内就可以处理完。不过我都把它记录到维护记录文档中，并记录工作量（适当夸大，呵呵，作为日后向用户收取维护费的依据）。

作者: springsunxixi 时间: 2006-5-15 16:18
标题: 还是应该记录
虽说项目结束了，但一个项目的生命周期并没有结束，它还包括维护期或者是质保期，在这个阶段内的修改还是要看成项目的变更，但这个变更可以做的简单一些，记录一下就可以了，具体还要看对于该项目的变更控制是如何规定的，是否规定了不同时期如何裁减或执行流程。

作者: luoyear 时间: 2006-5-15 18:11
还是应该作为需求变更管理起来，可以不存在具体的项目，但这些变更还是要触发各环节工作产品的同步变更，并且由测试人员最后验收交付。

作者: atce 时间: 2006-5-17 14:50
区分商业优先级和技术优先级，如果是大客户，当然要做补丁(patch)。

作者: 海的女儿 时间: 2006-5-20 22:25
项目的结束和项目组的解散，通常是以接收到验收报告为准的。对于已经签订验收报告的项目，通常即转为维护项目，此时仍不能忽视对变更的版本管理，可利用“需求双向跟踪矩阵”来进行跟踪管理，需求-设计-代码-测试用例等相关中间产品都需要同步变更。至于由谁来完成这些工作就要看各公司的具体情况了。

作者: 耶罗 时间: 2006-5-23 22:28
需求变更是免不了的，需求变更应当拉入公司管理范畴里面。
如果当前项目里面完成不了，后面可以打一些patch啊，呵呵。

作者: cjycjy11 时间: 2006-5-25 16:31
不要想当前的流程是最尤的，以后也不可能是最优的。我们应该遵循已定义的流程，是否改进现有流程应该由管理层从组织整体利益出发进行考虑，所以，常见的做法是走变更流程并上报我们遇到的问题。组织总希望项目是可控的，哪怕付出更多的附加成本，因此需求变更必须受控，哪怕它很小，也许可以简单些。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)