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

想必每一个刚进入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 与使用者约会测试

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

五、迭代再迭代

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

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

六、留档是功德无量

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

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

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

题图来自Unsplash，基于CC0协议