部分产品经理在主持需求评审会议时，习惯性地会用很快的语速完成需求评审。但大部分时候，语速越快，需求评审的质量也越差。

需求评审会议中，绝大多数的语速过快，都是我们在面对很多的开发时，容易紧张所导致的。

我们害怕自己方案中的漏洞被发现，害怕被开发拒绝，害怕自己讲的不够好。

这些或多或少的恐惧，都会直接导致紧张。

人在紧张的时候，往往会想要早点结束，好逃离现在的处境，摆脱紧张的感受。此时，就会不自觉地提高语速。

语速过快问题

参会人员跟不上

日常生活中，如果一个人说话的语速过快，倾听的人往往需要集中注意力，非常认真地去听，才能听清楚他说话的内容。在会议中，也是如此。

需求评审会议，看起来大家都是带着工作任务来参加会议，应该会比较认真。

但实际情况并非如此。

在会议室中，每一个参会开发的风格都不一样:

少数人会认真地听完全部内容;

有些可能只会听自己关注的点，自动忽略自己不关注的内容

有些可能已经在想下班后要去打游戏；

有些可能还沉浸在会前没有解决的bug中；

······

不仅参会人员的注意力无法完全集中，接收、理解和分析信息的效率和能力也是参差不齐的。

参会人员不仅要听我们当前正在讲的内容，还需要见缝插针地理解和分析：

内容中有哪些概念？明确定义是什么？

逻辑关系是否有问题？

技术上如何实现这个需求？

有没有什么异常问题产品经理没考虑到，但是会影响技术方案设计？

······

效率高、能力强的人，能很快地听明白我们讲的内容，并完成自己的理解和分析；而效率低、能力弱的人，则需要时间来慢慢理解消化，否则，就会不知所云。

在参会人员注意力无法集中和接收、理解、分析信息效率和能力参差不齐的前提下，如果我们讲解的语速过快，必然就会导致参会人员跟不上节奏。

最后，参会人员从需求评审会议中，可能只半知半解地理解了业务流程，有些甚至连个业务流程都没明白。会后，为了开发的顺利进行，还需要花大量的时间逐个逐个地解答他们提出来的疑问。

需求评审目的，完全没有达到。

影响团队对产品经理的认同

从产品研发的流程上看，产品经理是一个团队的核心成员。作为一个核心成员，需要让团队看到一个自信、沉稳、胸有成竹的状态。

当我们有理有据地告诉开发，我们为什么要这么做的时候；当我们面对质疑，沉稳应对的时候；当我们准备妥当，了然如胸的讲解需求的时候；我们都是在给团队带来安全感和方向感。
这样的产品经理，是非常容易被团队认可的。

需求评审会议中，我们的语速过快，参会开发感受到的很可能不是自信、沉稳、胸有成竹，而是信心不足、心浮气躁、张皇失措。长此以往，开发就会认为这个我们对自己做的产品方案不自信，进而贴上不靠谱的标签！

即使我们仅仅是语速快，并没有犯错，参会人员对我们的评价也会被降低。因为过快的语速，会让大家感到我们的耐心不够、信心不足。

团队对我们的认同，就在这一次次语速过快的需求评审会议中，不知不觉地降低。

为什么要降低语速？

参会人员理解的更透彻

前面我们讲到，人们接收、理解和分析信息的效率和能力是参差不齐的。要想通过需求评审会议高效传递信息，我们就必须考虑这个问题，照顾参会的大多数人。

有些开发在需求评审时，可能会投入时间思考很多问题。而较慢的语速，给了参会开发足够的时间差，他们在时间间隙中，有更多的时间理解我们所表达的内容，并分析所描述事物之间的逻辑关系。

而在较快的语速下，大家能听清楚我们在讲什么就已经非常不容易。完全没有时间去理解和分析。

让我们做一个简单的数学题：13+34+21+89+10=？

如果我念题的时候，语速很快，用时不到3秒。相信大家都来不及计算，甚至连题目都没记住，根本不可能完成计算。

但如果我每念完一个数字，停顿5秒，甚至更长时间，整个题目我花1分钟才念完，我相信大部分人都能马上得出计算结果。因为，我们一边听题目，一边就完成了计算。

需求评审会议，也是如此。我们降低了语速，就给参会开发留下了更多的时间，不仅让大家听的更清楚，也有足够的时间深度地理解需求。

给自己留足思考的时间

在需求评审会议中，我们要把自己已经想明白的方案，有结构、有条理地表达出来，让参会开发也理解清楚。这并不是一个简单的任务。

看起来，我们只需要按自己准备的东西，从头到尾讲一遍，我们的任务就已经完成了。

但实际上，这是非常不专业的做法。因为需求评审会议，不能以“完成需求讲解”为目标，而应该以“准确、完整地传递了需求”为目标。

需求讲解完成，不是我们的目的，而仅仅是一种基本手段。而准确、完整地传递需求，需要我们有结构、有条理地完成需求讲解。

那如何才能有结构、有条理地完成需求讲解呢？

除了提前做好充分的准备，使用可读性更高的方式来撰写需求文档，还需要我们在需求评审时，有足够的缓冲时间去思考，接下来应该要如何表达。

我们在发言时，至少需要同时做2个事情：

将目前要表达的内容，表达出来；

准备接下来要讲的内容。

而降低语速后，我们的大脑就能利用低语速带来的缓冲时间，完成思考。

更容易缓解紧张和保持理性

大部分人在进行公开演讲时，都会紧张，这是非常正常的表现。

作为听众，我们常常会以为演讲者侃侃而谈，一点都不紧张。这其实是因为对方控制的很好，或者有充足的演讲经验，可以从容应对，以至于听众看不出来。

在紧张的前提下，如果我们降低语速，主动思考的时间就会更多，大脑马上就可以发出指令，指挥身体的各个部位，调节紧张情绪。

一旦紧张情绪被抚平，我们的的注意力，就会逐渐被集中到“如何准确、有条理地表达”上。此时，需求评审就会进入一个正向循环，越讲越好。

同时，在需求评审中，还可能发生一些意想不到的争执。

如果我们用很快的语速去回应争执问题，甚至可能会让对方产生更大的反感。最后导致我们无法理性面对冲突，陷入僵局。

而如果我们降低语速，我们就能利用时间间隔，组织和语言合适地进行回应。对方看到我们能如此沉稳、自信、耐心地解答他的疑惑，自然会对我们更加信服，冲突也更容易被化解。

放慢语速，让我们在需求评审时，不仅更容易缓解紧张情绪，同时还能让我们保持理性，从容应对一些突发情况。

总结

需求评审会议，有很多的技巧。但我认为，降低语速是最有价值的技巧。不仅可以让参会开发理解的更透彻，还能给我们留足思考的时间，缓解紧张情绪、保持理性状态，从而准确、完整地传递需求。

降低语速是需求评审最有价值的技巧相关推荐

软件测试需求评审目的,需求评审的重要性
需求评审常见问题汇总: - 目标性需求没有沟通好,后面的需求变成空中楼阁. - 缺乏评审的可操作依据,遗漏评审内容. - 没有作好前期准备工作,导致评审时间长,效率低. - 没有选择合适的评审人员,无 ...
软件项目中如何开展有效的需求评审
1.需求评审的重要性在软件项目中,需求分析是最开始的工作,同时也是最重要的工作.需求分析如果做得不够详细或者是偏离用户需求或者是存在缺陷的话,往往会给项目带来灭绝性的灾难,不重视需求过程的项目团队将 ...
需求评审五个维度框架分析及其带来的启示-2-框架原理
本文试图归纳分析近年来出现的需求评审方式方法,全面涵盖系统性评审和非系统性评审,提出五维需求评审框架. 首先确定对于需求评审的定义,结合传统需求阶段评审和敏捷迭代开发中相关需求实践,得如下定义. 定义 ...
需求评审五个维度框架分析及其带来的启示-总起
摘要近年来随着CMMI.敏捷软件开发的推进,出现了多种多样的需求评审类型,这些类型超出了标准评审类型的范围.根据这些情况进行分析,得到了一个新的软件需求评审框架,这个新框架由5个维度组成: 1,组织 ...
如何进行需求测试/需求评审
由于软件系统的复杂性,在需求分析阶段可能存在着开发方对委托方业务需求理解不全面.不准确的情况.在这种情况下,如果不进行相关的质量控制,往往会造成开发结果与用户需求不一致的后果.需求测试的目的就在于保证 ...
简述需求评审的目的、主要内容、主要参加人员.
目的: 1.了解需求的动机.目标.方案.排期等,为开发设计.测试设计做准备: 2.降低需求设计本身的不完整.不一致.不准确等出现的可能性 3.通过评审尽可能降低团队成员理解的不一致性 4.提早考虑排期 ...
深圳软件测试培训：软件测试的需求评审
深圳软件测试培训:软件测试的需求评审需求评审 1．需求阶段评审的角色和职责一句话,根据具体情况选择相关人员,充当相关角色,履行相关职责,大家也别吐槽我,现实就是这样,别去记忆这些死规则了 2．好的 ...
产品经理学习总结（3）——测试用例的需求评审
前言软件评审,IEEE定义为'一种对软件元素所做的正式的.同行间的评审活动,其目的在于验证软件元素满足其规格说明,并能符合标准的要求'.CMMI中要求按照已文档化的规程在所选择的项目里程碑处(阶段成 ...
测试人员如何进行需求评审
最近一直在忙于各种工作上的事情,加上周末设计与录制在腾讯课堂上放的各种课程,没有太多的去写文档,以至于最近微信公众号上发布的都是以往收集的内容.鉴于最近在和大家交流的过程中,发现不少同学的功能测试的基 ...

降低语速是需求评审最有价值的技巧