国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

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

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

本文將從以下幾個維度來分享對應內(nèi)容：

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

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

1. 行業(yè)

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 競品

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當然這個也還算是初略的版本，所以下一步，我們就需要進入詳細的方案擬定；

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

在進行詳細的需求設(shè)計時，遵循三個原則：

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

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

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

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

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

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

確定好角色和審批，就需要確認賬號體系，但一般TO B大型項目都會有一套通用的賬號體系，所以直接沿用即可；

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

如：

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

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

在我負責項目中，接收的數(shù)據(jù)要求有：

• 推送及升級情況：包括推送和下載情況；
• 設(shè)備及分布情況：當前主流設(shè)備版本號、版本分布情況、在線設(shè)備數(shù)量；
• 任務(wù)及詳細情況：單次升級包推送情況、單次任務(wù)成功率、失敗及對應日志；

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

在初始化項目時，一般我們都是需要有初步的數(shù)據(jù)源導入到平臺中，因為從0-1的項目中，設(shè)備未激活，無法上報對應的數(shù)據(jù)，我們就無法發(fā)布任務(wù)推送到端上，所以是需要默認的數(shù)據(jù)源作為平臺的基礎(chǔ)數(shù)據(jù)；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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