项目需求变更的“痛点”和应对之策

一谈到需求变更，很多开发人员都面露难色，似有一肚子的苦水不知向哪里倒。有人调侃道：杀一个程序员不需要枪，改三次需求就可以了!想想也是，程序员辛辛苦苦编写的代码因为一个变更就白费了，得不到成就感，而且可能又要加班加点，刚定好的计划又要调整。此时，开发人员会抱怨，产品经理或需求人员也会觉得委屈：客户要改，我也木有办法呀。而客户呢，有时候也同样不满意，觉得做出来的软件不是他原本想要的，进度已经一再延误了，还想加钱?看来，需求变更会给各方带来“痛点”，处理不好就会出现没有赢家的局面。

记得有首歌的一句歌词是：“不是我不明白，这世界变化快。”正好可以用它来解释需求变更的外部环境原因。当前，国际、国内环境都在发生着剧烈而深刻的变化，必然会带来政策的调整、流程的再造、业务规则的修改，而科技进步与发展也是日新月异，这也必然催生新的业务、新的需求，因此大部分项目发生需求变更是无法完全避免的。导致需求变更的外部原因虽无法把控，但我们可从客户方、开发方的内因角度来分析一下，寻找问题的症结，以便能“对症下药”，找到应对之策。

原因一：对需求的理解不到位或存在分歧

当客户向产品经理或需求人员提出需求的时候往往是用自然语言来表达的，很难保证这样的描述可以得到完全正确的理解，有可能双方交流的第一时刻就埋下了理解分歧的种子，为后续发生变更埋下了伏笔。当然这也跟需求分析人员的知识、背景，还有客户表述的标准程度、双方的交流情况有关。特别是对于较为复杂的项目，如果只提供给客户上百页的需求文档，没有界面原型、用例图或演示系统等工具的支撑，很难想象用户会逐字逐句去阅读文档，即使有需求评审会议，也通常会流于形式。

原因二：用户对需求的认识在不断加深

软件项目的用户需求本身就具有模糊性、不确定性、主观性等特点，想一步到位获取到准确定义的需求是很困难的。客户在进行需求评审时可能当时提不出明确的修改意见，但是当拿到差不多可以试用的产品时，通过实际操作就会对系统的界面、功能、性能等有切身的体会，这时就很可能提出新的要求。另外，需求的变化往往并不是突发的、颠覆性的，最常见的是项目需求的渐变(Project Scope Creep)问题。特别是大中型系统的建设通常都要延续较长一段时间，更要对此给予重视。

原因三：开发方自身要求变更

就开发方本身而言，来自线上问题的处理、技术架构升级、性能改进等要求也有可能导致需求变更。

由以上分析可以看出，就算需求人员与客户(或用户)之间不存在理解上的分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务或环境也会变化，这些都是无法避免的。为了解决这一问题，需要采取有效的方法和步骤来控制变更，尽量将其负面影响降到最低。没有明确、规范的需求变更管理流程，就会使需求变更变得随意、泛滥。并不是所有的变更都要修改，也不是所有变更都要立刻修改，需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。比如，对于界面风格问题，就可以视情况先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要有严格把关流程，有些需求看起来是小需求，工作量不大，但殊不知很可能是“牵一发而动全身”，实际上开发人员要耗费比较长的时间去解决客户没有考虑到的细节问题。

下面介绍的是由项目管理专业人士总结出的“需求变更管理七步法”，希望能抛砖引玉，通过大家的集思广益来总结出更符合公司实际、更有效的应对需求变更之策。

第一步 先把理由说清楚

不管什么样的变更，首先都有第一步：变更申请。通常客户提出需求的渠道是非正式的，例如口述，打电话或当面交流，那就先由需求人员把变更描述记下来，请注意：一定要有书面的记录。然后，我们可以把需求变更申请的描述提交给客户，由客户进行签字确认。

同时，要引导客户说明进行需求变更的理由，要描述清楚如果变更被接受，对业务的正面促进，如果变更被拒绝对业务的负面冲击。对于有些强势的客户，可能直接说“就按我说的办”，这时就需要需求人员动动脑筋，从客户的谈话中间去捕获信息，从客户的业务角度出发去了解变更的必要性。

第二步 能否实现作评估

变更控制小组(Change Control Board，简称 CCB)要对需求变更实现的技术可行性进行分析和评价。是否要成立CCB可视公司的具体情况而定，对于简单的需求变更，由项目组进行分析即可，但对于较复杂的需求变更，就至少需要“技术大牛”和相关负责人对可行性和影响进行评估了。

第三步 可以实现看进度

这一步是评价对工期的影响，先看对具体活动工期的影响，再看对于整体工期的影响，一定要用数据来说话。有人可能马上会反驳说，工期评价没用，反正是自己消化掉。其实从这一步到第五步将工期、成本、质量都进行量化的重要目的就是强迫我们的项目组先要想清楚，一个变更意味着什么。如果自己心里都没数，又怎么去和客户交流?我们在项目中、甚至工作和生活中，就经常由于没有确切量化数据的支撑而产生不必要的矛盾和摩擦。

第四步 变更成本要算足

有些变更不仅会增加项目工作量而且会导致项目中需要添加新的人手 (可能因为独特的技术背景)，而现有的人员怎么样加班也是无济于事的。因此，项目负责人在接收到变更请求时，不仅要考虑工作量所增加的人天数，还要考虑现有人力资源能否满足要求。

第五步 质量不得有马虎

变更会带来潜在的质量问题是毋庸置疑的，而且问题可能会在设计、编码、测试和运行各个阶段引入。如果组织有量化的历史数据作参考(比如功能点、缺陷密度等),则开展变更所导致的质量问题分析相对容易些，否则只能进行一些定性分析了。例如要在测试阶段后期实施一项较大的变更，通过定性分析可知：由于引入新功能或修改功能可能会导致更多的缺陷，而在回归过程中如发现新的问题需要修改的话又可能带来更多的问题。

第六步 风险再细分

由于变更往往意味着要实现更多的功能，更多的功能意味着更多的工作要做，因而面临更多的变数，也即我们经常所说的风险。比如说变更往往伴随着工期的延长，而对于在异地开发的项目遇到此种情形更有可能导致项目组成员普遍的厌倦情绪，对应的风险表述就是项目组士气低下，导致工作效率下降，甚至会引起人员的流失。对于项目组来说，必须要预见这种类型的风险并制定相应的措施。

第七步 主意大家拿

最后一步是根据前面给定的各方面信息综合权衡以后做出是否变更的决定。实际上，通过实施上面六个步骤已完成了需求变更理由的描述、技术可行性分析和进度\成本\质量\风险的影响分析，这时再让相关决策人员来拍板就变得相对容易了。

综上所述，用户需求作为整个软件项目中最关键的一个输入，需求变更管理能否做到位自然就成为决定软件项目成败的关键因素之一。对于需求变更，除了从分析和设计的角度通过采用合理的分析和设计方法适应需求变更以外，还应该改变我们的意识和对需求变更的理解，主动做好对需求变更的控制和管理，减少“需求变更之痛”。