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

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

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

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

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

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

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

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

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个特征结合起来，整理出完整的流程图：

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

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

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

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

作者：子文，公众号：产品百闻

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

题图来自Unsplash，基于CC0协议