後臺產品知識點總結

努力向上終會有收穫

　　1、寫在前面

　　本人入行產品從後臺產品開始，已經有一年時間。在此作出這一年的作後臺產品的總結，其實有些部分不管作什麼產品都是相通的，重要的是方法。經過總結一是梳理一些知識，二是跟你們分享討論心得。總結將會涉及到後臺產品前期的設計-後臺產品迭代-後臺產品運營-後臺產品特徵這幾部分。

　　2、後臺產品設計

　　

　　前期後臺產品關注點

　　1.產品定位與目標用戶

　　當從零開始，進行咱們的產品設計以前，切忌動手畫原型，一步一步梳理。

　　首先，弄清楚作這款產的最終目的是什麼，是爲了提升內部人員的工做效率，從線下切到線上；是爲了對公司的前臺系統作出強有力的支撐等等。另外須要弄清楚系統的邊界，哪些業務的實現是咱們系統該完成的，而哪些是不該該參雜到系統中的。

　　那咱們這個系統是給哪一個部門哪些人用的呢？這些人根據職能能夠分類爲哪幾個角色呢？例如呼叫中心繫統爲公司的客服部門服務，用戶就包括負責接電話的客服，專門外呼的客服，還有負責資源來源的運營人員，固然還包括客服的組長，須要作一些管理工做等。

　　理清楚後臺產品的定位和目標用戶以後，咱們開始規劃後臺產品的用戶權限體系。

　　2.用戶權限體系

　　對於後臺系統來講，很重要的一點就是用戶的權限管理部分。每一個角色各司其職，然後臺系統的數據通常涉及敏感信息，須要有嚴格的權限控制。

　　在用戶權限體系的設計中，須要明白的是用戶權限包括哪幾個部分。據我本身的理解，用戶權限的管理以下：

　　①權限細分爲兩部分：功能權限和數據權限。功能權限就是能夠看到哪些菜單功能；數據權限即我能夠看到哪些數據，能夠看到哪些人的數據等，數據權限通常根據系統業務的不一樣會有不一樣的劃分。

　　②角色管理：根據目標用戶的類型，對系統中的角色進行管理。角色的權限也包括有功能和數據權限。

　　③組織管理：不能的用戶在公司屬於不能的組織級別，例如一個小組長只負責他們小組的成員；可是一個總經理則是負責部門全部成員。因此有一個組織樹的管理，一是能夠清晰地看到系統中用戶的組織關係；二是根據組織樹，默認有一我的員權限的邏輯，即組長能夠看到下面組員的數據。

　　④用戶管理：給用戶賦予某一個或多個角色，歸屬於某個組織，固然用戶還能夠單獨設置本身的功能和數據權限。

　　3.業務流程與業務邏輯

　　作後臺系統，須要對涉及的業務十分熟悉與理解。這樣才能在一個大的業務目標前提下，理解用戶爲何會這樣作還不那樣作。整個業務的主流程是什麼，會有哪些分支流程。在這些流程中有狀態變化的流程用狀態圖呈現，還有業務流的動做變化用流程圖呈現，對於不一樣角色不一樣不一樣職能須要用跨職能流程圖實現。

　　梳理業務流程後，咱們才懂得其中的邏輯進而把他們搬進系統裏。

　　4.產品架構設計

　　根據梳理出來的產品流程邏輯，咱們能夠規劃系統的產品架構。

　　①應該有哪些菜單模塊構成

　　②每個菜單模塊下有哪些頁面，每一個頁面之間的交互關係是怎麼樣的

　　③每個頁面有什麼功能，這些功能服務於哪些角色

　　梳理產品架構時使用xmind/mindmanager這樣的思惟導圖工具時有利於理清思路。

　　注意點：對於產品架構的設計咱們還要考慮它的可擴展性，由於業務在不一樣那個時期會有變化，咱們怎麼才能作到更大程度適應這種變化，怎麼作到可以複用如今已有邏輯和功能，最大化減小開發的人力和時間成本。我認爲其中很重要的一點就是系統中各個功能以及對接其餘系統的交互邏輯不要強耦合，儘可能減小依賴。

　　5.原型輸出

　　對於原型的設計，咱們也遵循一個基本的步驟。

　　①系統頁面佈局：整個系統的頁面主要以什麼樣的佈局方式呈現，導航是頂部仍是側邊欄。不一樣的展示方式各有優劣，須要咱們根據自身系統來決定。

　　②頁面主色調：系統頁面主色調決定第一眼看上去的感覺。對於後臺系統來講，大多用一些深藍色等的冷色調。

　　③交互方式：交互控件如篩選/彈框等元素的打開方式，視覺效果的一致性。

　　④頁面內設計：後臺產品設計主要以簡約原則爲主，頁面內對於信息的顯示及按鈕/文本框等的設計，都要起到引導用戶的做用不能給用戶留疑惑，讓用戶以最少的成本去完成想作的事情。例如操做層級不能太深，給用戶少而夠的選擇，文本框給以適當的提示等。

　　注意點：對於功能點和交互設計時，一樣須要考慮到可能的性能問題，不要爲了某個功能而使系統性能降低，致使某些功能速度很慢。後臺產品產品界面設計能夠不要炫酷，可是要保證基本的功能/性能體驗好，這纔是基礎。

　　3、產品迭代

　　這裏總結一些產品迭代的原則，其實應該是適用於全部產品的。

　　①肯定大目標是前提。通常近幾個月/本季度/半年內本產品的目標。

　　②把握迭代節奏。產品迭代如今推崇快速迭代，基本是一週或一週半一迭代，發現不合理時能夠及時修正。

　　③肯定需求優先級。在需求池中根據是否緊急是否重要的原則，肯定出每一個需求的優先級，並預估每一個需求的工做量，根據迭代節奏將需求安排到每一個迭代中。

　　④每一個迭×××發中原則上不插入其餘需求。每次迭代的計劃都已肯定好的狀況下，除非有特別緊急且重要的需求插入，不打破現有工做進度，不然咱們的產品迭代計劃會被打亂而且不利於管理。

　　其實，對於後臺產品經理來講除了對業務需求系統化，還須要對本身的產品有一個規劃，即在特定的時間咱們的系統要實現怎麼樣。在大目標前提下，咱們能夠提出更好的業務流程及產品解決方案。

　　4、後臺產品運營

　　後臺系統也包含對於用戶的運營對於數據的運營。

　　1.用戶運營

　　後臺系統的用戶是公司內部的人員，我以爲這對於產品經理來講很是好。由於咱們能夠常常面對面地去跟用戶溝通，瞭解他們的想法。

　　①需求挖掘：跟用戶多溝通，能夠了解到表層下真實的用戶需求

　　②真正的用戶而非內心所想的用戶：有時作出一個滿懷自信的功能，用戶反而不用。爲何不用，功能沒用處？體驗差？這證實了用戶的心聲，可是咱們都有機會去了解用戶的真實想法，這樣咱們就能夠不斷進步。

　　2.數據運營

　　對於後臺系統輸出的數據通常涉及公司某個業務下的關鍵數據，這時數據沉澱積累與分析顯得特別重要。

　　①數據分析：經過每週對業務數據的相關分析，能夠看出一些漲幅跌幅，進而發現一些問題，提出對業務的一些改進。另外一方面能夠對一些重要的數據產品化，在系統中作成數據圖表的形式。

　　②數據沉澱：數據慢慢積累下來，造成一個龐大的庫，這對於之後的業務開展須要的數據分析及利用有很大的幫助。

　　5、後臺產品特徵

　　①業務導向

　　②重功能實現而非用戶界面設計

　　③用戶基數通常不大

　　④須要跟各業務部門溝通：跟其餘部門對接時要肯定對接邏輯/技術對接細節（甚至細到什麼字段）/統一時間點。當須要兩方合做時，不要貿然按照一方的想法作或者不通知對方直接上線，任何涉及兩方的信息都須要共享，以避免出現意想不到的影響，由於每一方都有本身內部的業務邏輯。

　　好了，寫到這裏就差很少總結完了，仍需繼續努力！

原文連接: http://mt.sohu.com/20160809/n463285525.shtml