產品經理如何基於需求迭代產品（下篇2）：產品的總體設計之業務層和系統層

上一篇：產品經理如何基於需求迭代產品（下篇1）：產品設計的高內聚低耦合

上篇所講的高聚合低耦合的宗旨，就是要用在產品設計上。此處所講的產品設計，不僅是界面設計，還包括產品架構、系統架構、功能模塊、實體結構、角色、邏輯等等。

本篇文章分爲總體設計和局部設計兩個部分。總體設計是指從零到一開發或者重構一款產品的所有流程，一共涉及業務層、系統層、邏輯層和交互層等四個層面。局部設計是指產品正常迭代或者設計產品某小塊下的流程和核心，局部設計的流程是總體設計流程的子集，因此主講局部設計的核心。

你們在看的時候，時刻要想着「高內聚低耦合塑造產品認知」的宗旨。

總體設計

產品的總體設計包括業務層、系統層、邏輯層和交互層等四個層面。基於需求提出業務方案，基於可行可落地的業務方案進行設計。

在實際過程當中，並不會嚴格按照順序一層層下來，由於方法是層級的，而靈感則是跳躍的。我通常是先從業務方案中抽象出實體、角色和邏輯，

總體設計

業務層：業務方案

業務層是指業務方案。業務方案就是業務層面的方案，要求業務方案是可行可落地的。新產品/新模塊的業務方案通常由產品經理、領導或者業務方提出，表明着在產品經理、領導或者業務方的思考中是如何解決這個問題的。

只有可行可落地的業務方案纔有意義，由於產品經理就是要把可行可落地的業務方案搬到線上，作成標準化的解決一類問題。若是業務方案的不可行，那麼後續的產品設計也就無從談起了。

若是業務方案已經落地且可行，例如在運營層面已經按照某規則人工實行了一段時間，效果不錯。產品經理就須要把這個方案搬到線上，要基於業務方案設計功能，作成標準化的功能解決一類的問題，還要結合總體和將來的發展。

若是沒有可行可落地的業務方案，產品經理不只須要和各方溝通出一個或者多個解決方案，還須要經過落地執行或者設計MVP等方法去測試方案的預計效果和可行性。有多個就對比選一個最好的，這裏的最好能夠是效果或者性價比等，具體請視狀況判斷。

當公司發展到必定階段，業務和系統一定有一個是縱向有一個是橫向，多個業務縱向鋪開後，須要橫向的系統打通，主要出於四方面考慮：專業深度、人力資源、用戶體驗、全局打通。例如滴滴出行在短期內造成了包括快車、出租車、專車、順風車、代駕等多業務的垂直化架構，滴滴啓動了中臺戰略整合業務系統，具體請見《從滴滴出行業務中臺實踐聊聊如何構建大中臺架構》。

系統層：系統定位、系統架構、模塊抽象、規劃藍圖

系統層是指系統層面的一些東西，包括系統定位、系統架構、模塊抽象、規劃藍圖。人們看到體驗到的產品都是露在外面的那一塊，實際上還有不少系統在海平面如下，或大或小的產品背後總後好幾套系統的存在。大的例以下圖的惟品會，整個分爲SAAS、PAAS和IAAS，每一個裏面有多個平臺多個系統，才能支撐起惟品會的發展。小小的一款APP裏的IM、推送等可能都是第三方提供的獨立的系統。

惟品會的總體架構

系統定位

系統定位就是指肯定系統要解決什麼需求，先要有拆分出系統的需求，而後纔有這個系統。系統定位必然是最早一步，並非全部東西都要單獨拉出個系統去作。觀察大型系統的演進過程能夠發現，絕大部分系統都是從初始的小功能到模塊最後再到系統的（功能＜模塊＜系統）。

系統化自己就是爲了解決資源共享低、利用率低、不能集中處理等問題，系統也能下降總體耦合性，此時應該和架構師進行探討，由於大部分都是技術層面的東西，要思考清楚哪些是系統哪些不是系統，所解決的需求是否重要是否急迫，而且對每一個系統提出定位做爲迭代方向，固然定位並非一成不變的。

系統架構

肯定了有哪些系統和對應的系統定位後，便可開始進行系統架構。系統架構強調的是系統和系統之間的聯繫，若是有多個系統還能夠像惟品會同樣平臺化，便於理解也便於組織架構劃分。

若是發現系統架構完成後，並無把全部系統or模塊包含進去，則要回到系統定位上從新梳理和思考，要把全部都包含進去。由於系統架構是解釋系統之間的關係，絕對不能硬塞進一個模塊。就像外出前收拾行李，把一堆東西塞進一個書包、一個旅行箱和一個編織袋，塞完了發現還剩一雙鞋，得想辦法塞到專門放鞋子得編織袋裏面，可是編織袋已經滿了也無法倒騰出空位，那就只能塞到旅行箱裏面。

裝滿東西的旅行箱（來自百度圖片）

系統和系統之間要協調配合，互相聯繫互相制約，就像運動系統、神經系統等八大系統令人體內各類複雜的生命活動可以正常進行。

模塊抽象

平臺、系統、模塊和功能之間的關係應該是：平臺包含系統，系統包含模塊，模塊包含功能。此處所講的均不能只看作是前臺的某個界面，均包含後臺所對應的邏輯等，是一個立體的結構而不是前臺的平面結構。平臺、系統、模塊和功能都是立體結構，只是粒度不一樣。而角色、實體和流程是平面結構，是不一樣角度下不一樣視野下的系統。

模塊抽象就是指把不一樣模塊都抽離出來，模塊和模塊之間互相獨立互相依存，相似系統定位，劃分了模塊以後才能肯定哪一個系統包含哪些模塊。

功能從場景和流程中抽象，模塊從功能和實體中抽象。像惟品會等電商系統，會分商品模塊、品類模塊、訂單模塊、購物車模塊、支付模塊等等。一個模塊包括前臺的展現頁面/組件+後臺邏輯。模塊的抽象是很天然的，由於自己系統的創建就有其內部的生態或者邏輯，就像人體的呼吸系統包含呼吸道（鼻腔、咽、喉、氣管、支氣管）和肺一系列器官以及內在邏輯。

規劃藍圖

優秀的產品都是迭代和規劃出來的，而不是一輩子下來就是。不少產品前期都是很簡單很基礎的幾個模塊，並且1.0版本用以快速試錯的，若是模塊不少體量很大就會浪費資源，要是失敗了就得不償失。

規劃藍圖並非計劃藍圖，規劃和計劃的區別在於，規劃是長遠的（6個月以上）、不詳細的、目標不精確的，計劃則是短時間的、詳細的、目標精確的。例如，2018上半年要開發新版本就是個規劃，而2018年6月前用戶要天然增加100%經過優惠券、滿減等手段則是計劃。

在系統架構和模塊抽象起來後，我會進行規劃藍圖的工做。規劃藍圖分兩塊，需求樹和產品路線圖，需求樹是把全部需求（系統、模塊、功能或者某些待解決的問題）放到樹形圖上，產品路線圖則是把需求樹上的需求通過篩減後按照產品階段放置。

需求樹示例

需求樹，是爲了梳理、分類需求，分析優先級和先後置條件。樹根是實現整個系統所必需要的基礎設施，樹幹是核心功能模塊，樹枝是能夠進入的領域或者方向，樹枝上也有功能模塊。一開始先把核心功能、基礎設施和方向領域肯定好，而後用便利貼往上貼功能模塊或者需求，最後按照越靠近主幹越優先的策略調整便利貼的位置。期間整個團隊都有一塊兒合做，各抒己見，一塊兒協商這些具體功能或者想法應該怎麼發展，一塊兒肯定優先級。

需求樹可隨時補充，並且要按期把需求樹上新增的需求刪減、調整以放到路線圖中。

產品路線圖示例

產品路線圖，是爲了明確產品何時該作什麼，是最多6個月到2年的產品路線，具體看公司規模、行業特色等。產品路線圖可根據實際狀況進行調整，但不是想要改就改的，產品路線圖很嚴肅，不嚴肅的毫無心義，要遵照他。

路線圖包括產品階段、里程碑、需求。

產品階段是指產品所處的階段，會有初始、成長、成熟和衰退四大階段，每一個大階段根據不一樣狀況會有小階段，視產品狀況自行肯定。處於不一樣階段的產品都有不一樣的產品戰略，要概括出來，爲需求的選擇和實施方向提供思想支持。

里程碑主要是用來劃分階段的，例如找到第一個用戶G點並造成可複製方案使得用戶大規模增加，從初始進入了成長期；在新增和流失用戶打平，作再多拉新活動ROI都會持續降低，從成長進入了成熟期等等。

基於產品階段、階段中的產品戰略和需求樹，把需求放到產品路線圖中，最終造成產品路線圖。離當前時間越近的要詳細些，遠的則大方向要清晰。

這些都是我本身的自我總結，也是我對世界的認知和總結，每一個人的認知或多或少有所不一樣，但願可以幫助你們更好地認識這個世界。

Vency，兩年經驗產品經理，追求用戶、技術、商業、社會價值的統一

搜索關注公衆號 Vency不二或者vencybu2，向你們分享我或系統或粗放的深度思考

下一篇《產品經理如何基於需求迭代產品（下篇3）：產品的總體設計之邏輯層和交互層》，敬請期待