编辑导语：产品经理在日常工作中，经常要做需求讲解，而需求讲解的质量对需求的范围，团队的效率、认可度等方面有很大的影响。那么，如何做好一场需求讲解呢？本文作者提出了几点建议，一起来看一下吧。

产品、需求在日常工作中，少不了做需求讲解，像我们团队可能两周就要组织一波评审。有时涉及到交付团队的需求支持，售前团队的产品演示，相关讲解会更频繁。

在近两年持续的讲解过程中，发现了主讲人一些共性的问题，并通过几个月的尝试让组内的小伙伴逐渐掌握了基本讲解能力，今天归纳出来供大家参考，各位有什么其他好方法也欢迎留言交流。

需求讲解的质量不仅影响理解效果、评审效果，更可能对需求的范围，团队的效率、认可度等方面产生深远影响，其重要性不言而喻。

01 先抛几个最常见问题

• 上来直接讲功能
• 不管听众是谁，讲解内容基本不会变化
• 主讲人的得失心太重，反而影响了语言表达的准确性
• 没有提前演练（准备讲一小时，实际上40分钟就讲完了。漏讲、节奏乱、不通畅、断片了）
• 没有真正理解吸收，过程不自信，问题解答不好

其他的问题大家可以自由补充。

那么我们可以从哪些方面来着手解决这些问题呢？

02 区分人群（见人说人话，见神说神话）

一定要根据听众的不同，差异化整理自己的话术，包括讲解的细致程度。

可能文档都是一样的，但是给项目经理讲、给开发人员讲、给测试人员讲、给需求组同事讲、给领导讲，侧重点一定是不一样的。

组内的同事要细讲，现状、业务规则、交互规则、关联功能、处理逻辑，在时间充裕的前提下，能多讲点就多讲点。

如果是项目经理或者测试人员，还可以把自己这样设计的原因、思路说出来，让大家都能与你共情。同时关联功能、关键功能记得讲解的时候时不时“敲敲黑板”提醒大家注意。

给领导讲更多的是讲解原因、思路、目标、效果，并将所涉的难点或需要领导重点关注的问题说出来。

如果给客户讲，又是一种方式。

看讲解的背景：是售前阶段，还是需求初期，还是需求评审，亦或是上线培训。

看听众的身份：甲方的领导、业务方、测试方、技术方、还是最终使用的用户。

这里简单区分一下，不展开介绍：

• 售前阶段：更重要的是讲解价值、定位、目标客群及各角色的使用场景
• 需求初期：重点是先让听众和我们的方案思路达成一致，同时关联实施路径，不用讲太细节的内容
• 需求评审：注重整体方案逻辑及关联方如何配合，细节的内容要挑重点功能进行细致讲解
• 培训阶段：更注重如何使用、常见问题如何应对等方面

总之一句话“看人下菜碟”，切莫一套话术讲到地老天荒。

03 从宏观到微观（由浅入深，抽丝剥茧）

讲解正式开始的时候，无论是0-1的新需求，还是优化迭代需求，都要先介绍一下背景、用户角色、整体场景、使用流程，让大家对本次讲解有个基础的认知同频。然后再开始按场景优先级进行功能介绍、规则介绍。

就像拆一个快递盒一样。先看收件人和发件人是谁，然后打开箱子看到礼物的外包装，整体的长宽高，颜色形状。然后打开外包装，发现里面有三个小盒子。再逐一开箱“品鉴”。

04 场景代入（变枯燥为生动）

人的大脑更容易接收“故事”而非“概念”。所以讲了一段“概念”后，一定要穿插一个“故事”，最好是真实的例子。如果是大家身边的例子，效果就更好了。

在这里我也拿一个大家能快速理解的场景“举个栗子”：比如很多公司的OA，或者人事财务类管理平台会有“线上算薪”功能，也就是把每个月财务给大家计算工资的过程通过此功能线上计算（钉钉、HRSaaS等多类产品均有此模块）。针对这个模块，下面三种风格的讲解思路高下立判。

薪酬计算这个模块分为了以下几个大功能：

• 应发工资计算
• 社保计算
• 个税计算
• 实发工资计算
• 社保方案维护
• 算薪方案维护
• 员工薪酬档案管理

下面我们来具体看每个功能是怎么实现的。

如果想完成线上的薪酬计算，我们需要先维护好各个员工的薪酬档案，也就是每个人的基本工资、补助之类的信息；然后制定每个人的算薪公式，五险一金缴纳方案。

这些前期准备完成之后，每次线上算薪时，先通过每个人的算薪公式和工资项，计算我们的应发工资；然后通过应发工资和五险一金方案计算我们的社保扣除金额；然后计算我们的个税，最后相减得出我们的实发工资。

我们公司每个月给大家算工资的时候，财务或者人事都要先根据咱们的考勤、绩效、请假、加班等信息，按照公司的算薪公式计算出大家的应发工资，或者叫税前工资。

然后根据咱们五险一金的缴纳比例、基数来计算我们这个月各项社保、公积金的扣除金额；然后再给大家算这个月应该扣除多少钱的个人所得税；最后通过应发工资再减去要扣除的社保、个税，得出我们的实发工资。

在这个过程中，衍伸出来了我们今天要讲解的几个核心功能：

而在正式计算之前，公司要先知道我们每个人的固定收入是多少，工资组成是怎样的，五险一金缴纳比例和基数是怎样的。所以系统需要通过“员工薪酬档案”、“算薪方案”、“社保方案”几个功能来配置生成这些信息，从而完整的完成我们算薪过程。

下面我们来具体看这些功能的描述和规则。

这三种表达方式在实际讲解中都是存在的，而且以前两种尤其是第一种居多。而且我们会发现一个神奇的现象：字多的比字少的听起来更容易理解。

因为我们需要在具体的需求讲解之前，先让听众对所涉及的功能有一个清晰的认知。通过现实生活中的场景代入，衍伸类比出系统中的抽象功能，大家才能真正明白这些功能是要解决什么问题。在听的时候才能具象地引出高质量的疑问。所以这个过程一定要精心的准备且多费一些口舌才行（当然废话不算）。

即便这样，我们也会经常发现讲完之后，对方的提问明显是没听明白……当然也可能是他个人的问题。对于讲解人来说，一次讲解能够保证大多数人能思维同频，认知一致就已经很厉害了。

同时场景代入不仅仅是开头，后面涉及到具体需求讲解时，对于一些相对复杂、或者认为听众容易产生歧义的功能，依然可以通过这种方式来提升效果。

代入场景的过程也需要讲解人提前准备、反复斟酌。一定要避免用错场景的情况发生，否则得不偿失。

05 多练（勤能补拙）

去年有一位新同事，按照团队的培训计划进行产品学习，并在一周后进行产品讲解。第一次讲解的效果非常差，虽然他准备了两大篇稿子，但真正脱稿讲的时候只讲了15分钟就因为屡次卡壳放弃了。

之后我又给了他一天时间准备。我发现那一天他一直在会议室里演练，在黑板上反复画图。自然而然第二次讲解能够通过考核。

所以即便我们准备好了提纲、稿子，乃至PPT的备注。真正在正式讲解的时候，如果没有多次演练，那效果一定不会好。

06 能脱稿最好（对内容全然吸收后的输出最有魅力）

很多需求人员前期对自己所涉业务有了初步认知后，经过多次练习便能够顺利的完成一次讲解。但是在答疑过程还是会发现很多问题不知道怎么解答。

能够做好一场准备充分的讲解只是完成了第一步【熟练】，真正第二步的【掌握】则是需要长时间的积累、思考，以及全面的答疑才能最终烂熟于心，随用随取。

自己的思考也很容易陷入思维怪圈，无法全面的发现问题。所以要多和团队内部各个岗位的同事交流。看看他们对这个需求的认知、理解、疑问。从而在这个过程中完善自己的想法。

同时在上一段提到的反复练习过程中也可以同步思考，讲到哪里，听众可能会提什么样的问题，我要如何应答。尤其是自己在设计过程中的疑问是如何解决的，其他人也很有可能有相似的问题。

而且不同的听众关注点不同，问的问题也不尽相同，我们要尽可能多角度思考，以备不时之需。

真正的大佬们一定是经历过几十甚至上百次不同场景、不同人群、不同业务的讲解、吸收、思考之后才形成随机应变的能力。

正所谓“见多识广”。

07 多复盘（在复盘中快速进步）

每次讲解完成之后都要整理大家的提问清单，事后再考虑一下如何更好地回答，以后肯定用得上。

讲解的过程，尤其是前几次的讲解，有条件的话，能录音最好全程录音，事后再听几次，在复盘中让自己对本业务的认知更丰满，发现自己现场无法察觉的问题以及可提升的小细节。

其中小细节一定不能忽视，它迟早会成为你前进路上的绊脚石。如不合适的口头禅，不合适的停顿，重点内容的抑扬顿挫及语气重音，都是在后续需要注意的。

08 其他小技巧（能掌握一个赚一个）

• 直接：语言要简单明确，不要有过多的无效解释，无效修饰。
• 互动：阶段性与听众有些小互动，或提问，或眼神交流，以便让大家更专注。
• 动作：讲解过程中的手势、表情等，能够让听众从外在更接受你的内容。
• 自信：即便你现在说的不一定对，但是你自信的表达出来，对方大概率也不会追问，后续思考过程中发现了问题，那就再私下解决。
• 问题复述：如果有些问题你是第一次听，可以先向提问者复述一遍问题，以确认对问题的理解是否有偏差。同时这个过程也能给你增加几秒“宝贵的”考虑时间。有时候还可以通过对方的提问发现他的理解可能存在误区，这时候就可以顺势进行纠偏。
• 把握时间：无论是一场正式的会议，还是一次短暂的讨论，或者是一个临时的“电梯演讲”，对时间的把握是非常重要的一环。心里始终装着一块表，随时提醒自己并调整讲解节奏。

09 写在最后

其实，做好需求讲解，不仅仅是需求人员、产品人员的必备技能，对于项目经理、运营等需要经常与不同类人群有工作交集的岗位，如果能掌握更清晰简洁的讲解方式，在工作中都会得心应手。即便是一名开发人员，能够把自己所涉业务很好的讲出来，也能在众多同事中脱颖而出。

同时文中提到的一些方法，不仅限于需求讲解，在其他交流场合也是互通的（如员工培训、测试用例评审、运营方案介绍等）。

篇幅所限，更多的场景和内容，大家可以结合自己的业务灵活扩展。

言而总之：沟通是一门艺术，愿我们都能成为一名优秀的“艺术家”！

公众号：不想延期了本文由 @不想延期了 原创发布于人人都是产品经理。未经许可，禁止转载。

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