PMCAFF（www.pmcaff.com）：互聯網產品社區，是百度，騰訊，阿里等產品經理的學習交流平臺。定期出品深度產品觀察，互聯產品研究首選。

外包大師（www.waibaodashi.com）：要外包，找大師。PMCAFF旗下高質量互聯網外包解決方案提供商。外包大師服務號：waibaodashi365

作者：crossfone 數據產品經理

從入產品坑開始，其實早期都是做前臺產品和Web產品為主，對前臺業務、用戶體驗、交互還是有一定熟悉了解。近些年來，被逼跳后臺、帶團隊，一個項目往往前后臺產品經理基本都帶上做。對于后臺產品開始也慢慢有了自己的模式和想法。

在之前的回答中，也提到像我們這種媒體型互聯網公司來說，產品還是非常看臉的。做后臺產品，不僅僅需要有業務流的分析梳理能力、項目管理能力，還必須要帶上點兒交互設計能力。多種角色集于一身，所負責的往往是一整條產品線，一名產品經理必須能有很強的獨擋一面能力。

好了，既然獨當一面，踩坑就是難免之事。結合幾個小案例，回憶回憶吧。

龐大后臺架構坑

也許是運氣太好，第一個后臺產品就是一個大坑。這是一套自主試驗型的后臺CMS產品，產品之初是一個很小的架構規劃，目標是小型資訊APP后臺使用。但是，很快產品的風向就變了，架構鋪大，功能和業務邏輯有的沒的都往里加。

就這么大概干了3、4個月，RD團隊和產品團隊已經處在崩潰的邊緣，這時候，我們團隊加入了，原來的產品團隊火速撤離，坑爹的經歷開始了。剛接到產品時我們做的第一件事情就是梳理功能架構：

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

問題清單如下：

• 內容管理不夠突出，并且分布在各個功能模塊中。

• 會員管理是個毛？完全沒用。

• 維護菜單下一堆百科內容管理，我實在不想看下去，全都拿出去。

• 站點管理和欄目管理等核心管理功能不全，需要增加管理功能。

經過和Boss的一番論戰，將一些將來可能用到的模塊繼續保留，但調整結構，核心功能集中。最后的初步成果如下：?

經過這次調整，成績可以總結為：

• 首先，我們對產品的功能架構進行了相當深入的了解。

• 其次，建立了站點管理模式，使得系統大規模站點集群管理成為可能。

• 再次，對缺失的核心管理功能進行了設計。

• 最后，對后臺的交互和體驗做了全新改版設計。?

但實際上回頭來看，仍然留下后一堆后續的大坑，也總結一下：

• 被逼留下的功能模塊實際上不少到最后也沒有用上，功能該砍的時候還是要痛下狠手。

• 欄目配置頁的核心作用是絕對突出了，在這個面板里能干的事情實在是太多了，而其他關聯的功能模塊能對其配置調用的相對有限，造成一些管理不便。

• 編輯器有大坑，我們默默地沒有發現。這個功能模塊被前行牽扯了太多業務邏輯和功能，導致后續代碼維護的困難。

• 權限系統還有坑，這個后面講。

權限體系的設計坑

接上文的權限體系坑，原來的系統權限體系經過一段時間實際使用測試發現，具有以下問題：

• 權限的類別不清，View類權限和Function類權限高度綁定，導致用戶菜單難以根據角色權限調整。

• Function類權限沒有根據角色進行調配，幾類用戶角色沒有很好實現權限隔離。

• 試運行階段，系統管理員由RD同學兼任。用戶權限配置在實際工作中，效率很低，需要提升交互效率，同時還要降低學習門檻以便RD撤退。

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

使用RBAC角色權限控制模型：

設計權限應用流程：

增加Data類權限，對應原來的欄目、稿件等內容類操作權限。

將原來View\Function兩類權限拆分，View類權限單獨在菜單權限模塊配置。

重新設計配置頁面交互，提升效率。

看下圖，原來的設置方法是一條下面有N條子菜單，控件方式既有單選也有多選。調整后改為左側權限樹方便批量選擇，右側詳細功能列表，單項功能可設：是、否、全不。?

在權限分類的理念下，建立角色組概念，將內容運營、開發、系統管理等角色分離，讓角色組作為角色的權限模板進行快速全局管理。

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

角色組概念很美好，但和權限類別還是無法區分，搞到最后萬不得已，搞出了可視化權限等級。

用戶權限配置聽起來簡單清晰多了，用戶體驗細節超豐富，但實際上系統管理員看完之后依然想罵娘！

權限維度很多，導致多個權限配置頁面都可能要做相關快速配置入口。API多，還要交叉調用，RD們已經罵娘了！

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

后臺做交互的坑

前面看到有一些后臺界面的截圖對吧，看上去還挺不錯的吧。壓根沒有交互設計師，我們產品狗們畫的可全都是最高水準的UE圖，甚至交互功能都做完了。

結果可想而知，以后后臺所有頁面都要按照這套交互做，UI和FD們更是被我們逼瘋。不過，也得承認確實有好處：構建了自己的一套前端交互框架，不少后臺產品可以直接照搬照抄這套交互邏輯。

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

在做這個后臺前還是對全景拼合相當了解的，全景在線展示基本上底層都是使用的老毛子Krpano，這個平臺的交互功能豐富，做快速后臺的話，需要做一定思考，什么功能參數是我們需要的，哪些是用戶高頻操作的。開始設計前，簡單畫了個圖幫助思考：?

業務流程基本就是簡單幾步：設置簡介-添加場景圖片-添加附加內容-設置交互事件-提交。附加內容資源主要有：按鈕、圖片、視頻、音樂、文字。

主要的VR全景應用需求有：

根據上面需求，構建了場景將最常用的功能設置加入場景設置第一步驟中：?

根據場景編輯器的需要，先添加擴展內容資源，后在場景編輯器中添加已上傳資源并調試位置：

跳坑之后總結的6點教訓

案例簡單講了幾個，最后總結下后臺產品經理的經驗教訓吧。

1、后臺產品能不新做UI和UE就別做，盡量用些現成的前端框架，基于bootstrap的后臺前端架構有不少，商用的有不少，開源的也有很多好用的，這種東西一搜一大堆。

2、To B 類后臺產品實際上也非常需要良好的用戶體驗，這類后臺產品可以加入細膩的交互設計，但也要注意把握度，產品工作的重點仍然是需要聚焦在業務梳理和邏輯。

3、To B 產品更需要良好的業務流程設計，盡可能涵蓋用戶（每種參與者都要）流程、業務流程、系統流程這幾項關鍵流程。

4、后臺業務流程負責，不妨在流程圖中為不同角色或模塊設置不同的“泳道”以方便RD理解（也是為了方便自己理解）。

5、功能架構復雜的后臺產品定時梳理功能架構十分有用。搭建SVN，利用Axure的多人協作功能提升效率。

6、后臺功能的調整上線重要度并不亞于To C 類產品的功能上線，務必盡量做到多方測試，特別是主要使用角色的測試盡量全覆蓋。有些改動你只是和其他調整修改時順手修改的，但實際上會嚴重影響某類用戶角色的使用習慣，盡量先灰度測試再做上線計劃。

本文由PMCAFF產品社區（www.pmcaff.com）原創發布，未經許可，禁止轉載。

點擊閱讀原文，獲取5000個成熟解決方案

中高端求職 & 招聘，PMCAFF人才服務最懂你

=> alice.zhang@pmcaff.com

總結

以上是生活随笔為你收集整理的后台产品经理跳坑“指南”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。