B端產品,如何做產品詳細方案設計?

本文作者詳細的描述了，一個產品經理在做B端（後端）的詳細的方案設計時的思考以及工作的流程，enjoy~

一、前言

有一天被老闆拉進了一個微信群，上遊渠道的對接群，然後就說，和這個上遊對接一下，把兩邊的系統打通。老闆的需求就這麼一句話，兩邊系統需要打通，而兩個企業系統之間對接起來往往需要通過接口的形式，所以首先需要的看對方給出的接口文檔。做B端的產品往往對外輸出產品的時候也是以接口的形式對外輸出。

二、系統流程設計

在和對方的接觸過程中，發現對方是一個支付公司，老闆的想法是在原有系統的支付渠道中加一條支付通道，加強系統的容災能力。原本系統是只有單渠道在允許，一旦上遊出現問題，那麼我們系統就無法完成支付，造成系統的癱瘓。

1. 原有流程整理

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

那麼先來看一下整理的現有的系統流程圖。我採用的也是常用的泳道圖，可以清晰的看到每個模塊的處理情況。

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

這是自助零售系統的充值業務，整個流程需要經過優惠管理模塊、訂單管理模式、帳戶管理模塊。具體流程主要以下幾點：

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

2. 問題思考

由於第一版系統設計的是單渠道模式，所以在創建訂單時直接是往上遊（即支付公司）上送交易數據，思考了以下幾點問題：

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

3. 新流程設計

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

根據上圖解釋對上面的問題進行一一的解釋：

1）如何新增渠道問題

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

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

2）為什麼路由模塊是添加在創建訂單之後呢

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

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

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

三、了解接口文檔參數信息

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

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

1. 公共參數信息

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

2. 請求參數

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

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

四、接口文檔關鍵欄位設計

1. 新增接口關鍵欄位說明

這裡是以對外輸出接口為主要設計，所以在寫文檔時，建議開發對外接口必填參數包含但不限於商戶訂單（這個是由商戶上傳的，可與支付寶的生成規則可不同，系統中訂單生成規則儘量使用同一套，系統兼容性更強一些）、支付場景、支付寶授權碼、訂單標題、支付寶用戶id、商戶籤約帳號、訂單金額，選填參數包括但不限於銷售產品碼、優惠金額、訂單描述等。

根據以上分析，生成下列的關鍵欄位信息描述如下（僅列舉了部分），這些關鍵欄位同樣適用於訂單查詢頁面。

2. 存量接口關鍵欄位說明

上圖列舉的關鍵欄位其實是針對於全新的接口對接，如果是在現有的接口上進行的兼容的話，那麼就需要先比對一下現有的欄位是否能夠滿足所對接接口的欄位要求，具體案例如下：

五、運營頁面設計

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

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

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

1. 頁面欄位設計

根據支付路由的流程設計到欄位，後臺的操作頁面與平時看到C端的頁面有所不同，基本都是由表格構成，先將頁面需要展示核心的關鍵欄位進行設計，方便後續的原型製作時，不會空想，此外幫助開發剛加的了解業務內容，避免開發在設計資料庫欄位與實際使用不相符情況。

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

2. 狀態機圖

狀態流程說明：創建完後進入到待審核狀態，審核通過直接啟用，審核拒絕則變更為審核不通過，審核不通過可以重新提交，進行待審核，啟用與禁用下可以相互轉換。

3. 頁面設計

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

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

六、總結

本文詳細的描述了一個產品經理在做B端（後端）的詳細的方案設計時的思考以及工作的流程。

總結歸納的步驟如下：

1. 系統流程梳理：輸出對應的業務流程圖。
2. 查閱接口文檔：查看現有系統的欄位是否可以復用。
3. 接口關鍵欄位設計：定義對外的接口文檔關鍵欄位。
4. 運營功能頁面設計：設計運營後臺的操作功能。

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

 

本文由 @TOM 原創發布於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

收藏已收藏 | {{ postmeta.bookmark }} 點讚已贊 | {{ postmeta.postlike }}