才子佳人博客

我的故事我讲述

软件需求总变更,需要管理和控制
 
来源:blog.csdn.net  编辑:xjh  2019-11-06

需求变更对每一位产品人来说都会经常遇到,产生变更的原因很多,有外在的、有内在的,但不论是因为什么产生的变更,遇到了就要正确的、合理的分析、评估,给项目以正确的指导。如果项目前期进行了大量的调研、跟踪、分析、评审,并请客户尽早参与,许多变更是可以避免的。

造成需求变更的主要原因有:

1、需求表达不到位

2、没有与客户认真沟通需求

3、需求理解不正确

4、没及时让客户参与

5、不愿听取意见

项目的成败与需求关联非常密切。如果想要做好一款产品,从需求调研、需求分析、文档梳理、需求评审每一步都要走的坚实,不可以走过场。一点的疏忽都可能导致产品的失败,需求变更,也就再所难免。有的需求变更是无法避免的,如客户、领导在产品开发阶段要求增减需求;有的需求变更是可以避免的,如需求调研的不够充分、分析的不到位、评审的不够严格。只要我们更虚心一点、更认真一点,需求管理流程更规范一点,许多变更都是可以避免的。

针对需求变更要早发现、早预防。需求变更避免不了,既然不能避免,那我们就要敢于直面惨淡的人生。引入需求变更管理机制,以降低需求变更带来的风险。需求变更管理的核心是减少变更所产生的影响,而非消灭变更。通过变更管理可以降低开发返工、重工的工作量,以减少项目风险。需求变更属于需求管理范围,同时也属于风险控制范围,对于产品经理要随时关注产品,定期对需求进行跟踪,做到“早发现、早治疗”。对已变更的需求要做到文档标记更新,编写需求变更说明,保证需求与开发工作一致,不要出现“两层皮”的现象。从技术角度考虑,技术架构要做到可扩展,以弹性的架构来解决变更的需求,把变更造成的影响降到最低。

需求变更流程当发生变更时,正规的流程需要走变更申请,申请后组织人员对变更进行分析、评审,以判断变更是否必要,对项目的影响有多大。又必要又紧急的需求要排到开发计划中,尽快安排开发;对必要不紧急的需求要考虑是否可以放到下一版本安排开发;对紧急不必要的需求,要根据项目实际情况考虑,是否可以不要?对不紧急也不必要的需求应该直接砍掉,无须变更。评审完成后,对于需要安排开发的变更需求,先整理变更需求说明书,以帮助开发人员、测试人员了解变更内容,指导技术人员开发。

需求变更管理过程为:问题分析和变更描述及变更提议->变更分析与成本计算->变更实现。在变更实现过程中这就要求需求文档和系统设计及实现都要同时变更。

如何分析需求变更的合理性?从哪些方面着手?

1、从业务方面分析

需求变更基本都是因业务变化而产生的,当发生变更时,我们也要从业务角度多思考,变更的是否合理,是否必要,与产品定位是否相符,能给产品带来哪些好处?如果不做变更是否可以?

2、从技术方面分析

变更会对开发有多大影响,需求变更的部分是否已经开发?开发到什么程度?工作量多少?是否可以通过技术框架的扩容性很好的解决变更?

3、从项目方面分析

从项目角度考虑,变更会使项目的时间、资源、费用上产生多大影响?影响是否能够承受?本次变更的需求必须本版本开发完,还是可以放到下一版本迭代开发?从以上三方面分析清楚后,变更的需求脉络也就理清了,变与不变、现在变还是以后变也能分析得透彻。

总结

需求变更对每一位产品人来说都会经常遇到,产生变更的原因很多,有外在的、有内在的,但不论是因为什么产生的变更,遇到了就要正确的、合理的分析、评估,给项目以正确的指导。如果项目前期进行了大量的调研、跟踪、分析、评审,并请客户尽早参与,许多变更是可以避免的。如果,技术框架设计的可扩展,程序设计的可扩容的话,当发生变更时也可以把变更对项目产生的影响控制到最小。防微杜渐、未雨绸缪,还是那句话:“早发现、早治疗”。

来源:
https://blog.csdn.net/u014205567/article/details/80783203


分类:编程开发| 查看评论
相关文章
文章点击排行
本年度文章点击排行
发表评论:
  • 昵称: *
  • 邮箱: *
  • 网址:
  • 评论:(最多100字)
  • 验证码: