上面兩篇文章，著重于理論層面，下面我結(jié)合之前做過的業(yè)務(wù)，講一講如何實操。

Step1：搭建業(yè)務(wù)框架

接手新業(yè)務(wù)，首先是通過流程圖搭建對這個業(yè)務(wù)的整體框架。

不一定是最全最準確的流程圖，最開始可以先畫一個比較簡單的流程，知道整個業(yè)務(wù)如何運轉(zhuǎn)的即可。

一般可以從以下兩個方面著手：

1. 【宏觀】先了解行業(yè)模式

通過大量泛讀，了解行業(yè)如何運作，可以參考的資料：體系化的課程、行業(yè)書籍、行業(yè)資訊、行業(yè)分析報告、券商分析報告、咨詢公司分析報告、相關(guān)公司財報、產(chǎn)品論壇上相關(guān)業(yè)務(wù)的調(diào)研和分析。

2. 【微觀】再研究公司的該業(yè)務(wù)如何運作

可以參考的資料：產(chǎn)品文檔、產(chǎn)品流程圖、接口文檔、開發(fā)的wiki文檔（按照我的閱讀經(jīng)驗，開發(fā)的wiki文檔一般會劃分系統(tǒng)模塊及對應(yīng)的功能，對后續(xù)輸出產(chǎn)品方案有很大幫助）。

下圖為我之前做過的兩個業(yè)務(wù)的流程：

可能你會覺得很簡單，其實事實上也并不復(fù)雜。把握了整個大體的框架，后續(xù)細化的時候，才知道自己做的需求是屬于哪個環(huán)節(jié)，才能做到“既見樹木，又見森林”。

Step2：根據(jù)流程圖，抽象數(shù)據(jù)對象

先科普一下數(shù)據(jù)對象（純屬個人的粗淺理解，如有不對，歡迎指正）：

行為產(chǎn)生數(shù)據(jù)，比如客戶下單會產(chǎn)生訂單、學(xué)生考試會產(chǎn)生成績，“下單”“考試”是行為，“訂單”“成績”是數(shù)據(jù)。對應(yīng)到數(shù)據(jù)庫里，“訂單”“成績”就是數(shù)據(jù)對象，可以簡單理解為“訂單”“成績”各自有一張表，記錄所有訂單和所有成績。

【以成績?yōu)槔?/p>

數(shù)據(jù)對象：成績

屬性/字段：學(xué)生ID、姓名、語文、數(shù)學(xué)、英語

1. 提煉數(shù)據(jù)對象

投資的數(shù)據(jù)對象：產(chǎn)品、訂單、持倉、還款計劃

小貸的數(shù)據(jù)對象：授信訂單、提現(xiàn)訂單、還款計劃

2. 根據(jù)數(shù)據(jù)對象畫實體關(guān)系圖（ER圖）

實體關(guān)系圖描述了各個數(shù)據(jù)對象的關(guān)系。

有兩種畫法：（以理財為例）

1）常規(guī)畫法

2）帶屬性的畫法

關(guān)系一般包含以下三種：

以理財舉例，1個投資產(chǎn)品對應(yīng)N筆訂單（多個客戶都可以買同一個產(chǎn)品，故產(chǎn)生N筆訂單），1筆訂單對應(yīng)0到1筆持倉（訂單失敗則不創(chuàng)建持倉，訂單成功則創(chuàng)建持倉），1筆持倉對應(yīng)1筆還款計劃（用戶投資之后總有退出投資，所以有還款計劃）。

順帶提一下，畫法2的數(shù)據(jù)對象，帶#的屬性為主鍵，主鍵決定了每條記錄的唯一性。

3. 分析數(shù)據(jù)處理的CRUD：增加(Create)、檢索(Retrieve)、更新(Update)和刪除(Delete)

下圖以訂單和成績?yōu)槔?，分析了四種操作，這些操作可能就是有待分析的需求或產(chǎn)品功能。

一般線上的用戶數(shù)據(jù)都不會被刪除，比如訂單只支持撤銷，很少看到從數(shù)據(jù)庫里直接刪除的。

Step3：數(shù)據(jù)對象的狀態(tài)機圖/生命周期

接手新項目，抽象出數(shù)據(jù)對象后，就需要用狀態(tài)機圖描述它們的狀態(tài)流轉(zhuǎn)，這對于之后了解系統(tǒng)交互很重要。狀態(tài)機圖描述了一個數(shù)據(jù)的生命周期。

下圖以優(yōu)惠券的狀態(tài)機圖為例，優(yōu)惠券的創(chuàng)建一般有這些場景：運營人員在后臺給客戶發(fā)放優(yōu)惠券、客戶參加活動獲得優(yōu)惠券、客戶花錢購買優(yōu)惠券……

優(yōu)惠券的初態(tài)是【待使用】，終態(tài)是【已使用】【已過期】。

Step4：泳道圖 or 劃分功能模塊/系統(tǒng)

1. 有清晰的角色或系統(tǒng)時，可直接畫泳道圖

如果不是從0到1的項目，一般系統(tǒng)都是劃分好的，這時候只需要把數(shù)據(jù)對象的狀態(tài)流轉(zhuǎn)帶入泳道圖即可。

下圖為簡單的一個運營系統(tǒng)的優(yōu)惠券狀態(tài)扭轉(zhuǎn)泳道圖，對比狀態(tài)機圖，可知，【待使用】【已過期】為運營系統(tǒng)內(nèi)部維護的狀態(tài)，【已占用】【已使用】和釋放占用，都是由訂單系統(tǒng)通知的。

通過泳道圖，我們可以知道數(shù)據(jù)在各個系統(tǒng)之間如何流轉(zhuǎn)，知道每個系統(tǒng)維護什么數(shù)據(jù)以及如何與其他系統(tǒng)交互。

2. 沒有清晰的角色或系統(tǒng)時，通過數(shù)據(jù)流程圖劃分模塊

數(shù)據(jù)流程圖使用的元素：

下圖紅框圈出來的就是一個模塊/一個系統(tǒng)，在劃分功能模塊時，需要滿足“高內(nèi)聚、低耦合”的標準，將相近、相似功能歸為一個模塊，如此便于開發(fā)和維護，提高整體分工效率。

Step5：基于泳道圖，了解系統(tǒng)間數(shù)據(jù)傳遞的方式

1. 接口傳輸

接口就像一扇門，請求方從這扇門里獲取想要的數(shù)據(jù)，而不關(guān)心門背后的具體邏輯。

同步調(diào)用模式和異步調(diào)用模式：

• 同步調(diào)用：接口的調(diào)用方一直等待被調(diào)用方的返回結(jié)果，比如前端請求服務(wù)端數(shù)據(jù)進行展示。一般處理結(jié)果較快，會使用同步調(diào)用，如上文的訂單系統(tǒng)調(diào)用運營系統(tǒng)，通知運營系統(tǒng)占用優(yōu)惠券，訂單系統(tǒng)會一直等待運營系統(tǒng)返回優(yōu)惠券的占用結(jié)果，作為訂單狀態(tài)的流轉(zhuǎn)依據(jù)
• 異步調(diào)用：接口調(diào)用方給被調(diào)用方發(fā)出指令，但不會等待結(jié)果，一般耗時比較長的處理工作會用異步調(diào)用模式，并且調(diào)用方會給被調(diào)用方提供一個回調(diào)接口。比如小貸里的訂單系統(tǒng)，將授信訂單推送給風控系統(tǒng)，風控系統(tǒng)需要一定時間處理，甚至需要人工介入，所以不能立馬給出結(jié)果。等風控系統(tǒng)處理完成后，會回調(diào)訂單系統(tǒng)的接口，返回授信額度等關(guān)鍵信息

泳道圖一般只展示了數(shù)據(jù)如何在系統(tǒng)間傳遞，但不涉及具體的實現(xiàn)方式。比如系統(tǒng)A要把數(shù)據(jù)同步給系統(tǒng)B，就有兩種實現(xiàn)方式：①系統(tǒng)A調(diào)用系統(tǒng)B的接口，通知系統(tǒng)B相關(guān)數(shù)據(jù)；②系統(tǒng)B調(diào)用系統(tǒng)A的接口，查詢需要獲取的信息。具體實現(xiàn)邏輯可以查閱接口文檔或者和開發(fā)討論。

2. 數(shù)據(jù)庫同步

接口傳輸，當數(shù)據(jù)量較大時，可能導(dǎo)致連接超時。使用數(shù)據(jù)庫同步，可以實現(xiàn)數(shù)據(jù)的實時同步更新，一般應(yīng)用在數(shù)據(jù)量大的場景下，主要適用于公司內(nèi)部系統(tǒng)之間數(shù)據(jù)庫對數(shù)據(jù)庫的傳輸，占用資源少、交互更加簡單。

有幾種同步方法：

• 使用中間庫：將目標數(shù)據(jù)放在一個中間庫里，需要這些數(shù)據(jù)的系統(tǒng)對這個庫都有訪問權(quán)限
• 實時同步數(shù)據(jù)：使用Otter是一個常用的方法，Otter進程會根據(jù)定義的規(guī)則將數(shù)據(jù)表的內(nèi)容從源頭數(shù)據(jù)庫更新到目標庫中，也支持雙向更新

按照上述方法論，畫完一遍圖，心里就對新業(yè)務(wù)有底了。我切換過幾次業(yè)務(wù)，每次都屢試不爽（屢次試驗都沒有差錯）。

對整體業(yè)務(wù)有了把握，做需求時再深入細節(jié)就好了。

希望對你有幫助~

作者：苒苒上升，互聯(lián)網(wǎng)金融產(chǎn)品經(jīng)理，就職于3億用戶平臺，微信公眾號：苒苒上升，輸出干貨包括但不限于成長秘訣、產(chǎn)品心經(jīng)。

本文由@苒苒上升 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash, 基于CC0協(xié)議。