当需求来敲门

1 评论 6278 浏览 23 收藏 10 分钟

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

一个“产品”或者“需求”会有哪些部分组成呢?

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

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

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

一、“拒单”这个需求

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

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

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

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

二、对需求做一个评估

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

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

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

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

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

三、对需求做一个分析

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

  • 阿姨操作拒单以后的二次派单的触发问题
  • 阿姨是否有一个拒单的阈值,频繁拒单以后是否需要一个策略去制止这个过程
  • 而用户是否需要对重新派单做一些干预或者评价

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

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

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

四、“拒单”的产品组成

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

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

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

1)用户端要做哪些

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

2)阿姨端怎么搞

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

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

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

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

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

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

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

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

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

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

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

组合起来走远一点看看:

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

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

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

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

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

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

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

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

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

那么,就按部就班地这么办吧!

专栏作家

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

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

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 好好好

    来自上海 回复