【IT168信息化】英国有位经济学家说过，任何变更，即使是向好的方向变更，也总是伴随着折磨与痛苦。这一语也恰道破了信息化建设过程中需求不断变更的苦恼。这种烦恼不仅是软件厂商实施方所有的，企业客户也照样有这烦恼。

　　需求变更不断，难言之痛

　　一旦需求变更，往往会引起重估、返工，你不得不修改你的设计，重写你的代码，修改你的测试用例，调整你的项目计划等，从而影响软件项目的范围、时间、质量和成本等多个要素，如果控制不好，还会导致项目范围蔓延、进度延迟、质量不过关和成本严重超支等诸多麻烦与问题，甚至因过多的分歧、变更而半途而废。因而需求变更在很多软件项目中都是一件头疼的事情。

　　时常听到这句业界常言——“上ERP找死，不上ERP等死”。其实何止ERP如此，中小型的IT项目如OA、CRM等，其成功率也不足55%，客户满意率不到30%，有不少项目成了“食之无味，弃之可惜”的鸡肋工程。何以如此?需求不断变更、盲目更改项目内容导致项目难于验收、结案，“始乱终弃”。

　　软件项目变更原因，总结起来主要有：国家政策不断改变，三天两头一个红头文件，使许多企业单位的财税政策、产品标准、服务规范等也要跟着变化，用户单位的业务内容、流程管理也要跟着变;客户可能一开始对项目内容与需求没有形成初步看法，或者一开始没有想法但随着项目的进行、参考其他单位的好做法，就产生了一些新想法、新需求;或因为业务手续太繁琐、流程太复杂，引起用户反感，要求修改;软件商系统员经验不足，没有捕获到用户的关键业务需求或者用户整理需求能力弱，遗漏了关键的需求点，导致需求不合需要重改;或可能是数据易丢失，也可能是系统不稳定，还可能是兼容性问题，用户反应强烈，要求修改，等等。

▲

　　可以说，从IT项目的实务看，几乎没有一个项目能够百分之百按照原订计划进行，需求变更是不可避免的，也是正常反应，但如果需求无序无度、变更无常，就易造成甲方、乙方的矛盾、对抗，无疑是种内耗，成了信息化建设的绊脚石。IDC机构调查数据显示，99.5%的信息化建设都有过需求变更，需求变更达到“严重程度”达到38.2%，需求变更“无度”达到甲、乙双方无法容忍乃至项目破裂的程度也占11.3%，只有28.6%的项目需求是甲、乙双方能协调、满意。

　　所有说，有时项目需求的变化好比是“万恶之源”，一旦发生了需求变化乃至无序变更，将为项目的正常进展带来了不尽的麻烦。因此解决需求变更尤其解决即将验收、签案的项目的需求变化，实际上是一项非常复杂重大、事关全局的工作，必须引起企业一把手、CIO和项目组成员的高度重视，积极管理、应对，千万不能虎头蛇尾、敷衍了事，最后马失前蹄、败走麦城。那么怎样来解决这个问题?有哪些应对之道?

　　如何诊治需求变更不断之痛?

　　每做一次项目计划变更，都会影响到日后的成本估算、活动顺序、行程日期、资源需求及风险控管的决策，因此甲乙双方的项目经理、IT经理都必须以整体的视野、统一的要求，对变更进行控制、确认与纪录。而需求变更的控制关键在于建立相应的控制组织、变更控制系统以及规范变更流程，主要有：

　　充分做好前期的需求调研、系统培训等工作。深入企业一线，全面调查研究，最大程度地挖掘企业用户的潜在需求，发现可能要需求变更的地方，让企业用户尽快做出是否要进行需求变更。一般把需求变更或者新需求的确认最迟时间定在系统培训阶段。也就是说，在系统培训完成后、开始准备双线并行前，企业用户还可以提出需求变更的申请，但是，当系统开始双线运行时，就不允许用户再提出需求变更等类似的请求了，如编码的内容和规则、表单的数量和格式、数据流转和统计方式等，否则就要付出变更的代价。

　　建立变更控制组织系统。项目启动时，尽可能地与客户沟通，尽快建立正式的对变更进行控制的组织，通称变更控制委员会(CCB)，成员可包括双方高层(挂名)、甲乙双方的项目负责人、相关的需求负责人等，负责裁定接受变更内容、方法、步骤等。建立该系统的目的是统一管理需求变更和跟踪变更的状态，便于项目组测试人员、开发人员、系统分析员以及PM相互之间的沟通和交流。建立变更控制系统目的不是让用户不提出变更，而是让用户不轻易、随便的提出变更。

　　严格规范变更流程。一旦需求分析阶段结束，此后如果用户要求有新的需求加入即将交付的软件系统中，甲乙双方的项目组或变更控制委员会，要根据角色定义，确定变更流程，规定严格的变更控制流程，并控制新需求提出的频率。

　　1)变更申请。系统界面如按钮的位置、字段的位置的细微调整，不涉及到业务规则，对基线基本没有影响的变更，由测试人员直接在变更控制系统中提出;其他如操作风格的较大变化、编码内容、业务规则的变化等，均要求用户提出电子和书面的需求变更单。

　　2)变更评估。由项目组或变更控制委员会组织人员对变更进行变更的合理性分析，变更替换方案分析，工作量的估算以及涉及什么模块、影响什么模块等影响分析。

　　3)变更实施。由测试人员在变更控制系统中填写变更信息，由系统分析员填写处理方法和影响分析后交由开发人员实施。

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

　　选用适当的开发模型防止多变更。采用建立原型的开发模型比较适合需求不明确的开发项目。软件供应商研发人员先根据用户对基本需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向用户最终、比较全面的需求靠拢，从根本上减少需求过多变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制较为管用。通常情况下，原型之后的需求沟通就实际得多，双方的理解迅速向一个全面折衷的方案贴近，一个可以指导研发过程、有针对性的需求说明书就可起到重要作用。

　　通过合同约束，建立有效的解决冲突机制。用户、开发商在实施、验收软件项目过程中难免会发生冲突，而需求变更给软件项目建设带来的影响也是有目共睹，从而可能让项目建设偏离轨道。关键是事先是否有明确的项目目标和项目要求，是否建立起有效的冲突解决机制。所以双方在签订合同时，可以增加一些相关条款，主要是要明确今后双方责权利关系，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程，否则自担变更的代价;而企业用户，也可对将来可能发生重大事件或不可抗拒事件所引发可能的实施超期、费用超支、产品价格调整以及服务收费超标等事项、行为及其权责做出预测，并有效约定，从而使信息化项目从一开始就按双方预定的规道行驶，互为制约、协调，避免再发意外。

　　验收与发现、检验需求并举。大型的ERP项目不少是边实施边验收，然后再发现新问题新需求，再进一步返工完善，一步一步地把项目向前推进，但许多中小型的ERP项目最好是成功切换后，录入一个月以上的企业重要数据，上线运行一个月时间，看看有没有出现新问题、新需求，如没有就可进入验收、签案。毕竟一个月才是一个小的系统周期，如果小的周期都没有跑顺，就更别说一年这样的大周期了。如ERP系统能做到平稳运行一两个月以上，能够准确导出各类月度报表的时候，系统应用和各项业务操作基本正常、顺畅，通常而言，可认为系统已达到的效果或者是达到了先前预定的目标，也说明企业不再有管理流程、业务流程新需求与变更了，系统项目可算上线成功了，可以放心验收、签案了。

　　通过以上几种手段，如执行实施到位，基本可以有效地把变更置于控制之下。

　　项目需求变更的几项须注意事项

　　充分交流、协商。变更管理的过程很大程度上就是用户与开发人员的交流过程。软件供应商项目经理、技术经理必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发方应郑重向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果，全面权衡轻重。

　　区别对待，折衷求同。随着项目不断进展，不少企业用户会不断提出一些在项目实施组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。如果用户仍坚持实施

　　新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的重要依据。如遇到有些需求无法在短时间内解决、需要花个把月才能解决的时候，那就不要硬拼，不要让项目因此僵住，而要通盘考虑一下，有否临时的折中方案可以先“应付”一下?如让用户先使用现有系统，等过一段时期，技术解决或二次开发成功后再给用户免费升级安装。

　　需求变更要尽早。建房子，若在房子快造好时，却发现原先设计不对，需要推倒重来，那成本与时间的浪费就大得不得了。对于软件项目而言，也是同样的道理。若你项目快要完工时，才发现原先的需求有纰漏、缺失，需要变更重设时，那损失就会大了。因此，项目越接近收尾阶段，再进行需求变更的话，给甲乙双方造成的损失则越大。因此需求变更要趋早，早提出早好。

　　总之，需求的变更，对于项目的影响是非常大的。但是，就如同天要下雨一样，我们难于从根本上加以消除。我们所能够做的，就是采取更多行之有效的工作，把这个几率降至到最低，或者采取一些补救措施，把需求变更给软件项目带来的损失减到最小。