B端SaaS产品因为我们无法成为真正的用户，很难体验到实际场景，如果产品经理花精力让团队成员快速熟悉了业务，那么对于整个团队的工作来说，将带来额外的增益。
01、前言
产品经理奋战三天设计出来的需求开发觉得不可理喻；
团队成员最终实现出来的交付物，并不是用户实际所要的效果；
大多数产品经理应该都遇到过以上情形，这些情况的出现无疑会增加我们的沟通和时间成本。
排除团队成员技能因素，如果经常遇到以上的情况，也许我们首先需要思考的是，团队成员足够理解了产品业务吗？
有人说，设计师、研发人员只需要按照产品给的需求实现即可，只要技能足够厉害就好，并不需要懂业务。
当然这样做也能让团队最终完成工作，只不过，懂业务的团队会完成得更好，就如同一份人间美味的菜肴，掌勺的厨师在制作菜品的时候，也会对顾客口味有充分的了解。
02、为什么需要让团队成员理解业务？
做产品并不是一个人的战斗，我们需要充分激活团队的力量，团队理解业务后能够给产品经理的工作带来额外增益。
1.1把关需求，减少错误
B端的SaaS产品经理需要为用户设计完整的功能方案，如果功能上线后发现设计方案有缺陷，可能会给企业用户造成经济损失，即便是轻微的问题也会降低用户对平台的信任度，影响下次续费。
一个熟悉业务的设计、研发团队，在一定程度上能够帮助产品经理发现设计方案的缺陷。开发中有一个环节是开发之间互相进行代码走查，与这个类似，团队成员对业务熟悉后，在评审和实现的过程中，也能觉察产品的需求方案有没有不符合业务场景的地方。
例如以下情景：
某租房APP要实现电子发票功能，产品经理小明设计的方案是，用户支付成功后即可开发票，工程师A觉得电商平台一般都是这样，拿到需求就开始做了。
然而，此时工程师B提出了质疑，假如支付的是租房押金，也允许开具发票吗？
小明反应过来，自己漏了这个场景，实际情况是押金在财务上是不开发票的，小明非常庆幸这位工程师及时提出了质疑，避免了后面上线后再发现问题。
上述情景中，工程师B至少知晓了2个业务知识点，才得以及时发现了这个问题，其一，是知道租房APP中是有押金缴费的；其二，知道押金在财务上不予开具发票。
假如按工程师A的做法，拿到需求后就去开发，那么很有可能上线后会造成事故，不该开票的订单开出了发票，给财务同事的工作带来不必要的麻烦。
事故出现后，责任并不在开发同事的身上，而是因为产品经理没有把场景考虑完整。
诚然，一个合格的产品经理在设计需求时必须要考虑完整的场景闭环，不出纰漏，但实际情况是，我们没办法确保每个需求都能考虑得详尽周到。
相信很多产品人都有过情景中类似的经历，事后在心里会非常感谢某个研发在进入开发前，及时指出了需求中未考虑到的业务场景。
视觉、研发实现需求的周期通常会比产品设计阶段的周期更长，也就是说，他们比产品接触需求的时间通常会更多，如果需求设计有缺陷，懂业务的团队成员大概率会察觉到问题，在上线前就提出来，产品经理能及时调整方案。
所以，假如团队成员也熟悉业务，能够让我们的工作避免发生许多不可挽回的错误。
1.2理解需求，降低沟通成本
产品经理几乎每天都要与团队成员沟通，大家都希望自己提出来的需求团队成员能够快速理解，以减少在沟通上所花的时间。
而让团队成员熟悉业务，就是一项行之有效的方法。
因为B端产品的需求是基于实际业务场景产生的，而实际业务经常会有一定复杂度，不太容易理解，所以团队成员在评审和实现的过程中可能产生不少疑问，如果熟悉业务，他们就能够站在实际业务场景中去考虑，减少因业务不熟而提出的疑问。
情景：
一次需求评审会上，产品经理小明讲到，要增加修改订单的功能，且已支付订单的支付时间也可修改，研发同事一致认为，这个功能不合理，市面上哪有产品允许修改支付时间的，都是根据实际时间来取值，这样做不符合规范。
小明讲解到，是因为有部分房租是通过线下收到的费用，管家收到钱后会录入到系统，但有时候会录错，需要将支付的时间改为实际收款的那天。
大多数研发听到这后点了头，但研发A这时提了个疑问：“不改时间也不会有什么影响吧，金额是对的就行了。”
小明：“财务每月做账时，报表的金额数据对应的日期必须为真实收费的日期。如果时间改成了在对应账单月份之后的月份，就在报表里面归到补收统计，反之，则归到预收统计。”
研发A：“什么是补收和预收呢？”
小明：“补收就是收的往月的费用，预收就是提前收以后的费用。”
研发A：“这样随便改时间的话就统计逻辑就复杂了，不太建议这样做。”
小明：“…”
类似的情景我们经常会遇到，产品解释后，三两句说服了还好，如果说服不了，还会继续pk几十分钟，也许到了开发阶段还得解释，沟通成本很高。
情景中都是平台上经常发生的业务，如果小明详细讲解过，研发A就会知晓在真实的业务场景中，管家可以在线下收费然后录到系统，且财务需要按真实收费的时间来统计补收、预收等数据，那么就能理解这个需求的合理性，降低沟通成本。
03、怎样讲解能让团队快速熟悉业务？
团队成员合作的越久，对业务会越熟悉，在没有专门讲解的情况下，这个过程可能需要半年甚至更长。我们都希望每个成员刚加入团队，就能对业务足够了解，让项目高效运转。
所以对团队成员进行业务培训存在着很高的必要性，那么怎样讲解才能让团队成员快速熟悉业务呢？有以下两个方法可供参考：
2.1巧用比喻，增加趣味
很多领域都会有一些特有的名词或业务，对于团队新人来说确实有点晦涩难懂。
举个例子，财务上有2种算账方式，权责发生制和收付实现制，在做财务数据统计的需求时，不同的报表所用的方式不同，如果不理解这2个基本概念，很容易出现最终呈现出来的数据不准确的情况。
按常理来说，我们会拿百科上专业的名词解释来讲解这2个概念指的是什么，但书面上的用语听起来乏味，也容易让人忘记。
如果在这里面加上一点有意思的比喻，会让培训的效果好很多。
情景：
菜市场有个卖肉的老王，赚的钱每天都会上交给他老婆，这天有个顾客一次付了2000元，让老王接下来1个月每天都给他留2斤猪肉。
老王回家很开心地跟老婆说，今天多赚了2000元，老婆夸老王越来越会做生意了，没细问是怎么赚的，奖励了老王200元生活费。
过了几天，老婆发现怎么肉突然不够卖了，钱却没变多，于是问老王这是怎么回事，老王说上次的2000元其实是未来1个月的钱，于是老婆很生气地说这类钱不能算成当天的收入，不然不好进货，罚老王洗碗一个月。
上述情景，老王他老婆算账的方式就是权责发生制，只把应收的钱，归为当天的收入，收到的未来的钱，不算进收入。
与之相对应的收付实现制，就是老王的做法，把实际收到的钱算为收入。
这样的比喻，让原本乏味的书面解释生动起来，听者听起来也会印象更加深刻。
在实际应用时，可以根据具体讲解的知识点，给出恰当、形象的比喻。
2.2讲解流程，回归场景
因为需要让团队成员熟悉产品的核心业务，所以需要讲解完整的业务流程，在这里可以用到场景化的方法，使业务讲解更加完整与饱满。
还是以租房平台为例，其核心业务是房租收费，流程如下：
生成账单——租户支付——平台收钱——财务入账
以上流程，简单的表明了是在做什么，接下来可以用场景进行详细讲解：
菜市场老王的儿子小王刚参加工作，通过某平台租了一间公寓住，到了月初，平台照例生成了待缴账单，小王想着能缓就缓吧，先不管了，2个月后小王打开APP一看，账单包含了房租、水电燃气费、宽带费、窗户维修费，除此之外还产生了不少违约金。
小王发现自己支付宝里边的钱不够，不过幸好身边存着2000元现金，于是跟管家说，能不能在线上先交一部分，剩下的当面给现金你，管家表示可以。
管家上门收到了钱，然后将支付记录录入到了系统，并把钱交给了公司财务部门。
这个场景贯通了整个核心流程，且从中可以听到很多业务知识：
- 账单除了房租费用，还存在水电燃气费、宽带费、维修费这些类型；
- 超时未缴会产生违约金；
- 平台存在上门收费的场景；
- 现金收费后要录到系统；
讲解核心流程时，加入场景，能够把业务知识点串联起来，使听者不仅对业务有了切实的认识，还熟悉了相关知识点。
这个方法因为涉及了完整的流程，所以讲解起来思路清晰，不容易遗漏知识点，如果对于知识点再引入比喻法，两种方法结合使用，将产生不错的培训效果。
04、结语
对于C端产品来说，团队成员自身就可以成为用户去体验，一般不需要专门的业务讲解，但B端的SaaS产品因为我们无法成为真正的用户，很难体验到实际场景，所以如果产品经理能花精力进行业务讲解，同时结合了系统功能，在短时间内让其他人也熟悉了业务，那么对于整个团队的工作来说，将带来额外的增益。
