📖 ZKIZ Archives

後臺產品經理跳坑“指南”

PMCAFF 2017-05-18 13:15

來源 | PMCAFF

文 | 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 類產品的功能上線，務必盡量做到多方測試，特別是主要使用角色的測試盡量全覆蓋。有些改動你只是和其他調整修改時順手修改的，但實際上會嚴重影響某類用戶角色的使用習慣，盡量先灰度測試再做上線計劃。

文章評論

匿名用戶

發布

全部評論：10

發布