本文作者詳細的描述了，一個產(chǎn)品經(jīng)理在做B端（后端）的詳細的方案設計時的思考以及工作的流程，enjoy~

一、前言

有一天被老板拉進了一個微信群，上游渠道的對接群，然后就說，和這個上游對接一下，把兩邊的系統(tǒng)打通。老板的需求就這么一句話，兩邊系統(tǒng)需要打通，而兩個企業(yè)系統(tǒng)之間對接起來往往需要通過接口的形式，所以首先需要的看對方給出的接口文檔。做B端的產(chǎn)品往往對外輸出產(chǎn)品的時候也是以接口的形式對外輸出。

二、系統(tǒng)流程設計

在和對方的接觸過程中，發(fā)現(xiàn)對方是一個支付公司，老板的想法是在原有系統(tǒng)的支付渠道中加一條支付通道，加強系統(tǒng)的容災能力。原本系統(tǒng)是只有單渠道在允許，一旦上游出現(xiàn)問題，那么我們系統(tǒng)就無法完成支付，造成系統(tǒng)的癱瘓。

1. 原有流程整理

在進行新的方案流程設計之前，如果這個系統(tǒng)之前不是你經(jīng)手的，或者是你很久之前做的，經(jīng)過了幾個版本的迭代，也不太記得具體的流程了。最好首選要做的是先梳理一下現(xiàn)有的系統(tǒng)中邏輯，只有清楚了現(xiàn)有系統(tǒng)中的邏輯才能實現(xiàn)以最小代價完成系統(tǒng)的改造，并且在上線之后不會有太大的后遺癥出現(xiàn)。

那么先來看一下整理的現(xiàn)有的系統(tǒng)流程圖。我采用的也是常用的泳道圖，可以清晰的看到每個模塊的處理情況。

給大家稍微的解釋一下原來的整體流程：

這是自助零售系統(tǒng)的充值業(yè)務，整個流程需要經(jīng)過優(yōu)惠管理模塊、訂單管理模式、賬戶管理模塊。具體流程主要以下幾點：

1. 用戶在前端點擊充值，后端接收請求后會根據(jù)系統(tǒng)配置判斷改用戶是否有充值優(yōu)惠，如果有充值優(yōu)惠則返回充值優(yōu)惠套餐給用戶選擇，系統(tǒng)沒有配置單的優(yōu)惠套餐則選擇系統(tǒng)默認套餐。
2. 用戶選擇充值金額后，請求后端訂單管理模塊，會創(chuàng)建充值訂單。根據(jù)用戶的支付結(jié)果返回給前端，然后前端展示相應的頁面。
3. 如果用戶充值成功，會通知賬戶管理模塊，賬戶管理模塊會根據(jù)充值數(shù)量，對應的用戶上增加相關的數(shù)量。還會判斷存在代理商分潤情況，如果有分潤則對應的代理商賬戶也會增加分潤值。

2. 問題思考

由于第一版系統(tǒng)設計的是單渠道模式，所以在創(chuàng)建訂單時直接是往上游（即支付公司）上送交易數(shù)據(jù)，思考了以下幾點問題：

1. 如果需要新增一條渠道，需要如何進行新增，創(chuàng)建訂單之前添加還是創(chuàng)建訂單之后添加？
2. 是否需要單獨的將渠道管理模塊獨立管理？
3. 用戶使用的前端頁面是否需要相應的修改，改動對于用戶是否無感知？

3. 新流程設計

帶著以上幾個問題，對系統(tǒng)的充值流程進行了改造，具體請看下圖：

根據(jù)上圖解釋對上面的問題進行一一的解釋：

1）如何新增渠道問題

采用了支付系統(tǒng)中常見的支付路由管理的辦法，對渠道進行新增，這樣對于系統(tǒng)而言，兼容性比較強，不需要每次新增渠道時，前端頁面需要相應的配合改造，同時也解決了第三個問題，采用這個模式用戶是無感的，整個流程僅僅只是新增了支付路由的形式。還有就是方便運營人員切換渠道，當上游不支持公司業(yè)務或與上游解約時，不需要上線，通過配置形式就可以完成渠道的切換。

此外制作路由最主要的目的是為公司節(jié)約成本，每次交易盡可能的走最低費率的渠道。

2）為什么路由模塊是添加在創(chuàng)建訂單之后呢

如果在創(chuàng)建訂單前添加的話，首先用戶在查詢訂單時候是查不到結(jié)果的，第二運營人員在相應的訂單查詢頁面也是查不到相關數(shù)據(jù)，就算有單獨創(chuàng)建失敗訂單查詢頁面（即單獨查詢系統(tǒng)創(chuàng)建失敗的位置），也不是很方便的進行查詢。

3）改動對于用戶是否無感知

系統(tǒng)中新增了支付路由選擇，渠道選擇是在系統(tǒng)中完成的，所以用戶是在體驗上是完全無感知的。由于整體的流程圖放置不下路由管理屬性，所以將路由規(guī)則單獨制作一張流程進行展示：

三、了解接口文檔參數(shù)信息

在設計完業(yè)務流程之后需要對系統(tǒng)關鍵字段進行設計，關鍵字段的設計包含著兩方面，第一是涉及到對接口的輸出，可以給開發(fā)輸出關鍵的字段給到對應的接口文檔中。第二是在運用在運營頁面上，所需要的字段內(nèi)容。本文以支付寶接口為例，接口地址：https://docs.open.alipay.com/api_1/alipay.trade.pay。

先設計對外接口的輸出部分，這里就以大家所熟知的支付寶的支付接口為例：這里例子是統(tǒng)一收單交易支付接口（其實就是常見的出示付款碼）。先來看一下請求參數(shù)部分，分為公共請求參數(shù)和請求參數(shù)。

1. 公共參數(shù)信息

公眾參數(shù)部分作為產(chǎn)品的角度看，不需要太多的關注，都是固定值比較多。前期在上線之前之前需要準備好相關的參數(shù)給給開發(fā)即可，例如下圖中的app_id，這個需要去支付寶那邊申請后會報備下來一個app_id，可以說是代表企業(yè)身份的唯一標識。其他的秘鑰這些參數(shù)由開發(fā)生成即可。

2. 請求參數(shù)

我們的核心重點一般是關注在請求參數(shù)上，請求參數(shù)是一些變量值，有可能是在對外的接口文檔中所需要，也有可能在運營頁面中需要。例如：訂單查詢頁面的字段就需要與接口請求參數(shù)保持一致，才能準確的查詢出訂單的詳情的信息。

上圖截取了請求參數(shù)的部分，其中必選參數(shù)則必須要往支付寶上送的參數(shù)值，可選參數(shù)則根據(jù)實際情況上送，如果是對外包裝成產(chǎn)品的話，這部分參數(shù)需要在對外接口中是否需要商戶端傳輸。例如訂單標題，買家支付寶ID、支付寶授權碼、訂單金額等，如果僅是自身業(yè)務使用則在業(yè)務中需要獲取到相關的參數(shù)值往支付寶接口中上送即可。

四、接口文檔關鍵字段設計

1. 新增接口關鍵字段說明

這里是以對外輸出接口為主要設計，所以在寫文檔時，建議開發(fā)對外接口必填參數(shù)包含但不限于商戶訂單（這個是由商戶上傳的，可與支付寶的生成規(guī)則可不同，系統(tǒng)中訂單生成規(guī)則盡量使用同一套，系統(tǒng)兼容性更強一些）、支付場景、支付寶授權碼、訂單標題、支付寶用戶id、商戶簽約賬號、訂單金額，選填參數(shù)包括但不限于銷售產(chǎn)品碼、優(yōu)惠金額、訂單描述等。

根據(jù)以上分析，生成下列的關鍵字段信息描述如下（僅列舉了部分），這些關鍵字段同樣適用于訂單查詢頁面。

2. 存量接口關鍵字段說明

上圖列舉的關鍵字段其實是針對于全新的接口對接，如果是在現(xiàn)有的接口上進行的兼容的話，那么就需要先比對一下現(xiàn)有的字段是否能夠滿足所對接接口的字段要求，具體案例如下：

五、運營頁面設計

對于B端（后端）來說，管理后臺的頁面雖然是比較注重的功能，但是對于使用體驗上也得有一定的要求才行，運營人員使用起來需要方便快捷。

針對此次系統(tǒng)改造頁面設計包括訂單查詢頁面優(yōu)化（因為系統(tǒng)已有訂單查詢頁面，如無則需要新增）、支付路由配置頁面新增。其中支付路由頁面包括，常規(guī)支付路由配置頁面，個性化支付路由配置頁面，銀行配置頁面等。

本文以常規(guī)支付路由配置頁面舉例，改動對于用戶是否無感知。

1. 頁面字段設計

根據(jù)支付路由的流程設計到字段，后臺的操作頁面與平時看到C端的頁面有所不同，基本都是由表格構成，先將頁面需要展示核心的關鍵字段進行設計，方便后續(xù)的原型制作時，不會空想，此外幫助開發(fā)剛加的了解業(yè)務內(nèi)容，避免開發(fā)在設計數(shù)據(jù)庫字段與實際使用不相符情況。

具體關鍵字段如下圖所示，里面的字段是隨機的列舉，如有錯誤請見諒：

2. 狀態(tài)機圖

狀態(tài)流程說明：創(chuàng)建完后進入到待審核狀態(tài)，審核通過直接啟用，審核拒絕則變更為審核不通過，審核不通過可以重新提交，進行待審核，啟用與禁用下可以相互轉(zhuǎn)換。

3. 頁面設計

操作按鈕包括查詢、新增、下載、審核、修改、刪除。

字段說明：成功率、費率在初始階段僅作為參考作用，成功率每日進行更新統(tǒng)計，這兩個字段后期可加入路由選擇權重判斷，其余的參考關鍵字段設計表。

六、總結(jié)

本文詳細的描述了一個產(chǎn)品經(jīng)理在做B端（后端）的詳細的方案設計時的思考以及工作的流程。

總結(jié)歸納的步驟如下：

1. 系統(tǒng)流程梳理：輸出對應的業(yè)務流程圖。
2. 查閱接口文檔：查看現(xiàn)有系統(tǒng)的字段是否可以復用。
3. 接口關鍵字段設計：定義對外的接口文檔關鍵字段。
4. 運營功能頁面設計：設計運營后臺的操作功能。

最后感謝大家閱讀完本文，如有寫的不對的地方，請批評指正錯誤，歡迎大家一起來探討。

本文由 @TOM 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。