我对B端任务中心功能的设计思考
编辑导语:B端系统中任务中心模块作用是什么,设计这个模块的意义在哪里,是很多人的疑虑,本文的作者就从设计的原因、适用范围等几个角度详细介绍了这个功能,感兴趣的小伙伴一起来看看吧。
如果大家留意,在B端系统中,经常会看到一个任务中心的模块。那么这个模块的作用是什么,为什么要设计这个模块呢?今天笔者就从自身的工作经验出发,来给大家介绍一下我对OMS系统中任务中心模块的设计思考。
一、为什么需要任务中心
B端系统中任务中心的出现,和程序编程接口(API)的特性脱不开关系。应用程序接口API(Application Programming Interface),是提供特定业务输出能力、连接不同系统的一种约定。这里包括外部系统与提供服务的系统(中后台系统)或后台不同系统之间的交互点。包括外部接口、内部接口等。接口的响应机制类型有:
- 同步交互: 即需等待服务端将请求处理完成,接口才会返回结果,业务才可以继续进行。如登录验证时,需要服务端验证通过账号密码时,接口才会返回成功,才能正常登录。
- 异步交互: 接口返回成功仅表示请求行为成功了,对方系统收到请求后异步对业务进行操作,调用方无须等待每个请求的调用结果。如OMS请求发货,接口返回成功,仅表示WMS收到了这个请求,WMS系统还会异步的去生成对应的发货单进行操作。
一般来说用户登录、单据状态的变更等等,都会使用同步交互操作,其余情况都优先使用异步交互。但是无论同步交互还是异步交互,仍然会遇到以下问题:
同步交互: 接口调用超时或由于非业务原因导致的调用失败,需要重复调用,那么我们当请求失败时其实最好的选择是:
step1:界面提示:
- case1:请求成功
- case2:请求失败,系统自动重
- case3:请求失败,失败原因为:xxxx
step2:系统自动重试:
- if 达到一定的次数
- 自动停止,展示错误原因,通知用户允许用户手动重试
异步交互:接口调用成功了(如果失败,和同步交互的处理方式一致),但是实际业务没正常进行。
对方系统推送失败数据,进行界面提示:
- 根据预设的逻辑,系统根据失败原因自动处理
- 用户查看失败原因,手动处理
由此可见,多系统间的交互异常是频繁的,那么用户仍需要对这种情况进行处理,则提出了几点要求:
1、要方便感知: 同步交互的方式下,异常反馈时,一般用户仍然会停留在业务发生界面,故可以使用弹窗的方式展示异常的原因或者详细的异常数据。但是由于长时间请求未响应的异常,用户可能就没有停留在当前界面了,同样的异步交互的方式下,异常反馈时,一般用户都已经离开了业务发生界面,这是使用弹窗提醒就不合适了;
2、要方便的重试: 在一些业务中,用户发起一次操作需要提交很多参数,如果直接要求客户重新从头做该操作,肯定会降低用户的效率;
那么我们知道,人驱动系统、事体现过程、物记录结果、规则控制运行,我们需要有一个单据或者说任务来承载这些诉求。所以我们一般将这些请求任务聚合起来管理的模块叫做任务中心。
二、任务中心的设计案例
在网上看了很多文章,讲了太多的理论和最后的结果,却不清楚一个功能为什么设计成当前的样子,而不是另外的样子。那么接下来,我们以商家调整商品上下架操作为例,来给大家讲解一下任务中心如何设计。
拆解:
首先,我们习惯将一个大而复杂的场景,根据参与者等要素的不同,拆解成几个用例。用例怎么拆,可以参考《火球:UML大战需求分析》或者《大象:think in uml》两本书。拆解用例的目的,是为了清晰的确认参与者、前置条件、业务场景、后置条件,更方便我们分析一个复杂的业务场景,更有利于我们发现一些可以复用的场景。
如上图可以看到,我们发现其实用例3和用例4是可以多个业务场景是可以复用的,这就是我们在产品设计过程中划分功能模块的重要思路。
拆解:
我们需要有一种结构化的方式,来设计产品方案,一般来说,我习惯用《用例分析》的方式来进行拆解。
设计:
在复杂的业务设计中,一般都涉及到状态机的设计,那么我习惯优先设计业务的信息架构和状态机,然后进行页面的设计。
(本图仅为示意图,已做数据脱敏并简化了业务,仅做说明使用)
三、任务中的数据加工机制说明
一般来说,任务中的数据加工机制是有两种实现方式的:
方式1:在任务创建时,即把同步给平台的数据加工完成为一个数据包,当任务执行时,直接将数据包抛给对应平台。
方式2:在任务创建时,只记录基础的请求信息,当任务执行时,再根据需同步数据当前的值加工一个数据包抛给对应平台。
方式1适合字段值明确的任务,如同步订单发货的请求等业务,在这个业务中,{key:value}结构下,value的值是确定的,故可以直接在任务创建时,就将数据包加工出来。
方式2适合同步范围明确的任务,如同步当前OMS系统中的商品上下架状态到外卖平台,在这个业务中,目的是保证平台上的商品上下架状态和OMS中商品的上下架状态一致,如果在任务创建时,就将数据包加工出来,如果此时商品的上下架状态发生变化,由于任务是按创建顺序依次执行的,可能出现平台上的商品上下架状态与OMS系统中短暂不一致的情况,造成一些业务问题。
四、任务中心的适用范围
不能立刻反馈操作结果的业务:如商家向平台同步商品上下架的请求,平台需依次校验后返回是否调用成功,需要一段时间。
需要预定时间执行的业务:如一些商品的特价活动,需要限定时间内生效,故可以放入任务中心统一管理。
业务执行结果较复杂不方便查看的业务:如商品信息同步到外卖平台,由于平台有多种校验机制,可能部分商品由于敏感词等原因出现各种不同的失败原因,需要用户多次查看,依次解决,故需要有一个地方能够进行查看。
需要重复执行的业务:如一些任务异常后,仍需要再次执行的任务。
五、任务中心设计的原则
入口统一,贴近业务:应培养客户心智,将系统中所有涉及的任务都放入一个入口,可将此功能设计到左侧导航栏或其他全局导航中。引导用户从请求反馈弹窗中进入任务中心查看。
进度可视化:防止客户因不知道业务还在进行,而重复发起操作。
支持异常原因的查看:允许查看执行失败和部分数据执行异常的原因,异常原因需进行翻译,尽量不要直接将接口返回的报错显示出来,因为用户无法根据异常的原因,直接做出相应的调整。正确的异常原因应该是【因为XX导致上传未成功,需做XX操作】。
控制数据量:异常数据要长久保存,正常数据可以稍微短一点,防止出现查询性能问题,已经浪费存储空间。
注意重试机制的设计:控制好重试的用户权限一个任务是否支持重试,需考虑实际业务允不允许重试,控制好哪些状态的任务支持重试。
注意异常的提醒设计:可参考文章《 我对B端通知提醒功能的设计思考 | 人人都是产品经理 (woshipm.com) 》
结语:
在文章中《 三年B端产品经理的胡言乱语 | 人人都是产品经理 (woshipm.com) 》,我表达了一个观点,即很多产品的需求,实际上是对当前技术的妥协,并不是说技术上不能做到产品经理的理想需求(比如无论多大的数据量,都能在用户可接受的等待时间内立即返回处理结果),而是做到这种需求的投入回报率(ROI)是我们无法接受的,那么此时,根据技术局限做一些产品设计上的妥协,就显得非常有必要。
同时,本文行文过程中,我尽力想告诉大家,一个产品模块为什么会被拆解设计成一个独立的模块。我们总结如下:
1、以用例的共性考虑: 如果多个用例的参与者和参与者的目标一致,那么我们可以考虑将用例抽象出来,设计成一个独立的模块。如业务配置,任务中心等。
2、以用例中涉及的信息架构考虑: 如果一个用例和另一个用例所需要的信息架构一致,那么我们一般将其做到一个模块中;如OMS的审单,拆单操作,即使两个用例的目标完全不一致,我们仍然将其做到一个模块中;
3、以用例间的操作连贯性考虑: 多个用例间存在连续的前后操作的依赖关系,那么我们一般也可以将其做到一个模块中;如订单的拣货和订单的发货,两个用例的参与者目的都不同,且操作过程中所需要的订单信息也不同(拣货可能更关注商品,发货更关注订单的配送信息),我们仍然将其做到一个模块中。
后续文章还会继续探讨用例是怎么影响产品模块,甚至领域模型的设计的,敬请期待。
本文由 @kathic 原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议。