對於中臺系統建設，如果只是簡單地按照業務進行劃分，會導致中臺建設過度“粗糙”。所以要對各業務線的功能進行拆解，拆解出一個個的能力。那麼，如何進行高效又無遺漏的模組拆解呢？本文作者分享了動作分析法，一起來看一下吧。

一、業務中臺化抽象

完成了對產品定位與使用者這兩個產品外部因素的分析後，接下來的重頭戲就是我們需要深入各業務線的內部去研究各個組成部分，也就是對每個產品的功能模組進行挨個拆解，從而得到我們公司的顆粒度最小的基礎單元，為下一步中臺業務資料模型提取做好準備。

之所以這樣做，就是因為在現在的公司中一個產品的各個模組實際上是由不同的團隊進行研發並最終合併成一個App的。舉例來說，在電商內部，為了實現使用者去搜索商品這一個功能，背後至少需要有商品中心、搜尋中心、訂單中心、庫存4個團隊交織參與才能完成。

所以在這種情況下，如果粗糙地按照業務進行劃分會導致中臺建設過度“粗糙”，此外難免會有一些團隊在資訊不對稱的情況下進行了功能的重複性建設。例如，我們梳理一家電商平臺的需求，如果按照業務劃分，那麼自營電商的訂單模組與第三方電商的訂單模組會被劃分為兩個模組，但是本質上這些在中臺中完全可以合併為一個訂單模組。

而我們去進行整個產品的全部功能拆解，就是為了找到各個模組的共同之處，從而將這些共性部分提煉出來，這樣就能保證我們站在整個公司的視角去思考整體的解決方案。只有這樣，我們才能避免在思考中臺需求時漫無邊際地將各個應用中的任意需求都加入中臺規劃。

所以說來，在中臺建設裡廣泛存在這兩個問題：

新增的需求為了能適配不同的前端業務線，所以不能是具體的功能而應是能力；

我們要將哪些功能新增到中臺的需求池中，避免將中臺建設為另一個“小後臺”。

這裡問題的解決方法就是對各業務線的功能進行拆解，拆解出一個個的能力。例如，對一個商品模組，我們可以拆解出商品品類管理能力、價格管理能力、商品標籤管理能力這3個能力。

那麼又要如何進行高效又無遺漏的模組拆解呢？這裡我推薦大家使用動作分析法來進行拆解工作。

所謂動作分析法，就是將任意模組拆分為某個人為了完成某個事件而需要在應用中做哪些動作。進一步說，這個方法在本質上就是將任意一個業務需求拆分為3個步驟，如圖9-4所示。

圖1 動作分析法示意

每層級拆分原理解釋如下。

例如，我們對登入模組進行分析：

第一步，將這個模組拆分為兩個角色，分別是登入使用者與業務系統；

第二步，繼續拆分可得到兩個事件——使用者賬戶資訊輸入，賬戶與密碼正確性校驗；

第三步，再將如上事件拆分為賬戶資訊輸入、校驗事件觸發、賬戶資訊異常判斷、校驗結果返回、下一事件聯動（如進入首頁）。

綜上，我們便將一個登入模組拆分為兩個角色、兩個事件、五個動作，得到如圖2所示的完整流程。

在成功將模組拆分為以使用者為角色的動作之後，下一步透過將各個節點中不同角色的輸入輸出進行統一，我們就能很快找到整個系統中我們所需要提供的最密集的能力是什麼。

還是用App中的登入模組舉例，可以發現如下的現狀：在登入註冊中，我們需要向用戶提供身份認證與使用者首頁配置查詢功能（根據使用者許可權而顯示首頁模組，如給員工顯示基本介面，給管理員顯示帶有統一看板的介面）；而當用戶點開某模組時我們又需要向用戶提供身份認證並按角色配置查詢功能，查詢使用者是否為VIP使用者等。

圖2 登入業務流程

那麼透過這幾點的分析，我們就可以將系統中使用者身份認證與使用者配置這兩個使用頻率比較高的部分進行統一抽象，使其成為中颱的一個能力模組。

此外在第8章我們也提到了中臺建設中會遇到這樣的現象，就是公司內部若干條業務線對於同一個功能有完全不同的使用場景存在，這個時候我們的中臺模組提取是以哪個場景作為核心物件的？

此時在本章最開頭我們分析出的業務線在整個公司商業模式中的地位就派上用場了，那些能為公司變現的業務模組應該是中臺優先歸納和剝離的，隨後其他不同的業務線都應該向此類模組集中。至此針對某一個具體場景的抽象方法我們就介紹完了，接下來我們需要做的就是針對全公司的業務進行逐個分析。

二、案例：地圖應用抽象

為了更好地理解產品畫像與流程抽象，在這兒我們以一款真實的地圖類應用為例。

產品背景：

產品終端：App。

一級功能：地點查詢、路線導航、公共交通乘坐指南、地理位置周邊發現、線上打車。

使用者資料：選取9天內無任何投放活動的自然流量下的使用者資料，如圖9-6所示。

圖3 自然流量下的使用者資料

步驟1：產品畫像分析

畫像一分析：產品線中各功能的地位分析，如表9-4所示。

步驟2：節點拆分

在這兒我們以線上打車功能進行流程通用性抽象，按照動作拆分理論，我們可以拆分出如圖9-7所示的結果。

圖4 打車需求拆分示例

步驟3：節點資訊流分析

讓我們對線上打車裡的各事件節點資訊流進行一下梳理：

登入系統（2個主要資訊項）：個人密碼校驗、個人賬戶資訊（暱稱、ID、聯絡方式、頭像）。

選擇終點（2個主要資訊項）：終點地理資訊、路線資訊查詢。

選擇車型（1個主要資訊項）：車型偏好資訊（在應用中選擇了打車模組）。

呼叫車輛（3個主要資訊項）：乘客資訊（賬戶資訊）、司機資訊、司機地理資訊。

到點付費（4個主要資訊項）：路程地理資訊、賬單資訊、個人賬戶評價資訊、司機評價資訊。

此時如果我們將上面的12個資訊項進行歸類，並統計下各節點的資訊項重疊次數，可以得到如表9-5所示的結果，也就是我們前臺業務所需要的能力。

所以根據這份表格的結果，我們可以先將使用者中心、位置管理中心這兩個相對高頻的模組進行剝離，使其成為公共模組。但是這裡得到的結果還不能立即作為中颱建設需求，還需要進行處理，具體我們將在下一章來看要如何建設。

專欄作家

三爺，微信公眾號：三爺茶館，人人都是產品經理專欄作家，2019年年度作者。《中臺產品經理寶典》作者，原萬達高階產品、MBA特約講師、獨立創業者，現叮咚買菜B端產品線負責人，擁有多款集團專案從零到一經驗並帶領實現商業化佈局。

本文原創釋出於人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。