需求变更的代价

　　进行综合变更控制的主要依据是项目计划、变更请求提供了项目执行状况信息的绩效报告。为保证项目变更的规范和有效实施，通常项目实施组织会有以下几种措施：

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

　　对于任何项目，变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段开始了。对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理扯皮的幌子越少。如果需求没做好，基准文件里的范围含糊不清，被客户抓住空子，往往要付出许多无谓的牺牲。如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更超出了合同范围，需要另外收费。这个时候千万不能手软，这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。相对于需求来说，什么WBS、风险管理、计划进度都是次要的，只要需求做好了会一帆风顺。 

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

　　成功项目和失败项目的区别在于项目的整个过程是否是可控的。项目经理应该树立一个理念??“需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。控制需求渐变需要注意以下几点： 

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

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

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

　　精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细，越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它不会变化了。 

　　注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点问题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。 

 　　在开发上尽量根据情况采用多次迭代的方式进行项目的开发，在每次迭代的同时让客户参与和使用软件，对下一步的开发做出建议争取在项目前期有效的减少后期可能出现的变更情况。

　　（3）项目收尾阶段的总结 

　　能力的提高往往不是从成功的经验中来，而是从失败的教训中来。许多项目经理不注重经验教训总结和积累，即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。

　　事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。 

　　需求变更的管理 

需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。 

　　需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也越多，需求变更因此不可避免地一次又一次出现。  

　　这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。 

　　实施需求变更管理需要遵循以下六大原则 

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

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

　　（3）成立项目变更控制委员会（CCB）或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。 

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

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

　　（6）妥善保存变更产生的相关文档。 

　　应对之道 

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

　　优先排序 分批实现　每个需求的重要性是不同的。由于资源或技术条件的限制，会显得“僧多粥少”，因此不可能把所有的需求一次完成。怎么办？把每个需求按照对效益的贡献打个分，排出个优先级来，优先级高的需求先实现，低的到一下版式本实现。由于不断有新的需求进来，有的需求可能永远没有机会被子实现，但不紧，还是要记录下来，并一起参加排序，保证在每个版本发布时重要的需求先得到满足。每个需求的实现是需要花时间的，没人有百分百的把握预估得很清楚，但借鉴过去的经验可以大概估算出人力成本，然后根据开发人员和开发周期得出可用人力投入作为上限。从优先级高的需求中挑，直到挑中的人力成本总和刚刚低于可用投入上限，这样得出的是需求的录取榜。今后的软件开发规划也会以此为依据，分期分批地在不同的回合中实现。合理的不一定是优先级高的，也是说不一不定是先考虑的，“经济为本”是指导优先排序的终原则。

　　相互协作　很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。  

　　充分交流　需求变更管理的过程很大程度上是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。
　安排专职人员负责需求变更管理　有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。  

　　合同约束　需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。  

　　区别对待　随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，项目的启动是以初的基本需求作为开发前提的，如果大量增加新的需求（虽然用户认为是细化需求，但实际上是增加了工作量的新需求），会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。
  
  　　选用适当的开发模型　采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。  

　　用户参与需求评审　作为需求的提出者，用户理所当然是具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行后确认的机会，可以有效减少需求变更的发生。