导读: 编辑导语:无论在项目制交付过程中,还是在产品制迭代过程中,需求变更都是一个无法规避的难题。本文作者对自己工作中涉及到需求变更的问题...

编辑导语:无论在项目制交付过程中,还是在产品制迭代过程中,需求变更都是一个无法规避的难题。本文作者对自己工作中涉及到需求变更的问题进行了总结,希望能给你带来帮助。

需求变更无论是在项目制交付过程中,还是在产品制迭代过程中,都是一个永远无法规避的难题。

频繁的需求变更不仅会造成进度风险、成本风险,还会引起“舆情风险”让内外人员都产生不可控的负面影响。

虽然无法避免,但我们还是可以通过自己的成长和技巧尽量避免,或把变更引起的负面结果控制到可接受范围内。今天我把自己工作中所涉及到需求变更的问题进行总结,希望能对大家有所帮助。如有不完善之处还请留言指正。

01 为什么会出现需求变更?

需求变更的原因有很多,不过总结来看无外乎是需求/产品人员自身的问题:

在需求分析、设计、评审阶段,对场景和解决方案的考虑不全面,对政策、市场调研不准确。或是某些功能缺失、或者业务逻辑不闭环;还有一些细节问题没有提前想到,导致在后期落地的时候发现了。

也可能有关联方需要配合改造的内容没有调研清楚,后期发现对方无法配合推进;或是系统内的关联功能改造范围评估不准确,后期发现这种方案会伤筋动骨,在落地过程中开发团队发现实现难度过大,周期或成本不可控等。

尤其是在评审过程中研发组、关联方、客户等角色没有认真听,仔细想。后面真正需要大家配合时才发现有问题。

以上所列的需求分析过程中的完成度不够,能占到后期变更的大多数因素。

当然还有一些其他原因:比如政策或市场变动。在设计阶段方案没有问题,但是在落地过程中,政策变了、市场动向变了、用户要解决的痛点升级了,最终都指向——需求变了。

还有很玄学的原因,比如领导的想法变了(无论甲方、乙方)。

02 对待需求变更应有的态度

如果变更的原因是自己的问题,那勇于承认、积极应对,同时事后要反思、提升、避免。切勿推卸责任,搞得大家都不愿意再配合你、协助你。

如果变更是因为外部无法拒绝的原因,就要从情绪上尽快接纳、尽快设计新的解决方案。因为对于一些无法拒绝的变更,负面情绪不仅无效,反而更容易让事态发展走向不可控。

03 一些能用到的方法

掌握结构化思维能力(下个月会单独做结构化思维的总结)。在方案产出阶段,要先想,先想好,想全面之后,和关键人员碰撞之后,再落笔写文档。就像开发写代码时一样,一定要先做设计、评审通过之后再开撸。因为我们在写文档的过程中,容易陷入具体的功能逻辑里,而缺少了宏观的整体性考量,非常容易让产出物不严谨。

和关联系统充分沟通。不要不好意思,不要嫌麻烦,得不到的答案一定要追问,自己协调不了的一定要上报。现在多做一点,多确认一个问题,能给后面整体过程节省很多时间和成本。

和开发人员尤其是项目经理、技术经理之类的关键角色充分沟通。沟通方案可行性,沟通方案落地难度,同时考量他们提出的修改意见。当然在这个过程中可能会遇到两难境地,但既然我们是一个团队,总要内部协商出可行性方案。

保持与客户的及时互动。清晰客户的需求本质,并向客户整体介绍清楚我们方案的思路,最终评判此思路是否能得到客户的认可。这个过程中也会涉及到如何进行需求洞察、如何进行方案讲解等问题。

让方案直观易懂,才能让“干系人”提出建设性意见。在向客户、项目组内讲解、探讨设计方案时,界面类的功能尽量用原型图、UI图等直观的表达模式,让大家更有概念;后台类的功能尽量用流程图、时序图、数据流图之类的表现形式进行讨论,从而保证大家理解达成一致。最不济,拿个白板或者厕纸快速画一画,总比干巴巴凭空讲解效果要好很多。

变更,也有多种变更方式。当真的遇到需求产生变化,或者领导要新增需求时,先看此需求的真实程度,是否是“伪需求”,现有功能是否可以“曲线救国”,从而引导不做。其次评估此需求的迫切程度,对现有需求的影响范围,再看能否基于现有需求最小化解决,同时还可以提出能否用新功能置换出一定比例的非关键功能,从而保证进度及工作量不至于偏离过大。

04 总结

我们能做的是尽量减少因为自己工作不到位而引起的需求变更,同时在真正遇到变更时能够更快更合理的拿出最小化执行方案。

需求变更出现越早,此次变更的影响才会越小。因此我们在分析、设计、评审等“前阶段”尽早的识别风险、丰满方案,才能让后期变更的可能性降低。

当然,控制变更和控制蔓延是两回事,我在整理的时候有些内容更像是控制蔓延、应对蔓延的方法,在本文中就都删掉了,后续会再单独整理。

在我看来,需求人员因为自身原因导致的一些变更,可以类比于开发人员写代码时出现了bug。既可以避免,又不好杜绝。既要杜绝躺平,又要以积极平和的心态处理。

同时在发生变更之后,一定要有据可查,并及时通知所有干系人,否则难免在后期别人突然发现这里产生变更时,对相关人员一顿“输出”。

当一个需求人员能够减少、控制、应对好需求变更,那一定是一位高水平选手。

--The End--
来源:集林心得Offer-集林转载 | 发布者:集林心得

版权声明:本文章,于2022-07-01 20:17:43集林心得整理发布,欢迎转载!

转载注明:频繁的需求变更,让你痛苦过吗? - 来自集林心得Offer

免责声明:集林心得Offer 站内所有信息、评论本站不对其真实性、实用性做任何承诺,请您理性查阅

本文章共有 0 条评论

还可以输入 100 个字
继续阅读相关文章
集林心得猜您想要
评论 打印 收藏 分享按钮