需求变更四对策

开篇：润墨网以专业的文秘视角，为您筛选了一篇需求变更四对策范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

需求变更频繁发生，如果处理不好更会影响项目团队和客户之间的关系，同时也影响产品的交付。

从理论上讲，需求包括业务需求、用户需求和功能需求。业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。这些需求在项目执行过程中都可能发生改变，即发生需求变更。

需求变更的表现形式也是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部，比如对项目人员的临时离职会发生突然的需求等。

原因

1、需求信息错位

在需求分析员确定客户需求之前，毫无疑问要和客户做好深度沟通。但是由于沟通渠道的限制，以及双方能力、教育、习惯背景的限制，往往会出现信息沟通偏差，就是我们说的需求信息错位。

当客户向需求分析人员提出需求的时候往往是通过自己的想法用一般语言来表达的，而且是基于客户对自己需求的理解角度上表达的，这就引起表达的结果对于真实的需求来说是一种仅仅从某个角度的一般描述，远远不能保证这样的描述可以得到百分之百的正确理解。以前有个盲人摸象的故事，这个例子可以解释一下为什么存在信息的偏差:顾客想要画一头大象，可是却不清楚大象的身子、耳朵、四条腿以及尾巴是什么具体样子，只能描述出这几个部分大致像什么。于是顾客告诉分析员，“我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子”。分析员听到这些，就按照自己对墙、扇子、柱子、绳子的理解画出了“大象”。

结果可想而知。然而这种现象在软件项目需求变更中并不少见的。

这里面还有一个细化工作的问题。细化工作是一般由需求分析人员完成，一般是根据客户提出的描述性的、总结性的文档去细化客户需求，将这种需求细化到一定程度后，就可以提取其中的一个个细小的功能，并给出描述。

但是不能光靠分析员做细化工作，还应该把这些细化过的功能描述与客户继续深入地沟通，否则以后将会发生因为细化而引起的不能适应范围的问题，比如原来是手工填入的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。

2、建设期的沟通局限性

现实中，一个大中型系统的建设可能要持续较长的一段时间。在整个建设内，当客户提出要求时，因为不能看到系统的运行情况，客户和开发商双方就会认为需求沟通方面不存在什么分歧，然而事实上还常常会有需求最终期限的问题，此时开发商就已经开始工作了。

最后当客户从开发商那里拿到差不多可以试用的产品时候，因为现在可以实际操作，他就会对现实的系统提出很多问题，就是我们说的需求变更，比如系统的界面、操作、功能、性能等方面。

3、客户所在环境的改变

当前客户的运营情况不确定，有可能客户行业的竞争度高，需要随时做出调整和反应，那么他们自然会经常提出需求变更的要求;也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发变更是需要随时准备应变。

一般说来客户会要求改变界面，改变操作方式，甚至改变业务，客户甚至会说:“当时我是那样要求的，不过现在我们的业务调整了。”这一切都是由行业大环境成的，所以对于这方面的需求变更必须要有一定的预测措施。

4、开发商的系统升级

为适应市场需求，或是由于竞争等因素，开发商自身会有可能存在进行开发系统版本的升级或性能改进、设计修正的要求，因此会出现需求变更。这时谁也无法绕开这个问题。

从上面的分析可以看出，就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以项目团队，或者说是开发商不要梦想会存在多么理想的需求分析，应该从一开始就要有客户需求变更一定会存在的准备。

代价

任何项目只要存在某个方面变更，那么就要付出对应的代价。需求的变更通常意味着需求的增加，同时也意味着相应的代价。当客户提出新需求的时候，项目开发人员应该分析这些新需求对项目现阶段带来的风险，得出双方实现变更需求所需要的成本，包括时间、人力、资源等方面。

同时，在评估代价、与客户讨论的过程中，要让客户了解变更的后果，变更之后面临最大的问题就是项目延期，让客户一起做是否继续修改还是要接受修改后果的决策。这样就会出现三种可能:

1、客户接受延期的后果，开发人员按客户要求做出修改，让客户知道为此需要付出延期的代价;

2、客户认为代价太大，那么开发人员就不必修改了，可以记录下需求，待到下一版本再做修改;

3、客户不接受变更的代价，导致项目夭折。

所以变更引起的后果一定要和客户沟通，确保客户了解后果。如果客户不知道项目开发人员为变更付出的代价，对他们的辛苦便难以体会，以致没完没了的提出新的变更。

然而对于这样的现状，我们该怎么办呢？

积极应对

1、完善软件项目需求变更的管理

需求变更管理就是要把项目的需求变更对项目的负面影响降到最低，即不为消除，只为减少。需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。

这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。

当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响。

2、项目启动阶段的变更预防

应对变更应该是从项目启动的需求分析阶段就开始了。 首先就是要和客户有一个深度沟通的过程，然后再做需求细分，做需求分析，同时在做这些的时候和客户实时沟通。

对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，双方的分界线也就越清晰，所以用户和项目经理扯皮的幌子就越少了。假如需求没做好，基准文件里的范围含糊不清，被客户抓住空子，往往要付出许多无谓的牺牲。

如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费，这样就可以弥补一下项目开发团队的损失。所以只要前面的需求分析做好了后面就会一帆风顺了。

3、项目实施阶段的需求变更

项目的实施过程中，需求变更是必然的，但是同时也是可控的、有益的。项目实施阶段的变更控制需要做的是分析变更请求以及评估变更可能带来的风险和修改基准文件。主要从以下几点考虑:

1）需求要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，无论是开发方还是出资方在项目开始前都要明确一条:需求变，软件开发的投人也要变。

2）需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。

3）小的需求变更也要经过正规的需求管理流程，否则会积少成多。冰冻三尺非一日之寒。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间，这样就使需求逐渐变为不可控，甚至导致项目的失败。

4、项目收尾阶段的总结

能力的提高往往不是从成功的经验中来，而是从失败的教训中来。项目开发团队要提高对项目总结的重视，以从以前的项目中吸取教训。

链 接

实施需求变更管理的的原则：

建立需求基线；

制定简单、有效的变更控制流程，并形成文档；

成立项目变更控制委员会或相关职能的类似组织，负责裁定接受哪些变更；

需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认；

需求变更后，受影响的软件计划、产品、活动要进行相应的变更，以保持和更新的需求一致；

妥善地保存变更所产生的相关文档。