回头再说。只要有人提出变更，我们就称之为变更申请。我们来看第一节变更内容描述：大家会说哎呀，这个首先行不通！我们的客户从来都是口述，打电话或当面交流。这个我们不怕，客户只要说出来，我们是不是就可以记录下来(有人又不高兴了：凭什么他说我记呀？别急，这样做对项目组有好处)？
除非客户不做任何表示让我们猜哑谜，我们是一定能够把客户的需求变更转成文字记录。大家可能又会说，我们可以帮他们记录，可是他们不愿意签字那怎么办？签字不是关键，此处我们关心的是把变更描述记下来，我们能不能把纪录的描述给客户看，客户会不会翻脸不认账：“不是我说的！”？不会的，果真这样我们就不做了！第一个问题是不是解决了？
往后看这可有点悬，什么叫对业务的影响呀？客户要改需求还需要理由吗？您说需要不需要？有人可能会说那是客户的事情，我们干涉不了。这个说法可是大谬不然也！业务上不需要的功能我们为什么要做？有人会说:客户不需要的功能他们会提出来给我们做吗？老大，您可是真糊涂了！你还以为客户每提一个需求都那么深思熟虑吗？所以得先让客户想一想！又有人说了，您搞形式主义！客户直接就写“如果做，对业务是极大促进；反之会对业务造成负面冲击”，你有什么办法？如果有人竟然有这样的想法，我真是替你们的领导难过：什么叫斗智斗勇？你要动脑筋呀！你能不能从客户的谈话中间去捕获信息？！你能不能去了解客户的业务了解变更的必要性？！！当然可以，要不还做什么项目！彻底成了客户的跟班了！怎么样？这个问题是不是也解决了？
第二步
我们再看第二步：技术评审。技术评审评什么？就是我们能不能做得了？比如说有这么一个糊涂客户提出说他们要求订单的最大处理时间是0.1秒，你应该做什么？直接告诉别人做不了。当然，大部分情况下技术还是可以满足新需求的。好，第二步问题也解决了吧？
第三步
第三步评价对工期的影响，有人可能马上会反驳说，工期评价没用，反正是自己消化掉。其实此处将工期、成本、质量都要量化的重要目的之一就是强迫我们的项目组先要想清楚，一个变更意味着什么。一定要把它落实到具体的数据上？为什么？我们在项目中、甚至工作和生活中，因为没有确切量化数据的情况比比皆是，而结果就是导致不必要的矛盾和摩擦。这也就是为什么细化、量化、图形化，在细化的基础上去量化才有意义。先看对具体活动工期的影响，可能是7天也可能是5天或其他；再看对于整体工期的影响，大家应该对关键路径的概念应该比较熟悉了。一个额外活动的工期需要10天，但是体现在整体工期却不一定是10天，还有可能是5天或者是0天，因为它有可能正好是一项非关键路径上的活动。所以这两种情况我们都要了解，简单吧？好，第三步就这么简单。
第四步
来看第四步，第四步也不会有什么歧义。因为一项变更有可能导致项目中需要添加新的人手(可能因为独特的技术背景)，而现有的人员怎么样加班也是无济于事的，所以项目组人员可能会增加。在看对应的工作量增加，这个应该相对容易，估算需要几个人(很多情况会是一个人)、多长时间(天或小时)，自然工作量就出来了。
小时工资率是什么？我们国内企业发工资一般会是基于工作天数的月薪，而许多外企则是基于工作小时数的月薪，所以这里有一个区别：一天可以是8个小时也可以是18个小时，难怪我们国内企业加班是家常便饭：没有请你周六周日来啊，不就是每天多那么几个小时嘛！而外企加班相对少许多：额外的工作时间要付加班费的(或许是工商局对它们看得比较严，而对我们国内的企业则网开一面的缘故吧)。说远了，小时工资率的设定与计算可依据组织的特点设定，自己搞不定请财务部门帮你出个数吧。
人时乘以小时工
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
