HI,下午好,新媒云不收取任何费用,公益非盈利机构
24小时服务热线: 4000-162-302
请扫码咨询

新媒易动态

NEWS CENTER

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

2021-01-02

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

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

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

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

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

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

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

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

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

1. 把关需求,减少错误

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

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

例如以下情景:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

情景:

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

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

相关推荐