产品经理怎么做才能在需求评审中少挨打?

编辑导语:需qiú评审是产品经理非常“害怕”但是又不得不做的一个X ,因为在评审会中,产品经理往往是被大家“攻击”的对象。做好评审会,对于产品经理的X能力也是一个非常大的考验。产品经理如何才能在需qiú评审中少挨打呢?

作为一个产品经理,需qiú评审是产品设计开发的一个重要环节。只要工作在进行,产品在迭代,新需qiú在不断产生,就会有需qiú评审。

在需qiú评审X上,产品经理将面对前端、后端、测试、UI设计师、你的X、甚至老板可能都会过来,不同角sè聚在一个X室听你讲解需qiú内容,简直妙不可言。在X中,不同角sè提出不同意见,出现无fǎX问题等,产品经理又该如何游刃有余的化险为夷,高效完成需qiú评审呢?

本文作者基于自身工作经验,和大家一起聊聊需qiú评审相关的内容,希望对你们有帮助。

一、原型准备阶段

在评审前,是产品经理收集需qiú、分析需qiú、提炼需qiú、输出原型等文档的过程,在此阶段提几点自己总结的鱼见,如果能做到以下几点的话,可能对你开展工作会有很大的帮助。

1. 需qiú细节尽量描述详细

详细即逻辑清晰、无遗漏、页面整洁、表达清晰等,图1、图2是作者平时写需qiú文档的一些xí惯,仅供大家参考。这里说一个有趣现象,不知道大家有没有遇到过:就是不管你需qiú说明写得如何详细,有些技术就是不看,次次都来问。

产品经理怎么做才能在需qiú评审中少挨打?

(图1:审核状态需qiú说明)

产品经理怎么做才能在需qiú评审中少挨打?

(图2:字段需qiú说明)

图1是我做的B端项目某个审核状态的需qiú说明,将书写需qiú说明可以分为三部分:要描述功能或者动作、分状态或场景、细节描述,大家可对照图1自行理解,一看就懂。

2. 以前有的功能,现在项目涉及到要不要把以前的功能需qiú再写一下

关于这个问题,也有好几个小伙伴问过我。如果是该功能迭代优化,那涉及其相关的需qiú要在会上说明:原先功能整套liú程是怎么样的,现在zhēn对哪个环节进行升级迭代。

其实多写总归没máo病的,毕竟上一版的开发人员不一定继续负责以后的相关迭代工作,我的做fǎ一般会加上这句话 “现有逻辑:若代码发生修改,应及时和产品、测试说明情况”。

因为在技术实际开发过程,可能会现有逻辑的代码进行增册刂,这种情况肯定需要测试人员重新测试;即使现有逻辑未动,测试人员可能也需要回归一下,走一X程,都是有必要做的。

产品经理怎么做才能在需qiú评审中少挨打?

总之呢,关于涉及到现有逻辑会不会被改动,X上还要重点提一下的。

3. 设计功能或者逻辑一定要有理有据

逻辑不通,形成不了闭环,大忌;设计功能的时候,自己认为这样就是这样,也是大忌;一起看下签到功能的例子,一说到签到功能想必大家脑海中连UI画面都想好了,常见的前台页面可能如下图这几种。

产品经理怎么做才能在需qiú评审中少挨打?

(图3:签到画面一)

产品经理怎么做才能在需qiú评审中少挨打?

(图4:签到画面二)

这两种签到布jú展示的方式,在座的各位应该都见过吧,两者布jú差异基本不大。从技术角度来看,图4的曰期显示效果肯定比图3按天数方式实现要复杂一些。

假如你选择图4方案时,技术人员有可能会问:你为什么要采用这种曰期显示方式,而不选择图3方式?各种小伙伴遇到这种问题,自己心里有X吗?

如果你支支吾吾的,说不出个子丑寅卯,那么技术人员分分钟钟教你做人,我们可以这么回答:之所以按照曰期的方式显示,可以使签到功能参与营销活动;比如5月20号这天,运营可以在X设置那天签到奖励是情人节大额优惠券等等,这样按曰期方式显示就很X义了。

记住我们设计的每个功能都要有理有据。

4. 设计过程中遇到技术难点、技术知识盲区,一定要和技术去沟通

相信大多数的产品是没有技术背景的,在产品设计过程中,经常遇到需要实现某些复杂的cāo作交互、炫酷特效、营销游戏等。要实现这些功能,估计需要技术人员有比较扎实的代码能力。

因此,当你遇到把握不准自家技术能不能实现自己功能,可以找到技术负责人把自己的想fǎ提前说给他听,提前一起讨论实现过程,或许让他们评估且及时制定方案。

最好在X前双方把方案制定,达成共识,而不是把所有问题放在X上讨论,这样做好处是避免了:在评审过程中就某一特效或功能实现难易程度,双方huā费太多的时间讨论,而导致评审时间被拉长。

二、评审前的准备

1. 产品内部评审

如果是比较大的项目,可能是多个产品经理一起负责,那么最好是产品部门内部开一个小评审会,把大致逻辑、功能统统讲一遍,看看有没有遗留的,有没有补充的。

2. X部门X

还是属于比较大的项目,跟X部门X主要目的是让他们了解产品部门做的东西是不是符合他们预期效果。我们只要跟他们大致讲解项目cāo作liú程即可,无需太细致。小范围的需qiú预评审主要还是为了保证需qiú的质量,以保证正式评审的时候,不会出现大的纰漏。

3. 提前把原型或者需qiú文档发给技术人员

在需qiú评审X的前一天,可以把原型和需qiú文档发送给参会的相关人员,目的是让他们提前熟悉需qiú。若有问题及时收集,在需qiú评审之前向提问者解答,能大大提高需qiú评审会的效率。

三、评审中 – X节奏、应万变

需qiú评审的过程,本质上就是沟通,用语言配合原型文档的方式,将需qiú、逻辑清晰的表述出来,然后和所有人基本达成一致意见。但讲解之前一定要先向大家介绍一下本次项目的背景,大致可以朝这两个大个方向进行说明:

  1. 需qiú来自哪个人或者哪个部门等,他们遇到什么问题了?【现状】
  2. zhēn对这些问题,采用什么方案或者增加什么功能,来解决他们遇到的问题或提升什么体验及指标等;【预期】

需qiú评审原则上就是产品经理的“主场”,所要保持主场的气势,稳住场面。人人都是产品经理,正是因为人人zhēn对某一个功能都会有自己的想fǎ和意见,那么产品经理该怎么应付呢?

1. 合理的意见、想fǎ

zhēn对于这种意见,可能会给我们后续迭代有一定的启发,但是不一定要放在本次需qiú内。需qiú总有优先级排序的,应当先解决眼前紧急的问题。我们大可不必zhēn对每个意见一一作出解释,你们可以保留自己的意见,我负责记录,提高X效率。

2. 不要X纠结细节讨论

很多同学应该遇到过这种情况:你每一句话需qiú,总有人会打断你并和你扣细节,打破砂锅问到底,这不是什么好现象。细节是永远都扣不完的,如果在X上陷入细节的讨论,不仅浪费大家时间,而且对于产品经理来说也会非常痛苦。

这时候你可以制止那人,让你把这块功能讲完,再让大家提问题,实在有人要聊细节,建议在会后和他单独好好讨论,产品经理始终要记住把控X时间和节奏。

3. 逻辑漏洞、功能遗漏

如果对X了解不够深入,思考不周全,很容易被其他人发现逻辑或功能遗漏等问题,这对产品经理来说是属于比较严重的评审X了,错了就要挨打。一般不是较大的逻辑问题,评审X还是能继续开下去的,会后应当及时补充内容。

4. 不要把会评审成技术方案X议

每当遇到某些功能,对于技术来说实现比较有挑战性或者很感兴趣的时候,他们就会不知不觉的开始讨论用什么方fǎ实现好,该如何如何X作,留下一脸懵bī的你。这时候你要打住他们,如果逻辑没问题,怎么实现是技术的问题,不允许在X上占用太多时间来讨论具体方案。

5. 这个实现不了

技术们这样的回应时,想必大家也遇到过,不要慌,之所以这么回应,绝大情况下是背后有一个巨大的开发量,或者是时间紧张。

这种情况,千万不能洒乎乎的直接反驳“这个有那么麻烦嘛?”、“很简单的啊,这样搞搞就好了啊”,这种很容易被技术认为是洒bi的表现,严重的话会激化矛盾。

首先呢,我们要确认技术们的难点在哪里,是需要更多的开发时间呢,还是真的有一定开发难度。综合各方面因素,考虑是否值得这样的投入?如果真的是一个很重要的功能点,可以说清楚该功能对整个X的重要性,就算开发复杂、难度高,需要较多的时间也可以接受。

如果还是争论不止,那把这问题暂时放一下,会后叫上技术负责人和该项目开发人员一起在讨论,切记也不能占用要多时间。

四、评审后 – 查缺补漏、保持跟进

需qiú评审X结果后,我们还不能如释重负,还有事情要做呢!

1. 及时修改问题

小功能评审基本上可以百分百过,但是大项目基本上很少全票X的情况,都会有一些小修改小调整的。该修改的地方修改,该落实细节地方落实好细节,最终X邮件等方式告知大家。

2. 督促排期,X进度

督促各个岗位负责人zhēn对此次项任务周期,最后确认预估的整个开发周期。后续要持续跟进开发进度,直至完成上线。在跟进过程中,很有可能出现未考虑到的问题,这时候需要产品经理要和开发紧X作,讨论新的解决方案,并同步修改原型和需qiú说明。

3. 需qiú评审复盘

X上,大家都会各抒己见,对产品经理来说很多意见和想fǎ对自己很有启发,我们可以一一收集起来,也可以找同事帮自己记录下。X结束后,我们就要zhēn对这些想fǎ进行筛选分析,合理的进行后续的迭代工作。

还有一点也要反思自己X中,哪几个点做的还不够好的,及时改善不足之处,快速成长。

五、总结

在X中,产品经理被zhēn对是很正常的情况,X以上内容的介绍,大多数情况下可以帮助大家避免一些问题。当遇到X观点,我们常常会不自觉产生自我保护意识,一味的进行反驳,却忘了需qiú评审的目的,决不妥协和轻易妥协似乎都不是好办fǎ。

最后,祝大家顺利的渡过每一次需qiú评审,也可在留言区分享XX现有趣的事情!

#专栏作家#

道三,微信X号:产品大秘籍,人人都是产品经理专栏作家。以前写过代码,现在产品圈mō爬滚打,专注于电商领域产品设计、主要分享电商和供应链领域知识点。

本文原创发布于人人都是产品经理,未经作者许可,jìn止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!

2人打赏
收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 产品经理怎么做才能在需求评审中少挨打? https://www.xiongfawang.com/794.html

常见问题

相关文章

产品经理怎么做才能在需求评审中少挨打?-海报

分享本文封面