上一篇：產(chǎn)品經(jīng)理如何基于需求迭代產(chǎn)品（下篇2）：產(chǎn)品的整體設(shè)計之業(yè)務層和系統(tǒng)層

整體設(shè)計

邏輯層：實體建模、角色結(jié)構(gòu)、邏輯流程

邏輯層顧名思義，就是邏輯上的東西，是系統(tǒng)和業(yè)務的內(nèi)在邏輯。邏輯明確才能開發(fā)出來，邏輯不明確只是空中樓閣。邏輯層分實體建模、角色結(jié)構(gòu)和邏輯流程，實體建模是說明系統(tǒng)里有哪些主要內(nèi)容流轉(zhuǎn)，角色結(jié)構(gòu)是說明系統(tǒng)有哪些人使用，邏輯流程是說明系統(tǒng)是怎么運作的。下面進行具體描述。

實體建模

實體，一般是指能夠獨立存在，作為屬性定位基礎(chǔ)的東西。業(yè)內(nèi)的實體概念具有此哲學思想以外，還是一個特定的軟件模塊。例如電商中的sku、品類、訂單等均可稱為實體，只是有些實體重要有些不重要。

實體建模，就是從業(yè)務流程抽象出實體，部分流程以實體為中心，便于理解和管理。例如抽象出訂單實體，就可以根據(jù)流程管理訂單的生命周期（狀態(tài)）。

實體建模注意兩點：實體的屬性與生命周期和實體間的關(guān)系。

1.實體的屬性與生命周期

一開始，選擇哪些是主要實體的時候，重點要看業(yè)務流程中流動的是什么東西，有時候表面上看不出來，就需要思考共同點和本質(zhì)。舉個例子，在業(yè)務流程上，管理員會在一段時間內(nèi)安排給用戶一系列工作，工作是批量安排的，并沒有明顯的實體，通過思考后抽象出【任務】的實體，【任務】又分【母任務】和【子任務】，前者指管理員設(shè)置的任務，后者指用戶自己的任務。

每個實體都會自己的屬性，訂單會有訂單號、狀態(tài)、賣家ID、買家ID等等，屬性是用來做判斷或者與其他實體關(guān)聯(lián)的，訂單的狀態(tài)就是做判斷，賣家ID和買家ID則是與其他實體關(guān)聯(lián)，把主要的想到即可，具體。生命周期其實也是一種屬性，單獨拿出來為了凸顯它的重要性，要包含實體的所有生命周期，否則會出現(xiàn)異常。

2.實體間的關(guān)系

某種實體關(guān)系（矩形=實體，菱形=關(guān)系，橢圓=實體的主要屬性）

實體間的關(guān)系是指實體的邏輯關(guān)系，包括實體和實體的關(guān)系以及實體屬性和實體的關(guān)系。實體和實體之間是一對多、多對多、多對一還是一對一，例如一個帳號可以有多個訂單，一個訂單有多個SKU。實體屬性和實體的關(guān)系，例如上面例子的【母任務】創(chuàng)建后才會產(chǎn)生【子任務】，而【子任務】又有完成、歸檔的概念，因此【母任務】創(chuàng)建后某些屬性的修改就要注意。一般來說，實體和實體都是互相獨立的，【子任務】這種算是特殊情況。

角色結(jié)構(gòu)

每個系統(tǒng)必定有角色，只是角色多少的區(qū)別。此處的角色，是系統(tǒng)邏輯層面的角色，而不是功能模塊層面的角色。例如電商后臺的用戶都是公司內(nèi)部人員，分各部門，在系統(tǒng)邏輯層面角色就是內(nèi)部人員，在功能模塊層面各部門就是不同角色，通過賬號-角色-權(quán)限來控制。

系統(tǒng)邏輯層面的角色劃分是非常清晰的，角色所對應的場景是完全不同的，按需為角色設(shè)計賬號體系、選擇合適端（PC客戶端、APP、PCweb端、mobileweb端等）、設(shè)計風格等一切和產(chǎn)品相關(guān)的東西。角色由業(yè)務場景所決定，針對角色（目標用戶的另一層意思）設(shè)計產(chǎn)品要基于場景和核心訴求。例如boss直聘中在一個APP端中包含boss和牛人兩種角色，入口是一致的可切換，賬號體系打通，boss的核心訴求就是招到合適價位的牛人，牛人的核心訴求就是找到心儀的崗位；滴滴分乘客端和司機端，入口不一致，賬號體系部分打通，乘客的核心訴求就是打到心儀的車，司機的核心訴求就是跑滴滴賺錢。

把握角色的核心訴求，作為指導思想和綱領(lǐng)，指導需求規(guī)劃和產(chǎn)品設(shè)計，這也是內(nèi)聚性的體現(xiàn)。無論角色、模塊、功能、系統(tǒng)、實體等等都能用一句宗旨總結(jié)是干嘛的，那這句宗旨就是指導思想、綱領(lǐng)和邊界，做之前都先想想符不符合宗旨，有宗旨才有高內(nèi)聚。宗旨是可以調(diào)整的，但是不能隨便調(diào)整，要想清楚想明確。

角色與流程密切相關(guān)。角色就是操作的人，是流程中非系統(tǒng)自動以外所有操作的執(zhí)行者，確定了角色才能確定流程，確定了流程才能確定角色所需功能，這樣才有交互層的東西，角色的重要性毋庸置疑。

邏輯流程

邏輯流程就是要把實體、角色和功能（操作/判斷/子流程）之間的關(guān)系想清楚想通透。每個模塊包含哪些功能都會在梳理邏輯的過程中找到答案，也可以順便理清楚模塊和功能的優(yōu)先級，后續(xù)可補充到產(chǎn)品規(guī)劃中。

邏輯流程以不同的目標為中心會呈現(xiàn)出不一樣的流程，以業(yè)務為中心的流程重點講述的是業(yè)務的過程，以實體為中心的流程重點講述的是實體的生命周期（狀態(tài)），以操作為中心流程重點講述的是交互和判斷（也可以到交互層再畫）。

廣告規(guī)劃流程（業(yè)務流程）

極其簡單的訂單狀態(tài)流程圖

兌吧積分商城交互流程圖（更注重開發(fā)層面）

以業(yè)務為中心的流程就是要把上述的實體、角色和功能（操作/判斷/子流程）集合到一張圖上。要體現(xiàn)出以下兩點：1.每個角色在業(yè)務中的作用，其實就是每個角色的主要功能或者操作 2.核心功能，與業(yè)務直接相關(guān)的功能或者操作，例如點擊【去支付】訂單生成等，如果非核心功能流程太多可以直接用子流程代替。

以實體為中心的流程要體現(xiàn)出實體的生命周期，設(shè)計實體的生命周期的時候要符合客觀事實，系統(tǒng)中很多地方的判斷都是要根據(jù)實體的生命周期的。要體現(xiàn)出以下點：1.包含實體的所有生命周期，絕對不能遺漏 2.什么操作/判斷會調(diào)整實體的生命周期，邏輯合理描述清晰。

主要的流程可以畫出來給開發(fā)看，其他可畫可不畫，但是腦子中一定要有邏輯，否則就不是個稱職的產(chǎn)品經(jīng)理。

交互層：模塊功能、頁面結(jié)構(gòu)、界面原型

交互層有很多文章講了，這塊太基礎(chǔ)了我就不多說，就只講最重要的兩點。

1.交互層必須要基于業(yè)務、系統(tǒng)和邏輯層進行設(shè)計，否則就只是空中樓閣，模塊功能中，具體哪個模塊是來源于系統(tǒng)層的模塊抽象，要有哪些功能是來源于邏輯層的邏輯流程。頁面結(jié)構(gòu)中，放在哪個端和邏輯層的角色結(jié)構(gòu)密切相關(guān)，具體怎么放和邏輯層的邏輯流程密切相關(guān)。

2.應該在業(yè)務層、系統(tǒng)層和邏輯層已經(jīng)通過需求方、研發(fā)團隊、運營團隊等相關(guān)人員的評審之后，才開始設(shè)計交互層。因此，在產(chǎn)品設(shè)計的四大層面中要多和團隊、用戶等相關(guān)人員交流，而不是閉門造車，車都造出來了發(fā)現(xiàn)有問題要推倒重來，那麻煩可就大了。

局部設(shè)計

局部設(shè)計是指在平常功能性非大版本或者非重構(gòu)的迭代，多以增減修改某個功能/模塊、體驗等不觸碰核心業(yè)務邏輯的迭代為主。下面說明下注意事項。PS：具體還是得看需求和實際情況，每個公司和產(chǎn)品都不一樣的。

1.明確修改的層級

明確改動處于業(yè)務層、系統(tǒng)層、邏輯層、交互層四層中的那一層，層級越高一般涉及到的東西就越多，越是要謹慎小心。

2.梳理改動相關(guān)的舊邏輯

根據(jù)層級往下羅列與改動相關(guān)的邏輯、功能、交互、組件等，先抽離出與改動相關(guān)的系統(tǒng)，再從系統(tǒng)中抽離出與改動相關(guān)的模塊，再從模塊中抽離出與改動相關(guān)的功能和交互，

必須和技術(shù)負責人、架構(gòu)師、后端工程師等成員進行溝通，清除技術(shù)層面的問題，并商量解決，有些問題是產(chǎn)品看不到但是技術(shù)看得到的。必須和測試等成員溝通，核對改動的影響內(nèi)容，對用例查漏補缺。必須和設(shè)計師溝通，核對改動的交互和視覺細節(jié)，明確目標用戶和使用場景。

3.梳理改動相關(guān)的新邏輯

根據(jù)梳理出來的舊邏輯和目標用戶的使用場景，根據(jù)新需求逐一填上新邏輯，和完形填空一樣。如果需要在別處新增，就需要從那個模塊的所有邏輯中入手，基于使用場景和用戶路徑等設(shè)計新的邏輯。數(shù)據(jù)、實體相關(guān)的要考慮舊數(shù)據(jù)如何處理，例如消息多了個已讀未讀狀態(tài)，舊數(shù)據(jù)是默認為已讀還是默認為未讀。

4.相關(guān)問題方案和改動在發(fā)版前告知其他部門

在改動的方案出來之前，要和需求方及相關(guān)人員多溝通；在改動的方案出來之后，要抄送給需求方及相關(guān)人員一份，保證信息同步，共同決策。

在發(fā)版前，把每個部門相關(guān)的文檔，例如需要給客服部門的QA要提前準備好，并發(fā)送給各個部門的對接人員，提前準備。

5.發(fā)版后跟進新改動的問題和數(shù)據(jù)反饋

版本發(fā)布后，告知各方并進入反饋階段。持續(xù)跟蹤新改動的相關(guān)問題和數(shù)據(jù)反饋，以便明確版本效果，如果發(fā)現(xiàn)邏輯和設(shè)計漏洞要迅速處理，大的漏洞不要出現(xiàn)，否則會造成很大損失。預先進行小規(guī)模的ABtest很有必要。

《產(chǎn)品經(jīng)理如何基于需求迭代產(chǎn)品》系列的四篇文章終于寫完了，本系列更注重的是產(chǎn)品架構(gòu)設(shè)計的內(nèi)容，希望大家能夠有所收獲。

在寫文章的時候，發(fā)現(xiàn)有很多內(nèi)容還可以寫，例如某垂直領(lǐng)域知識、某小模塊的細節(jié)設(shè)計、通用的方法論等，我也會持續(xù)輸出的，請大家持續(xù)關(guān)注，敬請期待。