从一个软件项目需求变更的笑话,谈如何做好需求变更控制
(一)一个关于软件的需求变更的笑话
公司开发部的管理混乱,开发项目下来没有正式的通知,没有需求计划书,而且参与的人离奇的少,一般一个项目一个人。你永远不知道用户最终要求的产品是什么样的。也永远不知道谁的意见才是最重要的。
举个例子,一般都是这样的:
开始,上面来个人叫你开发一个自行车,他会说:就一个自行车,你看多简单呀。就两个轮子,加一个三角架。你问:有什么要求?他通常会回答:没什么要求,就是一辆自行车嘛。最后不忘问你一句:明天能好不?
通常第二天也可能过几天,他会来问你:开发的如何了?好了吧。你会说:还有点,过几天就好。这时他就会在你身边看,不时提点意见,最后说:干脆,你给它装个发动机,做成个摩托车吧。你说:啊,这个难度高了吧,还要找变速箱、离合器的资料。他会说:不怕,要的不是很急,加个发动机而已,又不是很难。然后你就去找资料去了。
再过几天,他又来了。又问:快好了吧。没等你回答他又说了:我回去想了一下,反正都加了发动机、变速箱、离合器,干脆再加多两个轮子,开发一个汽车好了。然后走开,留下你愕然而立。
再过段时间,他还会来,说道:这几天我与他们讨论了一下,觉得把汽车上加多一对翅膀,做成架飞机,这样爽点。怎么样?这时你已经没有多少言语了,不管他,做自己的事。
再过了段时间,终于他又来了,同行的还有老板和几个客人。他们一起来参观你的作品。老板对客人大肆吹嘘:怎么样?我们的开发能力,世界一流吧。那个谁,在飞机上再加多几个火箭助推器,做成个飞船不是更好。你愕然:啊!?这时,先前那个他马上跳出来:老板英明,算无遗策,千秋万代,必一统江湖~~~~~然后他们相互拍马,吃饭唱歌泡澡也顺随泡mm去了,没你什么事。该干啥还是干啥吧。
再过几天,客户的订单来了,飞船 xx 艘,10天内交货。
这个笑话有点意思,不过想想,搞管理的不了解搞技术开发的,软件的定位一变再变,这样的郁闷事并不少
(二)需求管理和范围管理的区别和联系
两者之间的区别:
需求开发和管理的目的是通过调查与分析,获取用户需求并定义产品需求,还要确保各方对需求的一致理解,管理和控制需求变更,需求的双向跟踪。
而范围管理的目的是确保项目包含且仅仅只包含项目所必须完成的工作。
需求管理是对已批准的项目需求进行全生命周期的管理,过程包括需求管理定义、需求管理流程、制订需求管理计划、管理需求和实施建议等,其主要的工作就是需求的变更管理。
范围管理过程包括范围计划编制、范围定义、创建工作分解结构、范围确认和范围控制。
两者之间的联系:
首先通过需求开发来获取项目的需求,再次基础上确定项目的范围、进行项目范围管理。
其次需求的变更会引起项目范围的变更。
范围管理包含一系列子过程,用以确保项目包含且只包含达到项目成功所必须完成的工作,范围管理主要关注项目内容的定义和控制,即包括什么,不包括什么。
而需求管理是确保各方对需求的一致理解,管理和控制需求的变更,以及需求的跟踪。
(三)如何控制需求变更
你必须面对这个现实:需求变更是不可避免的。项目经理应该做的,是如何在发生需求变更的情况尽量减少其对项目的影响。需求变更不可避免,不是说就不做需求变更的控制了,需求变更如果量很大,对项目的影响无论如何也降不下来,因此还是要在控制需求变更上下功夫,但不要奢望杜绝需求变更。
对于管理信息系统的项目,其需求的核心点在于业务流程,如果业务流程保证没问题了,那么系统就不会发生大的需求变更,界面调整一下,多一两个字段,甚至多一两个查询页面,都对系统不会产生太大的影响;但是如果流程变了,比如中间加了一个环节,或是环节间数据交互的变更,都可能会给整个系统带来很大甚至致命的影响,有可能因为某流程的变化导致整个系统都要重新翻一遍,这样的修改对质量的影响是非常可怕的。
要把握用户的流程,首先看用户这个业务流程是否正在正常的运行,在这种情况下,你把这个流程调研清楚了就没有问题了;但是如果业务流程是用户新构想出来,正指望着你通过系统去实施(也可以说试试)这个流程,那你就要小心了,必须仔细的分析这个流程的可行性,主动的和客户探讨这个流程的缺陷,可能面临的问题,必要时请有关专家做咨询,总之,一定要保证流程的可行性,否则流程一旦执行不下去,虽然软件本身没有任何质量问题,你还得改。
对于流程分析要了解哪些关键点呢,首先当然是有哪些环节,环节间的运作关系,比如报销流程,有填单、部门领导审批、财务稽核、主管副总审批、结算这些环节,简单来说是依次传递的;其次要了解每一环节的控制点,比如领导审批,可以通过、不通过,一定要注意不通过这个非正常流程的下一节点,也许是终点(该报销单作废,要求报销人重填),也许又到了填报环节(报销人可以修改后重新提交审批);然后一定要搞清楚环节间的数据和传递关系,这是非常重要的,因为这些数据和关系至少会影响两个环节的处理,甚至可能影响整个流程的处理,而其他的无需传递的数据项,一般只对某个环节的处理产生影响,即使发生变化也无关大局。
这三点把握住了,流程也就基本清楚了,但是要注意,了解这些信息首先是通过和客户的直接交流,同时一定要注意分析客户提供的每一环节的表单和最终的分析报表,确定每一信息的来源,因为表单和报表的数据理论上讲都是通过流程的处理得到的,它们真的都包含在流程处理中了吗?
(四)IT项目管理如何应对需求变更
1、提前做好需求分析,尽量较少需求变更
2、如果出现变更,应评估变更带来的风险,如技术是否可以实现、成本是否增加、工期是否延长,根据变更带来的影响进行分类管理,严格控制需求变更。
3、对变更进行正式书面确认和审批,增加变更的严肃性。