如果项目已经结项，一段时间后客户提出很小的需求变更

tracyhuang · 发表于 2006-5-10 10:26:38

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

tracyhuang · 发表于 2006-5-10 13:55:52

斑竹给点意见呢。

Tender · 发表于 2006-5-10 14:07:35

我估摸着比较难说。

lierbo · 发表于 2006-5-11 09:36:35

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

springsunxixi · 发表于 2006-5-15 16:18:48

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

luoyear · 发表于 2006-5-15 18:11:06

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

atce · 发表于 2006-5-17 14:50:07

区分商业优先级和技术优先级，如果是大客户，当然要做补丁(patch)。

海的女儿 · 发表于 2006-5-20 22:25:01

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

耶罗 · 发表于 2006-5-23 22:28:20

需求变更是免不了的，需求变更应当拉入公司管理范畴里面。
如果当前项目里面完成不了，后面可以打一些patch啊，呵呵。

cjycjy11 · 发表于 2006-5-25 16:31:43

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

		自动登录	找回密码
密码			(注-册)加入51Testing

[讨论] 如果项目已经结项，一段时间后客户提出很小的需求变更