第二步
　　我们再看第二步：技术评审。技术评审评什么？是我们能不能做得了？比如说有这么一个糊涂客户提出说他们要求订单的大处理时间是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个之间，也即一到两个。
　　我们将对质量的影响是不是也可做相应的分析？当然喽！
　　第六步
　　这个小节关注的是风险，变更往往意味着更多的功能，更多的功能意味着更多的工作要做，因而面临更多的变数，也即我们常所说的风险。比如说变更往往伴随着工 期的延长，而对于在外地开发的项目此种情形尤其有可能导致项目组成员普遍的厌倦情绪，对应的风险表述是项目组士气低下，导致工作效率下降，甚至会引起人 员的流失，对于项目组来说不得不预见这种类型的风险，所以变更分析应该做出对应的风险分析。
　　第七步
　　这一步很简单了，主要是根据前面的给定的各方面信息权衡以后做出是否变更的决定。有人又说了：才不是呢，如果是需求变更，那一定得客户签字，客户如果不签 字，我们一点招数都没有！我们再一次退而求其次：能不能把客户的名字写上，表明他（她）知晓这件事情？应该是可以的吧。
　　至于表头信息，我想应该没什么问题，所提供的相关信息主要是供以后做统计分析之用。
　　好，到此为止，我们介绍了软件需求变更管理七步法。