六大原则
实施需求变更管理需要遵循如下原则：
1.建立需求基线。需求基线是需求变更的依据。在研发过程中，需求确定并经过评审后（用户参和评审），能建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。 项目管理软件
2.制订简单、有效的变更控制流程，并形成文件。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目研发和其他项目都有借鉴作用。 项目管理软件
3.成立项目变更控制委员会（CCB）或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员一起组成，应该包括用户方和研发方的决策人员在内。项目管理软件
4.需求变更一定要先申请然后再评估，最后经过和变更大小相当级别的评审确认。项目管理软件
5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。项目管理软件
6.妥善保存变更产生的相关文件。项目管理软件
应对之道
需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。变更控制流程如图所示。针对变更控制流程，笔者在实际工作中总结出了软件研发人员在需求变更管理实践中的几点对策：
相互协作 非常难想像遭到用户抵制的项目能够成功。在讨论需求时，研发人员和用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在研发人员看来"过分"的需求，也应该仔细分析原因，积极提出可行的替代方案。项目管理软件
充分交流 需求变更管理的过程非常大程度上就是用户和研发人员的交流过程。软件研发人员必须学会认真听取用户的需求、考虑和设想，并加以分析和整理。同时，软件研发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个研发工作带来什么样的冲击和不良后果。项目管理软件
安排专职人员负责需求变更管理 有时研发任务较重，研发人员容易陷入研发工作中而忽略了和用户的随时沟通，因此需要一名专职的需求变更管理人员负责和用户及时交流。项目管理软件
合同约束 需求变更给软件研发带来的影响有目共睹，所以在和用户签订合同时，能增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更能接受、拒绝接受或部分接受，还能规定发生需求变更时必须执行变更控制流程。项目管理软件
差别对待 随着研发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇见这种情况，研发人员能向用户说明，项目的启动是以最初的基本需求作为研发前提的，如果大量增加新的需求（虽然用户认为是细化需求，但实际上是增加了工作量的新需求），会使项目不能按时完成。如果用户坚持实施新需求，能建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。 项目管理软件
选用适当的研发模型 采用建立原型的研发模型比较适合需求不明确的研发项目。研发人员先根据用户对需求的说明建立一个系统原型，再和用户沟通。一般用户看到一些实际的东西后，对需求会有更为周详的解释，研发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式研发方法对工期紧迫的项目的需求变更控制非常有成效。项目管理软件
用户参和需求评审 作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，能有效减少需求变更的发生。项目管理软件
作为项目经理的我做如下变更控制的总结：
变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多，因此变更控制显得格外重要。项目管理软件
IT项目中引起变更的因素有两个：一是来自外部的变更要求，如客户要求修改工作范围和需求等；二是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更，因为IT项目需求变更的概率大，引发的工作量也大（特别是到项目的后期）。项目管理软件
变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义，否则“变化”也无从谈起。工作范围（以前章节谈过）；另一种方法是评审，特别是对需求进行评审，这往往是项目成败的关键。需求评审的目的不仅是“确认”，更重要的是找出不正确的地方并进行修改，使其尽量接近“真实”需求。另外，需求通过正式评审后应作为重要基线，从此之后即开始对需求变更进行控制。项目管理软件
虽然可以事前定义好变更控制流程，但在各种压力下真正“控制”起来其实非常困难。下面给大家分析一个变更失控的项目案例：
王先生刚出任项目经理，并承接了一个中型软件项目。上任时公司高层再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。王先生动员大家加班，保持了项目的正常进度，客户相当满意。项目管理软件
但需求变更却越来越多。为了节省时间，客户的业务人员不再向王先生申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快王先生就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。 项目管理软件
而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。项目管理软件
随后发生的事情让王先生更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。王先生知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面，王先生只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问王先生：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”王先生委屈极了，疑惑自己到底错在哪里了。项目管理软件
从上面的案例中可以看到各种变更失控的现象和造成的后果，王先生主要犯了几个错误：
（1） 没有明确的授权。
事先应该明确客户方有权提出变更申请的人员和实施方有权受理变更的人员，并要控制双方人数。这样做才可以对变更有整体的控制。绝不能进行“私下交易”，而没有人能完整地知道到底改了些什么。另外，授权双方接口人的好处是可以屏蔽客户内部的矛盾，如果只有一个接口人，内部尚未达成一致时变更是无法提出来的。从实际经验看，授权可以显著减少变更，特别是那些因内部看法不同而导致的反复变更。项目管理软件
（2） 对变更没有进行必要的审核。
并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。比如案例中提到的界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要严格审核把关，否则会引起全局问题，案例中提到的“擅自修改核心模块”造成的事故就是因为没有审核而造成的。项目管理软件
（3） 对变更的影响没有评估。
变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让客户了解变更的后果，并与客户一起做判断。案例中客户最后的质问正是因为没有事前告诉客户变更的影响造成的。如果客户不知道你为变更付出的代价，对你的辛苦便难以体会。案例中客户刚开始对王先生加班处理变更相当满意，但只是对工作态度满意，后期当变更引发一系列问题时客户并没有感谢王先生的苦劳。项目管理软件
（4） 应该让客户确认是否接受变更的代价。
在评估代价并且与客户讨论的过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗？”。案例中如果王先生评估了修改界面的工作量并请客户确认，则有三种可能：客户预先接受延期这一后果，也就不会再质问王先生了；如果客户认为代价太大，则王先生就不必修改了；如果认为可以缩短延期时间，则王先生至少争取到了与客户协商的机会，让客户知道为此项目组需要付出加班的代价，吃个“明亏”。 项目管理软件
上述步骤完成后，要等客户确认变更再组织实施变更的相关工作。变更要按配置管理（读者可以查阅相关的资料）的规定执行，确保所有交付物的一致性和完整性。同时，对所有的变更要跟踪和验证，确保都按要求完成了。项目管理软件
最后，要特别提醒的是：要在项目开始就对项目组和客户进行宣传和培训，让所有成员都理解变更控制的重要意义；在项目过程中要对变更控制的执行情况进行审计，发现违反规定的事件要严肃处理，否则过程很快就会失效。项目管理软件
综上所述，变更控制的目的是管理变化。变更控制对项目成败有重要影响，事前要明确定义，事中要严格执行。实施变更之前有四个重要控制点：授权、审核、评估和确认；在实施过程要进行跟踪和验证，确保变更被正确执行。项目管理软件 |
