所以一看这个表您就明白了，其实这个表反映了一个最朴实的道理：就是项目三角形在发生变形时需要保持的对应关系。
大家会说，我看明白了，可是这张表应该怎么去使用?谁去填表?什么时候填表?如果有人不愿意填，那该怎么办?下面我们分七个步骤来讨论操作中可能会遇到的问题
步
首先得说到变更流程的事情。不管什么样的变更，首先都有 步：变更申请。有人就不乐意听了：我们的客户都是“变更命令”!这个回头再说。只要有人提出变更，我们就称之为变更申请。我们来看 节变更内容描述：大家会说哎呀，这个首先行不通!我们的客户从来都是口述，打电话或当面交流。这个我们不怕，客户只要说出来，我们是不是就可以记录下来(有人又不高兴了：凭什么他说我记呀?别急，这样做对项目组有好处)?
除非客户不做任何表示让我们猜哑谜，我们是一定能够把客户的需求变更转成文字记录。大家可能又会说，我们可以帮他们记录，可是他们不愿意签字那怎么办?签字不是关键，此处我们关心的是把变更描述记下来，我们能不能把纪录的描述给客户看，客户会不会翻脸不认账：“不是我说的!”?不会的，果真这样我们就不做了! 个问题是不是解决了?
往后看这可有点悬，什么叫对业务的影响呀?客户要改需求还需要理由吗?您说需要不需要?有人可能会说那是客户的事情，我们干涉不了。这个说法可是大谬不然也!业务上不需要的功能我们为什么要做?有人会说:客户不需要的功能他们会提出来给我们做吗?老大，您可是真糊涂了!你还以为客户每提一个需求都那么深思熟虑吗?所以得先让客户想一想!又有人说了，您搞形式主义!客户直接就写“如果做，对业务是极大促进;反之会对业务造成负面冲击”，你有什么办法?如果有人竟然有这样的想法，我真是替你们的领导难过：什么叫斗智斗勇?你要动脑筋呀!你能不能从客户的谈话中间去捕获信息?!你能不能去了解客户的业务了解变更的必要性?!!当然可以，要不还做什么项目!彻底成了客户的跟班了!怎么样?这个问题是不是也解决了?
第二步
我们再看第二步：技术评审。技术评审评什么?就是我们能不能做得了?比如说有这么一个糊涂客户提出说他们要求订单的最大处理时间是0.1秒，你应该做什么?直接告诉别人做不了。当然，大部分情况下技术还是可以满足新需求的。好，第二步问题也解决了吧?
第三步
第三步评价对工期的影响，有人可能马上会反驳说，工期评价没用，反正是自己消化掉。其实此处将工期、成本、质量都要量化的重要目的之一就是强迫我们的项目组先要想清楚，一个变更意味着什么。一定要把它落实到具体的数据上?为什么?我们在项目中、甚至工作和生活中，因为没有确切量化数据的情况比比皆是，而结果就是导致不必要的矛盾和摩擦。这也就是为什么细化、量化、图形化，在细化的基础上去量化才有意义。先看对具体活动工期的影响，可能是7天也可能是5天或其他;再看对于整体工期的影响，大家应该对关键路径的概念应该比较熟悉了。一个额外活动的工期需要10天，但是体现在整体工期却不一定是10天，还有可能是5天或者是0天，因为它有可能正好是一项非关键路径上的活动。所以这两种情况我们都要了解，简单吧?好，第三步就这么简单。
第四步
来看第四步，第四步也不会有什么歧义。因为一项变更有可能导致项目中需要添加新的人手(可能因为独特的技术背景)，而现有的人员怎么样加班也是无济于事的，所以项目组人员可能会增加。在看对应的工作量增加，这个应该相对容易，估算需要几个人(很多情况会是一个人)、多长时间(天或小时)，自然工作量就出来了。
文章来源于领测软件测试网 https://www.ltesting.net/
