典型场景：最近比较烦，烦客户！我们现在正在给长江市政府做一个电子政务项目，其中有一项功能是网上婚姻申请登记功能。因为前一段国家政策取消了强制性体检这个环节，所以我们的工作流程也相应的变更。

没想到客户从中得到启发：我们的许多工作流程做好后改动的可能性很大（例如政策调整、部门变动、领导班子重组等），干脆给我们做成可定制的功能，我们提一个最大的功能集合，你们做好了我们自己就可以随需而变，嗯，这样好！

可是对项目组来说这可是个灾难啊！因为可定制的功能往往意味着工作量的倍增！
分析：先说说大家对于这种现象的应对方法吧。最典型的是通过与客户的沟通来解决问题。怎么样沟通呢？因为尤其是对于软件项目的合同很难在签订之初就能够精确定义的每项功能，所以靠合同是帮不上忙的。

我和许多IT公司的老总们作交流，我开玩笑说我们IT公司都是清政府。为什么是清政府？清政府的特点之一就是丧权辱国的条约太多。大家往往只有苦笑：有什么办法呀，客户着急了就是一句潜台词：做不做，不想做滚蛋！想做的公司多着呢。

所以你看合同是没用的，那怎么办呢？通常都是通过感情联络争取客户的同情。就像上面的场景中谈到的一样，明明是不合理的要求，可是客户也会狡辩呀，“凭什么不给我们做，这可是合同范围内的工作！”。因为原来只说要实现工作流，而没有谈到定制的工作流算不算。问题出来了，看看怎么办吧。

当然了，如果现在遇到类似的问题，您的组织都可以举重若轻的化解，那您就不用往下看了。我们常听到一句话就是“合情合理”，大家说这有什么好希奇的呀，老生常谈！不过这句话在软件项目的变更管理中却有独特的表现形式。从感情上与客户去沟通很重要，但是您注意到它只做了一半工作，还有一半工作需要去讲理。大家会反驳我说：讲什么理！我们的客户就是上帝，让你做你就做！哪儿那么多废话呀你。

我注意到一个社会现象：客户方的直接项目负责人从年龄上来看往往有年轻化的趋势——三四十岁居多。这些人有什么特点呢？首先从教育程度上讲他们往往都接受过正规教育，所以还比较讲理——或者是因为现在职位还不够高（开玩笑）？其次这些人是真正希望在工作上出成绩的。当项目真遇到负面的风险时，他们愿意去说服自己的领导而不是不作为。

正是基于以上两点分析，我们先来介绍需求变更管理方法——变更管理七步法。七步法印证了我经常鼓吹的项目管理三部曲：细化、量化、图形化，七步法主要验证了细化和量化的必要性和好处。我们先来看看下面这幅图：

大家一看就明白了：噢，原来是项目管理三角形，扯上它干吗呀。范围可以理解为一个项目需要完成的内容的多少，而时间质量和成本则意味着完成这么多内容的工作必须投入的时间成本以及对应的质量水平。我们再看下面这幅图：

这幅图一看就不得劲，为什么？第一副图中三角形内切于圆，而第二副图则完全破坏了这种内切关系，所以显得不伦不类。为什么应该内切？工作任务与投入应该相适应，这么一个常识性的东西在我们的IT行业中竟然被破坏得极为彻底！好，下面我们就一起来看看怎么样这样一幅项目三角形的图形来讲理！

正如我们从变形的项目管理三角形所得到启示：项目范围变了，对应的时间、质量和成本也应该发生变化！我们首先来看下面这张变更表。

表一：变更表

所以一看这个表您就明白了，其实这个表反映了一个最朴实的道理：就是项目三角形在发生变形时需要保持的对应关系。大家会说，我看明白了，可是这张表应该怎么去使用？谁去填表？什么时候填表？如果有人不愿意填，那该怎么办？下面我们分七个步骤来讨论操作中可能会遇到的问题。

第一步

首先得说到变更流程的事情。不管什么样的变更，首先都有第一步：变更申请。有人就不乐意听了：我们的客户都是“变更命令”！这个回头再说。只要有人提出变更，我们就称之为变更申请。我们来看第一节变更内容描述：大家会说哎呀，这个首先行不通！我们的客户从来都是口述，打电话或当面交流。这个我们不怕，客户只要说出来，我们是不是就可以记录下来（有人又不高兴了：凭什么他说我记呀？别急，这样做对项目组有好处）？

除非客户不做任何表示让我们猜哑谜，我们是一定能够把客户的需求变更转成文字记录。大家可能又会说，我们可以帮他们记录，可是他们不愿意签字那怎么办？签字不是关键，此处我们关心的是把变更描述记下来，我们能不能把纪录的描述给客户看，客户会不会翻脸不认账：“不是我说的！” ？不会的，果真这样我们就不做了！第一个问题是不是解决了？

往后看这可有点悬，什么叫对业务的影响呀？客户要改需求还需要理由吗？您说需要不需要？有人可能会说那是客户的事情，我们干涉不了。这个说法可是大谬不然也！业务上不需要的功能我们为什么要做？有人会说:客户不需要的功能他们会提出来给我们做吗？老大，您可是真糊涂了！你还以为客户每提一个需求都那么深思熟虑吗？所以得先让客户想一想！又有人说了，您搞形式主义！客户直接就写“如果做，对业务是极大促进；反之会对业务造成负面冲击”，你有什么办法？如果有人竟然有这样的想法，我真是替你们的领导难过：什么叫斗智斗勇？你要动脑筋呀！你能不能从客户的谈话中间去捕获信息？！你能不能去了解客户的业务了解变更的必要性？！！当然可以，要不还做什么项目！彻底成了客户的跟班了！怎么样？这个问题是不是也解决了？

第二步

我们再看第二步：技术评审。技术评审评什么？就是我们能不能做得了？比如说有这么一个糊涂客户提出说他们要求订单的最大处理时间是0.1秒，你应该做什么？直接告诉别人做不了。当然，大部分情况下技术还是可以满足新需求的。好，第二步问题也解决了吧？

第三步

好，接着来看第三步。第三步评价对工期的影响，有人可能马上会反驳说，工期评价没用，反正是自己消化掉。其实此处将工期、成本、质量都要量化的重要目的之一就是强迫我们的项目组先要想清楚，一个变更意味着什么。一定要把它落实到具体的数据上？为什么？我们在项目中、甚至工作和生活中，因为没有确切量化数据的情况比比皆是，而结果就是导致不必要的矛盾和摩擦。这也就是为什么细化、量化、图形化，在细化的基础上去量化才有意义。先看对具体活动工期的影响，可能是7天也可能是5天或其他；再看对于整体工期的影响，大家应该对关键路径的概念应该比较熟悉了。一个额外活动的工期需要10天，但是体现在整体工期却不一定是10天，还有可能是5天或者是0天，因为它有可能正好是一项非关键路径上的活动。所以这两种情况我们都要了解，简单吧？好，第三步就这么简单。

第四步

来看第四步，第四步也不会有什么歧义。因为一项变更有可能导致项目中需要添加新的人手（可能因为独特的技术背景），而现有的人员怎么样加班也是无济于事的，所以项目组人员可能会增加。在看对应的工作量增加，这个应该相对容易，估算需要几个人（很多情况会是一个人）、多长时间（天或小时），自然工作量就出来了。

小时工资率是什么？我们国内企业发工资一般会是基于工作天数的月薪，而许多外企则是基于工作小时数的月薪，所以这里有一个区别：一天可以是8个小时也可以是18个小时，难怪我们国内企业加班是家常便饭：没有请你周六周日来啊，不就是每天多那么几个小时嘛！而外企加班相对少许多：额外的工作时间要付加班费的（或许是工商局对它们看得比较严，而对我们国内的企业则网开一面的缘故吧）。说远了，小时工资率的设定与计算可依据组织的特点设定，自己搞不定请财务部门帮你出个数吧。

人时乘以小时工资率不就是人员工作量对应的成本嘛！其他的有时候可能涉及到材料费用、软硬件的采购费用、差旅费用等，我们统一将它归结为非人力成本好了。这样我们将这两部分相加就得到需求变更对应的成本增加情况。第四步也是这么一目了然，没有问题吧。

第五步

要说第五步还真不太容易给一个统一的建议，这得取决于项目组的情况。如果项目组没有量化的历史数据参考，只能以定性的方式去描述需求变更对于项目不同阶段的影响。例如我们在测试阶段的后期实施一项大的变更，那么它对测试阶段的质量影响是可以想见的：因为引入新功能或更改功能，一定导致更多的缺陷，而在回归过程中如发现新的问题需要修改的话又可能带来更多的问题。所以对于测试阶段的质量是负面的。对于产品运行阶段的质量影响也是显然的：系统的稳定性、可靠性、安全性可能都会受到波及。

当然，如果项目所在的组织有些历史数据作参考，那判断起来就容易多了。如果变更的需求是30个功能点,又假定测试阶段缺陷密度是0.4/FP到0.8/FP之间,我们容易推测变更将导致增加的缺陷个数介于12到18个之间；而如果残余缺陷密度是0.02/FP到0.05/FP之间，则上线后暴露给客户的问题数目为0.6个到1.5个之间，也即一到两个。

我们将对质量的影响是不是也可做相应的分析？当然喽！

第六步

这个小节关注的是风险，变更往往意味着更多的功能，更多的功能意味着更多的工作要做，因而面临更多的变数，也即我们就常所说的风险。比如说变更往往伴随着工期的延长，而对于在外地开发的项目此种情形尤其有可能导致项目组成员普遍的厌倦情绪，对应的风险表述就是项目组士气低下，导致工作效率下降，甚至会引起人员的流失，对于项目组来说不得不预见这种类型的风险，所以变更分析应该做出对应的风险分析。

第七步

这一步就很简单了，主要是根据前面的给定的各方面信息权衡以后做出是否变更的决定。有人又说了：才不是呢，如果是需求变更，那一定得客户签字，客户如果不签字，我们一点招数都没有！我们再一次退而求其次：能不能把客户的名字写上，表明他（她）知晓这件事情？应该是可以的吧。

至于表头信息，我想应该没什么问题，所提供的相关信息主要是供以后做统计分析之用。

好，到此为止，我们介绍了软件需求变更管理七步法。