但是，從本質(zhì)上看，后臺(tái)主要有權(quán)限管理、工作流、記錄流三大方面。可以歸結(jié)為一句話，誰可以對(duì)什么進(jìn)行怎樣的操作，需要產(chǎn)生什么記錄：簡(jiǎn)稱who-where-how-what

權(quán)限管理（who-where）

權(quán)限管理，是指一般指根據(jù)系統(tǒng)設(shè)置的安全規(guī)則或者安全策略，用戶可以訪問而且只能訪問自己被授權(quán)的資源。通俗解釋就是，誰是否對(duì)某資源具有實(shí)施 某個(gè)動(dòng)作（運(yùn)動(dòng)、計(jì)算）的權(quán)限

權(quán)限管理，目前主要是通過用戶、角色、資源三方面來進(jìn)行權(quán)限的分配。具體來說，就是賦予用戶某個(gè)角色，角色能訪問及操作不同范圍的資源。通過建立角色系統(tǒng)，將用戶和資源進(jìn)行分離，來保證權(quán)限分配的實(shí)施。

那么，權(quán)限可以怎樣設(shè)計(jì)呢？

如果是業(yè)務(wù)流后臺(tái)，在設(shè)計(jì)權(quán)限時(shí)，可以按業(yè)務(wù)類型進(jìn)行角色設(shè)計(jì)，比如客服、運(yùn)營(yíng)、充值員；如果是數(shù)據(jù)統(tǒng)計(jì)后臺(tái)，可以按用戶類型來進(jìn)行角色設(shè)計(jì)，如對(duì)外用戶、內(nèi)部人員；如果是CRM，則可以按用戶的職位等級(jí)進(jìn)行劃分。在進(jìn)行一級(jí)劃分后，往往還需要對(duì)角色進(jìn)行細(xì)分，例如客服，可以細(xì)分為 普通客服、客服組長(zhǎng)、客服總監(jiān)，通過級(jí)別的劃分來控制可訪問及操作的數(shù)據(jù)。

另外，在進(jìn)行角色的細(xì)化時(shí)，有兩點(diǎn)是需要注意的：

1. 同類型的角色，上下級(jí)角色的權(quán)限關(guān)聯(lián)是怎樣的？上級(jí)角色是否能對(duì)下級(jí)角色的業(yè)務(wù)進(jìn)行操作？下架的操作是否需要上級(jí)的審核？

2. 對(duì)外用戶，是采取權(quán)限分離，還是采取兩個(gè)不同的后臺(tái)去處理？前者的話，實(shí)現(xiàn)起來方便一些，就看系統(tǒng)對(duì)于安全性的考慮；后者的話，會(huì)更加的安全，在數(shù)據(jù)的處理上也會(huì)方便一些

雖然我們將權(quán)限管理放在第一位，但是在實(shí)際開發(fā)過程中，權(quán)限的分配往往是在整個(gè)后臺(tái)開發(fā)完畢后才去實(shí)現(xiàn)的（主要是為了避免權(quán)限設(shè)置對(duì)開發(fā)造成影響）。

工作流（how）

工作流（Workflow），指“業(yè)務(wù)過程的部分或整體在計(jì)算機(jī)應(yīng)用環(huán)境下的自動(dòng)化”。是對(duì)工作流程及其各操作步驟之間業(yè)務(wù)規(guī)則的抽象、概括描述

工作流主要解決的主要問題是：為了實(shí)現(xiàn)某個(gè)業(yè)務(wù)目標(biāo)，利用計(jì)算機(jī)在多個(gè)參與者之間按某種預(yù)定規(guī)則自動(dòng)傳遞文檔、信息或者任務(wù)。

設(shè)計(jì)工作流時(shí)，除了最基本的單個(gè)后臺(tái)工作流的設(shè)計(jì)，還有多個(gè)后臺(tái)之間進(jìn)行工作流的設(shè)計(jì)。OK，先從最基本的單個(gè)后臺(tái)開始聊聊，工作流的設(shè)計(jì)，其實(shí)和2C產(chǎn)品的需求設(shè)計(jì)很相似：

1. 在了解業(yè)務(wù)需求后，產(chǎn)出適合的業(yè)務(wù)流程圖（業(yè)務(wù)流程圖此處不展開，稍后另開一章來寫）、狀態(tài)圖（部分簡(jiǎn)單的工作流不需要出這個(gè)），通過業(yè)務(wù)流程圖，向開發(fā)更好的傳遞業(yè)務(wù)需求

2. 搭建工作流的產(chǎn)品架構(gòu)圖，主要是羅列工作流涉及到的功能模塊（廣度思考），這個(gè)時(shí)候，就可以將產(chǎn)品架構(gòu)圖和其他人進(jìn)行碰撞；為什么不使用產(chǎn)品原型圖來碰呢？這個(gè)以下幾點(diǎn)原因：

（1）產(chǎn)品原型產(chǎn)出周期較長(zhǎng)，不適合前期的思維碰撞

（2）產(chǎn)品架構(gòu)圖比產(chǎn)品原型返工更容易，能夠更快的迭代

（3）可以針對(duì)后期加入的需求低成本的進(jìn)行討論，使開發(fā)設(shè)計(jì)庫表時(shí)，更好的考慮拓展性

3. 通過前兩步，基本可以把工作流較好的傳遞給研發(fā)那邊；緊接著，可以將產(chǎn)品架構(gòu)圖進(jìn)行細(xì)化，細(xì)化到什么程度呢？最好是把工作流涉及的點(diǎn)都能夠細(xì)化在上面，這樣，在產(chǎn)出產(chǎn)品原型圖的時(shí)候，可以更加全面的是思考單個(gè)模塊與整個(gè)后臺(tái)系統(tǒng)之間的交互

4.在第三點(diǎn)，有提到了產(chǎn)品架構(gòu)圖的細(xì)化，接著，就是放大招的時(shí)候— 出產(chǎn)品原型圖

5.適當(dāng)?shù)闹貜?fù)上述3、4點(diǎn)，這樣，一個(gè)較完整的工作流就設(shè)計(jì)好了

在出了產(chǎn)品原型圖，就要開始和研發(fā)大大進(jìn)行更兇殘的肉體碰撞了，關(guān)于肉體碰撞的細(xì)節(jié)，在這里就不展開了，但是可以補(bǔ)充一句：做產(chǎn)品得耐操！

上面講述的都是單個(gè)系統(tǒng)內(nèi)的工作流設(shè)計(jì)，那么 多個(gè)系統(tǒng)協(xié)同處理的工作流有什么不同呢？

首先在設(shè)計(jì)上，基本流程不會(huì)有區(qū)分。主要是要和系統(tǒng)架構(gòu)師多多溝通，讓一整套系的工作流能夠更好的滿足業(yè)務(wù)需求。在進(jìn)行溝通的時(shí)候，最好可以先自己擬定一份假想架構(gòu)圖，這份產(chǎn)出物更多關(guān)注的是不同系統(tǒng)之間的數(shù)據(jù)交互，表明系統(tǒng)間的輸出、輸入，這樣，在定好滿足需求的架構(gòu)上，才能夠更好的對(duì)工作流進(jìn)行設(shè)計(jì)。

其次，還有一點(diǎn)細(xì)節(jié)是需要關(guān)注的，那就是在不同后臺(tái)的原型圖中，要注意描述清楚工作流是否與其他模塊有所交互，這樣方便自己，也方便他人。

記錄流（what）

后臺(tái)系統(tǒng)進(jìn)行設(shè)計(jì)時(shí)，往往都會(huì)有一個(gè)專門的操作日志，記錄后臺(tái)登錄用戶的操作軌跡，主要是因?yàn)楹笈_(tái)數(shù)據(jù)對(duì)于企業(yè)來說是比較有價(jià)值的，所以需要對(duì)其進(jìn)行保護(hù)。

總的來說，記錄流主要分 操作軌跡、數(shù)據(jù)查詢兩種。

操作軌跡，很容易理解，就是用戶對(duì)后臺(tái)的數(shù)據(jù)進(jìn)行操作所產(chǎn)生的記錄，需要達(dá)到一步一記錄的程度。這種，在進(jìn)行設(shè)計(jì)時(shí)，就是將初始狀態(tài)、變更狀態(tài)、操作內(nèi)容、操作人、操作時(shí)間羅列清楚就OK了，不同業(yè)務(wù)差異性不大，算是后臺(tái)的標(biāo)配模塊

數(shù)據(jù)查詢，這個(gè)的話，更多是對(duì)于工作流中產(chǎn)生的數(shù)據(jù)進(jìn)行整理，然后形成的功能模塊。這種的話，不會(huì)像操作軌跡那樣，每一步都會(huì)記錄下來。而是會(huì)根據(jù)具體的業(yè)務(wù)需求來進(jìn)行設(shè)計(jì)，以滿足用戶能夠在后臺(tái)中針對(duì)不同緯度的數(shù)據(jù)進(jìn)行查詢、了解、分析，獲取價(jià)值。

出了上述的三個(gè)基本模塊，在進(jìn)行后臺(tái)設(shè)計(jì)的時(shí)候，還有一點(diǎn)可以關(guān)注一下，盡量使用默認(rèn)控件去進(jìn)行設(shè)計(jì)，以及不同模塊之間，能夠使用較為統(tǒng)一的交互方式，這樣開發(fā)起來更有效率。

以上是后臺(tái)設(shè)計(jì)Part1，在這方面有心得大大，歡迎加我微信Yoic__，（驗(yàn)證寫簡(jiǎn)書）一起交流討論下哈~~

#專欄作家#

Yoic，簡(jiǎn)書@Yoic，人人都是產(chǎn)品經(jīng)理專欄作家，關(guān)注游戲、電商等領(lǐng)域，正在努力成長(zhǎng)的產(chǎn)品汪一枚。愛好：星際2和看書

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