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

领测软件测试网 1．需求分析阶段采用原型方法明确用户需求

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

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

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

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

切忌对用户提出的需求拍胸脯，在此之前可以扪心自问：“如果拍了胸脯，以后不能按时完成，我能不能负担全部责任？”这样冷静一下就不会胡乱应承了。有一个比较好的方式减少这样的麻烦，就是在需求分析阶段之后，与用户不要亲密接触，而是按照软件项目的周期，或者双方在初期的约定，定时通报软件研发的进展。如果软件研发采用迭代式开发，就可以在每一期交付产品发布时做这个事情，征询到的用户需求将纳入以后某期的软件版本中。

3．为将要频繁改动需求的软件项目进行版本规划
如果考虑到软件项目比较大，周期比较长，如超过一年，其间的需求变化必然多得不可胜数，建议采用迭代式开发，为每个阶段的产品进行版本规划。第一个版本一般是包括了软件系统最基本的功能，用户最关心的功能，它的研发过程实际上还为后续版本提供了系统构架和新技术探索。一个按时交付、质量较好的版本可以让用户保持对项目成功的信心，并给了用户在最终产品未出来之前逐渐接近最终产品的机会，这个过程将使用户需求更加明确和完善，以提高最终产品的一次成功的几率。
所以第一个版本的完成是项目的重要里程碑，建议项目组在此时举行庆祝会来提高凝聚力，鼓舞员工士气。后续的版本规划，一般是需求的分期完善，对系统的缺陷做持续改进。这个过程将一直持续到软件的生命周期结束。  

文章来源于领测软件测试网 https://www.ltesting.net/