浅议IT项目需求变更问题与对策

提要IT项目管理是项目管理在IT领域的应用。由于信息技术行业的特点，IT项目管理除了具有项目管理普遍特性外，还具有需求变化快、需求变更频繁等特点，造成IT项目管理难度相对较大、项目成本、进度控制不力等现象，因此对IT项目的需求管控和项目实施过程中的项目需求变更对策就成了IT项目管理操作上的一个重点，也成为广大IT项目经理在项目管理方向上探讨的一个焦点。

关键词：项目管理；需求管控；成本控制

中图分类号：F27文献标识码：A

随着信息时代的来临，IT行业发展迅猛，各行各业都试图通过IT系统支撑其业务发展，提高效益。但从整体看，IT行业项目管理程度较低，据了解，国内真正实现或基本实现项目目标的IT项目占比很小。究其原因，不少失败IT项目在项目管理方面都不同程度地存在着这样或那样的问题，而在这当中，有很多都是对IT项目实施中的需求变更处理不当造成的。

一、IT项目需求变更问题

完整的IT项目需求管理一般包括业务需求、用户需求、功能需求、非功能需求和需求分析报告等五部分内容。其中，业务需求来源于业务发展需要，用户需求来源于用户实际功能要求，功能需求来源于业务部门管理的流程及思路，非功能需求来源于用户的习惯爱好，需求分析报告则是IT人员对上述内容的汇总。但在IT项目管理实践中，往往不能全面地获得上述资料，原因很多，比如用户对未来业务预估并非准确、用户本身也许并没有完整的阐述其需求等，这一切的结果，就是项目经理时刻面对着用户不断提出的需求变更。为应对这些需求变更，项目经理只好在实施中不断调整项目计划，其结果就造成了项目成本难以控制，项目交付日期不断推延，以至于IT项目管理当中流传着这样一句笑话：做IT项目哪有不延期的。

客观地说，需求变更这种情况的出现几乎是必然的，因此如何解决需求管控，并对其进行有效处理就变成了IT项目经理的必修课。IT项目需求之所以变化，是IT项目需求本身的复杂性造成的。与传统项目比较，IT项目的需求相对模糊，变动较大，主观随意性较强，具体体现在以下三个方面：

1、需求的准确描述。需求来源于客户，但很少有客户会很认真地准备需求文档。笔者在项目当中经常见到的情况都是甲方简要的提出自己的需求（三言两语而已），或者甲乙双方在需求沟通会上做一个业务设想的沟通交流，这样造成了需求最初来源的简易化和随机化。一般情况下，乙方会根据沟通会上的情形对甲方需求进行还原，最终形成上百页的需求文档，并交由甲方签字确认，以此作为需求的文字来源。如此操作在表面上看来是完备的，但实际工作当中，需求往往来源于甲方不同部门、不同层次的业务人员，不同的人员对业务的理解自然也带有自身的本位想法，对系统的关注角度也不尽相同。这可能就此造成了需求的矛盾与歧义（此问题是可以在甲方层面上协调解决的）。甲方确认需求当然是毫无疑义的，但甲方是否系统的、全面的审阅了乙方还原后的需求汇总，那就不得而知了。

同时，甲乙双方对于需求的理解也有一定的差距，比如作一个登录用户的认证功能，对于甲方来说可能有自己先入为主的认识，很可能乙方也已经有了自己的理解，在这样的沟通过程中，甲乙双方很可能就迅速达成了“共识”，当按照乙方理解开发出来的最终产品呈现在对此功能已经有了设想的甲方面前的时候，此功能的需求文档就成了双方掰持不清的糊涂账。

另外，由于甲乙两方在业务知识层面上属于两个不同的方向，这样很可能造成需求的完整度不足。一般来说，甲方对业务更为了解，技术业务层面了解相对较少；反之，乙方亦然。这样就造成了双方沟通需求的时候，甲方提供的需求完整度不足，比如，甲方提供了必须实现的业务需求，乙方忠实地作了记录，并根据沟通了解了甲方的需求内容，但甲方只是提供了自己的需求、想要的功能，要知道系统是由多个功能模块组成的，甲方很可能把一些其自认为是常用的功能模块作为必须功能而未作阐述，这就造成了需求功能的缺失。

需求的详细准确程度也是一个大问题，在明确需求的时候，往往甲乙两方只是对某一需求达成了共识，但可能并不明确这个达成共识的需求具体如何实现，也许乙方的实现并非甲方所愿，如甲方要求实现某种数据检索，乙方的实现方式只能支撑低量级的数据量，碰巧实战当中要检索的数据量是天量级的，这就造成功能失效。

2、明确需求工期不足。需求的生成也是需要工期的，对于甲方来说，需求由乙方前来调研，开完需求调研会，再开几个碰头会，需求调研应该就算完成了。对于乙方项目经理来说，这种工作恐怕只是开始。如前文所述，需求的准确获取需要大量时间，还需要相当一部分人力资源，对需求进行推敲、确定。但在实际工作当中，甲乙双方的上层很难认同这种耗费时间且没什么直接效益的工作，如此就造成了如下现象：项目经理为保证需求的准确性拼命拖时间；甲乙双方上层因为见不到成果不断对项目组施加压力；由于需求的反复沟通修改，项目组成员也对此感到疲乏厌倦，希望尽快了结此项工作；多方权衡的结果，很可能就造成项目经理的退让。在这样情况下诞生的需求文档，其有效性、稳定性就有可能是有限的。

3、项目需求变化极快。不同于工程类项目，IT项目的变化极快，尤其是互联网类型的项目。前文中我们了解了需求不完整这一情况，需求调研的不完备、不准确都会给后边的项目实施带来变数。在互联网时代，业务的诞生几乎是爆炸式的，新的业务往往会对现有的项目造成影响，甚至是颠覆性的影响，这也给项目实施带来困难。

在项目实施当中，随着时间的推移，用户、业务都在发生转变，由于操作人员、系统、业务流程之间的关系发生变化，业务发生变化，自然需求也跟着变化。在互联网项目当中，往往某些项目带有突发的革命性需求，如甲方设计一个搜索网站，必须保证与业界同类型的网站保持一致，若业界出现了一个全新的极受用户欢迎的业务，那就必须把此项功能加入，否则可能本项目就算完成，也不能达成甲方项目设计的初衷。此案例中的需求变化对项目造成的影响可以说是颠覆性的。

二、IT项目管理需求变更对策

以上几点是笔者分析项目需求变化的原因，对于这样的需求变化，必须有对于需求变更的管控办法或者处理策略，否则这些需求变更造成的项目成本增加、进度推迟恐怕会毁了项目实施。笔者认为，对于上文所提到的项目需求不完备等情况，由于现时情况不太可能得到彻底的解决，因此只能在后续的项目需求管控当中进行补救处理。

1、需求评审流程化处理。对于需求的变更、增添认定均需要走专门的流程。可能有不少同行感觉这样要求有点多余，但笔者认为新的需求变化都是在业务演进过程中逐步出现的，对于需求变更的评审，有助于项目组加强对业务需求本质的把握与理解，有可能通过对新需求的评估，推断出业务的演进方向，或者增加项目需求的完备程度。同时，对需求的评估也可以使项目组更好地把握现有的工作进展情况。

2、需求确认。任何需求的变更，都不可避免地影响到项目的工作量，进而影响到进度，且项目需求来源于甲方，因此需求的确认必须有甲方的签字确认。对于乙方来说，所有的这些需求的实现都是有投入成本的，这些成本的来源就是甲方的“签字”确定的需求或需求变更。笔者曾经历过一个IT项目，在该项目实施过程当中，为避免风险，邀请一个甲方业务人员作为业务指导，项目期间项目组对甲方代表的意见言听计从，根据其要求对项目的某些部分进行大量变更，因此延误了项目工期，且发现项目上线后，某些其建议功能并不为甲方整体认可，为此还得修改，其间造成了不少无用的工作，此部分项目投入没有任何意义。这一案例表明，项目需求的变更应经过甲方官方同意，若甲方业务决策人员知悉此问题，就可能避免这部分无效投入。

3、项目计划冗余准备。项目计划冗余准备是指在项目计划当中，对项目投入准备一定比例的富余量。在具体项目实施项目中，项目变更几乎是不可避免的，这些变更包括需求变化、风险的发生等多种情况，若在项目收支许可的范围内做一定的冗余准备，在较小的变更发生时，就可以通过项目计划当中的富余资源处理，从而保证项目实施进度。平心而论，这种操作办法是要让乙方投入更多的成本来完成项目，对乙方不太公平，但在商业项目当中，若能尽早完成项目，就可以保证乙方的大部分利益，适当的平衡一下投入上的取舍，也是很好的解决办法。同时，本办法也适用于项目的风险处理。

4、商务处理办法。笔者曾经见过一个工程项目，在此项目合同中确定了工程的基本工作量预估，并明确当实际工作量超过预估工作量的10%以内时，由乙方自行承担；若超过10%限度，根据超出工作量多少，结合合同约定的单价进行处理。此案例给了我们另一个解决项目变更的办法：通过商务合同中对工作量的约定，来保障项目的实施。案例当中的实际工作量异常，可视为IT项目当中的需求调研不完备，或是需求变更造成的实际工作量增加，若在商务合同当中明确有关工作量、超额工作量的约定，就可以按照合同约定解决由于需求变更而造成的项目成本、进度问题。

（作者单位：北京交通大学经济管理学院）

主要参考文献：

[1]吕凌.IT项目行业管理现状以及发展趋势[J].高科技产业，2004.4.

[2]凯西・施瓦尔贝（美）.IT项目管理[M].北京：机械工业出版社，2001.