这“2.5”个B端产品方法论，我想分享给你( 二 ) 重在|付费|运营者|内容|知识

如何减少一线人员的划水情况？
如何对比内外部模型水平差异？
如何降低线上工作和质检工作环境的差异？
如何设计一个评分弹窗？

实际上问题3在实际工作中没有暴露出这么明显，当时情况是质检准确率总是比较低，经过一番调研后才发现这个问题，这也比较符合大部分产品经理实际工作遇到的情况。
而问题4是我在面试中遇到的一个问题，它掠过了问题分析的步骤，要求直接提供问题的解决方案。但是评分弹窗何时出现，用户评分结果要用在哪里，都没有给出，设计起来就比较困难了，面试结果也不如人意。
那么如何设计一个评分弹窗呢？
二、提供解决方案后台产品的设计往往是为了支撑上游业务，提供信息化的传输/协调能力，从而加快整体流程，达到节省成本的作用，规范/加快/简化业务流程是解决方案重要且基本的要求。
在此之上，节省开发成本的多少，是区分产品优劣的另一个因素。如何降低开发成本呢？有三种可能，且一般情况下优劣同先后顺序：
1. 当下开发成本为0这意味着，用现有的流程去满足新的业务需求。
已有流程可能不完美，但如果能快速实现，且满足业务方的关键要求，对比之下便是最好的选择。还有一点是，紧急的流程可能是低频且不重要的流程，毕竟如果足够重要，往往早已实现，或在部门的大规划上。
入门的产品经理在面对业务需求时，对现有功能/历史情况不了解，即使明明有菜刀了，还要另外造一把匕首。
2. 有多个方案的情况下，选择开发成本最小的一种运大象到冰箱前，还是运冰箱到大象前更简单？新规划一条航线去运大象，还是将原定航线上的船空出来一个位置比较节省成本？这个选择很简单，但可能会和3冲突。
3. 流程可兼容日后流程/规划，节省以后的成本如果逼不得已要新建一个流程，最好将其做到足够通用（减少个性化）。而通用的要求是，先将多个流程的维度抽象出来，变成一个个个性化的值。这么说有点模糊，放出我一般梳理需求时都会用到的excel表：

文章插图
（表1）

文章插图
（表2）
表1是对表单设计时的信息梳理。后台的每个任务（电商入库，每个货物/包裹都是一张入库流水单；oa系统，每个用户/id都是一条记录。
如果信息过多，则通过uid将储存在不同库表的信息关联起来）都对应一条数据记录，而每条数据记录都有自己的信息，通过将实际的线下流程节点和记录的状态数据变更触发点关联起来，一个个流程便可以实现。
可以看到，我：

首先将每个任务需要记录的信息维度列出，比如任务名称/任务时间/…这要求我们对所有场景的流程需要用到的相同信息抽象出来；
再将信息维度归类，归为任务信息/业务范围/投放时机/…信息归类可以帮助产品自己对每个信息的用处有更深的了解，对开发同学设计库表，理解业务时也有帮助；
根据每个场景，制定每个维度里面都有什么值。

表2与表1的区别在于，表1是对一个个任务（如实物）的信息进行抽象，表2是对一个个流程（虚物）的将信息进行抽象。只要练习多了，就可以将不同对象都按照不同维度抽象起来。
实际上按照不同维度来抽象描述，这和技术同学的[面向对象编程]有相似之处，而日常在介绍各类内容时，我们也是按照一定逻辑/维度顺序的，比如时间顺序、空间顺序…
这个方法可是我的压箱法宝了，它帮助我在一天内就把这个容纳了双审/质检/培训的系统方案给梳理完善出来。当然，我所负责的业务的流程复杂程度相对而言是比较低的，有些行业的线下业务流程可要复杂得多，但抽象总是有用的。
以电商流程为例，如果抽象的流程为[入库]，那么购置的货物入库/退货入库/调仓入库/…是不是都可以使用同一套流程呢？只是货物来源不同，那么货物来源又可以定义为一个维度了。
三、效果验证这part主要描述的内容是 [制定关键指标]（结果），以及不只看[关键指标]（关注过程）。就当0.5个，下次有机会再分享吧～
本文由 @Ien 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自unsplash，基于CC0协议