五个要点,助你应对需求变更!

毫无节制的需求变更,影响的不仅仅是项目成本,更是会影响整个团队的士气。本篇总结一下,我们应该以怎样的姿态和方法来应对需求变更。

毫无节制的需求变更,影响的不仅仅是项目成本,更是会影响整个团队的士气。本篇总结一下,我们应该以怎样的姿态和方法来应对需求变更。



一、思维观念



1. 需求变更是必然的、可控的、有益的。


2. 一切的需求变更都是为了让项目更加完善。


3. 客户所有的变更都是有原因的,我们要积极地满足其背后的需求,而不是机械地满足其表面的要求。


4. 需求变更控制的目的不是控制变更的发生,而是对变更进行科学的管理,要确保变更有序地进行,最大限度地控制需求变更给软件质量造成的负面影响。


5. 需求分析人员和客户的关系不应该仅仅是记录人员和需求提供者,他们的关系应该更多的是战略合作伙伴关系。


二、原因分析



1. 需求变更的出现主要是因为在项目的需求确定阶段,用户往往不能确切地定义自己需要什么。


2. 用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备、新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验。


3. 随着开发工作的不断进展,系统开始展现功能的雏形,用户对系统的了解也逐步深入。于是,他们可能会想到各种新的功能和特色,或对以前提出的要求进行改动。


5. 他们了解得越多,新的要求也就越多,需求变更因此不可避免地一次又一次出现。


三、应对措施



1. 项目前期尽量清晰地确定需求范围和需求基线并与客户共同确认。


2. 设计灵活的软件架构,以能够对变化的需求进行快速响应。


3. 对变更的需求进行优先排序,分批实现。对于零星变更,集中研究、批量处理。


4. 妥善保存变更产生的相关文档。


5. 制订简单、有效的变更控制流程。


四、流程规范



1. 变更申请


如果用户需要变更需求,则填写《需求变更申请》,经客户方和服务方共同确认后,发送内容给项目组需求负责人。


2. 变更分析


《需求变更申请》的项目组接收者,录入此变更请求到《问题跟踪清单》,分析并标识“问题类型”。


3. 变更决策


项目经理和相关人员进行内部变更评估、审核,决定哪些变更无法修改并说明原因,哪些变更需要修改和什么时候修改。


4. 变更实施


审核通过的《需求变更申请》,确定开发时间和纳入的版本,制定开发计划。


5. 变更验收


对于需求变更而进行的版本更新,需交付相应的《版本更新说明》。

五、注意事项



1. 需求的变更要经过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。


2. 小的需求变更也要经过正规的需求管理流程,否则会积少成多。在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。但正是由于这种观念才使需求逐渐变为不可控,最终导致项目的失败。


3. 精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细,就越能避免需求的渐变,这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的,并非需求写细了,它就不会变化了。


4. 注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点问题,但是由于需求的变更可能来自客户方,也可能来自开发方,因此,作为需求管理者,项目经理需要采用各种沟通技巧来使项目的各方各得其所。


5.需求一定要与投入有联系,如果需求变更的成本由开发方来承担,则项目需求的变更就成为必然了。所以,在项目的开始,无论是开发方还是出资方都要明确这一条:需求变,软件开发的投入也要变。



文章来源:作者:啊庄。公众号:晓庄同学产品笔记。

图片来源:部分图片来源网络,版权归原作者所有,不为商业用途,如有侵犯,敬请作者与我们联系。文章为作者独立观点,不代表135编辑器立场。



文章申明:本文章转载自互联网公开渠道,如有侵权请联系我们删除
文章评价
登录后可以评论
立即登录
分享到