编辑导语：B端系统中任务中心模块作用是什么，设计这个模块的意义在哪里，是很多人的疑虑，本文的作者就从设计的原因、适用范围等几个角度详细介绍了这个功能，感兴趣的小伙伴一起来看看吧。
如果大家留意，在B端系统中，经常会看到一个任务中心的模块。那么这个模块的作用是什么，为什么要设计这个模块呢？今天笔者就从自身的工作经验出发，来给大家介绍一下我对OMS系统中任务中心模块的设计思考。
B端系统中任务中心的出现，和程序编程接口（API）的特性脱不开关系。应用程序接口API（Application Programming Interface），是提供特定业务输出能力、连接不同系统的一种约定。这里包括外部系统与提供服务的系统（中后台系统）或后台不同系统之间的交互点。包括外部接口、内部接口等。接口的响应机制类型有：
一般来说用户登录、单据状态的变更等等，都会使用同步交互操作，其余情况都优先使用异步交互。但是无论同步交互还是异步交互，仍然会遇到以下问题：
同步交互： 接口调用超时或由于非业务原因导致的调用失败，需要重复调用，那么我们当请求失败时其实最好的选择是：
step1：界面提示：
step2：系统自动重试：
异步交互：接口调用成功了（如果失败，和同步交互的处理方式一致），但是实际业务没正常进行。
对方系统推送失败数据，进行界面提示：
由此可见，多系统间的交互异常是频繁的，那么用户仍需要对这种情况进行处理，则提出了几点要求：
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 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。