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

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

本人關于管理后臺的一些設計有一部分的思考和總結，期望分享給大家后能有啟發，進而對產品研發等工作有一部分幫助~

本文將從以下幾個維度來分享對應內容：

1. 競品及行業分析
2. 梳理業務需求和使用場景
3. 設計方案詳述
4. 填坑經驗分享

一、競品及行業分析

1. 行業

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

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

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

單從ota來看，市面有分三種，FOTA、SOTA和集成OS三類；

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

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

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

• 交互模式；
• 應用穩定性安全；
• 語音交互為主；
• 云端能力&車聯網；

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

再舉個其他領域的管理后臺-開放平臺。

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

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

可以看出，各行各業的管理后臺，五花八門，那么我們現在就基于單個應用領域去切入，進行詳細的產品設計工作；

2. 競品

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

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

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

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

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

• 產品線管理：FOTA&SOTA；
• 設備接入管理：接入終端硬件信息和系統要求；
• 軟件升級及任務包管理：android差分\整包；
• 數據管理：活躍\版本\地域分布；

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

二、梳理業務需求和使用場景

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

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

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

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

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

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

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

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

三、設計方案描述

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

• 合理運用中臺思路；
• 能簡化就簡化；
• 關注業務流程閉環；

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

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

還是以OTA作為例子，在這個例子中，由于首先是面向的對象是車企研發和測試的人員，使用對象不會外授權給外部開發者和市場人員。

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

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

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

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

如：

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

由于OTA的領域要求，一般都是會對數據及升級情況有比較明確且具體的要求，下面就以數據上報和報表呈現展開；

在我負責項目中，接收的數據要求有：

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

針對推送及升級情況這類數據：

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

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

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

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

針對設備及分布情況這類數據：

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

針對任務及詳細情況這類數據：

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

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

四、填坑經驗分享

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

坑一：平臺審批權限不夠細分

一般權限分幾種：操作權限、菜單權限、數據權限和用戶權限；

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

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

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

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

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

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

另外平臺需要注意盡量不要出現以下幾點：

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

以上就是本文的全部內容，希望能在業務管理后臺的設計上提供一些建議和幫助！

本文由 @SiegZhong 原創發布于人人都是產品經理，未經許可，禁止轉載

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