当需求来敲门

" 拒单 " 在一些电商平台或者服务型的平台是一个常见的功能，作为产品经理，要明白 " 拒单 " 这个需求背后的逻辑，才能更好地进行产品设计。本文作者对此进行了分析，希望对你有帮助。

(相关资料图)

一个 " 产品 " 或者 " 需求 " 会有哪些部分组成呢？

理解这一点对于我们去做需求分析和产品设计非常重要，因为我们脑子里有全景图，知道应该去思考哪些方面的问题。

而在需求分析和产品设计时，我们要去思考所有相关部分和环节要做的事情。

下面我们就以 " 拒单 " 为例，聊一聊当需求来敲门时，如何去全面的思考以及设计。

一、" 拒单 " 这个需求

要先明确的就是在什么场景下产生了这个需求。

一位保洁阿姨住在通州，突然被派了一个亦庄的擦玻璃的单子，或者因为其他原因去不了，所以需要拒掉这个单子，拒掉之后，平台会重新匹配阿姨。

在这个场景里，阿姨需要能够表达自己去不了的意愿，而用户需要平台指派阿姨，而平台的运营者为了促成这一单生意让大家可以满足各自的需求。这就是在这个场景下，各方的诉求。

以上就是我们对需求场景的挖掘。

二、对需求做一个评估

了解的场景之后，我们需要进行一个评估，这个玩意儿值不值得做，做了会有什么好处，不做会有什么坏处。

任何坏处和好处都跟体量有很大关系，比如一年就 1 次场景发生的概率，那就没必要评估了，太低频了，如果频率很高，我们再去评估这个场景下需求的意义。

对于有什么坏处，如果阿姨拒不了单，但又去不了，那这一单就可能会异常完结，在这个过程中阿姨又不能接新的单子，只能干等着这一单结束，而用户也等不到阿姨上门，这一单只能异常完结；整个过程中所有人的权益和体验都得不到保证。

而好处就是坏处的对立面，就不再赘述了，因此，这个事从场景出发肯定是要做的。

既然要做，我们再来聊一聊如何从产品层面去实现这个需求。

三、对需求做一个分析

要实现以上的拒单能力，还有很多问题需要思考，除了用户、阿姨、运营各端的流程以外，还要考虑其他的一些相关问题。比如：

阿姨操作拒单以后的二次派单的触发问题

阿姨是否有一个拒单的阈值，频繁拒单以后是否需要一个策略去制止这个过程

而用户是否需要对重新派单做一些干预或者评价

等等，围绕需求的内核 " 拒单 "，又会衍生出一系列的问题需要去思考，而每一次思考都可以认为是新需求的派生，而新派生的需求就需要有产品或者运营等环节去承接。

直到不再有新的问题，那么这个需求才真正分析清楚。

接下来就是针对这些想明白的问题进行产品化的设计。

四、" 拒单 " 的产品组成

从下图中可以看出来，任何一个需求或者功能，都可能由以下这些维度组成：

对于拒单这个需求同样也会在以上的各结构层上有所提现。

在前台展现层上有 3 个端需要考虑。

1）用户端要做哪些

用户发起擦玻璃的单子，可以看到平台关于指派阿姨的实况，派单中、派单成功、以及阿姨的情况，这个跟滴滴打车很类似，需要知道是否已经指派了司机，而司机也有权利拒单，然后平台重新指派；这些都是用户端要思考的内容。

2）阿姨端怎么搞

阿姨需要能够看到平台派的这个单子，并且提供给阿姨一个功能，比如在订单后面的一个 " 拒单 " 按钮，点击按钮发起拒单的操作，第二步可能需要填写一个拒单的原因，然后拒单成功，或者不允许拒单，以及其他可能的情况。

3）在后台支撑端需不需要

这个要看运营体系本身，要不要去干预整个 " 拒单 " 的过程，比如，是不是需要去审核阿姨的拒单申请，或者时候去对 " 拒单 " 记录做一个考核评估，打一个分，或者给阿姨一个惩罚等一系列操作。

那这些都意味着工作量，所以需要有对应的人员去承接这个职责。

在服务层要想清楚很多问题。

前台的展现依赖底层服务端的逻辑实现，比如阿姨拒单操作就是对订单发起的一系列动作，或者是对履约发起的动作，就需要订单系统或者履约系统给与支持。

同样，二次派单又是对派单环节提出的任务请求。

那么，这些底层的服务需要对以上这些给予支持，比如履约系统需要提供给阿姨端一个 " 接口 "，来接受阿姨的拒单请求。

同样，派单服务也需要给履约系统一个 " 接口 " 或者通路，来接受履约系统发起的重新派单的申请。

而这个过程中也可能需要风控服务的参与，来规避阿姨过高的拒单请求，来决定是否对阿姨做出一些限制。

因此，在服务端，我们可以用这种方式去思考问题，以获得 " 拒单 " 需要的全部新的支持以及对旧服务体系带来的变更的要求。

组合起来走远一点看看：

以上相关环节思考的差不多时，我们就把他们放到一起，整体看一看，演练一下，是否实现了想要的目标。

五、组装和规整 " 拒单 " 的方案

经过上面一系列的操作以后，我们逐渐的看清了这个 " 拒单 " 怎么做，他的影响面有多大，需要哪些环节参与进来。

想明白了这些问题以后就可以进行方案的落地设计了。

比如前端把原型画出来，前后的链接把流程画出来，而各个逻辑的处理把逻辑流程以及各种规则做出来。

至此，我们将得到一个包含了多端原型和流程以及各环节逻辑、规则的可执行产品方案。

所以以上当需求来敲门时，从场景出发经过一个设计模式，而得到了我们想要的产品方案。

这个过程我们需要知道哪些方面需要思考，而每个思考又需要思考哪些方面。

同时，本文也回答了一些朋友的问题 " 面对一个新需求，我不知道该怎么办 "。

那么，就按部就班地这么办吧！

专栏作家

陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；专注为 10 万支付产品经理和支付机构以及企业提供深度支付内容和服务！

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

题图来自 Unsplash，基于 CC0 协议。

标签：