從入產(chǎn)品坑開始，其實(shí)早期都是做前臺產(chǎn)品和Web產(chǎn)品為主，對前臺業(yè)務(wù)、用戶體驗(yàn)、交互還是有一定熟悉了解。近些年來，被逼跳后臺、帶團(tuán)隊(duì)，一個(gè)項(xiàng)目往往前后臺產(chǎn)品經(jīng)理基本都帶上做。對于后臺產(chǎn)品開始也慢慢有了自己的模式和想法。

在之前的回答中，也提到像我們這種媒體型互聯(lián)網(wǎng)公司來說，產(chǎn)品還是非?？茨樀?。做后臺產(chǎn)品，不僅僅需要有業(yè)務(wù)流的分析梳理能力、項(xiàng)目管理能力，還必須要帶上點(diǎn)兒交互設(shè)計(jì)能力。多種角色集于一身，所負(fù)責(zé)的往往是一整條產(chǎn)品線，一名產(chǎn)品經(jīng)理必須能有很強(qiáng)的獨(dú)擋一面能力。

好了，既然獨(dú)當(dāng)一面，踩坑就是難免之事。結(jié)合幾個(gè)小案例，回憶回憶吧。

1. 龐大后臺架構(gòu)坑

也許是運(yùn)氣太好，第一個(gè)后臺產(chǎn)品就是一個(gè)大坑。這是一套自主試驗(yàn)型的后臺CMS產(chǎn)品，產(chǎn)品之初是一個(gè)很小的架構(gòu)規(guī)劃，目標(biāo)是小型資訊APP后臺使用。但是，很快產(chǎn)品的風(fēng)向就變了，架構(gòu)鋪大，功能和業(yè)務(wù)邏輯有的沒的都往里加。就這么大概干了3、4個(gè)月，RD團(tuán)隊(duì)和產(chǎn)品團(tuán)隊(duì)已經(jīng)處在崩潰的邊緣，這時(shí)候，我們團(tuán)隊(duì)加入了，原來的產(chǎn)品團(tuán)隊(duì)火速撤離，坑爹的經(jīng)歷開始了。剛接到產(chǎn)品時(shí)我們做的第一件事情就是梳理功能架構(gòu)：

看到了吧，這是一個(gè)小型APP的CMS可能需要的后臺架構(gòu)嗎？顯然不是。

問題清單如下：

• 內(nèi)容管理不夠突出，并且分布在各個(gè)功能模塊中；
• 會員管理是個(gè)毛？完全沒用；
• 維護(hù)菜單下一堆百科內(nèi)容管理，我實(shí)在不想看下去，全都拿出去；
• 站點(diǎn)管理和欄目管理等核心管理功能不全，需要增加管理功能。

經(jīng)過和Boss的一番論戰(zhàn)，將一些將來可能用到的模塊繼續(xù)保留，但調(diào)整結(jié)構(gòu)，核心功能集中。最后的初步成果如下：?

經(jīng)過這次調(diào)整，成績可以總結(jié)為：

• 首先，我們對產(chǎn)品的功能架構(gòu)進(jìn)行了相當(dāng)深入的了解；
• 其次，建立了站點(diǎn)管理模式，使得系統(tǒng)大規(guī)模站點(diǎn)集群管理成為可能；
• 再次，對缺失的核心管理功能進(jìn)行了設(shè)計(jì)；
• 最后，對后臺的交互和體驗(yàn)做了全新改版設(shè)計(jì)。?

但實(shí)際上回頭來看，仍然留下后一堆后續(xù)的大坑，也總結(jié)一下：

• 被逼留下的功能模塊實(shí)際上不少到最后也沒有用上，功能該砍的時(shí)候還是要痛下狠手；
• 欄目配置頁的核心作用是絕對突出了，在這個(gè)面板里能干的事情實(shí)在是太多了，而其他關(guān)聯(lián)的功能模塊能對其配置調(diào)用的相對有限，造成一些管理不便；
• 編輯器有大坑，我們默默地沒有發(fā)現(xiàn)……這個(gè)功能模塊被前行牽扯了太多業(yè)務(wù)邏輯和功能，導(dǎo)致后續(xù)代碼維護(hù)的困難；
• 權(quán)限系統(tǒng)還有坑，這個(gè)后面講。

2. 權(quán)限體系的設(shè)計(jì)坑

接上文的權(quán)限體系坑，原來的系統(tǒng)權(quán)限體系經(jīng)過一段時(shí)間實(shí)際使用測試發(fā)現(xiàn)，具有以下問題：

• 權(quán)限的類別不清，View類權(quán)限和Function類權(quán)限高度綁定，導(dǎo)致用戶菜單難以根據(jù)角色權(quán)限調(diào)整；
• Function類權(quán)限沒有根據(jù)角色進(jìn)行調(diào)配，幾類用戶角色沒有很好實(shí)現(xiàn)權(quán)限隔離；
• 試運(yùn)行階段，系統(tǒng)管理員由RD同學(xué)兼任。用戶權(quán)限配置在實(shí)際工作中，效率很低，需要提升交互效率，同時(shí)還要降低學(xué)習(xí)門檻以便RD撤退。

面對這些情況，具體怎么做的，我就貼點(diǎn)兒圖少碼字吧：

• 使用RBAC角色權(quán)限控制模型；

• 設(shè)計(jì)權(quán)限應(yīng)用流程；

• 增加Data類權(quán)限，對應(yīng)原來的欄目、稿件等內(nèi)容類操作權(quán)限；
• 將原來View/Function兩類權(quán)限拆分，View類權(quán)限單獨(dú)在菜單權(quán)限模塊配置；
• 重新設(shè)計(jì)配置頁面交互，提升效率；（看下圖，原來的設(shè)置方法是一條下面有N條子菜單，控件方式既有單選也有多選。調(diào)整后改為左側(cè)權(quán)限樹方便批量選擇，右側(cè)詳細(xì)功能列表，單項(xiàng)功能可設(shè)：是、否、全不） ?

• 在權(quán)限分類的理念下，建立角色組概念，將內(nèi)容運(yùn)營、開發(fā)、系統(tǒng)管理等角色分離，讓角色組作為角色的權(quán)限模板進(jìn)行快速全局管理；

上面的一套工作看上去還挺過癮，但我可以負(fù)責(zé)任的告訴你，坑爹的地方太多了：

• 角色組概念很美好，但和權(quán)限類別還是無法區(qū)分，搞到最后萬不得已，搞出了可視化權(quán)限等級……?

• 用戶權(quán)限配置聽起來簡單清晰多了，用戶體驗(yàn)細(xì)節(jié)超豐富，但實(shí)際上系統(tǒng)管理員看完之后依然想罵娘！
• 權(quán)限維度很多，導(dǎo)致多個(gè)權(quán)限配置頁面都可能要做相關(guān)快速配置入口。API多，還要交叉調(diào)用，RD們已經(jīng)罵娘了！
• 
  

這件事情的最終結(jié)果是，辛辛苦苦做了一個(gè)禮拜，Boss并不買單，要求砍砍砍改改改，結(jié)果砍了多少然而我并不想說……

3. 后臺做交互大坑

前面看到有一些后臺界面的截圖對吧，看上去還挺不錯的吧。壓根沒有交互設(shè)計(jì)師，我們產(chǎn)品狗們畫的可全都是最高水準(zhǔn)的UE圖，甚至交互功能都做完了。結(jié)果可想而知，以后后臺所有頁面都要按照這套交互做，UI和FD們更是被我們逼瘋。不過，也得承認(rèn)確實(shí)有好處：構(gòu)建了自己的一套前端交互框架，不少后臺產(chǎn)品可以直接照搬照抄這套交互邏輯。

坑很多，還是講講正面案例吧，比如說本人設(shè)計(jì)的一個(gè)在線VR全景快速生成后臺。

在做這個(gè)后臺前還是對全景拼合相當(dāng)了解的（不用得意，只有我了解，所以只能我來做……），全景在線展示基本上底層都是使用的老毛子Krpano，這個(gè)平臺的交互功能豐富，做快速后臺的話，需要做一定思考，什么功能參數(shù)是我們需要的，哪些是用戶高頻操作的。開始設(shè)計(jì)前，簡單畫了個(gè)圖幫助思考：?

• 業(yè)務(wù)流程基本就是簡單幾步：設(shè)置簡介-添加場景圖片-添加附加內(nèi)容-設(shè)置交互事件-提交。
• 附加內(nèi)容資源主要有：按鈕、圖片、視頻、音樂、文字。
• 主要的VR全景應(yīng)用需求有：

• 根據(jù)上面需求，構(gòu)建了場景將最常用的功能設(shè)置加入場景設(shè)置第一步驟中：?

• 根據(jù)場景編輯器的需要，先添加擴(kuò)展內(nèi)容資源，后在場景編輯器中添加已上傳資源并調(diào)試位置：

4. 跳坑總結(jié)陳詞

案例簡單講了幾個(gè)，時(shí)間關(guān)系沒法深入（全是借口），最后總結(jié)下后臺產(chǎn)品經(jīng)理的經(jīng)驗(yàn)教訓(xùn)吧。

• 后臺產(chǎn)品能不新做UI和UE就別做，盡量用些現(xiàn)成的前端框架，基于bootstrap的后臺前端架構(gòu)有不少，商用的有不少，開源的也有很多好用的，這種東西一搜一大堆，隨手給一個(gè)鏈接。
• toB類后臺產(chǎn)品實(shí)際上也非常需要良好的用戶體驗(yàn)，這類后臺產(chǎn)品可以加入細(xì)膩的交互設(shè)計(jì)，但也要注意把握度，產(chǎn)品工作的重點(diǎn)仍然是需要聚焦在業(yè)務(wù)梳理和邏輯。
• 在上次的文章中也提到了，toB產(chǎn)品更需要良好的業(yè)務(wù)流程設(shè)計(jì)，盡可能涵蓋用戶（每種參與者都要）流程、業(yè)務(wù)流程、系統(tǒng)流程這幾項(xiàng)關(guān)鍵流程。
• 后臺業(yè)務(wù)流程負(fù)責(zé)，不妨在流程圖中為不同角色或模塊設(shè)置不同的“泳道”以方便RD理解（也是為了方便自己理解）。
• 功能架構(gòu)復(fù)雜的后臺產(chǎn)品定時(shí)梳理功能架構(gòu)十分有用。搭建SVN，利用Axure的多人協(xié)作功能提升效率。
• 后臺功能的調(diào)整上線重要度并不亞于toC類產(chǎn)品的功能上線，務(wù)必盡量做到多方測試，特別是主要使用角色的測試盡量全覆蓋。有些改動你只是和其他調(diào)整修改時(shí)順手修改的，但實(shí)際上會嚴(yán)重影響某類用戶角色的使用習(xí)慣，盡量先灰度測試再做上線計(jì)劃。