如何做好一個后臺產品經理
2017-05-20
4606
從入產品坑開始，其實早期都是做前臺產品和Web產品為主，對前臺業(yè)務、用戶體驗、交互還是有一定熟悉了解。近些年來，被逼跳后臺、帶團隊，一個項目往往前后臺產品經理基本都帶上做。對于后臺產品開始也慢慢有了自己的模式和想法。
在之前的回答中，也提到像我們這種媒體型互聯(lián)網公司來說，產品還是非?？茨樀?。做后臺產品，不僅僅需要有業(yè)務流的分析梳理能力、項目管理能力，還必須要帶上點兒交互設計能力。多種角色集于一身，所負責的往往是一整條產品線，一名產品經理必須能有很強的獨擋一面能力。
好了，既然獨當一面，踩坑就是難免之事。結合幾個小案例，回憶回憶吧。
龐大后臺架構坑
也許是運氣太好，第一個后臺產品就是一個大坑。這是一套自主試驗型的后臺CMS產品，產品之初是一個很小的架構規(guī)劃，目標是小型資訊APP后臺使用。但是，很快產品的風向就變了，架構鋪大，功能和業(yè)務邏輯有的沒的都往里加。
就這么大概干了3、 4 個月，RD團隊和產品團隊已經處在崩潰的邊緣，這時候，我們團隊加入了，原來的產品團隊火速撤離，坑爹的經歷開始了。剛接到產品時我們做的第一件事情就是梳理功能架構：
1
看到了吧，這是一個小型APP的CMS可能需要的后臺架構嗎?顯然不是。
問題清單如下：
內容管理不夠突出，并且分布在各個功能模塊中。
會員管理是個毛?完全沒用。
維護菜單下一堆百科內容管理，我實在不想看下去，全都拿出去。
站點管理和欄目管理等核心管理功能不全，需要增加管理功能。
經過和Boss的一番論戰(zhàn)，將一些將來可能用到的模塊繼續(xù)保留，但調整結構，核心功能集中。最后的初步成果如下：
2
經過這次調整，成績可以總結為：
首先，我們對產品的功能架構進行了相當深入的了解。
其次，建立了站點管理模式，使得系統(tǒng)大規(guī)模站點集群管理成為可能。
再次，對缺失的核心管理功能進行了設計。
最后，對后臺的交互和體驗做了全新改版設計。
3
但實際上回頭來看，仍然留下后一堆后續(xù)的大坑，也總結一下：
被逼留下的功能模塊實際上不少到最后也沒有用上，功能該砍的時候還是要痛下狠手。
欄目配置頁的核心作用是絕對突出了，在這個面板里能干的事情實在是太多了，而其他關聯(lián)的功能模塊能對其配置調用的相對有限，造成一些管理不便。
編輯器有大坑，我們默默地沒有發(fā)現。這個功能模塊被前行牽扯了太多業(yè)務邏輯和功能，導致后續(xù)代碼維護的困難。
權限系統(tǒng)還有坑，這個后面講。
權限體系的設計坑
接上文的權限體系坑，原來的系統(tǒng)權限體系經過一段時間實際使用測試發(fā)現，具有以下問題：
權限的類別不清，View類權限和Function類權限高度綁定，導致用戶菜單難以根據角色權限調整。
Function類權限沒有根據角色進行調配，幾類用戶角色沒有很好實現權限隔離。
試運行階段，系統(tǒng)管理員由RD同學兼任。用戶權限配置在實際工作中，效率很低，需要提升交互效率，同時還要降低學習門檻以便RD撤退。
面對這些情況，具體怎么做的，我就貼點兒圖少碼字吧：
使用RBAC角色權限控制模型：
4
設計權限應用流程：
5
增加Data類權限，對應原來的欄目、稿件等內容類操作權限。
將原來View\Function兩類權限拆分，View類權限單獨在菜單權限模塊配置。
重新設計配置頁面交互，提升效率。
看下圖，原來的設置方法是一條下面有N條子菜單，控件方式既有單選也有多選。調整后改為左側權限樹方便批量選擇，右側詳細功能列表，單項功能可設：是、否、全不。
6
在權限分類的理念下，建立角色組概念，將內容運營、開發(fā)、系統(tǒng)管理等角色分離，讓角色組作為角色的權限模板進行快速全局管理。
7
上面的一套工作看上去還挺過癮，但我可以負責任的告訴你，坑爹的地方太多了：
角色組概念很美好，但和權限類別還是無法區(qū)分，搞到最后萬不得已，搞出了可視化權限等級。
8
用戶權限配置聽起來簡單清晰多了，用戶體驗細節(jié)超豐富，但實際上系統(tǒng)管理員看完之后依然想罵娘!
權限維度很多，導致多個權限配置頁面都可能要做相關快速配置入口。API多，還要交叉調用，RD們已經罵娘了!
9
這件事情的最終結果是，辛辛苦苦做了一個禮拜，Boss并不買單，要求砍砍砍改改改，結果砍了多少然而我并不想說……
后臺做交互的坑
前面看到有一些后臺界面的截圖對吧，看上去還挺不錯的吧。壓根沒有交互設計師，我們產品狗們畫的可全都是最高水準的UE圖，甚至交互功能都做完了。
結果可想而知，以后后臺所有頁面都要按照這套交互做，UI和FD們更是被我們逼瘋。不過，也得承認確實有好處：構建了自己的一套前端交互框架，不少后臺產品可以直接照搬照抄這套交互邏輯。
坑很多，還是講講正面案例吧，比如說本人設計的一個在線VR全景快速生成后臺。
在做這個后臺前還是對全景拼合相當了解的，全景在線展示基本上底層都是使用的老毛子Krpano，這個平臺的交互功能豐富，做快速后臺的話，需要做一定思考，什么功能參數是我們需要的，哪些是用戶高頻操作的。開始設計前，簡單畫了個圖幫助思考：
10
業(yè)務流程基本就是簡單幾步：設置簡介-添加場景圖片-添加附加內容-設置交互事件-提交。附加內容資源主要有：按鈕、圖片、視頻、音樂、文字。
主要的VR全景應用需求有：
11
根據上面需求，構建了場景將最常用的功能設置加入場景設置第一步驟中：
12
根據場景編輯器的需要，先添加擴展內容資源，后在場景編輯器中添加已上傳資源并調試位置：
13
跳坑之后總結的 6 點教訓
案例簡單講了幾個，最后總結下后臺產品經理的經驗教訓吧。
1、后臺產品能不新做UI和UE就別做，盡量用些現成的前端框架，基于bootstrap的后臺前端架構有不少，商用的有不少，開源的也有很多好用的，這種東西一搜一大堆。
2、To B 類后臺產品實際上也非常需要良好的用戶體驗，這類后臺產品可以加入細膩的交互設計，但也要注意把握度，產品工作的重點仍然是需要聚焦在業(yè)務梳理和邏輯。
3、To B 產品更需要良好的業(yè)務流程設計，盡可能涵蓋用戶(每種參與者都要)流程、業(yè)務流程、系統(tǒng)流程這幾項關鍵流程。
4、后臺業(yè)務流程負責，不妨在流程圖中為不同角色或模塊設置不同的“泳道”以方便RD理解(也是為了方便自己理解)。
5、功能架構復雜的后臺產品定時梳理功能架構十分有用。搭建SVN，利用Axure的多人協(xié)作功能提升效率。
6、后臺功能的調整上線重要度并不亞于To C 類產品的功能上線，務必盡量做到多方測試，特別是主要使用角色的測試盡量全覆蓋。有些改動你只是和其他調整修改時順手修改的，但實際上會嚴重影響某類用戶角色的使用習慣，盡量先灰度測試再做上線計劃。
在之前的回答中，也提到像我們這種媒體型互聯(lián)網公司來說，產品還是非?？茨樀?。做后臺產品，不僅僅需要有業(yè)務流的分析梳理能力、項目管理能力，還必須要帶上點兒交互設計能力。多種角色集于一身，所負責的往往是一整條產品線，一名產品經理必須能有很強的獨擋一面能力。
好了，既然獨當一面，踩坑就是難免之事。結合幾個小案例，回憶回憶吧。
龐大后臺架構坑
也許是運氣太好，第一個后臺產品就是一個大坑。這是一套自主試驗型的后臺CMS產品，產品之初是一個很小的架構規(guī)劃，目標是小型資訊APP后臺使用。但是，很快產品的風向就變了，架構鋪大，功能和業(yè)務邏輯有的沒的都往里加。
就這么大概干了3、 4 個月，RD團隊和產品團隊已經處在崩潰的邊緣，這時候，我們團隊加入了，原來的產品團隊火速撤離，坑爹的經歷開始了。剛接到產品時我們做的第一件事情就是梳理功能架構：
1
看到了吧，這是一個小型APP的CMS可能需要的后臺架構嗎?顯然不是。
問題清單如下：
內容管理不夠突出，并且分布在各個功能模塊中。
會員管理是個毛?完全沒用。
維護菜單下一堆百科內容管理，我實在不想看下去，全都拿出去。
站點管理和欄目管理等核心管理功能不全，需要增加管理功能。
經過和Boss的一番論戰(zhàn)，將一些將來可能用到的模塊繼續(xù)保留，但調整結構，核心功能集中。最后的初步成果如下：
2
經過這次調整，成績可以總結為：
首先，我們對產品的功能架構進行了相當深入的了解。
其次，建立了站點管理模式，使得系統(tǒng)大規(guī)模站點集群管理成為可能。
再次，對缺失的核心管理功能進行了設計。
最后，對后臺的交互和體驗做了全新改版設計。
3
但實際上回頭來看，仍然留下后一堆后續(xù)的大坑，也總結一下：
被逼留下的功能模塊實際上不少到最后也沒有用上，功能該砍的時候還是要痛下狠手。
欄目配置頁的核心作用是絕對突出了，在這個面板里能干的事情實在是太多了，而其他關聯(lián)的功能模塊能對其配置調用的相對有限，造成一些管理不便。
編輯器有大坑，我們默默地沒有發(fā)現。這個功能模塊被前行牽扯了太多業(yè)務邏輯和功能，導致后續(xù)代碼維護的困難。
權限系統(tǒng)還有坑，這個后面講。
權限體系的設計坑
接上文的權限體系坑，原來的系統(tǒng)權限體系經過一段時間實際使用測試發(fā)現，具有以下問題：
權限的類別不清，View類權限和Function類權限高度綁定，導致用戶菜單難以根據角色權限調整。
Function類權限沒有根據角色進行調配，幾類用戶角色沒有很好實現權限隔離。
試運行階段，系統(tǒng)管理員由RD同學兼任。用戶權限配置在實際工作中，效率很低，需要提升交互效率，同時還要降低學習門檻以便RD撤退。
面對這些情況，具體怎么做的，我就貼點兒圖少碼字吧：
使用RBAC角色權限控制模型：
4
設計權限應用流程：
5
增加Data類權限，對應原來的欄目、稿件等內容類操作權限。
將原來View\Function兩類權限拆分，View類權限單獨在菜單權限模塊配置。
重新設計配置頁面交互，提升效率。
看下圖，原來的設置方法是一條下面有N條子菜單，控件方式既有單選也有多選。調整后改為左側權限樹方便批量選擇，右側詳細功能列表，單項功能可設：是、否、全不。
6
在權限分類的理念下，建立角色組概念，將內容運營、開發(fā)、系統(tǒng)管理等角色分離，讓角色組作為角色的權限模板進行快速全局管理。
7
上面的一套工作看上去還挺過癮，但我可以負責任的告訴你，坑爹的地方太多了：
角色組概念很美好，但和權限類別還是無法區(qū)分，搞到最后萬不得已，搞出了可視化權限等級。
8
用戶權限配置聽起來簡單清晰多了，用戶體驗細節(jié)超豐富，但實際上系統(tǒng)管理員看完之后依然想罵娘!
權限維度很多，導致多個權限配置頁面都可能要做相關快速配置入口。API多，還要交叉調用，RD們已經罵娘了!
9
這件事情的最終結果是，辛辛苦苦做了一個禮拜，Boss并不買單，要求砍砍砍改改改，結果砍了多少然而我并不想說……
后臺做交互的坑
前面看到有一些后臺界面的截圖對吧，看上去還挺不錯的吧。壓根沒有交互設計師，我們產品狗們畫的可全都是最高水準的UE圖，甚至交互功能都做完了。
結果可想而知，以后后臺所有頁面都要按照這套交互做，UI和FD們更是被我們逼瘋。不過，也得承認確實有好處：構建了自己的一套前端交互框架，不少后臺產品可以直接照搬照抄這套交互邏輯。
坑很多，還是講講正面案例吧，比如說本人設計的一個在線VR全景快速生成后臺。
在做這個后臺前還是對全景拼合相當了解的，全景在線展示基本上底層都是使用的老毛子Krpano，這個平臺的交互功能豐富，做快速后臺的話，需要做一定思考，什么功能參數是我們需要的，哪些是用戶高頻操作的。開始設計前，簡單畫了個圖幫助思考：
10
業(yè)務流程基本就是簡單幾步：設置簡介-添加場景圖片-添加附加內容-設置交互事件-提交。附加內容資源主要有：按鈕、圖片、視頻、音樂、文字。
主要的VR全景應用需求有：
11
根據上面需求，構建了場景將最常用的功能設置加入場景設置第一步驟中：
12
根據場景編輯器的需要，先添加擴展內容資源，后在場景編輯器中添加已上傳資源并調試位置：
13
跳坑之后總結的 6 點教訓
案例簡單講了幾個，最后總結下后臺產品經理的經驗教訓吧。
1、后臺產品能不新做UI和UE就別做，盡量用些現成的前端框架，基于bootstrap的后臺前端架構有不少，商用的有不少，開源的也有很多好用的，這種東西一搜一大堆。
2、To B 類后臺產品實際上也非常需要良好的用戶體驗，這類后臺產品可以加入細膩的交互設計，但也要注意把握度，產品工作的重點仍然是需要聚焦在業(yè)務梳理和邏輯。
3、To B 產品更需要良好的業(yè)務流程設計，盡可能涵蓋用戶(每種參與者都要)流程、業(yè)務流程、系統(tǒng)流程這幾項關鍵流程。
4、后臺業(yè)務流程負責，不妨在流程圖中為不同角色或模塊設置不同的“泳道”以方便RD理解(也是為了方便自己理解)。
5、功能架構復雜的后臺產品定時梳理功能架構十分有用。搭建SVN，利用Axure的多人協(xié)作功能提升效率。
6、后臺功能的調整上線重要度并不亞于To C 類產品的功能上線，務必盡量做到多方測試，特別是主要使用角色的測試盡量全覆蓋。有些改動你只是和其他調整修改時順手修改的，但實際上會嚴重影響某類用戶角色的使用習慣，盡量先灰度測試再做上線計劃。
最新資訊
微信掃一掃
關注公眾號，了解更多資訊
