面试题,作为产品经理你是如何应对需求变更的?

产品刘

共 3021字,需浏览 7分钟

 · 2020-12-06












有个小伙伴在微信上问我,他说面试官问他作为产品经理如何应对需求变更,今天我就来说说我的看法。
产品经理在项目中经常会遇到需求变更的情况,哪怕你计划做的再详细,也免不了受到一些需求变更的困扰,变化不可怕,(毕竟这个世界本身就变化的很快),关键是要建立起来应对变化的机制,在发生变化的时候,按照预先制定的机制来管理变更。
通常对发生的变更需要识别是否在既定的项目范围以内,如果在项目范围之内,就需要评估变更造成的影响,以及应对措施,及时通知受到影响的各方,如果在项目范围外,就需要商务人员主动和外部沟通,看是否需要增加费用和时间,还是放弃变更。
1、需求变更原因
1.1 需求定义不明确
如果产品经理自己对需求都没了解清楚,就让技术同事进行开发,最后开发出来的东西只能是回炉重造,我之前做EHR项目的时候,因为薪资模块上线比较急,说实话,我之前是做金融的,对薪资模块的业务根本不是很了解,只是简单的写了一些需求,就让技术小伙伴开发,估计技术小伙伴也懵懵懂懂,结果做出来的东西各种bug,不得不回炉重造,我重新梳理细节需求,不断的给大家宣讲。
1.2 需求理解有歧义
你说的是小龙女,其他项目组其他成员理解的是贾玲,所以我一般在项目评审的时候,都会让技术的小伙伴主动的说一下他们理解的需求,这种做到彼此信息的理解没有偏差。
1.3 业务需求变更
这个也是我们最讨厌,和最无法可控的,在启动开发之前变更需求还好,在开发启动变更之后,对士气的打击很大,所以产品经理要不断给业务灌输一个意识,一定要明确需求,不能反复变更,如果逼不得已变更,外包的话,就要向业务方要时间要钱,自己公司内部的业务方需求,就需要给团队要时间,让业务方知道,经常变更需求该来的弊端,以此掣肘业务方的需求变更。
1.4 项目周期过长
这也是为什么推荐敏捷开发的原因之一,项目周期过长,容易发生变化,比如技术人员变动,导致的人力短缺,市场环境发生变化,导致业务需求发生变化,古人说的夜长梦多就是这个意思。
 
2、需求变更来源
需求的变更来源分为两个部分,一个是内部来源,一个是外部来源。
2.1 内部来源
内部来源又分为两个部分,一个是产品经理变更需求,一个是技术的小伙伴变更需求。
产品经理自己变更需求,主要原因分为以下这些:
1、需求没有考虑清楚,逻辑有遗漏
2、产品设计变更
3、临时插入需求,比如交互要调整、要加字段等。
 
技术小伙伴变更需求,主要原因分为以下这些:
1、技术方案变更
2、人员的变更
 
说完内部来源,我们再来看看需求变更的外部来源有哪些:
2.2 外部来源
外部来源有用户、公司的同事、领导、以及市场政策等
1、用户。比如产品的目标用户的需求变了
2、公司的运营、市场、业务等部门变更需求。
3、公司的高层(分为本公司的领导、外部门的领导、以及公司的大boss,这里顺便说一下,职场一定要和领导接近,那些决定你能升官的领导才是你真的领导)。
4、市场政策变化(比如政府政策的调整、潮流趋势、以及突发的黑天鹅事件)。
 
3、需求变更的目的 
记住,所有的变更目的最终一定是能够更好的实现目标,不是追责,也不是扯皮。
产品经理变更需求是为了贴近产品设计;
开发变更需求是为了技术方案更加合理化,便于实现;
用户变更需求是为了贴近自身需求;
公司高层以最小的代价实现目标;
市场人员变更需求是为了适应市场变化;
政策变化是为了产品更加合法化。
 
4、需求变更的影响
需求变更首先要评估一下需求影响的范围,然后评估一下对现有进度的影响,对项目交付质量的影响,是否需要增加成本(比如人力资源成本、服务器成本等),以及需求变更带来的潜在风险点。
 
5、预防需求变更
与其发生问题想办法,不如在问题发生之前去预防。
所以在考虑需求变更之前,我们先想想如何预防需求变更,产品经理提的需求,设计师设计的ui设计稿一定要经过团队内部的充分评审,让大家充分发表意见,做到需求理解一致,并最后邮件确认,也许你一个人无法发现问题,但是大家一起头脑风暴,就容易发现问题。
针对技术实现方案,技术团队的同事也要充分沟通,反复研讨,务必把一切能想到的问题提前想到。
对于外部的需求一定要充分沟通,能不变就不。
同时保持对业务环境的敏感,知道业务同事的习性,提前做好应对措施。
针对业务同时可能变更的需求,提早分析,做好预案。
 
6、接受OR 拒绝需求变更?
针对变更的需求,我们是接受还是拒绝呢?在说拒绝还是接受之前,我们先说一下PM的态度问题,针对变更的需求,PM一定要保持积极的态度,不能消极对抗对于变更的需求一概拒绝,在高度重视的同时,要有全局意识,要能看到变化给每个模块带来的影响,以及给整个全局带来的影响。
那我们判断是否接受变更可遵循以下三个原则:
1、变更对项目是否有利,如果无利,我们肯定拒绝。
2、如果变更对项目有利,那我们要接着看,变更需要投入的成本和变更带来的利益,也就是看投入产出比(ROI)如何,然后根据投入产出比判断是否值得更改。
3、如果值得更改,那接着看是否紧急,如果变更带来的收益不是我们目前急需的,也可以往后放。只要那些重要且紧急的变更需求,我们才考虑插入。
  
7、变更的流程
7.1 收集
对于变更的需求,需求变更方需要通过一定的流程提交给产品经理,不论是邮件还是流程协作工具confluence这种,亦或是自己做的企业效能工具,通过系统的好处就是做到有迹可循,责任到人,事后也方便对需求变更进行统计,以分析变化的原因,降低变化。
7.2 评估
将变更的需求提交给变更控制委员会评审,变更委员会可根据上面的拒绝OR接受需求变更原则进行评估,这个评估的过程就是需求分析的过程,也是头脑风暴的过程。需求变更委员会最好由项目所涉及的多方人员共同组成,应该包括产品经理、项目经理、用户方和开发决策负责人等。
7.3 变更
需求如果确认变更,那就走变更的流程,变更的需求再开一次评审会,给项目团队的成员详细讲解一下。 
7.4 修改
评审过后的需求,产品经理要修改对应的文档,开发计划的排期也需要重新排。
7.5 归档
妥善保存变更的相关文档,无论是以后自行查阅还是给到接盘者,让接盘者接手,都很有意义。
 
对于变更的需求,产品经理对上要反馈现状、明确目标、提出解决方案,对下要组织变更评估,明确目标,体现团队工作成绩。
当然,最好的情况是不变更需求。
最后欢迎有问题的小伙伴加微信:chanpin628 沟通交流。

此外我们的官方网站也上线了,每日分享高质量的文章、原型素材和行业报告,小伙伴可自行前往索取,支持搜索,需要的小伙伴可点击底部的阅读原文直接查看,或者复制网址:www.dadaghp.com 打开。
更多干货可关注微信公众号:产品刘
想学习更多关于产品、职场、心理、认知等干货,可长按右边二维码,关注我们。
··················END··················
如果想系统的学习产品经理,线下学习可点击线下实战2.0,线上学习可点击手把手教你做产品经理1.0

RECOMMEND

推荐阅读
手把手教你编写接口需求文档
面试题,你的兴趣爱好是什么?
最全的B端产品经理干货知识
竞品分析竞的是思维

点击“阅读原文”

查看更多干货

浏览 43
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

举报