產品經理如何基于需求迭代產品(下篇2):產品的整體設計之業務層和系統層
上篇所講的高聚合低耦合的宗旨,就是要用在產品設計上,本篇文章分為整體設計和局部設計兩個部分。
上篇所講的高聚合低耦合的宗旨,就是要用在產品設計上。此處所講的產品設計,不只是界面設計,還包括產品架構、系統架構、功能模塊、實體結構、角色、邏輯等等。
本篇文章分為整體設計和局部設計兩個部分。整體設計是指從零到一開發或者重構一款產品的全部流程,一共涉及業務層、系統層、邏輯層和交互層等四個層面。局部設計是指產品正常迭代或者設計產品某小塊下的流程和核心,局部設計的流程是整體設計流程的子集,所以主講局部設計的核心。
大家在看的時候,時刻要想著“高內聚低耦合塑造產品認知”的宗旨。
整體設計
產品的整體設計包括業務層、系統層、邏輯層和交互層等四個層面?;谛枨筇岢鰳I務方案,基于可行可落地的業務方案進行設計。
在實際過程中,并不會嚴格按照順序一層層下來,因為方法是層級的,而靈感則是跳躍的。我一般是先從業務方案中抽象出實體、角色和邏輯,
整體設計
業務層:業務方案
業務層是指業務方案。業務方案就是業務層面的方案,要求業務方案是可行可落地的。新產品/新模塊的業務方案一般由產品經理、領導或者業務方提出,代表著在產品經理、領導或者業務方的思考中是如何解決這個問題的。
只有可行可落地的業務方案才有意義,因為產品經理就是要把可行可落地的業務方案搬到線上,做成標準化的解決一類問題。如果業務方案的不可行,那么后續的產品設計也就無從談起了。
如果業務方案已經落地且可行,例如在運營層面已經按照某規則人工實行了一段時間,效果不錯。產品經理就需要把這個方案搬到線上,要基于業務方案設計功能,做成標準化的功能解決一類的問題,還要結合整體和未來的發展。
如果沒有可行可落地的業務方案,產品經理不僅需要和各方溝通出一個或者多個解決方案,還需要通過落地執行或者設計MVP等方法去測試方案的預計效果和可行性。有多個就對比選一個最好的,這里的最好可以是效果或者性價比等,具體請視情況判斷。
當公司發展到一定階段,業務和系統必定有一個是縱向有一個是橫向,多個業務縱向鋪開后,需要橫向的系統打通,主要出于四方面考慮:專業深度、人力資源、用戶體驗、全局打通。例如滴滴出行在短時間內形成了包括快車、出租車、專車、順風車、代駕等多業務的垂直化架構,滴滴啟動了中臺戰略整合業務系統。
系統層:系統定位、系統架構、模塊抽象、規劃藍圖
系統層是指系統層面的一些東西,包括系統定位、系統架構、模塊抽象、規劃藍圖。人們看到體驗到的產品都是露在外面的那一塊,實際上還有很多系統在海平面以下,或大或小的產品背后總后好幾套系統的存在。大的例如下圖的唯品會,整個分為SAAS、PAAS和IAAS,每個里面有多個平臺多個系統,才能支撐起唯品會的發展。小小的一款APP里的IM、推送等可能都是第三方提供的獨立的系統。
唯品會的整體架構
系統定位
系統定位就是指確定系統要解決什么需求,先要有拆分出系統的需求,然后才有這個系統。系統定位必然是最先一步,并不是所有東西都要單獨拉出個系統去做。觀察大型系統的演進過程可以發現,絕大部分系統都是從初始的小功能到模塊最后再到系統的(功能<模塊<系統)。
系統化本身就是為了解決資源共享低、利用率低、不能集中處理等問題,系統也能降低整體耦合性,此時應該和架構師進行探討,因為大部分都是技術層面的東西,要思考清楚哪些是系統哪些不是系統,所解決的需求是否重要是否急迫,并且對每個系統提出定位作為迭代方向,當然定位并不是一成不變的。
系統架構
確定了有哪些系統和對應的系統定位后,即可開始進行系統架構。系統架構強調的是系統和系統之間的聯系,如果有多個系統還可以像唯品會一樣平臺化,便于理解也便于組織架構劃分。
如果發現系統架構完成后,并沒有把所有系統or模塊包含進去,則要回到系統定位上重新梳理和思考,要把所有都包含進去。因為系統架構是解釋系統之間的關系,絕對不能硬塞進一個模塊。就像外出前收拾行李,把一堆東西塞進一個書包、一個旅行箱和一個編織袋,塞完了發現還剩一雙鞋,得想辦法塞到專門放鞋子得編織袋里面,但是編織袋已經滿了也沒法倒騰出空位,那就只能塞到旅行箱里面。
裝滿東西的旅行箱(來自百度圖片)
系統和系統之間要協調配合,互相聯系互相制約,就像運動系統、神經系統等八大系統使人體內各種復雜的生命活動能夠正常進行。
模塊抽象
平臺、系統、模塊和功能之間的關系應該是:平臺包含系統,系統包含模塊,模塊包含功能。此處所講的均不能只看做是前臺的某個界面,均包含后臺所對應的邏輯等,是一個立體的結構而不是前臺的平面結構。平臺、系統、模塊和功能都是立體結構,只是粒度不同。而角色、實體和流程是平面結構,是不同角度下不同視野下的系統。
模塊抽象就是指把不同模塊都抽離出來,模塊和模塊之間互相獨立互相依存,類似系統定位,劃分了模塊之后才能確定哪個系統包含哪些模塊。
功能從場景和流程中抽象,模塊從功能和實體中抽象。像唯品會等電商系統,會分商品模塊、品類模塊、訂單模塊、購物車模塊、支付模塊等等。一個模塊包括前臺的展示頁面/組件+后臺邏輯。模塊的抽象是很自然的,因為本身系統的建立就有其內部的生態或者邏輯,就像人體的呼吸系統包含呼吸道(鼻腔、咽、喉、氣管、支氣管)和肺一系列器官以及內在邏輯。
規劃藍圖
優秀的產品都是迭代和規劃出來的,而不是一生下來就是。很多產品前期都是很簡單很基礎的幾個模塊,而且1.0版本用以快速試錯的,如果模塊很多體量很大就會浪費資源,要是失敗了就得不償失。
規劃藍圖并不是計劃藍圖,規劃和計劃的區別在于,規劃是長遠的(6個月以上)、不詳細的、目標不精確的,計劃則是短期的、詳細的、目標精確的。例如,2018上半年要開發新版本就是個規劃,而2018年6月前用戶要自然增長100%通過優惠券、滿減等手段則是計劃。
在系統架構和模塊抽象起來后,我會進行規劃藍圖的工作。規劃藍圖分兩塊,需求樹和產品路線圖,需求樹是把所有需求(系統、模塊、功能或者某些待解決的問題)放到樹形圖上,產品路線圖則是把需求樹上的需求經過篩減后按照產品階段放置。
需求樹示例
需求樹,是為了梳理、分類需求,分析優先級和前后置條件。樹根是實現整個系統所必須要的基礎設施,樹干是核心功能模塊,樹枝是可以進入的領域或者方向,樹枝上也有功能模塊。一開始先把核心功能、基礎設施和方向領域確定好,然后用便利貼往上貼功能模塊或者需求,最后按照越靠近主干越優先的策略調整便利貼的位置。期間整個團隊都有一起合作,各抒己見,一起協商這些具體功能或者想法應該怎么發展,一起確定優先級。
需求樹可隨時補充,而且要定期把需求樹上新增的需求刪減、調整以放到路線圖中。
產品路線圖示例
產品路線圖,是為了明確產品什么時候該做什么,是最多6個月到2年的產品路線,具體看公司規模、行業特點等。產品路線圖可根據實際情況進行調整,但不是想要改就改的,產品路線圖很嚴肅,不嚴肅的毫無意義,要遵守他。
路線圖包括產品階段、里程碑、需求。
產品階段是指產品所處的階段,會有初始、成長、成熟和衰退四大階段,每個大階段根據不同情況會有小階段,視產品情況自行確定。處于不同階段的產品都有不同的產品戰略,要歸納出來,為需求的選擇和實施方向提供思想支持。
里程碑主要是用來劃分階段的,例如找到第一個用戶G點并形成可復制方案使得用戶大規模增長,從初始進入了成長期;在新增和流失用戶打平,做再多拉新活動ROI都會持續下降,從成長進入了成熟期等等。
基于產品階段、階段中的產品戰略和需求樹,把需求放到產品路線圖中,最終形成產品路線圖。離當前時間越近的要詳細些,遠的則大方向要清晰。
下一篇《產品經理如何基于需求迭代產品(下篇2):產品的整體和局部設計》,敬請期待。
相關閱讀
產品經理如何基于需求迭代產品(下篇01):產品設計的高內聚低耦合
本文由 @Vency?原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自unsplash,基于CC0協議
缺少例子佐證,理論太強看不明白
感覺沒講清楚系統如何高聚合低耦合,怎么避免這種情況
干貨干貨