編輯導(dǎo)讀：業(yè)務(wù)管理后臺(tái)對(duì)于很多企業(yè)來說都是必備的工具，不同的行業(yè)對(duì)管理后臺(tái)的要求有細(xì)微的區(qū)別。本文作者從自身工作經(jīng)驗(yàn)出發(fā)，提出了一套業(yè)務(wù)管理后臺(tái)的設(shè)計(jì)方案，希望對(duì)你有幫助。

本人關(guān)于管理后臺(tái)的一些設(shè)計(jì)有一部分的思考和總結(jié)，期望分享給大家后能有啟發(fā)，進(jìn)而對(duì)產(chǎn)品研發(fā)等工作有一部分幫助~

本文將從以下幾個(gè)維度來分享對(duì)應(yīng)內(nèi)容：

1. 競(jìng)品及行業(yè)分析
2. 梳理業(yè)務(wù)需求和使用場(chǎng)景
3. 設(shè)計(jì)方案詳述
4. 填坑經(jīng)驗(yàn)分享

一、競(jìng)品及行業(yè)分析

1. 行業(yè)

不同的行業(yè)對(duì)管理后臺(tái)的要求有細(xì)微的區(qū)別，以行業(yè)的角度來看：

大致可以分為以上幾類，商城類的注重訂單管理和產(chǎn)品發(fā)布，開放平臺(tái)注重開發(fā)者和技術(shù)應(yīng)用，客戶管理（CRM）注重客戶信息和訂單管理，財(cái)務(wù)關(guān)注資產(chǎn)管理和工資管理，oa注重業(yè)務(wù)流和審批層級(jí)，特殊類如ota和金融監(jiān)管也有各自的業(yè)務(wù)訴求，如ota注重軟件管理和任務(wù)管理，雙錄注重監(jiān)管和訂單；

雖然管理后臺(tái)面向各行各業(yè)都有不一樣的特性，但一般都是有賬號(hào)體系、角色體系、審批流程和操作日志等基礎(chǔ)功能，下面基于其中一類以及筆者經(jīng)歷較深的領(lǐng)域-ota和開放平臺(tái)；

單從ota來看，市面有分三種，F(xiàn)OTA、SOTA和集成OS三類；

FOTA-固件遠(yuǎn)程升級(jí)，一般是涉及到汽車底層電子元件的軟件升級(jí)，剎車、座艙底層和儀表盤等軟件的升級(jí)，大部分的傳統(tǒng)車企都有這部分的能力，并且對(duì)安全性和穩(wěn)定性要求都非常高，畢竟涉及到擋位這類行駛的控制，如果沒有必要的缺陷，基本都不會(huì)隨意升級(jí)；

但在汽車行業(yè)的資本滲透和新興玩家入場(chǎng)，如特斯拉\小鵬等，現(xiàn)在逐步的開放FOTA的遠(yuǎn)端升級(jí)，但一般都是集成類升級(jí)，不會(huì)單獨(dú)分開升級(jí)FOTA；

SOTA-又稱軟件系統(tǒng)升級(jí)，一般都是中控臺(tái)的os層及應(yīng)用升級(jí)，類似手機(jī)系統(tǒng)升級(jí)，但在汽車行業(yè)，這塊還是跟手機(jī)端有所不同，區(qū)別在于以下幾點(diǎn)：

• 交互模式；
• 應(yīng)用穩(wěn)定性安全；
• 語音交互為主；
• 云端能力&車聯(lián)網(wǎng)；

舉個(gè)簡(jiǎn)單的例子，如果車企需要升級(jí)某個(gè)應(yīng)用層的bug或者有新的應(yīng)用可以發(fā)布，一般都是通過SOTA的形式推送給到各端，包括已銷售出去的汽車；

再舉個(gè)其他領(lǐng)域的管理后臺(tái)-開放平臺(tái)。

本人接觸的有語音語義和小程序開放平臺(tái)，這類管理后臺(tái)一般是面向三方開發(fā)者提供技術(shù)底層能力和應(yīng)用框架；

類似于小程序管理后臺(tái)，這類平臺(tái)會(huì)提供開發(fā)者接入手冊(cè)和底層小程序的技術(shù)框架，開發(fā)者基于這個(gè)框架定制化開發(fā)多個(gè)小程序，這類平臺(tái)注重生態(tài)的擴(kuò)充和開發(fā)者入駐的數(shù)量，所以一般都是技術(shù)能力或者市場(chǎng)實(shí)力較為雄厚的科技平臺(tái)公司在布局，這類平臺(tái)既具備To C能力也有To B的能力，區(qū)別在于兩者的資質(zhì)認(rèn)證；

可以看出，各行各業(yè)的管理后臺(tái)，五花八門，那么我們現(xiàn)在就基于單個(gè)應(yīng)用領(lǐng)域去切入，進(jìn)行詳細(xì)的產(chǎn)品設(shè)計(jì)工作；

2. 競(jìng)品

單從OTA，我們就可以找出三類玩家：

• 傳統(tǒng)ota廠商tier1：松下、博世多、偉世通、德賽西威、華陽等；
• 新型車企：特斯拉、小鵬、理想、蔚來等；
• 科技巨頭及合資子品牌：百度、小米、阿里斑馬等；

而傳統(tǒng)車企一般都是和傳統(tǒng)OTA廠商合作，當(dāng)隨著科技能力的滲透和智能化、新能源化越來越高，車企也逐步和科技公司一起合作，在這里我就舉百度的ota能力(給BAIDU打個(gè)廣告)；

從百度提供的ota后臺(tái)可以看出類似開放平臺(tái)的產(chǎn)品定位，以通用能力提供技術(shù)能力，輸出較為豐富的行業(yè)理解能力和技術(shù)底層能力，使接入方能快速接入上線服務(wù)；

但如果我們從項(xiàng)目的角度出發(fā)，我們需要從平臺(tái)中抽象出ota的特征通用需求出來作為參考，如下：

• 產(chǎn)品線管理：FOTA&SOTA；
• 設(shè)備接入管理：接入終端硬件信息和系統(tǒng)要求；
• 軟件升級(jí)及任務(wù)包管理：android差分\整包；
• 數(shù)據(jù)管理：活躍\版本\地域分布；

在抽取了ota的特征需求后我們需要針對(duì)真實(shí)的項(xiàng)目情況去落地設(shè)計(jì)；

二、梳理業(yè)務(wù)需求和使用場(chǎng)景

一般而言業(yè)務(wù)管理后臺(tái)都是面向TO B產(chǎn)品，而TO B的產(chǎn)品最大的特點(diǎn)就是定制化程度高，私有化部署；

而這對(duì)產(chǎn)品設(shè)計(jì)帶來的挑戰(zhàn)就是業(yè)務(wù)訴求頻繁變化和場(chǎng)景復(fù)雜，如果考慮不全面，后續(xù)平臺(tái)返工的成本、概率就會(huì)隨著功能的堆疊變得越來越高；

所以第一步我們需要對(duì)業(yè)務(wù)需求和使用場(chǎng)景進(jìn)行梳理，并且需要基于項(xiàng)目背景及終端設(shè)備出發(fā)，制定核心可落地的功能；

我們假定手頭有以下信息：

• 車載應(yīng)用系統(tǒng)：android 10.1.X;
• 終端芯片：XXX;
• 是否具備輔助設(shè)備：T-box；
• 設(shè)備型號(hào)：XXX；

有了以上的信息，咱們就以車載OTA（云端更新系統(tǒng)軟件包）的服務(wù)端簡(jiǎn)化流程舉例，可以參考以下的思路嘗試整理：

經(jīng)過上面的整理，我們就可以從中抽取出具體的平臺(tái)功能，如下圖標(biāo)藍(lán)部分：

當(dāng)然這個(gè)也還算是初略的版本，所以下一步，我們就需要進(jìn)入詳細(xì)的方案擬定；

三、設(shè)計(jì)方案描述

在進(jìn)行詳細(xì)的需求設(shè)計(jì)時(shí)，遵循三個(gè)原則：

• 合理運(yùn)用中臺(tái)思路；
• 能簡(jiǎn)化就簡(jiǎn)化；
• 關(guān)注業(yè)務(wù)流程閉環(huán)；

前面兩點(diǎn)簡(jiǎn)單地說，就如下圖展示的情況，模塊高度集成且互相關(guān)聯(lián)；

然后在制定詳細(xì)的需求書時(shí)需要先制定基礎(chǔ)功能，類似于角色數(shù)量、權(quán)限管理及審批、賬號(hào)登錄\登出等，如下圖：

還是以O(shè)TA作為例子，在這個(gè)例子中，由于首先是面向的對(duì)象是車企研發(fā)和測(cè)試的人員，使用對(duì)象不會(huì)外授權(quán)給外部開發(fā)者和市場(chǎng)人員。

畢竟如果更新包或者策略出問題了，這個(gè)肯定是會(huì)造成車企經(jīng)濟(jì)損失和名譽(yù)損傷。

這時(shí)候其實(shí)角色數(shù)量和審批的流程就可以簡(jiǎn)化處理，角色定義管理員和普通角色、審批流采取二級(jí)審批或者驗(yàn)證碼二次確認(rèn)即可，如果為了保險(xiǎn)，其實(shí)也可以增加一個(gè)密鑰驗(yàn)證；

確定好角色和審批，就需要確認(rèn)賬號(hào)體系，但一般TO B大型項(xiàng)目都會(huì)有一套通用的賬號(hào)體系，所以直接沿用即可；

當(dāng)我們制定了完整閉環(huán)的業(yè)務(wù)流程后，我們就可以參考之前的需求分析抽取的功能點(diǎn)和業(yè)務(wù)流程制定幾個(gè)大的功能模塊；

如：

1. 首頁：呈現(xiàn)業(yè)務(wù)數(shù)據(jù)和報(bào)表，涉及設(shè)備、系統(tǒng)版本、升級(jí)成功率等數(shù)據(jù)類型等；
2. 軟件包管理：管理軟件包和上傳通道，涉及軟件包校驗(yàn)、軟件包大小要求及信息、產(chǎn)品線管理等；
3. 任務(wù)管理：制定OTA的規(guī)則和策略，涉及OTA任務(wù)信息、升級(jí)版本要求、重復(fù)推送機(jī)制、基于VIN碼和系統(tǒng)版本推送、任務(wù)中止條件等；
4. 操作歷史記錄：記錄每個(gè)用戶對(duì)應(yīng)的操作記錄，涉及軟件包上傳、產(chǎn)品線信息變更、任務(wù)發(fā)布等；
5. 賬號(hào)中心和通知中心：記錄審批的通知和用戶角色管理，涉及角色梯度、任務(wù)發(fā)布通知管理等；

由于OTA的領(lǐng)域要求，一般都是會(huì)對(duì)數(shù)據(jù)及升級(jí)情況有比較明確且具體的要求，下面就以數(shù)據(jù)上報(bào)和報(bào)表呈現(xiàn)展開；

在我負(fù)責(zé)項(xiàng)目中，接收的數(shù)據(jù)要求有：

• 推送及升級(jí)情況：包括推送和下載情況；
• 設(shè)備及分布情況：當(dāng)前主流設(shè)備版本號(hào)、版本分布情況、在線設(shè)備數(shù)量；
• 任務(wù)及詳細(xì)情況：?jiǎn)未紊?jí)包推送情況、單次任務(wù)成功率、失敗及對(duì)應(yīng)日志；

針對(duì)推送及升級(jí)情況這類數(shù)據(jù)：

在初始化項(xiàng)目時(shí)，一般我們都是需要有初步的數(shù)據(jù)源導(dǎo)入到平臺(tái)中，因?yàn)閺?-1的項(xiàng)目中，設(shè)備未激活，無法上報(bào)對(duì)應(yīng)的數(shù)據(jù)，我們就無法發(fā)布任務(wù)推送到端上，所以是需要默認(rèn)的數(shù)據(jù)源作為平臺(tái)的基礎(chǔ)數(shù)據(jù)；

而一般這類基礎(chǔ)數(shù)據(jù)都會(huì)由車企或者tier1來提供，我們需要導(dǎo)入到平臺(tái)中進(jìn)行初始化；

有了基礎(chǔ)數(shù)據(jù)，我們還需要定義好具體的數(shù)據(jù)指標(biāo)，方便項(xiàng)目交付后的驗(yàn)收，呈現(xiàn)的數(shù)量雖然能滿足車企的訴求，但不夠直觀，所以一般我們還是需要定義具體指標(biāo)；

如推送成功率=下載成功量/成功推送量等；

針對(duì)設(shè)備及分布情況這類數(shù)據(jù)：

這類數(shù)據(jù)需要基于客戶端下載的情況進(jìn)行上報(bào)，如設(shè)備在接收到軟件包升級(jí)時(shí)，需要在升級(jí)成功時(shí)同時(shí)上報(bào)升級(jí)結(jié)果、當(dāng)前版本，如果涉及到地區(qū)分布需求，還需要上報(bào)經(jīng)緯度，然后后臺(tái)進(jìn)行推演按照地區(qū)或者省份進(jìn)行展示；

針對(duì)任務(wù)及詳細(xì)情況這類數(shù)據(jù)：

任務(wù)對(duì)于每次的ota都是至關(guān)重要的部分，需要準(zhǔn)確記錄每一個(gè)VIN碼的升級(jí)情況（VIN碼、升級(jí)成功與否、推送成功與否等），任務(wù)的推送情況及錯(cuò)誤日志上報(bào)；

另外任務(wù)的詳細(xì)信息也許準(zhǔn)確在后臺(tái)上做展現(xiàn)，方便后續(xù)的維護(hù)和迭代運(yùn)營(yíng)；

四、填坑經(jīng)驗(yàn)分享

最后我就以個(gè)人的經(jīng)驗(yàn)分享“坑”，方便大家避避雷；

坑一：平臺(tái)審批權(quán)限不夠細(xì)分

一般權(quán)限分幾種：操作權(quán)限、菜單權(quán)限、數(shù)據(jù)權(quán)限和用戶權(quán)限；

我遇到過之前有個(gè)平臺(tái)只有菜單權(quán)限，整個(gè)平臺(tái)中只要具備菜單的權(quán)限就可以進(jìn)行操作，細(xì)分顆粒度不夠，導(dǎo)致管控的力度比較粗；

這樣導(dǎo)致的后果，就是無法有效的管理用戶的操作和數(shù)據(jù)泄密的問題，而且如果還沒有操作記錄功能的話，那完全無法知道是誰做了哪些操作，追溯起來十分麻煩；

坑二：交互方式不太符合主流

一般而言，平臺(tái)化的交互模式都是自上而下，模塊放置左側(cè)，右側(cè)放置模塊內(nèi)容信息，并且以列表的形式呈現(xiàn)；

這樣的結(jié)構(gòu)符合用戶的習(xí)性和查看習(xí)慣，如果刻意追求標(biāo)新立異的模式，如從左到右的模式，就有種畫蛇添足的感覺；

如之前接觸過一個(gè)平臺(tái)頂部放置功能欄，左側(cè)放置數(shù)據(jù)報(bào)表和數(shù)據(jù)，右側(cè)放置模塊內(nèi)容信息，整個(gè)交互即讓人眼花繚亂，交互起來又經(jīng)常出問題；

另外平臺(tái)需要注意盡量不要出現(xiàn)以下幾點(diǎn)：

1. 彈框之后再出現(xiàn)彈框；
2. 不知道操作路徑在哪里，即用戶無法知道進(jìn)入的是二級(jí)還是三級(jí)；
3. 能用彈框就用彈框，不要輕易新增頁面；

以上就是本文的全部?jī)?nèi)容，希望能在業(yè)務(wù)管理后臺(tái)的設(shè)計(jì)上提供一些建議和幫助！

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

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