怎样从容应对客户的需求反复?

发表于:2008-10-15来源:作者:点击数: 标签:需求反复客户
在软件项目的研发过程中,需求变更贯穿了软件项目的整个生命周期,从软件的项目立项,研发,维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能,优化 性能 ,提高用户友好性的要求。我在自己的软件 项目管理
 在软件项目的研发过程中,需求变更贯穿了软件项目的整个生命周期,从软件的项目立项,研发,维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能,优化性能,提高用户友好性的要求。我在自己的软件项目管理职业过程中,几乎天天面对用户的需求变更,切身感受到,如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,用户的耐性渐渐消逝,研发人员的士气也越来越低落,最后所有的人都在等待一个结果:项目最好马上结束。所幸,在不断的学习和实践中,我总结了几点比较有效的方法,在软件研发阶段能够较好地解决这方面的问题。 

  1.需求分析阶段采用原型方法明确用户需求。 

  在软件项目的需求分析阶段,有大量需求信息需要收集、筛选、加工,这是需求管理的开始。客户和研发两方面的人员对需求的理解呈现“大体上共识多,细节上差异多”的特点。即使通过反复沟通,最终在时间表限制之内也能拿出一份“用户需求说明书”,但是以实践经验,用户需求的描述永远是“不够清晰”、“不够明确”的。这主要是因为在这个阶段,所谓的产品都在大家的大脑中构思,正如100个人读《射雕英雄传》,就有100个郭靖的形象一样,每个人的想法都是大致轮廓相同,而细节差异很大。在此阶段,原型开发是一个较好的辅助手段,它将存在于大家头脑中的虚境实实在在地表达出来,一个界面,几个控件,外观形式固定了,功能描述明确了,这就是研发部门对用户的需求理解。此时与用户再次沟通,用户基本上可以说出来:“这是我想要的”,或者“不,这不是我想要的,我要的是……”。一般情况下,原型之后的需求沟通就实际得多,双方的理解迅速向一个折衷方案靠拢,一个可以指导研发过程的需求说明书正式诞生了。 

  2.需求分析之后的研发过程采用严格的需求变更管理流程。 

  一旦需求分析阶段结束,此后如果用户要求有新的需求加入交付的软件系统中,需要走需求变更管理流程。这个流程必须在软件项目成立之初与用户约定好,一般的软件企业内部有需求变更的管理流程,可以向用户解释这种管理的必要性,直至与用户就此问题达成共识为止。不必担心用户不会接受,有过多次成功研发软件项目经验的需求变更管理流程,有着它不容置疑的合理性,这正是软件企业的经验和价值所在,用户最终会理解和同意的。 

  需求变更管理流程各家企业有各家的做法,借用CMM的需求管理KPA来讲,需要两级需求变更管理委员会(以下简称CCB)来处理,即产品CCB和项目CCB。产品CCB处理涉及到产品一级的需求变化,主要体现在需要多个职能部门,多个软件项目,以及与其他产品线的协调等问题;项目CCB处理本项目内部的需求变更,如不同小组之间的协调,接口变化等等。每一个需求都要经过CCB的审批,决定这个需求的各种属性描述是否合适,如时间紧迫性,采用的技术是否有风险,对系统的重要程度,需求变更的波动分析,需求实现的资源状况。在与会人员对需求属性取得共识之后,规划需求实现的版本,确定时间计划。 

原文转自:http://www.ltesting.net