后臺產品設計系列:認識后臺(一)
在進行后臺產品設計時,我們應該怎么做才能讓我們產品設計更加流暢呢?本文作者結合點播內容管理后臺(CMS),總結了系列文章,給大家介紹一下后臺產品,該如何設計,這是系列文章的第一篇。
對于大多數的產品經理而言,后臺的產品設計總是讓人很頭大。不熟悉、沒頭緒、理不清邏輯等各種問題,讓我們在做后臺產品時舉步維艱,最后結果也是差強人意。
那么,我們需要怎么做來讓我們的后臺產品設計更加順暢呢?
筆者將結合所做的點播內容管理后臺(CMS),總結了系列文章,給大家介紹一下后臺產品,該如何設計。這是第一篇——認識后臺。
在開始設計前,我們最需要做的,是對后臺有一個全面的認識——后臺是什么?做什么?包括哪些層次?整體流程有哪些?涉及角色及分工又有哪些?產品經理在整個流程需要參與的環節和職責是哪些?
只有一個更清晰的認識,才能讓我們在做后臺設計時有更深的理解,面對其他業務的后臺,也能夠舉一反三,有章可循。
一、后臺是干什么的
要了解后臺,需要結合與后臺相關的幾個角色,形成整體認知。
一般我們所面對的,簡化后就是以下圖中所示:后臺—前端,或是后臺—中間件—前端,后一種情況在特殊場景中會遇到,例如:后臺部署在內網,而前端部署在外網的情況下。
先來看看每個元素是做什么的。
- 前端:負責與用戶交互。主要工作是數據獲取、頁面布局展示、數據展示、完成各類動畫動效、進行文字圖片加載與渲染、視頻播放和部分前端邏輯處理。需要特別說明的是,前端同學在甩鍋時最常說的一句話就是:“我前端只是做顯示的,這個問題找后臺啊?!边@個確實如此,但有的邏輯前端也是要處理的,如后臺數據返回不全、接口失效時,前端就需要做好應對措施,例如:增加容錯頁面。
- 中間件:負責信息的解析與轉發。中間件是非常寬泛的概念,形式上它可以是一臺物理設備,也可以是一個在中轉服務器上的程序或代碼,而它的用處也非常廣泛,不僅在前后端之間使用,在后臺與第三方系統對接、保護敏感系統等多個場景都會用到,但本質作用就是將信息轉化成它的上下游能看懂的信息。舉個栗子:A手機錄制了一段.mp4格式的視頻,C手機只能播放.avi格式,那么A手機錄制的視頻要想在C手機上播放,就需要中間件B將.mp4轉化成.avi的C才能播,所以中間件主要是幫忙轉一下數據形式,而數據內容其實還是那個;
- 后臺:負責與管理員交互并響應前端行為。主要工作是數據存儲、數據處理、邏輯處理、數據輸出。而這幾個工作,則是整個產品處理任務最重,最復雜的地方,那么我們一般遇到的流程沒走通,數據、邏輯問題,都與后臺有關。
在這三者之間,就是通過接口進行數據與用戶行為(行為也可以看做數據)傳輸的。認清每個角色,就能讓我們看清每個角色在整個產品中所起的作用,角色間的關系,進而幫助我們在做產品設計時,能進一步梳理清楚流程、功能涉及方,在遇到問題定位時也能更清晰。
清楚后臺的作用后,我們需要進一步認識后臺包括哪些。
二、后臺的三個層次
在做前端產品時,通常會根據用戶體驗五要素來對產品不同層次進行劃分,進而幫助我們系統的認識產品。類似的,后臺也可以將包含的內容,按照由淺到深分為表現層、業務層、數據層。
1. 表現層(UI)
作用:通俗講就是展現給管理員用戶的這套界面,即管理員用戶在使用一個后臺系統時他所看到的。用于顯示數據和接收用戶輸入的數據,為用戶提供一種交互式操作的界面。
說明:一般來講,內部使用的后臺不會專門安排UI進行設計,也不會協調前端資源進行表現層的開發,基本都是由后臺小哥們自己解決,但Java與JS是兩種語言。
所以現在我們經??吹降倪@幾種后臺UI,都是后臺使用的開源模板,如:easyUI、bootstrap、vue.js+es6、Extjs(收費)等。
對于產品經理而言,我們在出后臺原型時,最好能大致了解后臺所使用的UI模板支持哪些頁面樣式,以免出現開發樣式與原型差異過大,導致使用體驗問題。
對于使用較多的easyUI和bootstrap,我們需要簡單了解這兩種模板的優點,當從0-1設計后臺時,能簡單根據后臺復雜度判斷選用哪種:
2. 業務層(BLL)
- 作用:主要處理業務邏輯。針對具體的問題、操作、請求,根據已定義好的規則,進行處理,類似于電腦的CPU。很多時候,也將業務邏輯層稱為領域層;
- 說明:業務邏輯層在后臺體系架構中的位置很關鍵,它處于數據層與表示層中間,起到了數據交換中承上啟下及處理的作用。對于數據層而言,它是調用者,對于表示層而言,它卻是被調用者。整個后臺的業務規則、業務流程等與業務需求有關的均在這一層次體現,它也直接決定數據層和表現層的設計。作為產品經理,需要最優先明確的,也是最重要的,就是這一層面的內容。
3. 數據層(DL)
數據層包括數據訪問層和數據庫兩個部分:
- 數據訪問層:主要是對數據庫進行直接操作,包括數據的增添、刪除、修改、查找等;
- 數據庫:按照數據結構來組織、存儲和管理數據的倉庫。我們通常所說的數據字典就是這一層面的內容,而數據表的結構關系就是根據業務層的需求而定。
三者之間,層與層的依賴是向下的,上層調用下層,下層支撐上層。那么對于產品經理而言,我們為什么要將后臺區分得這么細致呢?
一方面是為了更加系統的認識后臺,而更重要的,是因為“高內聚,低耦合”的思想,通俗講就是——產品經理在設計后臺時需要保證后臺設計的靈活性和高可擴展性。
產品經理在進行產品迭代時,一般對前端的改動會更多,同時盡量減小對后臺的影響,因為后臺的變動往往會牽一發而動全身。那么這就要求后臺在設計之初,需要保證高擴展性和高度的靈活性,能盡可能的適配多種場景,不同的前端需求。
所以通過對后臺不同作用的內容進行分層,能從最基礎的后臺架構上,做到“低耦合”。
在架構設計時,如果遵循了“面向接口設計”的原則,保證“弱耦合”結構,那么改變上層的設計對于其調用的底層而言,影響較小甚至沒有任何影響。
認識完后臺,再來介紹一下后臺設計開發流程及產品經理在其中所扮演的角色。
三、后臺的設計開發流程——V模型
先來看看每個環節涉及人員及主要工作,這里部分與產品經理有關。
1. 需求收集
這是整個流程的起始環節,也是產品經理最核心的工作部分。在這個階段,產品經理需要從運營、市場、上級等各方收集關于后臺的需求,同時梳理清楚業務要求、業務流程、前后端流程,保證每個業務需求清晰和流程的通常,在這些基礎上,結合前端產品定義后臺所需滿足的功能。
這部分需求確認清楚后,需要進行需求評審,尤其是當業務流程梳理出來后,一定要與后臺開發人員、技術經理、開發組長、測試等人進行溝通,確定流程無誤后,才能進入開發階段。那么這一部分,主要體現在業務層和表現層的設計上。
2. 架構設計
需求確認后,架構師或技術經理需要根據需求進行后臺的架構設計。主要是架構的搭建、后臺各模塊功能的劃分、數據字典的設計、表之間的邏輯關系設計、模塊間接口定義和數據傳遞的實現等。
在這個階段,產品經理需要與架構師/技術經理溝通,保證后臺模塊劃分的合理性,雖然我們在原型上已經劃分好了不同模塊,但有時架構師們會從他們技術角度進行微調。
而產品經理需要從業務需求角度,保證這種調整不會有其他不利影響。當架構師完成這部分設計后,產品經理需要參與數據字典及表間關系的評審,以避免從一開始就跑偏的情況。
3. 軟件設計
這個階段,后臺開發人員根據架構師設計好的這些內容,對各模塊進行深入分析,對各模塊組合進行分析,并實現相應的接口、頁面、控件。
4. 軟件編碼
這部分,就是實際敲代碼的過程,后臺開發人員按照詳細設計好的功能,編寫出實際的代碼。
5. 單元自測
按照設定好的最小測試單元進行按單元自測,主要是測試程序代碼,為的是確保各單元模塊被正確的編譯,而這部分的測試一般是開發小哥自己搞定。
6. 系統測試
經過了單元測試后,將各單元組合成完整的體系,主要測試各模塊間組合后的功能實現情況,以及模塊接口連接的成功與否,數據傳遞的正確性等,其主要目的是檢查軟件單位之間的接口是否正確。
這一階段的測試主要是架構師/技術經理和測試人員共同完成,確保后臺開發人員是根據架構師的設計來實現的。
7. 驗收測試
這個是整個流程的最后一環,與前端產品類似,這個環節需要產品經理根據需求進行驗收,保證開發按照需求實現,測試人員根據測試用例,進行產品功能測試。
從這個“V模型”就可以看出:產品經理最主要的工作是需求階段,而與這個節點有聯系的,都是產品經理需要參與的工作。
認清后臺,不僅為我們在做后臺產品設計時提供很大幫助,還讓我們在做產品迭代時,能初步評估需求改動對前后端的影響,甚至有一個基本的工作量評估。同時在跟后臺開發人員溝通時,能減小不少障礙,理解他們的工作內容,做一個“懂”他們的產品經理。
相關閱讀
本文由 @Z. Fly 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
寫的很棒,你的那本書我也看了,數據建模那一塊在我剛接觸erp的時候對我幫助很大,感謝作者
我的書《不枯燥的B端產品實戰課》已經上市了,主要介紹了B端產品從0到1的過程,歡迎大家閱讀
請教一下,公司內部使用的后臺,一般是用瀏覽器打開的好,還是在桌面啟動好,這兩者有什么區別嗎?
絕大多數情況下是瀏覽器,桌面用應用程序打開的極少,或者包了一個c/s的殼
多年產品,做過移動端和后臺ERP 軟件,其實一直感覺設計的東西很多時候影響了后臺的架構和有效實現方法,請問如何解決這個問題?舉例來說,設計出來,后臺看了之后說,不是這樣的,這樣不對。我理解他的話有兩點,一是他覺得我設計太復雜,他實現麻煩,讓我改,還有一點是后臺數據處理上不夠合理。如果是后者就比較麻煩了,一直想能直接設計時考慮到數據處理,苦于沒有任何開發基礎,不知道如何解決,只能一次次和后臺碰,碰出個好的方案
先多跟開發溝通,理解技術原理,后面就一通百通了,其實技術本質是邏輯,不是代碼,理解邏輯就好了
請教各位,沒有后臺產品經理工作經驗,但想做一份工作,如何彌補工作經驗的缺失?(日常工作包含和PM的溝通)
多學習,這個沒有捷徑,也避免不了痛苦和迷茫的過程
你好,看了文章,非IT專業,文中說與后臺相關的角色,前端和中間件,后臺又分表現層、業務層、數據層,這個表現層在前端和中間件調取數據的時候是不參與過程的吧,換一種說話,前端展現過程是:數據層 – 業務層 – 中間件 – 前端。
是這樣的嗎,求教!
如果要這么分的話,可以這么理解。不過還有一條:表現層——數據層——業務層——中間件——前端。就是表現層是數據的輸入層,是起點
Get你獲得了一個忠實的粉絲及朋友!
后臺產品設計系列:產品設計方式(二)http://www.aharts.cn/pd/1202556.html
后臺產品設計系列:流程設計(三)http://www.aharts.cn/pd/1329615.html
后臺產品設計系列:原型設計五大要點(四)http://www.aharts.cn/pd/1547652.html
我最近在一個后臺系統,前端說我的業務流程想的是很仔細和全面,但是從后臺搭建的邏輯上是有很大的bug 的,增加了他們前端開發的復雜性和浪費時間,一直沒太想明白不同模塊,不同頁面調用一下數據怎么了,看了這篇文章我好像有些懂了,謝謝作者!
能具體分享一下嗎?
能分享一下?
耦合度太高了吧
期待二
系列第二篇新鮮出爐 ??
easyui真心丑,但是好用
不錯的,很適合小白,以及對后臺有誤解的同學看 ??
為什么適合不了解后臺的人看呢
表現層到業務層 業務層到數據訪問 都是通過接口嗎?這里接口是指兩個系統之間進行通信的那種接口么?那既然是同一個系統,為什么要用接口通信呢?
接口其實是一個很寬泛的概念,不光是同一系統的不同層次,一個后臺的不同模塊間,都可以理解為通過接口通信,我們通常所說的不同系統間的接口,是其中的一種而已。而這種方式的好處就是能最大程度上降低耦合度 ??
不同模塊間用接口通信 這個在技術實現上跟兩個系統之間的通信接口 是啥區別呢? ??
本質上沒有區別,都是起到數據傳遞作用的
我理解的接口是:沒有權限直接操作數據,需要通過接口這個通道來完成
直接操作數據的話會導致耦合程度比較深吧