首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如何看待项目的需求变更和应对方法

需求变更可能产生的原因

1、需求表达不到位。

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

3、需求理解不正确。

4、没及时让客户参与。

早发现,早应对

我们身处软件工业时代这个令人振奋的时代,却面临着遗留系统这个令人尴尬的难题。事情总是这样的:软件最开初开发的时候总是非常清晰,清晰的需求、清晰的设计、清晰的代码,清晰的程序结构让人赏心悦目,甚至有些自我陶醉。

随后,软件开始需求变更,每变更一次软件的质量就下降一次。这样,软件经过数次的变更以后,需求文档变得模糊不清,设计思路跟不上变更的脚步,程序代码则随着业务逻辑的复杂而臃肿不堪,程序员开始读不懂代码,软件开发工作变得不再是一种乐趣。随着时间的推移,经过数年、数十次的需求变更,情况变得越来越糟,软件质量像滚雪球一样直线下降。

针对需求变更要早发现、早应对。

需求变更避免不了,既然不能避免,那我们就要敢于直面惨淡的人生。

引入需求变更管理机制,以降低需求变更带来的风险。需求变更管理的核心是减少变更所产生的影响,而非消灭变更。

通过变更管理可以降低开发返工、重工的工作量,以减少项目风险。

需求变更属于需求管理范围,同时也属于风险控制范围,对于产品经理要随时关注产品,定期对需求进行跟踪,做到“早发现、早治疗”,以防病入膏肓后才下手。

对已变更的需求要做到文档标记更新,编写需求变更说明,保证需求与开发工作一致,不要出现“两层皮”的现象。从技术角度考虑,技术架构要做到可扩展,以弹性的架构来解决变更的需求,把变更造成的影响降到最低。

需求变更流程

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

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

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

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

从项目方面分析。从项目角度考虑,变更会使项目的时间、资源、费用上产生多大影响?影响是否能够承受?本次变更的需求必须本版本开发完,还是可以放到下一版本迭代开发?

从以上三方面分析清楚后,变更的需求脉络也就理清了,变与不变、现在变还是以后变也能分析得透彻。

总 结

需求变更对每一位产品人来说都会经常遇到,产生变更的原因很多,有外在的、有内在的,但不论是因为什么产生的变更,遇到了就要正确的、合理的分析、评估,给项目以正确的指导。

如果项目前期进行了大量的调研、跟踪、分析、评审,并请客户尽早参与,许多变更是可以避免的。

如果,技术框架设计的可扩展,程序设计的可扩容的话,当发生变更时也可以把变更对项目产生的影响控制到最小。

防微杜渐、未雨绸缪,还是那句话:“早发现、早治疗”。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20191028A0498M00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券