需求变更的代价

需求变更的代价让我们先来看一个需求变更的典型案例：Steven刚出任项目经理，并承接了一个中型软件项目。

公司再三叮咛他一定要尊重客户，充分满足客户需求。

项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。

Steven动员大家加班，保持了项目的正常进度，客户相当满意。

但需求变更却越来越多。

为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。

程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。

很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。

版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。

但在进度压力下，他也只能佯装不知此事。

但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。

而这还只是噩梦的开始。

一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。

虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。

更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。

随后发生的事情让Steven更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。

Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。

最终客户决定调整所有界面，Steven只好立刻动员大家抓紧时间修改。

可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。

对软件需求和需求变更的理解软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，它不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的。

软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素，因此对于需求分析和需求变更的处理十分重要。

需求变更会给项目带来巨大的风险,会导致项目的成本费用增加、开发周期延长、产品质量下降及团队工作效率下降等不良后果，因而软件开发项目中应该尽量减少需求变更的出现频率。

然而由于政府对特定软件的相关要求、用户部门市场战略的调整、工业界的发展等因素都可能带来需求的变更，而这些因素往往不可避免。

在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。

因而，对于需求变更应该正确的对待，尽量将其负面影响降低到最低。

需求变更的原因需求包括业务需求、用户需求和功能需求。

业务需求（BusinessRequirement）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（UserRequirement）描述了用户使用产品必须完成的任务，功能需求（FunctionalRequirement）定义了开发人员必须实现的软件功能。

会导致需求变更的原因会有很多，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。

在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。

在软件系统开发过程中，有很多问题都是由于在需求分析阶段没有正确地收集、编写、协商、修改产品真实需求而产生的，造成这样的状况有以下几方面的基本原因: （1）对需求的理解分歧当客户向需求分析人员提出需求的时候往往是通过自己的想法用自然语言来表达的，这样的表达结果对于真实的需求来说是一种描述（甚至只是某个角度的描述），远远不能保证这样的描述可以得到百分之百的正确理解，也许在同客户交流的第一时刻就埋下了理解分歧的种子，打一个比方说客户说我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子，分析人员想，哦，墙、扇子、柱子、绳子这些我都知道，但是真的画出来的时候客户当然会跳起来了！这是理解分歧的问题，一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关。

（2）系统实施时间过长一个大中型系统的建设可能要延续一段时间，当客户提出要求之后，他当时并不能看到系统的运行情况，当双方认为理解大概没有分歧的时候（事实上还会有个Deadline），开发方就开始工作了。

当客户拿到差不多可以试用的产品时他可以实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能提出需求变更要求。

（3）用户业务需求改变当前客户的运营情况不确定，有可能客户行业的竞争度高，需要随时作出调整和反应，那么他们自然会经常提出需求变更的要求；也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发方更是需要随时准备应变。

（4）系统正常升级有可能是来自开发方自身版本升级或性能改进、设计修正的要求出现需求变更，这时更是无法绕开这个问题的了！所以说就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以不要梦想那么理想的需求分析，当你开始一个项目的时候就应该意识到，客户需求变更一定会有的，那么对于这样的现状，我们该怎么办呢？客户是上帝，难道我们就象以前一样，跟着客户的需求不停地修改软件，到最后工期延长，员工疲惫，成本成倍增长，客户满意度降低，原来的设计也会改变得支离破碎，系统难以维护？需求变更的代价一般来讲，需求的变更通常意味着需求的增加，需求的减少相对很少，而且处理需求减少方面的问题也比较容易。

当客户提出新需求的时候，项目开发人员应该分析这些新需求对项目现阶段带来的风险，得出双方实现变更需求的需要的成本，包括时间、人力、资源等等方面。

变更都是有代价的，应该评估一下变更的代价和对项目的影响，在评估代价并且与客户讨论的过程中，要让客户了解变更的后果，变更之后面临最大的问题就是项目延期，让客户一起做判断：“我可以修改，但您能接受后果吗？”。

现在会出现三种可能：客户接受延期这一后果，开发人员按客户要求做出相应修改，让客户知道为此需要付出延期的代价；如果客户认为代价太大，那开发人员就不必修改了，可以记录下需求，待到下一版本再做修改；客户不接受变更的代价，导致项目夭折。

如果客户不知道你为变更付出的代价，对你的辛苦便难以体会，以致没完没了的提出新的变更。

减少需求变更正如前文所说，需求变更往往是不可避免的。

通常是项目负责人员花费了大量的气力避免需求变更，可最后需求变更总是会出现。

但是这并不意味着项目开发人员不应该做这方面的工作，项目开发人员对于需求变更的正确态度应该和软件测试的态度一样，在需求变更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。

项目开发人员切忌在项目设计之前试图消除需求变更，这样做往往费力不讨好。

相比于需求开发人员而言，客户可能对需求变更认识不足，认为他们出钱，程序员或软件开发公司就要为它服务，因此客户对需求变更往往更加肆无忌弹，将需求变更视为儿戏，随个人喜好随意变更需求。

因此，在需求人员同用户代表或用户部门主管人员接触时，就应该向他们挑明态度，和他们协商好，特别是应该让他们清楚软件的定价应该与软件的功能相关，以及需求随意变更所带来的风险的承担者应该由客户和项目开发者共同承担。

通过这样做，让客户在需求分析之前就尽量对他们所需要的功能有个整体的了解和确定的思路，而不是等到程序员开始编码了，才提出以前原本在需求分析时就可以提出的需求。

让客户明白减少需求变更的重要性后，需求分析人员应该采取合适的方法同客户交流，帮助他们明确他们的需求。

需求分析人员和客户的关系不应该仅仅是记录人员和需求提供者，他们的关系应该更多的是战略合作伙伴关系。

虽然需求分析人员和客户存在着服务商和顾客的关系，但是他们有着一个共同的目标：开发出适合客户需求的软件，因此需求分析人员除了记录客户提出的需求以外，还应和用户讨论，提出一些建议，使用合适的工具帮助客户提出需求。

在需求分析时，尽量多的召集需求研讨会，邀请开发人员和客户共同协商探讨，在研讨会上允许任意的提出需求，并将这些需求整理成档后由客户代表和需求分析人员共同商议可选的功能，这样能够尽量使得需求完备。

在需求开发时，开发人员采用原型的方法启发客户思考功能需求也不失为一个好办法。

虽然需求不可能是完备的、变更不可能没有的，但是在项目开始设计时使得需求尽可能完备还是应该的，也是值得的，完备需求的过程也就相应的减少了因为需求不清楚而产生变更的几率。

如何控制需求变更按照现代项目管理的概念，一个项目的生命周期分为启动、实施、收尾三个过程。

需求变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期的全过程。

为了将项目变更的影响降低到最小，就需要采用综合变更控制方法。

综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。

进行综合变更控制的主要依据是项目计划、变更请求提供了项目执行状况信息的绩效报告。

为保证项目变更的规范和有效实施，通常项目实施组织会有以下几种措施：（1）项目启动阶段的变更预防对于任何项目，变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段就开始了。

对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理扯皮的幌子就越少。

如果需求没做好，基准文件里的范围含糊不清，被客户抓住空子，往往要付出许多无谓的牺牲。

如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。

这个时候千万不能手软，这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。

相对于需求来说，什么WBS、风险管理、计划进度都是次要的，只要需求做好了就会一帆风顺。

（2）项目实施阶段的需求变更成功项目和失败项目的区别就在于项目的整个过程是否是可控的。

项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的”。

项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。

控制需求渐变需要注意以下几点：需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。

所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。

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

小的需求变更也要经过正规的需求管理流程，否则会积少成多。

在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。