产品、需求在日常工作中，少不了做需求讲解，像我们团队可能两周就要组织一波评审。有时涉及到交付团队的需求支持，售前团队的产品演示，相关讲解会更频繁。 在近两年持续的讲解过程中，发现了主讲人一些共性的问题，并通过几个月的尝试让组内的小伙伴逐渐掌握了基本讲解能力，今天归纳出来供大家参考，各位有什么其他好方法也欢迎留言交流。 需求讲解的质量不仅影响理解效果、评审效果，更可能对需求的范围，团队的效率、认可度等方面产生深远影响，其重要性不言而喻。

01 先抛几个最常见问题 上来直接讲功能 不管听众是谁，讲解内容基本不会变化 主讲人的得失心太重，反而影响了语言表达的准确性 没有提前演练（准备讲一小时，实际上40分钟就讲完了。漏讲、节奏乱、不通畅、断片了） 没有真正理解吸收，过程不自信，问题解答不好 其他的问题大家可以自由补充。 那么我们可以从哪些方面来着手解

01 先抛几个最常见问题 上来直接讲功能 不管听众是谁，讲解内容基本不会变化 主讲人的得失心太重，反而影响了语言表达的准确性 没有提前演练（准备讲一小时，实际上40分钟就讲完了。漏讲、节奏乱、不通畅、断片了） 没有真正理解吸收，过程不自信，问题解答不好 其他的问题大家可以自由补充。 那么我们可以从哪些方面来着手解决这些问题呢？ 讲解的背景：是售前阶段，还是需求初期，还是需求评审，亦或是上线培训。 看听众的身份：甲方的领导、业务方、测试方、技术方、还是最终使用的用户。 这里简单区分一下，不展开介绍： 售前阶段：更重要的是讲解价值、定位、目标客群及各角色的使用场景 需求初期：重点是先让听众和我们的方案思路达成一致，同时关联实施路径，不用讲太细节的内容

这里简单区分一下，不展开介绍： 售前阶段：更重要的是讲解价值、定位、目标客群及各角色的使用场景 需求初期：重点是先让听众和我们的方案思路达成一致，同时关联实施路径，不用讲太细节的内容 需求评审：注重整体方案逻辑及关联方如何配合，细节的内容要挑重点功能进行细致讲解 培训阶段：更注重如何使用、常见问题如何应对等方面 总之一句话“看人下菜碟”，切莫一套话术讲到地老天荒。 03 从宏观到微观（由浅入深，抽丝剥茧） 讲解正式开始的时候，无论是0-1的新需求，还是优化迭代需求，都要先介绍一下背景、用户角色、整体场景、使用流程，让大家对本次讲解有个基础的认知同频。然后再开始按场景优先级进行功能介绍、规则介绍。 就像拆一个快递盒一样。先看收件人和发件人是谁，然后打开箱子看到礼物的外包装，整体的长宽高，颜色形状。然后打开外包装，

04 场景代入（变枯燥为生动） 人的大脑更容易接收“故事”而非“概念”。所以讲了一段“概念”后，一定要穿插一个“故事”，最好是真实的例子。如果是大家身边的例子，效果就更好了。 在这里我也拿一个大家能快速理解的场景“举个栗子”：比如很多公司的OA，或者人事财务类管理平台会有“线上算薪”功能，也就是把每个月财务给大家计算工资的过程通过此功能线上计算（钉钉、HRSaaS等多类产品均有此模块）。针对这个模块，下面三种风格的讲解思路高下立判。

薪酬计算这个模块分为了以下几个大功能： 应发工资计算 社保计算 个税计算 实发工资计算 社保方案维护 算薪方案维护 员工薪酬档案管理 如何做好一场需求讲解 2022-05-23 17:09·人人都是产品经理 编辑导语：产品经理在日常工作中，经常要做需求讲解，而需求讲解的质量对需求的范围，团队的效率、认可度等方面有很大的影响。那么，如何做好一场需求讲解呢？本文作者提出了几点建议，一起来看一下吧。

产品、需求在日常工作中，少不了做需求讲解，像我们团队可能两周就要组织一波评审。有时涉及到交付团队的需求支持，售前团队的产品演示，相关讲解会更频繁。 在近两年持续的讲解过程中，发现了主讲人一些共性的问题，并通过几个月的尝试让组内的小伙伴逐渐掌握了基本讲解能力，今天归纳出来供大家参考，各位有什么其他好方法也欢迎留言交流。 需求讲解的质量不仅影响理解效果、评审效果，更可能对需求的范围，团队的效率、认可度等方面产生深远影响，其重要性不言而喻。

01 先抛几个最常见问题 上来直接讲功能 不管听众是谁，讲解内容基本不会变化 主讲人的得失心太重，反而影响了语言表达的准确性 没有提前演练（准备讲一小时，实际上40分钟就讲完了。漏讲、节奏乱、不通畅、断片了） 没有真正理解吸收，过程不自信，问题解答不好 其他的问题大家可以自由补充。 那么我们可以从哪些方面来着手解决这些问题呢？ 02 区分人群（见人说人话，见神说神话） 一定要根据听众的不同，差异化整理自己的话术，包括讲解的细致程度。 可能文档都是一样的，但是给项目经理讲、给开发人员讲、给测试人员讲、给需求组同事讲、给领导讲，侧重点一定是不一样的。 组内的同事要细讲，现状、业务规则、交互规则、关联功能、处理逻辑，在时间充裕的前提下，能多讲点就多讲点。

如果是项目经理或者测试人员，还可以把自己这样设计的原因、思路说出来，让大家都能与你共情。同时关联功能、关键功能记得讲解的时候时不时“敲敲黑板”提醒大家注意。 给领导讲更多的是讲解原因、思路、目标、效果，并将所涉的难点或需要领导重点关注的问题说出来。 如果给客户讲，又是一种方式。 看讲解的背景：是售前阶段，还是需求初期，还是需求评审，亦或是上线培训。 看听众的身份：甲方的领导、业务方、测试方、技术方、还是最终使用的用户。 这里简单区分一下，不展开介绍： 售前阶段：更重要的是讲解价值、定位、目标客群及各角色的使用场景 需求初期：重点是先让听众和我们的方案思路达成一致，同时关联实施路径，不用讲太细节的内容 需求评审：注重整体方案逻辑及关联方如何配合，细节的内容要挑重点功能进行细致讲解 培训阶段：更注重如何使用、常见问题如何应对等方面 总之一句话“看人下菜碟”，

03 从宏观到微观（由浅入深，抽丝剥茧） 讲解正式开始的时候，无论是0-1的新需求，还是优化迭代需求，都要先介绍一下背景、用户角色、整体场景、使用流程，让大家对本次讲解有个基础的认知同频。然后再开始按场景优先级进行功能介绍、规则介绍。 就像拆一个快递盒一样。先看收件人和发件人是谁，然后打开箱子看到礼物的外包装，整体的长宽高，颜色形状。然后打开外包装

04 场景代入（变枯燥为生动） 人的大脑更容易接收“故事”而非“概念”。所以讲了一段“概念”后，一定要穿插一个“故事”，最好是真实的例子。如果是大家身边的例子，效果就更好了。 在这里我也拿一个大家能快速理解的场景“举个栗子”：比如很多公司的OA，或者人事财务类管理平台会有“线上算薪”功能，也就是把每个月财务给大家计算工资的过程通过此功能线上计算（钉钉、HRSaaS等多类产品均有此模块）。针对这个模块，下面三种风格的讲解思路高下立判。

薪酬计算这个模块分为了以下几个大功能： 应发工资计算 社保计算 个税计算 实发工资计算 社保方案维护 算薪方案维护 员工薪酬档案管理 下面我们来具体看每个功能是怎么实现的。 如果想完成线上的薪酬计算，我们需要先维护好各个员工的薪酬档案，也就是每个人的基本工资、补助之类的信息；然后制定每个人的算薪公式，五险一金缴纳方案。 这些前期准备完成之后，每次线上算薪时，先通过每个人的算薪公式和工资项，计算我们的应发工资；然后通过应发工资和五险一金方案计算我们的社保扣除金额；然后计算我们的个税，最后相减得出我们的实发工资。

我们公司每个月给大家算工资的时候，财务或者人事都要先根据咱们的考勤、绩效、请假、加班等信息，按照公司的算薪公式计算出大家的应发工资，或者叫税前工资。 然后根据咱们五险一金的缴纳比例、基数来计算我们这个月各项社保、公积金的扣除金额；然后再给大家算这个月应该扣除多少钱的个人所得税；最后通过应发工资再减去要扣除的社保、个税，得出我们的实发工资。 在这个过程中，衍伸出来了我们今天要讲解的几个核心功能： 而在正式计算之前，公司要先知道我们每个人的固定收入是多少，工资组成是怎样的，五险一金缴纳比例和基数是怎样的。所以系统需要通过“员工薪酬档案”、“算薪方案”、“社保方案”几个功能来配置生成这些信息，从而完整的完成我们算薪过程。 下面我们来具体看这些功能的描述和规则。

这三种表达方式在实际讲解中都是存在的，而且以前两种尤其是第一种居多。而且我们会发现一个神奇的现象：字多的比字少的听起来更容易理解。 因为我们需要在具体的需求讲解之前，先让听众对所涉及的功能有一个清晰的认知。通过现实生活中的场景代入，衍伸类比出系统中的抽象功能，大家才能真正明白这些功能是要解决什么问题。在听的时候才能具象地引出高质量的疑问。所以这个过程一定要精心的准备且多费一些口舌才行（当然废话不算）。 即便这样，我们也会经常发现讲完之后，对方的提问明显是没听明白……当然也可能是他个人的问题。对于讲解人来说，一次讲解能够保证大多数人能思维同频，认知一致就已经很厉害了。

同时场景代入不仅仅是开头，后面涉及到具体需求讲解时，对于一些相对复杂、或者认为听众容易产生歧义的功能，依然可以通过这种方式来提升效果。 代入场景的过程也需要讲解人提前准备、反复斟酌。一定要避免用错场景的情况发生，否则得不偿失。 05 多练（勤能补拙） 去年有一位新同事，按照团队的培训计划进行产品学习，并在一周后进行产品讲解。第一次讲解的效果非常差，虽然他准备了两大篇稿子，但真正脱稿讲的时候只讲了15分钟就因为屡次卡壳放弃了。 之后我又给了他一天时间准备。我发现那一天他一直在会议室里演练，在黑板上反复画图。自然而然第二次讲解能够通过考核。 所以即便我们准备好了提纲、稿子，乃至PPT的备注。真正在正式讲解的时候，如果没有多次演练，那效果一定不会好。

06 能脱稿最好（对内容全然吸收后的输出最有魅力） 很多需求人员前期对自己所涉业务有了初步认知后，经过多次练习便能够顺利的完成一次讲解。但是在答疑过程还是会发现很多问题不知道怎么解答。 能够做好一场准备充分的讲解只是完成了第一步【熟练】，真正第二步的【掌握】则是需要长时间的积累、思考，以及全面的答疑才能最终烂熟于心，随用随取。 自己的思考也很容易陷入思维怪圈，无法全面的发现问题。所以要多和团队内部各个岗位的同事交流。看看他们对这个需求的认知、理解、疑问。从而在这个过程中完善自己的想法。 同时在上一段提到的反复练习过程中也可以同步思考，讲到哪里，听众可能会提什么样的问题，我要如何应答。尤其是自己在设计过程中的疑问是如何解决的，其他人也很有可能有相似的问题。 而且不同的听众关注点不同，问的问题也不尽相同，我们要尽可能多角度思考，以备不时之需。 真正的大佬们一定是经历过几十甚至上百次不同场景、不同人群、不同业务的讲解、吸收、思考之后才形成随机应变的能力。 正所谓“见多识广”。 07 多复盘（在复盘中快速进步） 每次讲解完成之后都要整理大家的提问清单，事后再考虑一下如何更好地回答，以后肯定用得上。 讲解的过程，尤其是前几次的讲解，有条件的话，能录音最好全程录音，事后再听几次，在复盘中让自己对本业务的认知更丰满，发现自己现场无法察觉的问题以及可提升的小细节。 其中小细节一定不能忽视，它迟早会成为你前进路上的绊脚石。如不合适的口头禅，不合适的停顿，重点内容的抑扬顿挫及语气重音