为什么说B端SaaS产品经理需要让研发团队懂业务?

8 评论 9342 浏览 30 收藏 18 分钟

编辑导读:想要做好一个产品,光靠一个人孤军奋斗是没用的,合适的团队才是最重要的。而团队对业务了解得更多,也就更有利于业务的顺利开展。本文作者梳理总结了让研发团队快速熟悉业务的几个方法,供大家一同参考学习。

01 前言

我们奋战数天做出来的需求,研发同事会觉得不可理喻;

功能已经实现出来后,才发现需求或代码设计上有错误,得花费额外的时间修改,甚至是重构,导致迭代延期;

大多数产品经理应该都遇到过以上情形,这些情况的出现无疑会增加我们的时间成本。

排除团队成员技能因素,如果经常遇到以上的情况,也许我们首先需要思考的是,团队成员足够理解了产品业务吗?

有人说,研发人员只需要按照产品给的需求实现即可,只要技能足够厉害就好,并不需要懂业务。

当然这样做也能让团队最终完成工作,只不过,懂业务的团队会完成得更好,就像一份美味的菜肴,掌勺的厨师在制作菜品的时候,也提前对顾客口味有过充分的了解。

02 为什么需要让团队成员理解业务?

随着在B端SaaS领域做得越久,笔者越来越多地遇到因团队成员不懂业务,而使研发实现上出现问题的情况,也越发深刻地认识到让研发人员懂业务的重要性。

做产品并不是一个人的战斗,我们需要充分激活团队的力量,团队理解业务后将会给产品经理的工作带来额外的增益。

1. 把关需求,减少错误

B端的SaaS产品经理需要为用户设计完整的功能方案,如果功能上线后发现设计方案有缺陷,可能会给企业用户造成经济损失,即便是轻微的问题也会降低用户对平台的信任度,影响下次续费。

一个熟悉业务的设计、研发团队,在一定程度上能够帮助产品经理发现设计方案的缺陷。开发中有一个环节是开发之间互相进行代码走查,与这个类似,团队成员对业务熟悉后,在评审和实现的过程中,也能觉察产品的需求方案有没有不符合业务场景的地方。

例如以下情景:

某租房APP要实现电子发票功能,产品经理小明设计的方案是,用户支付成功后即可开发票,工程师A觉得电商平台一般都是这样,拿到需求就开始做了。

然而,此时工程师B提出了质疑,假如支付的是租房押金,也允许开具发票吗?

小明反应过来,自己漏了这个场景,实际情况是押金在财务上是不开发票的,小明非常庆幸这位工程师及时提出了质疑,避免了后面上线后再发现问题。

上述情景中,工程师B至少知晓了2个业务知识点,才得以及时发现了这个问题,其一,是知道租房APP中是有押金缴费的;其二,知道押金在财务上不予开具发票。

假如按工程师A的做法,拿到需求后就去开发,那么很有可能上线后会造成事故,不该开票的订单开出了发票,给财务同事的工作带来不必要的麻烦。

事故出现后,责任并不在开发同事的身上,而是因为产品经理没有把场景考虑完整。

诚然,一个合格的产品经理在设计需求时必须要考虑完整的场景闭环,不出纰漏,但实际情况是,我们没办法确保每个需求都能考虑得详尽周到。

相信很多产品经理都有过情景中类似的经历,事后在心里会非常感谢某个研发在进入开发前,及时指出了需求中未考虑到的业务场景。

视觉、研发实现需求的周期通常会比产品设计阶段的周期更长,也就是说,他们比产品经理接触需求的时间通常会更多,如果需求设计有缺陷,懂业务的团队成员大概率会察觉到问题,在上线前就提出来,产品经理能及时调整方案。

所以,假如团队成员也熟悉业务,能够让我们的工作避免发生许多不可挽回的错误。

2. 理解需求,降低沟通成本

产品经理几乎每天都要与团队成员沟通,大家都希望自己提出来的需求团队成员能够快速理解,以减少在沟通上所花的时间。

而让团队成员熟悉业务,就是一项行之有效的方法。

因为B端产品的需求是基于实际业务场景产生的,而实际业务经常会有一定复杂度,不太容易理解,所以团队成员在评审和实现的过程中可能产生不少疑问,如果熟悉业务,他们就能够站在实际业务场景中去考虑,减少因业务不熟而提出的疑问。

情景:

一次需求评审会上,产品经理小明讲到,要增加修改订单的功能,且已支付订单的支付时间也可修改,研发同事一致认为,这个功能不合理,市面上哪有产品允许修改支付时间的,都是根据实际时间来取值,这样做不符合规范。

小明讲解到,是因为有部分房租是通过线下收到的费用,管家收到钱后会录入到系统,但有时候会录错,需要将支付的时间改为实际收款的那天。

大多数研发听到这后点了头,但研发A这时提了个疑问——

研发A:“不改时间也不会有什么影响吧,金额是对的就行了。”

小明:“财务每月做账时,报表的金额数据对应的日期必须为真实收费的日期。如果时间改成了在对应账单月份之后的月份,就在报表里面归到补收统计,反之,则归到预收统计。”

研发A:“什么是补收和预收呢?”

小明:“补收就是收的往月的费用,预收就是提前收以后的费用。”

研发A:“这样随便改时间的话就统计逻辑就复杂了,不太建议这样做。”

小明:“…”

类似的情景我们经常会遇到,产品解释后,三两句说服了还好,如果说服不了,还会继续pk几十分钟,也许到了开发阶段还得解释,沟通成本很高。

情景中都是平台上经常发生的业务,如果小明详细讲解过,研发A就会知晓在真实的业务场景中,管家可以在线下收费然后录到系统,且财务需要按真实收费的时间来统计补收、预收等数据,那么就能理解这个需求的合理性,降低沟通成本。

03 怎样讲解能让团队快速熟悉业务?

团队成员合作的越久,对业务会越熟悉,在没有专门讲解的情况下,这个过程可能需要半年甚至更长。我们都希望每个成员刚加入团队,就能对业务足够了解,让项目高效运转。

所以对团队成员进行业务培训存在着很高的必要性,那么怎样讲解才能让团队成员快速熟悉业务呢?有以下两个方法可供参考:

1. 带入故事,帮助理解

很多领域都有一些特有的业务,对于研发人员来说确实会有点生涩不易理解。

举个例子,财务上有2种算账方式,权责发生制和收付实现制,在做财务数据统计的需求时,不同的报表所用的方式不同,如果不理解这2个业务知识,很容易出现最终呈现出来的数据不准确的情况。

按常理来说,我们可以拿百科上专业的解释来讲解这2个业务知识指的是什么,但书面上的用语听起来生硬难懂,也容易让人忘记。

我们知道在需求表达的过程中,信息越是丰富,越容易被理解,而故事,则是能够把信息之间有机结合在一起的非常好的载体。

因为一个完整的故事需要具备六要素:时间、地点、人物、起因、经过、结果,将这些与业务知识结合在一起去讲述时,就产生出了故事的一个重要作用——‘画面感’,听起来就好像是发生在我们生活中的一件事情,能够把听众带入到完整的业务场景中去感受、理解。

例如下面这个故事:

菜市场有个卖肉的老王,赚的钱每天都会上交给他老婆,这天有个顾客一次付了2000元,让老王接下来1个月每天都给他留2斤猪肉。

老王回家很开心地跟老婆说,今天多赚了2000元,老婆夸老王越来越会做生意了,没细问是怎么赚的,奖励了老王200元生活费。

过了几天,老婆发现怎么肉突然不够卖了,钱却没变多,于是问老王这是怎么回事,老王说上次的2000元其实是未来1个月的钱,于是老婆很生气地说这类钱不能算成当天的收入,不然进货会不准,罚老王洗碗一个月。

上述故事场景中,老王他老婆算账的方式就是权责发生制,只把应收的钱,归为当天的收入,收到的未来的钱,不算进当期收入。

与之相对应的收付实现制,就是老王的做法,把当期实际收到的钱都算为收入。

就像听过的某个童话故事,过了十多年画面感还是会存留在脑海中一样,这样把原本难懂的书面解释结合到故事中,虽然没有童话那般丰富有趣,却也能达到相近的效果,比直接用书面用语讲业务知识,能更通俗易懂且印象深刻。

我们在实际应用时,也可以根据具体讲解的业务,给出类似这样合适的故事。

2. 绘制流程,辅助表达

在讲述业务的时候,为了让讲解更加完整与饱满,我们通常都会详细描述实际业务场景,而因为B端SaaS产品业务场景较为复杂,仅用文字或语言描述会显得不够清晰明了,如果此时附上一张带有角色的业务流程图,则能直观地体现出不同角色、业务知识之间的联系。

因为流程图能够同时拥有这几个特征:节点化、方向性、可分支、角色划分。

下面针对这些特征进行说明,先看看这个业务场景:

小王今年刚毕业参加工作,通过某平台租了一间公寓住,到了月初,平台照例生成了待缴账单,小王想着能缓就缓吧,先不管了,2个月后小王打开APP一看,账单包含了房租、水电燃气费、宽带费、窗户维修费,除此之外还产生了不少违约金。

小王发现自己支付宝里边的钱不够,不过幸好身边存着1000元现金,于是跟管家说,能不能在线上先交一部分,剩下的当面给现金你,管家表示可以。

管家上门收到了钱,然后将支付记录录入到了系统,并把钱交给了公司财务部门。

这个场景听下来,确实提到了很多业务知识,却并不容易吸收,正是因为知识点多,所以短时间内不容易看出哪些是重点,以及之间有什么关联。

此时不妨运用一下流程图的4个特征:

1)节点化

将场景中所有的关键事件提炼出来作为流程中的各个步骤,这个过程就是节点化。假如没有节点化,那么遇到越是复杂的业务场景,为了让听众理解,我们越是会用更多的文字或语言去阐述,内容更多听众反而更不容易抓到所有重点,这样就形成了一个困境。

而节点化能够拆分出一个复杂的业务场景中所有的关键事件,这些事件可以是系统执行的关键逻辑,或是业务场景中的关键业务行为,这样抽丝剥茧,就把一个复杂的场景高度提炼了,听众一眼就能看出整个业务场景中的关键事件是哪些,解决了在复杂业务中快速找到关键事件的问题。

2)方向性

流程图中一个节点之后用箭头指向到下一个节点,即为方向性。方向性是流程图特有的特性,体现出了不同关键事件之间发生的先后顺序,谁是这件事情发生的前置条件。

在业务场景中,方向性可以直观展示出所有事件之间的先后顺序,这样听众很容易就能理解这些业务事件之间的关联性、前后逻辑。

3)可分支

可分支是指流程图中支持增加判断节点,每个判断节点之后可以指向多个路径。有时候业务场景中并不只有1种路径,不同的业务行为会带来不同的业务结果,这时用纯文字和口述表达会显得复杂,而流程图可分支的特性就很直观的表达出了这种情况,使其他人容易看出这里存在多种情况,以及不同情况会产生什么业务结果。

4)角色划分

在跨职能流程图中支持标注各步骤对应的角色,即为角色划分。标注角色后能够让人直观的知道,业务场景中的每个业务事件是由谁触发的,便于理解业务中不同角色间的协作关系。

可以看出,当这几个特征运用到了一起时,最终呈现出来的效果,就是把复杂的场景进行了抽象化、逻辑化、可视化。

我们将以上4个特征结合起来,整理出完整的流程图:

图中寥寥几字,便体现出了完整的核心业务,最重要的是与纯文字相比,非常便于短时间内理解并加深记忆,有助于让团队成员快速熟悉业务。

这个方法因为绘制了完整的流程,所以讲解起来思路清晰,且不容易遗漏知识点,如果将故事和流程法结合使用,将产生不错的培训效果。

04 结语

对于C端产品来说,团队成员自身就可以成为用户去体验,一般不需要专门的业务讲解。

但做B端产品时,因为我们无法成为真正的用户,很难体验到实际场景,所以如果产品经理能花精力进行业务讲解,同时结合了系统功能,在短时间内让其他人也熟悉了业务和功能,那么对于整个团队的工作来说,将带来额外的增益。

 

作者:子文,公众号:SaaS产品闻

本文由 @子文 原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我们公司特地让我在现场观摩 ,然而每次问到他们的专业时,他们就很不耐烦,他们觉得很简单的东西,我这边觉得非常难理解,毕竟不是他们专业的,导致调研也没调出个啥,还得坐办公室空想

    回复
    1. 有些行业业务属性很强,内行人很明白,外行人一开始会完全不懂很正常,这个需要时间沉淀,专业术语可以百度,另外除了问一线人员,公司本部应该还会有其他资深的人士,也可以去问问。

      回复
  2. 但是很多公司产品经理都只是分配任务,都不会详细讲解业务需求,导致开发和设计做出的产品存在很多缺陷,我是做设计的,经常因为对一个业务不了解,做设计思考的层面都比较局限,都无从下手,也很想从实际业务以及客户角度去设计相关的需求,但是一个人是做不了的

    回复
    1. 我们团队会强制要求产品经理提的需求里面,要有需求背景(业务场景、现状)、需求价值,如果需要的话还会加上用户故事,久而久之我们的开发经理、测试经理现在已经非常熟悉业务了,评审会上经常能提出建设性的意见,思考什么样的产品方案更合理。
      其实你们也可以向leader提对需求质量的要求,需要讲清楚需求背景、需求价值,否则视为需求不完整,有权利提出挑战、质疑。

      回复
    2. 我提过很多次,上班第一天就建议公司为团队做一次产品的培训,让我们都了解产品,到现在都没有培训,我们团队都没有人了解自己开发的产品,一问三不知,哈哈,做需求的时候也是零碎,都不理解需求的本质,我也是很无奈,提过很多次,让我们都了解需求,知道客户需求的本质,可是就是不走这个程序,尴尬🙃

      回复
    3. 产品经理的失职。。。

      回复
  3. 不仅技术懂业务,产品经理更要了解技术的数据结构怎么搭建的

    回复
    1. 是的,在设计产品时,我们也需要了解数据结构的设计和技术实现难易,因为这方面已经有很多文章做出了详尽的论证,本文想从另一个点带来思考,技术懂业务对产品设计影响

      回复