当前位置:   article > 正文

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

面试产品经理问你新增了很多需求怎么回答

有个小伙伴在微信上问我,他说面试官问他作为产品经理如何应对需求变更,今天我就来说说我的看法。

产品经理在项目中经常会遇到需求变更的情况,哪怕你计划做的再详细,也免不了受到一些需求变更的困扰,变化不可怕,(毕竟这个世界本身就变化的很快),关键是要建立起来应对变化的机制,在发生变化的时候,按照预先制定的机制来管理变更。

通常对发生的变更需要识别是否在既定的项目范围以内,如果在项目范围之内,就需要评估变更造成的影响,以及应对措施,及时通知受到影响的各方,如果在项目范围外,就需要商务人员主动和外部沟通,看是否需要增加费用和时间,还是放弃变更。

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端产品经理干货知识

竞品分析竞的是思维

点击“阅读原文”

查看更多干货

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/代码创新者/article/detail/62231
推荐阅读
相关标签
  

闽ICP备14008679号