域名频道资讯站
我们一直在努力制造惊吓

B端功能初级方法论


当自身经验不足,但又遇到“特殊”的功能需求时,可能会显得力不从心,不知从哪里着手解决问题,这对我们的工作进度也造成了一定的阻碍。

B端功能初级方法论

想必每一个刚进入b端或从c端转b端的产品经理们都会遇到一个困境:做一个功能想要找到最优解,但没有可参考的对象。胸中欲装山海,却拔剑四顾心茫然。

b端的封闭性导致了我们看不到好的应用/好的系统来当老师,更多的时候是自己闭门造车,根据以往的经验去解决。如果经验不足又遇到“特殊”的功能需求,就会无从下手。我曾经就陷入这样的泥沼里,一个月苦思冥想,一次次的否定自己,没有输出。

偶然我在策略产品经理的视频中,看到一个很有意思的模型。这个模型在我无法输出成果的日子里,仿佛上帝打开了一扇窗,让光照了进来。

一、深入理解业务逻辑

在讲方法论之前,我想先谈谈业务逻辑。这是b端的核心,也是方法论的前提。

理解业务逻辑不能停留于表层,更深层的细节其实就是产品经理挖掘需求的过程。有一个笨办法是场景模拟并推敲过程的每一个细节。模拟发起者的动作,模拟承接者的动作,模拟中间发生意外情况,模拟最后的收官动作。及时记录下你想到的每一个细节点。就像做一个演员,自己写好剧本代入其中。不要业务部门说什么你就听什么,那和传话筒没有区别。业务部门只是帮助你初步了解业务走向,补充一些生僻的使用细节和共同敲定你方法可行性的。

我们以投诉业务为例,表层是后台有一个展示投诉单的地方,投诉专员可以上传投诉结果并完成。更深层的细节是:投诉单是否要根据不同的投诉场景进行分类?投诉单的重要等级如何定义?投诉单按照什么规则分配到相应的投诉专员?投诉带来的赔偿损失是否要界定到内部人员责任并进行记录?等等。

二、初级方法论

需要声明的是,初级方法论只能做到简单粗暴的解决当下的问题,它并不是最优解,也不是市面上最好的解决方案。但你可以努力让它成为最适合你们公司的解决方案。

我把它分解为四步:目标-输入-输出-结果。

2.1 目标

无论是老功能的调整还是新功能的增加,其实归根到底都是为了解决问题。目标就是当前你想要解决的问题。

例如:当前的订单分配太过复杂/当前的佣金体系计算不正确。

2.2 输入

输入即是根据目标,拆解问题的关键因素。可以简单的理解为,是哪些因素导致了现在的问题。

以订单分配太过复杂举例:订单进来后需要分配客服进行跟单,分配到哪个客服由后台配置。复杂主要指配置规则上太过复杂。

问题拆解后输入的因素为:

  1. 没有考虑特殊商户的vip服务,常规订单和特殊商户的订单混杂在一起没有作区分。
  2. 建立客服分组的配置项太多:新建一个衣服订单的客服分组(即衣服订单都会由该分组的客服来跟进),需要勾选衣服的性别,衣服的季节,衣服的颜色,展示区域等等(以上仅为示意,非实际业务场景)
  3. 配置重复时没有自动识别提示。重复勾选时,没有识别提示,且无法保存成功。不知道到底是多勾了哪个。
  4. 没有异常订单归类。因为是人为建组分配订单,难免会出现漏掉配置或配置错误的情况。而如果没有对漏单错单进行归类展示,不仅会造成业务上的损失,后期排查配置起来也会非常麻烦。

以上都是现有订单分配功能的问题拆解,找到了输入因素后,我们就可以针对这些去输出因素了。

2.3 输出

输出即是对上述输入因素的解决方案。简单来说,就是去解决上面列出的那些问题。

还是以订单分配为例,输出的因素为:

  1. 新建特殊商户的配置方式,优先级大于常规订单分配。
  2. 简化配置项。实际业务场景并不需要这么细化的配置规则,只需要衣服的性别和季节即可(春夏男装分配给A客服组,秋冬男装分配给B客服组),那么直接去除其他的配置项。
  3. 配置时,已勾选的配置可以灰掉不可勾选或进行提示。
  4. 新建异常订单的显示页,将没有分配客服或分配异常的订单进行展示并指明问题点。

2.4 结果

结果即是最后交付研发的产品原型。可以看到,初级方法论的思维角度不是寻找一套最完美的体系,而只是发现问题解决问题的思维。它只适用于初级产品或在迷茫的时候带来突破的可能性。

而更高级的方法论一定是深扎业务,经过打磨的系统化思维了。

三、细节

3.1 模块化思维

经常调用的功能可以做成模块化,方便后期进行维护。例如订单中填写信息一步,如果不同类型的订单都单独做填写信息功能,一个是会导致研发非常低效,重复性的体力劳动。另一个是后期如果填写信息中的某项要进行调整,而这项又是出现在很多类型订单中,那么首先要找全这些订单类型,然后一个个的调整过去,也是非常低效。

而做成模块化,订单对模块进行调用,那么只需要对模块进行修改,所有相关的订单都会同步修改。不需要再进行重复性的体力劳动。

3.2 代码语言思维

在设计产品原型时,使用代码逻辑的思维代替日常性口语进行设计。这样研发理解起来会非常轻松,也不容易走偏方向。同时,也可以使自己的逻辑性更加有条理。

例如:下单时需要进行库存判定,对比下单数和库存数,库存不足需要提醒商家。

设计原型时如果写库存不足,需要向商家发送库存增补提醒。默契不足的研发容易误解,库存不足指代库存=0,其实还有一种情况是,下单商品数量>库存数。

而正确的思维逻辑:判定若下单数≤库存数,则走正常订单流程。若下单数>库存,则向商家发送库存增补提醒。就不容易误解出错。

四、开关与测试

4.1 做好开关留条退路

如果是已有功能的重构或改版,要视重要程度做好开关,好汉也要给自己留条退路。有问题随时切换回去,以免影响业务运转。

也可以划定小部分群体/商品分类进行试点,成熟后全面覆盖推广。例如只上线上海区域或只上线食品这一分类的商品。

当然无论是做开关还是试点都需要提前和研发讨论敲定。等研发一半了再提出,怕是要被打成小猪佩奇。

4.2 与使用者约会测试

测试的时候,有条件就拉上使用该功能的业务部门一起跑跑。有些细节或体验,只有使用者才能切身实际的感受到。所谓的产品经理同理心,容易走入理想化的乌托邦。

五、迭代再迭代

选个黄道吉日上线,运行也一切正常,就要开始考虑迭代的问题了。我们先撇开复杂功能需要分几个大版本的迭代规划不谈。

这里的迭代,是收集上线后的使用反馈,继续进行调优的过程。之前也说过,这套初级方法论只能保证以最简单粗暴的方式解决当下,而不是最优解。最优解需要不断调优来默契的匹配业务场景。自己一遍遍的使用功能,与使用者反复的确认细节,不断的去优化迭代,你可以让它成为最适合公司当下的解决方案。

六、留档是功德无量

留档也是前人栽树后人乘凉,功德无量的事情。如果一个功能的产品经理溜了,而又没有任何说明留下来,那么接手会非常痛苦。

业务逻辑得自己默默的跑百八十遍,细节还得求爷爷告奶奶找研发查代码。最后还不知道前人脑回路是怎么想的,无奈骂一句傻子产品经理。当然,实际情况可能真的是傻子做的,也有很大概率是当时的业务场景只允许他这么做。那么当时的坑是否你现在也要面对还不自知?

 

本文素材来自互联网

赞(0)
分享到: 更多 (0)

中国专业的网站域名及网站空间提供商

买域名买空间