邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9950 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 产品经理的世界没有对错
免费
01 | 验证码是个好设计吗?
02 | 产品经理工具指南
03 | 产品案例分析·Trigraphy的设计哲学
04 | 如何当好AI时代的产品经理?(学习篇)
05 | 如何当好AI时代的产品经理?(实践篇)
06 | 产品案例分析 · The Guardian的文本之美
07 | 关于需求变更(上):需求背后的需求
08 | 关于需求变更(下) : 化变更于无形
09 | 产品案例分析:Hopper的“人工智能”
10 | 产品被抄袭了,怎么办?
11 | 如何借鉴灵感?
12 | 产品案例分析:LabRdr的设计实验
13 | 无用却必要:产品规划(上)
14 | 留白与节奏:产品规划(下)
15 | 产品案例分析:Mimo与Learn Python的导学之趣
16 | 在内部产品中找到产品经理的价值
17 | 产品经理如何获得非权力性的影响力?
18 | 产品案例分析:WWF Together的情怀设计
19 | 产品经理如何与开发打交道(上):打破思维的边界
20 | 产品经理如何与开发打交道(下):合作与共赢
21 | 产品案例分析:Fabulous的精致养成
22 | 产品经理的图文基本功(上):产品文档
23 | 产品经理的图文基本功(下):产品图例
24 | 产品案例分析:PathSource的混乱与直观
25 | 产品世界的暗黑模式:操纵的诱惑
26 | 写好产品文档的诀窍
27 | 产品案例分析:Quartz&Hooked的对话式交互
28 | 产品分析的套路(上):谁是利益相关者?
29 | 产品分析的套路(中):解决什么问题?
30 | 产品案例分析:Primer的扑克牌交互
31 | 产品分析的套路(下):如何出解决方案?
32 | 从受众规模、需求频率和强度出发:排定需求优先级的方法(上)
33 | 产品案例分析:Arts & Culture 的架构之美
34 | 价值曲线分析:排定需求优先级的方法(下)
35 | 答疑时间:关于产品经理的12个问题
36 | 产品案例分析:解读知识星球
37 | 如何做好需求评审(上):需求评审不只是一次会议
38 | 如何做好需求评审(下):在评审中控住全场
39 | 产品案例分析:SeatGeek的订票设计
40 | 新年给产品经理的几碗鸡汤
41 | 产品经理的项目管理心得
42 | 产品案例分析:Unread的阅读体验
43 | “玩”的力量:从游戏设计中学习产品设计(上)
44 | “玩”的启示:从游戏设计中学习产品设计(下)
45 | 产品案例分析:Chartistic的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

38 | 如何做好需求评审(下):在评审中控住全场

邱岳 2018-02-15
爆竹声中一岁除,2018 pretty cool。
千门万户曈曈日,all your dreams coming true。
——王安石 & 邱岳
作为产品经理,需求评审时最头疼的事情莫过于参与人都心不在焉,嬉皮笑脸就通过了评审,结果到了项目都快做完了突然又提出问题,这时再返工除了浪费资源,还会打击士气。
除此之外,有的产品经理甚至提到需求评审就紧张,因为经常会有人跳出来挑战产品方案,需求评审会最终演变成争吵掐架会,没有结果产出,大家不欢而散。
上次分享中我们聊到了需求评审的目的和准备工作,今天我分享几个能帮助我们提高评审效率的方法,希望可以给你带来启发。

1. 当心知识的诅咒

我们说到了评审会上大家不能积极参与的情况,通常情况产品经理都会责怪评审会的参与人,觉得他们没有积极投入,缺乏主动性。其实我觉得并不完全是这样,很多时候他们也是有苦难言。
这里要先提到一个叫做“知识的诅咒”的概念,指的是当一个人拥有某种知识之后,就很难想象和模拟出不知道它时的状态,因为陷入这样的状态会影响沟通和表达,仿佛就像受到诅咒一般,所以由此得名。
有个著名的心理学实验,让一组人在限定的范围内选择一首非常简单的曲子,然后在桌面上敲击它的节奏,另一组来猜具体是哪一首,最终结果是只有 2.5% 的听众猜对了曲目,而敲击者在敲打节奏之前,预测这一概率至少是 50%。
你也可以试试,在脑中试想一首旋律,然后手指敲打书桌,这时你会觉得自己敲打出的节奏如此准确清晰,别人不可能听不出来啊;但倘若你把桌面上的敲击声录下来,回放自己听,你就会发现当脑子里没有旋律的时候,这些敲击声就像是一串毫无规律的莫尔斯码。
作为产品经理,对业务和产品细节的了解就像脑海中的旋律,台上的你其实无法想象坐在下面听讲的人的处境。我参加过类似的评审会,虽然抱定全情投入的决心,但产品经理在上面讲不了几分钟,我就完全迷失了。
所以我建议你在做宣讲或者评审需求的时候,要像做产品设计的时候一样,把自己放到听众的上下文中去,把来龙去脉讲清楚。哪怕有一部分听众会觉得你有点啰嗦,也要讲,尽可能从所有人都了解的背景开始讲起,逐渐向外延伸,像讲故事一样。大部分人听到自己已经知道的事情时会有安全感,以此为基础延伸开来,才能让听众感到踏实和好奇,摆脱知识的诅咒。

2. 不要强迫,要吸引

和与人相处一个道理,当听众没有积极参与的时候,我们要做的不是强迫他们,而是引导他们来理解。在需求评审会上引导听众的最有力武器就是“具体”。
先讲个故事,这是我在一本书上看到的,说一个产品经理在公司内部做便携式平板电脑的提案,在上面介绍这个平板电脑的外观、尺寸、数据,说了半天下面的听众一头雾水,鸦雀无声。这时他发现自己随身携带的文件夹的尺寸跟这个产品的设计尺寸很相近,于是灵机一动,把这个文件夹扔到会议桌中间,说:这就是那个平板电脑的样子。
有人拿起那个文件夹端详,然后传给下一个人,终于有人开始发言,并且逐渐演变成了七嘴八舌的热烈讨论,开始提出问题,讨论功能特性。所以你看,一个莫名其妙却足够具体的文件夹,就能帮助所有漂浮在空中虚无缥缈的概念落地。
对于软件产品来说,我们的“文件夹”就是用户场景和用例故事。
为了让听众理解需求和方案,我们最好可以从场景和故事出发,用具体的案例来跟听众沟通,而不是对着文档从头到尾照本宣科。我过去的习惯是,先整体地介绍业务,大的逻辑和背景,然后用一个实际的业务案例把相关的功能和流程串讲一遍,最后回到文档本身,把需求文档从头到尾过一遍。
比如我之前做工单流转的需求,里面涉及了很多角色和业务场景,还有一张巨大的流程图。为了让所有人能看懂这个流程图,我就编了一个客户案例,然后还花了很多时间做幻灯片的动画,上面有一个卡通形象,顺着这个流程图移动,每移动到一个点,会停下来,然后跟大家解释在这个流程点上,系统的界面会是什么样子。
那次评审很成功,虽然流程和逻辑非常复杂,但基本上没什么人走神,这是因为大家都可以在具体的用例故事里理解需求和方案。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • 刘祯
    我只能感叹,关于需求评审的每一点都恰到好处,这让我有了更多的信心与武器来面对产品工作。我已经把这几篇文章收藏了,会一步一步去实践起来。

    新的一年,我的目标就是成为向二爷一样牛逼的产品经理。

    这已经是第 37 篇专栏文章了,我也会继续留言下去。感谢二爷的持续分享,感谢池老师的引见,感谢「极客时间」团队的辛苦付出。

    祝大家新年快乐,工作、生活、学习旺旺旺~

    作者回复: 貌似换头像了 :P

    希望我们都能有突破,有新的收获和成长

    2018-02-15
    4
  • 林彦
    小公司里翻译老板或需求方的想法,和开发方交待背景,解读场景,把它们拆分成开发放能理解,能认同的具体元素,这个过程在现实中经常缺乏。

    技术出身的创业公司老板们是如何在资源紧张,变化迅速的环境中找到一个合适的产品经理的?靠过去的人脉积累拉拢或推荐,靠物色合适的人刻意培养,自己承担部分或大多数产品经理的职责。

    很多非互联网公司的从业人员和他们聊天并没有典型的互联网公司的产品经理这种角色,有项目经理,产品线经理。

    他们在创业小公司阶段是不是有一个善于翻译用户需求的一线销售/商务,还是有一个明白用户需求,愿意花不少时间与开发执行人员沟通的老板/技术领导,还是开发核心既实现能力强,又情商高,善于沟通,很快抓住非工程领域的问题关键并建立与工程领域的联系。
    2018-02-15
    3
  • 张伟
    “不要让赢得争吵,替代了最终的评审目的”一句话概括了评审中的冲突处理
    2018-02-22
    2
  • CC
    今天的文章让我注意到“换位思考”的重要性。

    自己踩过几次“知识的诅咒”的坑,就是因为没有换位思考。自己第一次主持评审时,下意识地假设听众和我一样有相关的背景知识,在一开始没有很好的铺垫和交代,导致很短的时间后,听众明显开始迷失。二爷文中“旋律”的类比,感同身受。

    这进一步让我想到了“类比”。就像文中提到的“文件夹”一样,类比可以让抽象的事物更具体,提起听众兴趣。同时,类比要选择听众熟悉的事物,能让听众产生安全感,把自己的体验带入思考,会让思维更活跃。

    以后如果还有机会主持评审,希望自己能做得更好。感觉由于需求评审流程的存在,也会督促产品经理严谨对待需求,让项目有一个很好的开头。

    祝大家的的需求评审都凯旋而归。

    感谢二爷在大年三十的更新,祝狗年更旺!

    作者回复: 加油加油💪

    2018-02-15
    1
  • ly
    可以具体说一下需求评审按照怎样的方法,讲给开发听,可以让对方理解并且显得自己更专业
    2019-11-19
  • DebugCat
    哈哈哈😂,作为开发,每次开需求评审...其他部门的开发几乎从来没有提前了解过需求,除了现场怼产品经理,就是“这个怎么能这么做?....这个做不了!”...怼到最后也没有任何正效的产出,我也是服了,浪费大家时间
    2018-10-22
  • 彭龙
    我一般会在之前单个沟通一遍
    2018-07-27
  • Dylan
    避免情绪化地讨论确实很难做到,在实际评审种,我们如若能做到延迟思考,思考对方背后的真正有价值动机,及时表达和沟通,相信可以节约大家很多时间。
    2018-07-24
  • 刘世芬
    二爷,一个完整的需求,用户提交的需求信息应该包含哪些内容信息?需求分析应该从哪几方面入手?
    2018-07-18
收起评论
9
返回
顶部