需求变更应对之道

项目需求变更规范

一、需求变更的原因分析

需求变更可能来自方案服务商、客户或BD等，也可能来源于项目组内部。而需求变更的表现形式是多方面的，如老板临时改变想法、需求插入，某一功能需求的增加或减少、客户对功能的需求改变等。对于任何项目，变更都无可避免，也无从逃避，只能积极应对。

二、如何控制需求变更

在版本的启动、实施、收尾三个生命周期过程中，需求变更的控制不应该只是在实施过程中才考虑的事情，而是要分布在整个项目生命周期的全过程。

1. 项目启动阶段的变更预防

基准文件定义的范围越详细清晰，PM，rd,qa之间扯皮的幌子就越少。如果需求没做好，基准文件里的范围含糊不清，rd开发可能与PM期望不一致，而QA失去了判断功能实现正确与否的前提条件

2. 项目实施阶段的需求变更

项目成功或失败，在于项目的整个过程是否是可控。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。

另外，小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。

3. 项目收尾阶段的总结

需求变更既然不可避免，那么就必须有一套规范的处理流程。对于需求变更的处理流程应该分以下步骤：提出变更申请、变更评估、决策、回复

三、实施需求变更需要遵循如下原则

• 建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线

• 制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用

• 由项目负责人最终裁定接受哪些变更。需求变更所涉及多方人员，应该包括rd、QA，pm，相关leader在内

• 需求变更一定要先申请然后再评估，最后经过变更评审确认

• 需求变更后，受影响的项目计划、开发进度、测试用例、mrd、交互、视觉都要进行相应的变更，以保持和更新的需求一致

• 妥善保存变更产生的相关文档

四、应对之道

需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更步骤，有时还会有取消变更的步骤。针对变更控制流程，在实际工作中总结了需求变更管理的几点对策：

• 相互协作：在讨论需求时，各方人员应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。仔细分析和评估，积极提出可行的替代方案。

• 充分交流：需求变更管理的过程很大程度上就是pm与rd或qa的交流过程。rd和qa应认真听取功能变更的需求，考虑和设想，并加以分析和整理。同时，rd应该向需求变更人员说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。

• 安排专职人员负责需求变更管理：有时开发任务较重，开发人员容易陷入开发工作中而忽略了与pm或qa的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。

• 区别对待：随着开发进展，有些pm会不断提出一些在开发人员看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况，开发人员可以向需求变更人员说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求(虽然需求变更人员认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。如果坚持实施新需求，可以建议需求变更人员将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。

• 选用适当的开发模型：采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。