导读: 编辑导语:产品经理在日常工作中,经常要做需求讲解,而需求讲解的质量对需求的范围,团队的效率、认可度等方面有很大的影响。那么,如何做...

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

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

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

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

01 先抛几个最常见问题

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

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

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

02 区分人群(见人说人话,见神说神话)

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

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

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

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

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

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

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

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

这里简单区分一下,不展开介绍:

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

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

03 从宏观到微观(由浅入深,抽丝剥茧)

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

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

04 场景代入(变枯燥为生动

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

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

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

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

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

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

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

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

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

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

  • 薪酬计算(应发工资计算、实发工资计算)
  • 社保计算
  • 个税计算

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

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

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

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

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

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

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

05 多练(勤能补拙

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

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

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

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

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

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

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

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

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

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

正所谓“见多识广”。

07 多复盘(在复盘中快速进步

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

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

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

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

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

09 写在最后

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

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

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

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

 

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

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

--The End--
来源:集林心得Offer-集林转载 | 发布者:集林心得

版权声明:本文章,于2022-07-06 20:02:42集林心得整理发布,欢迎转载!

转载注明:如何做好一场需求讲解 - 来自集林心得Offer

免责声明:集林心得Offer 站内所有信息、评论本站不对其真实性、实用性做任何承诺,请您理性查阅

本文章共有 0 条评论

还可以输入 100 个字
继续阅读相关文章
集林心得猜您想要
评论 打印 收藏 分享按钮