如何终结需求变更之痛?

文：《赢》35期

作者：鼎捷数智 | 发布时间：2013-11-22 13:34:37

　　英国有位经济学家说过，任何变更，即使是向好的方向变更，也总是伴随着折磨与痛苦。这也恰好一语道破了企业信息化建设过程中需求不断变更的苦恼。它不仅困扰着软件厂商，对企业客户而言，更是挥之不去的烦恼。

　　案例中恒远钢铁厂ERP项目的需求变更状况也是如此。

　　难言之痛，需求变更不断

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

　　业界很早就已流传这样一句话：上ERP找死，不上ERP等死。其实何止ERP如此，中小型的IT项目如OA、CRM等，其成功率也不足55%，客户满意率不到30%，有不少项目成了“食之无味、弃之可惜”的鸡肋工程。何以如此?需求不断变更、盲目更改项目内容使得项目难以顺利验收、结案，较终导致了“始乱终弃”状况的发生。

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

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

　　然而，解决需求变更尤其是解决即将验收项目的需求变化，实际上是一项复杂重大、事关全局的工作，必须引起企业一把手、CIO和项目组成员的高度重视，积极应对，千万不能敷衍了事，不然较后只会马失前蹄、败走麦城。那对于项目需求变革，企业可以有哪些应对之道呢?

　　诊治痛点，多管齐下促双赢

　　无疑，每做一次项目计划变更，都会影响到日后的成本估算、活动顺序、行程日期、资源需求及风险控管的决策，因此甲乙双方的项目经理、CIO都必须以整体的视野、统一的要求，对变更进行控制、确认与纠正，并推动项目朝着双赢的大方向发展。

　　◆ 充分做好前期的需求调研、系统培训等工作。

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

　　◆ 建立变更控制组织系统。

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

　　◆ 严格规范变更流程。

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

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

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

　　◆ 选用适当的开发模型防止多变更。

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

　　◆ 通过合同约束，建立有效的解决冲突机制。

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

　　◆ 验收与发现、检验需求并举。

　　许多中小型的ERP项目较好是成功切换后，录入一个月以上的重要数据，并上线运行一个月时间，看看有没有出现新问题和新需求，如没有就可验收、签案。毕竟一个月只是相对短的系统周期，如果系统在短周期内都没有跑顺，就更别说一年这样的长周期了。如果ERP系统能做到平稳运行一两个月以上，并能准确导出各类月度报表，系统应用和各项业务操作基本正常、顺畅，通常可认为系统已达到效果或是达到了先前预定的目标，也说明企业不再有管理流程、业务流程层面的新需求与变更了，系统项目可以算是上线成功。

　　◆ 区别对待，折衷求同。

　　随着项目进展，不少企业用户会不断提出一些在项目实施组看来确实无法实现，或工作量比较大、对项目进度有重大影响的需求。如在沟通协调后，用户仍坚持实施新需求，可以建议用户将新需求按重要性和紧迫程度划分档次，作为需求变更评估的重要依据。如遇到有些需求无法在短时间内解决的情况，不要让项目因此陷入僵局，而要通盘考虑有否临时的折衷方案可以先“应付”，如让用户先使用现有系统，之后等技术解决或二次开发成功后再为用户免费升级安装，以全力确保项目继续往前走。

　　面对当前大有成为“万恶之源”之势的项目需求变革，不管是软件厂商还是企业用户，都需要通过各项行之有效的措施，把需求变更基本置于自己的控制之下，使其发生机率降至较低。一旦发生了需求变更，则要采取有效的补救措施，把其为IT项目带来的损失减到较小。

上一页：企业快速成长如何赢得供应商支持?

下一页：物流管理系统需求分析