上篇指路——>后臺產品經理入門指南（上），本篇繼續介紹后臺產品經理入門的剩余幾章內容。

5、后臺產品設計要點

6、分析復雜業務的幾個思考維度

7、后臺與中臺的關系

8、后臺產品的未來

05

后臺產品設計要點

后臺產品作為支撐系統往往涉及到具體的行業和業務特點，當我們直接拿具體業務來闡述后臺設計經驗時，往往會陷入其中無法進行通用性的提煉，也很難讓其他領域的產品經理讀者受益。

因此我從產品設計的角度而不是結合業務的角度來總結一些有共性的后臺設計要點，這套思路是適合所有后臺產品的。

1、對狀態的強化認知

對于一個后臺系統，狀態無處不在，靈活多變的業務需求是靠一張張數據庫的表在記錄的，除了業務數據的記錄，狀態是非常重要的基礎。訂單必須有狀態，用于區分不同業務環節；一個上線的活動必須要有狀態，是進行中、已暫停、還是已下線；一個員工賬號也要有狀態，是啟用中、禁用中還是已注銷。

設計一個功能或系統通常需要先繪制流程圖，而流程圖中一個個狀態的連接支撐起了整個功能設計的骨架，然后才是具體細節的設計。如何正確的強化對狀態的認知和理解，我大概總結以下幾點：

a）狀態的獨立互斥

這點與上面說的唯一判斷字段有點類似，但實際不是一回事。因為狀態是用于描述不同業務節點的，每個狀態要與實際業務的關鍵節點進行一一對應，狀態之間不能出現二義性，否則會出現多個狀態對應同一個業務關鍵節點，不但會造成理解混淆，還可能使系統做具體判斷時出問題。

b）狀態在時間維度上是穩定的

這點其實也很好理解，一個具體業務的發展是有階段性的，而狀態就是在每個階段取一個值，各個值連接起來就串聯的業務，但如果狀態的值取在各個階段的臨界點，這就很不好描述業務了。比如一個運營活動，可以用“進行中”和“已下線”兩個狀態來區分發生和不發生兩個階段，這是合理的，但如果狀態叫做“下線中”，這就不是處在一個穩定的狀態，而像一個瞬時態，到底是上線還是下線，我們從狀態命名中就感覺很模糊。

c）注意子狀態和組合狀態

當業務相當復雜時，一個狀態下面還可以設置子狀態，比如單據的撤銷狀態，可以包括用戶主動撤銷、系統撤銷、人工撤銷，用于區分具體是怎么被撤銷的。

而組合狀態的意思是在用戶側展示的狀態不單是訂單表里存的狀態名稱，而是一個組合狀態，比如在用戶側顯示“已發貨”，其實包含了訂單狀態為“創建成功”、支付狀態為“已付款”、物流狀態為“已出庫”。像比較復雜的保險訂單狀態，還會包含訂單狀態、支付狀態、續保狀態等，因此不能用一維的線性的思維來看待狀態。

d）狀態機的流轉路線

狀態機圖的確定，基本確定了系統和功能主體結構，各狀態之間的起點終點、流轉路線、判斷條件決定了功能的玩法和限制，狀態機圖是梳理并對照實際業務的必備工具。當業務有功能拓展時，首先查看狀態機圖是否滿足，如何調整才能滿足，已經涉及到哪些相關調整，都需要用到這個圖。

e）合理的狀態有利于數據統計

當狀態的設計都按照上述原則進行，狀態與狀態之間非常清晰，這對數據統計是非常有益的，因為很多的數據統計都強依賴對狀態的定義，如果你在做數據統計的時候發現很難準確的提需求，或者發現無法按照業務需要的維度來進行統計，可以反思下系統的狀態是否合理。

2、模塊化抽象

對變量的抽象是一種模塊化思維，能夠減少很多重復的工作量，提高后期的開發效率，我將分成兩種情況來描述。

一種是當多個頁面都用到同一個內容時，該內容應該被抽象為公共變量，供各頁面調用。比如一個常用聯系人組件包含姓名、證件類型、證件號碼、性別、出生日期這五要素，那么可以把這五要素設置成一個公共變量模塊，在不同產品下單需要用到時直接調用即可。如果有的產品下單時只需要用到姓名、證件類型、證件號碼三要素，則可以把五要素的變量模塊拆細為五個變量元素，這樣可以達到最大自由度的組合。

另一種情況是兩個頁面絕大部分內容相同，只有幾個元素有差異時，這幾個有差異的元素應該抽象為配置變量，做成一個配置文件或者管理后臺，這樣在調整該配置時就不用再寫代碼。有的同學可能對配置文件不太懂，它可以理解為一段未被編譯器編譯的配置代碼，是對一個軟件運行時狀態的本地儲存形式，可以實現對軟件靈活的實時調整。

比如同樣一個商品的詳情頁需要在A平臺是紅色背景，有評論模塊，在B平臺是綠色背景，不要評論模塊。如果事先將背景色、有無評論模塊這兩個變量做成配置項，只需要更改配置文件或在管理后臺做相應勾選即可。

3、合理的配置化程度

有了模塊化思維后，在做一些有配置的后臺功能時，還有一個非常重要的點是掌握配置的尺度，針對不同產品設定合理的配置功能。

配置化功能有時候會提高系統的靈活度，有時候反而會限制系統的靈活性，這就要看配置化的程度是否與具體業務的需求相結合，對于業務上沒有嚴格定義的內容最好不要做成固定的配置值，而是做成開放的配置項，可以隨時更改和擴充。

比如我負責的一個推薦產品的功能，根據用戶的個性化信息推薦不同的產品，且不同產品展示的樣式和內容不一樣，考慮到推薦結果頁產品介紹圖、特性、推薦語可能會變動，我把這些可能變動的項都做成了管理后臺的開放字段，可以讓運營隨時修改，而產品名稱、價格、在售狀態這些隨著平臺統一調整的項則從產品后臺去拉取，保證了與平臺其他位置展示的一致性。

合理的配置化程度其實就是把該配置的都做成可配置，幾乎不會修改的做成固定邏輯，這樣既能支持業務，又能減少不必要的配置化開發工作量。

4、系統的拓展性

我之前經常遇到一種情況，當我做一個功能上線之后，業務方有時會再提一個與這個非常類似的需求，有時候僅僅只是改動很少的內容。如果在第一次設計時并沒有預留可能的拓展性，就算只是很少的改動，還是要排期開發和測試，特別是有的功能還需回歸測試，非常浪費開發資源，而且影響迭代速度。這時就考驗在設計之初能否大概看出可能有的拓展性，在開發工作量幾乎不變的情況下預留一些類似的邏輯，這樣會非常便于類似功能的迭代。

舉個例子，對于一個人工審核的結論頁，有多種狀態，每種狀態下結論頁的不同模塊的元素、文案、以及對用戶的觸達文案，都是首次開發時配置好的。首次開發時業務方提出有三種狀態，上線之后業務方說要再加一種特殊的狀態，如果事先在狀態機中預留了待定的狀態，只需要把該待定狀態下頁面的元素、文案、對用戶的觸達進行設置即可，改動的工作量很小，可以快速的上線。

不過值得注意的一點是，在預留拓展性時盡量保證首次開發的工作量影響很小，如果為了暫時使用不到的預留需求消耗過多開發資源，就有點本末倒置了。最好的針對復制一份代碼、預留一個狀態這種相似功能進行考慮。

5、異常處理機制

穩定性是一個后臺系統非常重要的職責，代碼上的異常報警有開發人員來跟進，但后臺功能上的異常處理機制是需要產品經理在設計時就考慮的。

比如產品上架時需要灰度驗證，那么需要一個白名單功能，如果細分到具體功能的上架，那這個白名單功能還要細化到具體功能入口。

還比如某個功能接口掛了之后的兜底邏輯，如果是一個定時取數的接口，是否可以在接口掛了無法更新數據時仍然展示上次拉到的數據，并給前端一個字段反饋，讓前端可以展示一個文案提示用戶。

異常處理機制就像一個個應急的創可貼，在系統出問題時能夠第一時間應急處理，讓系統不至于大出血而影響使用，是非常必要的臨時解決問題機制。

06

分析復雜業務的5個思考維度

很多時候我們在面對一個復雜的業務需求時，容易被業務的表象所迷惑，看起來非常復雜，這不只是后臺產品，所有產品需求都會遇到。但如果有良好的結構化思維和本質思維，就可以剝開業務外表，把問題歸納為數學和物理上的關系，再復雜的業務往往也可以快速的理清頭緒。?

當然，理解業務是前提，理解業務后可以再從以下幾個維度來思考其中的邏輯關系：

1、對應關系

任何業務需求一定會涉及到幾個業務主體，它們之間要么毫不相干，要么就存在一定聯系，當有聯系時就涉及到它們的對應關系，理清這層關系后才能進行具體的方案設計。

在數學上，兩個數據的基本對應關系只有三種，一對一，一對多，多對多。看似很常見的對應關系，卻在后臺產品的設計中無處不在。

舉個最簡單的例子，比如賬號的注冊，一個賬號注冊后生成一個uid，用戶可以綁定手機號、微信號，也可以輸入身份證號進行實名認證，手機號和微信號還支持更換，這時uid與手機號就是一對多的關系，uid與身份證號是一對一關系。

搞清數據之間的對應關系非常有必要，它直接關系到開發人員對數據庫表字段的設計，以及后續要進行的相關數據傳輸和統計查詢。其實對應關系也是UML圖里類圖部分的內容，是理清業務邏輯過程中必備的。

2、主從關系

主體之間的關聯關系除了對應關系，還會存在主從關系。比如在靜態條件時，兩個主體之間的包含和被包含關系，以哪個主體為準，哪個主體次之；在動態變化時，哪個主體的變化會影響其他主體，哪個主體是被動受到制約。我將這類關系統稱為主從關系。比如下圖：

B主體全部被包含于A中，C主體部分包含于A中，當B發生變化時，A一定受影響，而C變化時則不一定。

對多個主體主從關系的正確判斷，可以幫助我們更客觀的認識事物，判斷需求的優先級，做出更好的選擇。

比如在產品經理日常工作經常會遇到一個情況，就是反復實現幾個類似的需求，明明好像上次做過類似的，這次只是改動了一點點又要重新做。這種情況常常是由于沒有抓住需求的根源，只是在從屬系統（模塊）中解決問題，沒有在這個需求對應的源頭主系統中解決，也或者說是需求實現的方案不是一個根源上的主方案，而是一個淺層的從屬方案。

3、關聯程度

當多個主體之間都有互相影響的關聯關系時，我們需要把這個關聯的程度進行量化和大小對比。比如A和B兩個主體之間影響的因子很少，那便是弱關聯程度，A和C之間有多個變量相互作用，那相對來說 屬于強關聯關系。在分析業務時，我們可以把所有的相關主體通過粗細不同的線條來描述它們之間的關聯程度大小。

理解不用主體之間的關聯程度可以幫助我們做出更好的選擇。

比如在實際處理業務需求時，同樣一個需求一般有多種實現方案，如果每個方案看做一個主體，現有的相關系統模塊也看做一個個主體，在進行選擇時需要基于該需求與當前系統哪個模塊關聯程度最高，根據高內聚低耦合的設計原則，應該把需求放在相關性最高的模塊中實現。

4、時間維度

在物理世界中，我們常用三維空間和時間用來描述事物，即時間和空間上都有順序。而互聯網的世界主要就是數據按照一定規則進行的交換與傳遞，不受三維空間的限制，因此可以認為只有時間維度的順序。

對應到產品設計的細節來看，不管什么復雜的業務，其中的具體事件一定有時間發生順序，它們發生的先后之間是否有對應不同的限制條件，是否為了實現的方便可以不按照業務事件的發生順序？在哪個時間點進行哪個事件更為合理？這些細節最終都會落到具體的對應到代碼的處理，也會一定程度影響到整個系統的實現方案和效果。

比如在互聯網保險投保的流程中，系統需要對用戶大量的信息進行校驗，來判斷用戶是否符合投保要求，即通常說的核保。用戶的一些直接輸入的信息通過前端實時校驗進行攔截，復雜的信息通過整個頁面提交后接口來進行校驗，該用戶更深層的一些諸如征信風險、信用風險等信息再通過風控接口進行攔截。這就把數據校驗這個功能從數據的傳輸時間維度上拆解成了三步。

這其實也就是研發的時序圖思路，只不過產品經理在業務梳理階段就要理清關鍵業務的時序。

5、因果關系

凡事有因必有果，不是不報，是時候未到。因果關系看起來非常簡單，但現實中我們卻常常陷入兩個誤區。

1? 把事件的結果歸納為單一原因造成的

2 ?把一個事件的結果當原因

這兩個誤區會使我們無法找到問題的根本原因，也就無法從根本上解決問題。

舉個例子，在上周A產品的銷量提升了，產品詳情頁的頁面轉化率提高了，而上周產品經理剛好給頁面加了指示引導功能，如果我們就認為產品經理上周做的功能是銷量上升的原因，那就陷入了第一個誤區，因為可能還存在其他很多的變量，比如可能是產品上周減價了。

如果認為產品詳情頁轉化率提高是銷量上升的原因，那就陷入了第二個誤區，因為頁面轉化率提高也是一個產品賣得更好的表現結果，而不是原因。也許我們全面盤查銷量提升的變量后會發現，根本原因其實是該產品可以使用剛發的優惠券進行大額折扣。

要避免陷入誤區一，需要更全面地看待影響事件的變量，不能停留在線性的因果視角；

要避免陷入誤區二，需要區分什么是結果什么是原因，一般只有變量事件才可能是原因，而數據、效果方面呈現的內容都是結果。

以上5個思考維度，前三個是靜態分析視角，后兩個是動態分析視角，并不是什么新的高大上的理論，但卻是我總結出來并真正在實踐中受益的。

后臺產品的建設本身就更偏向嚴謹的工程思維，抽去業務的外衣，從產品層面進行高度歸納的東西才能讓我們舉一反三。

07

后臺與中臺的關系

后臺是一個廣泛的范圍，是一個與前臺對應的概念，對于大多數公司，后臺其實就是所有的業務支撐系統，比較小的公司是沒有產品經理專門來負責后臺產品。

但隨著大公司大平臺的出現，并行的業務線發展得越來越大，每條業務線都要一個后臺，各個后臺之間又相對獨立，形成了煙囪式的技術架構，這樣很難以實現多業務數據的整合和共享，也很難快速對類似的新業務進行支撐響應，于是才誕生了中臺。

國內最早實踐的應該是阿里巴巴，簡單點說，中臺是后臺的精細化設計衍生出的概念，是為了更高效率的提升對前端業務支撐的系統，偏重與對技術、數據、業務的共性抽象和復用。

因此，我認為后臺與中臺是相輔相成的，在不同公司背景下的重合情況并不相同，我們不用刻意為了概念上的區分而分離后臺與中臺的具體內容，特別是在行業內真正在做需求的產品經理，要做好中臺需要先做好后臺的事情，掌握后臺設計的原理、方法，在公司發展壯大后需要進行中臺建設時才能把后臺相關能力抽象成為中臺。

08

后臺產品的未來

互聯網蓬勃發展的初期，產品經理是供不應求的，非常多來自各個專業的畢業生只要多體驗APP、寫點競品分析報告、畫畫交互，就能進入行業獲得一份不錯的工作。

然而時間已經來到2020年，做純互聯網的產品早就不再是主流，互聯網已經與各行各業相結合并產生了不同的化學反應，再加上經濟下行的背景，企業對效率提升的重視，資本也不再盲目砸錢投新項目，產品經理的招聘越來越細分了，各個領域公司需要的是既懂業務又懂互聯網的產品經理，而這些與各領域業務有著高度結合的需求正是后臺、B端產品的主要工作，這些都需要很多軟件設計底層的基本功。

一個不懂UML、不懂數據庫、不懂算法、不懂軟件開發流程，只會分析用戶、交互設計、線上活動策劃的C端產品經理的競爭壁壘會越來越低，也很難在有行業深度的領域擔當大任。

作為業內人士，特別是從事后臺產品經理的人來說，一定能看到企業內部非常多環節都是不合理不夠高效的，公司對外的PR稿寫的都是高大上的人工智能，真正到做需求時我們這幫人會發現更多的是人工智障。

現在還是互聯網與各行業的融合期，各領域的公司也有非常大的改善空間，未來的企業內部組織效率提升一定會發揮更大的價值，這也是后臺產品經理價值的所在。

后臺產品經理，任重道遠，但未來可期。

↘好文推薦：

后臺產品經理入門指南（上）

產品經理要懂的「技術那些事」

美團王慧文，王興14年的帶刀護衛

點個“在看”吧

總結

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

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