我对B端任务中心功能的设计思考

2 评论 7182 浏览 53 收藏 14 分钟

编辑导语:B端系统中任务中心模块作用是什么,设计这个模块的意义在哪里,是很多人的疑虑,本文的作者就从设计的原因、适用范围等几个角度详细介绍了这个功能,感兴趣的小伙伴一起来看看吧。

如果大家留意,在B端系统中,经常会看到一个任务中心的模块。那么这个模块的作用是什么,为什么要设计这个模块呢?今天笔者就从自身的工作经验出发,来给大家介绍一下我对OMS系统中任务中心模块的设计思考。

一、为什么需要任务中心

B端系统中任务中心的出现,和程序编程接口(API)的特性脱不开关系。应用程序接口API(Application Programming Interface),是提供特定业务输出能力、连接不同系统的一种约定。这里包括外部系统与提供服务的系统(中后台系统)或后台不同系统之间的交互点。包括外部接口、内部接口等。接口的响应机制类型有:

  • 同步交互:即需等待服务端将请求处理完成,接口才会返回结果,业务才可以继续进行。如登录验证时,需要服务端验证通过账号密码时,接口才会返回成功,才能正常登录。
  • 异步交互:接口返回成功仅表示请求行为成功了,对方系统收到请求后异步对业务进行操作,调用方无须等待每个请求的调用结果。如OMS请求发货,接口返回成功,仅表示WMS收到了这个请求,WMS系统还会异步的去生成对应的发货单进行操作。

一般来说用户登录、单据状态的变更等等,都会使用同步交互操作,其余情况都优先使用异步交互。但是无论同步交互还是异步交互,仍然会遇到以下问题:

同步交互: 接口调用超时或由于非业务原因导致的调用失败,需要重复调用,那么我们当请求失败时其实最好的选择是:

step1:界面提示:

  1. case1:请求成功
  2. case2:请求失败,系统自动重
  3. case3:请求失败,失败原因为:xxxx

step2:系统自动重试:

  1. if 达到一定的次数
  2. 自动停止,展示错误原因,通知用户允许用户手动重试

异步交互:接口调用成功了(如果失败,和同步交互的处理方式一致),但是实际业务没正常进行。

对方系统推送失败数据,进行界面提示:

  1. 根据预设的逻辑,系统根据失败原因自动处理
  2. 用户查看失败原因,手动处理

由此可见,多系统间的交互异常是频繁的,那么用户仍需要对这种情况进行处理,则提出了几点要求:

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 协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 有点初级

    回复
  2. 欢迎大家批评指正,如果觉得还可以,帮忙点点收藏点赞,哈哈哈

    来自上海 回复