降低语速,完美应对需求评审
评审会议里,产品经理哪些小技巧?作者认为,降低语速可以准确传达需求,让开会人员理解地更透彻,自己的思考也能够更深度。
部分产品经理在主持需求评审会议时,习惯性地会用很快的语速完成需求评审。但大部分时候,语速越快,需求评审的质量也越差。
需求评审会议中,绝大多数的语速过快,都是我们在面对很多的开发时,容易紧张所导致的。
我们害怕自己方案中的漏洞被发现,害怕被开发拒绝,害怕自己讲得不够好。这些或多或少的恐惧,都会直接导致紧张。
人在紧张的时候,往往会想要早点结束,好逃离现在的处境,摆脱紧张的感受。此时,就会不自觉地提高语速。
语速过快导致的问题
参会人员跟不上
日常生活中,如果一个人说话的语速过快,倾听的人往往需要集中注意力,非常认真地去听,才能听清楚他说话的内容。在会议中,也是如此。
需求评审会议,看起来大家都是带着工作任务来参加会议,应该会比较认真。
但实际情况并非如此。
在会议室中,每一个参会开发的风格都不一样:
- 少数人会认真地听完全部内容;
- 有些可能只会听自己关注的点,自动忽略自己不关注的内容;
- 有些可能已经在想下班后要去打游戏;
- 有些可能还沉浸在会前没有解决的bug中;
- ……
不仅参会人员的注意力无法完全集中,接收、理解和分析信息的效率和能力也是参差不齐的。
参会人员不仅要听我们当前正在讲的内容,还需要见缝插针地理解和分析:
- 内容中有哪些概念?明确定义是什么?
- 逻辑关系是否有问题?
- 技术上如何实现这个需求?
- 有没有什么异常问题产品经理没考虑到,但是会影响技术方案设计?
- ……
效率高、能力强的人,能很快地听明白我们讲的内容,并完成自己的理解和分析;而效率低、能力弱的人,则需要时间来慢慢理解消化,否则不知所云。
在参会人员注意力无法集中和接收、理解、分析信息效率和能力参差不齐的前提下,如果我们讲解的语速过快,必然就会导致参会人员跟不上节奏。
最后,参会人员从需求评审会议中,可能只半知半解地理解了业务流程,有些甚至连个业务流程都没明白。会后,为了开发的顺利进行,还需要花大量的时间逐个逐个地解答他们提出来的疑问。
需求评审目的,完全没有达到。
影响团队对产品经理的认同
从产品研发的流程上看,产品经理是一个团队的核心成员。作为一个核心成员,需要让团队看到一个自信、沉稳、胸有成竹的状态。
当我们有理有据地告诉开发,我们为什么要这么做的时候;当我们面对质疑,沉稳应对的时候;当我们准备妥当,了然如胸的讲解需求的时候;我们都是在给团队带来安全感和方向感。
这样的产品经理,是非常容易被团队认可的。
需求评审会议中,我们的语速过快,参会开发感受到的很可能不是自信、沉稳、胸有成竹,而是信心不足、心浮气躁、张皇失措。长此以往,开发就会认为这个我们对自己做的产品方案不自信,进而贴上不靠谱的标签!
即使我们仅仅是语速快,并没有犯错,参会人员对我们的评价也会被降低。因为过快的语速,会让大家感到我们的耐心不够、信心不足。
团队对我们的认同,就在这一次次语速过快的需求评审会议中,不知不觉地降低。
为什么要降低语速?
参会人员理解的更透彻
前面我们讲到,人们接收、理解和分析信息的效率和能力是参差不齐的。要想通过需求评审会议高效传递信息,我们就必须考虑这个问题,照顾参会的大多数人。
有些开发在需求评审时,可能会投入时间思考很多问题。而较慢的语速,给了参会开发足够的时间差,他们在时间间隙中,有更多的时间理解我们所表达的内容,并分析所描述事物之间的逻辑关系。
而在较快的语速下,大家能听清楚我们在讲什么就已经非常不容易。完全没有时间去理解和分析。
让我们做一个简单的数学题:13+34+21+89+10=?
如果我念题的时候,语速很快,用时不到3秒。相信大家都来不及计算,甚至连题目都没记住,根本不可能完成计算。
但如果我每念完一个数字,停顿5秒,甚至更长时间,整个题目我花1分钟才念完,我相信大部分人都能马上得出计算结果。因为,我们一边听题目,一边就完成了计算。
需求评审会议,也是如此。
我们降低了语速,就给参会开发留下了更多的时间,不仅让大家听的更清楚,也有足够的时间深度地理解需求。
给自己留足思考的时间
在需求评审会议中,我们要把自己已经想明白的方案,有结构、有条理地表达出来,让参会开发也理解清楚——这并不是一个简单的任务。
看起来,我们只需要按自己准备的东西,从头到尾讲一遍,我们的任务就已经完成了。
但实际上,这是非常不专业的做法。因为需求评审会议,不能以“完成需求讲解”为目标,而应该以“准确、完整地传递了需求”为目标。
需求讲解完成,不是我们的目的,而仅仅是一种基本手段。而准确、完整地传递需求,需要我们有结构、有条理地完成需求讲解。
那如何才能有结构、有条理地完成需求讲解呢?
除了提前做好充分的准备,使用可读性更高的方式来撰写需求文档,还需要我们在需求评审时,有足够的缓冲时间去思考,接下来应该要如何表达。
我们在发言时,至少需要同时做2个事情:
- 将目前要表达的内容,表达出来;
- 准备接下来要讲的内容。
降低语速后,我们的大脑就能利用低语速带来的缓冲时间,完成思考。
更容易缓解紧张和保持理性
大部分人在进行公开演讲时,都会紧张,这是非常正常的表现。
作为听众,我们常常会以为演讲者侃侃而谈,一点都不紧张。这其实是因为对方控制地很好,或者有充足的演讲经验,可以从容应对,以至于听众看不出来。
在紧张的前提下,如果我们降低语速,主动思考的时间就会更多,大脑马上就可以发出指令,指挥身体的各个部位,调节紧张情绪。
一旦紧张情绪被抚平,我们的的注意力,就会逐渐被集中到“如何准确、有条理地表达”上。此时,需求评审就会进入一个正向循环,越讲越好。
同时,在需求评审中,还可能发生一些意想不到的争执。
如果我们用很快的语速去回应争执问题,甚至可能会让对方产生更大的反感。最后,导致无法理性面对冲突,陷入僵局。
而如果我们降低语速,我们就能利用时间间隔,组织和语言合适地进行回应。对方看到我们能如此沉稳、自信、耐心地解答他的疑惑,自然会对我们更加信服,冲突也更容易被化解。
放慢语速,让我们在需求评审时,不仅更容易缓解紧张情绪,同时还能让我们保持理性,从容应对一些突发情况。
总结
需求评审会议,有很多的技巧。
但我认为,降低语速是最有价值的技巧。不仅可以让参会开发理解更透彻,还能给我们留足思考的时间,缓解紧张情绪、保持理性状态,从而准确、完整地传递需求。
本文由 @誓博 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
专栏作家
誓博,微信公众号:产品慎思录。人人都是产品经理专栏作家。7年产品经验,专注电商交易系统方向。
本文原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
这个技巧确实很好,心态和技巧是一方面,主要还是产品对这个需求有足够的思考和了解!
一场评审会是否达到了目的,确实作为产品经理调整语速后,给自己大脑缓冲时间,给参会人员缓冲时间能给这场评审会议加分·
我的小技巧是在每次评审了一个需求后会附上一句“我这样说是否表达清楚”,大脑在线的参会人员就会给我反馈,没在线的也会被这句话打断并调整状态进入到评审会议中····
这个技巧也很有用,我一般会在讲完一个复杂逻辑的时候,问这个问题,引导开发主动反馈。
十年前做开发的时候,每次需求评审前都会仔细看PRD,记录疑问点并思考落地过程中可能的问题,在需求评审会议上大家直接沟通问题。
现在做了产品经理,发现现在的需求评审,都默认成了开发人员在会前不看PRD,只靠产品经理现场去讲,有的还边听边刷手机,后面搞不懂业务逻辑和需求细节,就开始抱怨产品经理太水。
这个问题是开发工作积极性和责任心的问题。需要领导从管理的角度来解决了。