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

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

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

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

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

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

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

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

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

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

1. 把关需求，减少错误

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

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

例如以下情景：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

情景：

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

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