往后看这可有点悬,什么叫对业务的影响呀?客户要改需求还需要理由吗?您说需要不需要?有人可能会说那是客户的事情,我们干涉不了。这个说法可是大谬不然也!业务上不需要的功能我们为什么要做?有人会说:客户不需要的功能他们会提出来给我们做吗?老大,您可是真糊涂了!你还以为客户每提一个需求都那么深思熟虑吗?所以得先让客户想一想!又有人说了,您搞形式主义!客户直接就写“如果做,对业务是极大促进;反之会对业务造成负面冲击”,你有什么办法?如果有人竟然有这样的想法,我真是替你们的领导难过:什么叫斗智斗勇?你要动脑筋呀!你能不能从客户的谈话中间去捕获信息?!你能不能去了解客户的业务了解变更的必要性?!!当然可以,要不还做什么项目!彻底成了客户的跟班了!怎么样?这个问题是不是也解决了? 第二步 我们再看第二步:技术评审。技术评审评什么?就是我们能不能做得了?比如说有这么一个糊涂客户提出说他们要求订单的最大处理时间是0.1秒,你应该做什么?直接告诉别人做不了。当然,大部分情况下技术还是可以满足新需求的。好,第二步问题也解决了吧? 第三步 第三步评价对工期的影响,有人可能马上会反驳说,工期评价没用,反正是自己消化掉。其实此处将工期、成本、质量都要量化的重要目的之一就是强迫我们的项目组先要想清楚,一个变更意味着什么。一定要把它落实到具体的数据上?为什么?我们在项目中、甚至工作和生活中,因为没有确切量化数据的情况比比皆是,而结果就是导致不必要的矛盾和摩擦。这也就是为什么细化、量化、图形化,在细化的基础上去量化才有意义。先看对具体活动工期的影响,可能是7天也可能是5天或其他;再看对于整体工期的影响,大家应该对关键路径的概念应该比较熟悉了。一个额外活动的工期需要10天,但是体现在整体工期却不一定是10天,还有可能是5天或者是0天,因为它有可能正好是一项非关键路径上的活动。所以这两种情况我们都要了解,简单吧?好,第三步就这么简单。 第四步 来看第四步,第四步也不会有什么歧义。因为一项变更有可能导致项目中需要添加新的人手(可能因为独特的技术背景),而现有的人员怎么样加班也是无济于事的,所以项目组人员可能会增加。在看对应的工作量增加,这个应该相对容易,估算需要几个人(很多情况会是一个人)、多长时间(天或小时),自然工作量就出来了。
此文章共有5页 上一页 1 2 3 4 5 下一页
|