中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：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 協議。