互聯網金融涉及的方面有很多，每個都值得細細研究。本文作者從七個角度深度分析集合理財計劃，希望對你有幫助。

互聯網金融理財方向涉及的業務場景主要包括如下幾個板塊：賬戶、存管、支付、還款、收款、分潤、清算、財務、投標、自動投標、智投、紅包、風控體系、運營體系、會員、積分商城等。

智投體系是整個理財業務中技術含量最高，最能考驗產品經理對金融的理解、對合規的理解、對資金的理解、對資產的理解、對流動性的理解、對投資人的理解、對借款人的理解、對平臺風控的理解、對平臺運營的理解、對支付的理解、對分潤的理解、對財務的理解、對清結算的理解、對數學的理解。

實際上遠不止上述14組知識能力的要求，基本上平臺原有的所有功能都需要做配套協同。譬如，用戶總賬體系下的虛擬子賬戶的處理、投資人收益體系、平臺紅包體系、電子合同體系（海量債權下的電子合同成本考慮）、提前還款違約金分潤邏輯、逾期墊付邏輯等都需要整體考慮。

我們在這方面并無項目經驗，但我們用了“2個產品-3個后臺研發-1個前端-2個測試”前前后后歷時3個月的上線。下面向大家分享一下自認為我們的一些創新和心得，尤其是一個優秀的產品經理在“底層邏輯思維”和“過程方法論”方面的能力要求和這種硬能力對各種復雜問題的殺傷能力。

一、極簡的、高效的競品調研

如何在一天內或者說一個小時內把某個需要幾個月完成的清晰搞清楚呢？如何確定自己的技術路線并確保比現有的方案都更優雅呢？如何來說服你的老板、業務團隊、技術團隊、法務團隊、風控團隊呢？

1.1 首要能力：靈性、有盤感

產品經理必須具備業務盤感，也即一說即明、一點即破。如果是木頭疙瘩，老板或上司講了3分鐘了，自己還一頭露水，沒有頭緒，那就是缺乏盤感。有盤感不代表需要立即知道怎么做，但知道需求方要什么？明白需求方需求背后的需求。

1.2 次要能力：方法論

產品經理必須具備自己的工作方法論，問題無窮盡、任務無窮盡、行業無窮盡，但“理”基本相通。譬如這里是了解競品，我們需要知道競品分析的核心要素、標準打法、快捷打法分別是什么？

打蛇打7寸，這里的要點是“極簡、高效”的競品調研，我們只需梳理出：

1.2.1 調研誰

平時有關注，直接拿來用，平時未積累，網上5分鐘提取出Top10名單（行業細分方向每組選2個左右）。

1.2.2 調研哪些點

投資規則、計息規則、贖回規則、紅包規則、合同條文（通過關鍵條文推斷底層業務邏輯和產品策略）、極端場景（通過極端場景推斷底層的業務邏輯和產品策略，譬如提前還款、提前退出、逾期、資金站崗、強制退出等）。

1.2.3 結論輸出

分條輸出+我們怎么做。

1.2.4 結論驗證

• 四用：自己要用，橫向用、縱向用、逆向用；
• 逆向拆解：提出推斷的問題、找客服死纏爛打掰扯清楚；
• 修正結論：通過用、推斷、客服驗證、多平臺多通道信息交差修正結論。

1.2.5 “快打”的特殊武器：小組行動

由于智投業務極其復雜，為了解決“快”、為了確保剖析“深”、為了確?？紤]面“廣”、為了確保結論“客觀”、為了規避被“掉鏈子員工”綁架，我當時采用了小組行動。

我及另外2個產品組員三人分頭行動、交差覆蓋，最后會審結論，集體review、把有爭議的問題再量化分解繼續求證。

二、梳理各方訴求、抽象凝練業務目標

產品經理日常工作中無非是針對如下三種問題來發揮自己的能力、實現自己的價值：

1. 場景1：當前的系統存在問題或無法滿足某種業務，需要優化；
2. 場景2：老板給個想法，我們要干一件事來幫助我們開拓一個陣地；
3. 場景3：無中生有或基于現商業資源開創性的自我提出需求、給出方案、推動落地；

場景1比較務實，基本上一個合格的產品經理基本都可以輕松勝任。

場景2和3都比較虛，前者是老板或客戶一句話我們就知道怎么辦，后者是無中生有造天地。但兩者都對產品經理硬功夫有很高的要求，能勝任的基本都是能獨當一面的不可多得人才。

場景2考驗的是我們是否有極強的產品盤感？能否綜合多業務的不同場景抽象總結平臺核心價值？能否清晰定義產品功能和系統邊界？能否形成長短期的一體化產品方案？能否在業務理解、產品決策、執行和遠景規劃上是否有全面把控能力和關鍵陣地攻取能力？

場景3考驗的是我們的產品創新意識及商業思考力，是否善于在復雜的商業環境和生態需求中進行抽象總結并找到切入點，通過產品創新設計將商業化策略進行落地，利用產品能力實現”無中生有”拿到結果的能力。

如下為我們老板說“咱們要上計劃，你們看下怎么做”一句話，我結合業務需求梳理凝練的我們的產品建設硬指標。

由于這是一個新的陌生的陣地，可以直接甩開膀子放手干（我最喜歡這種任務、任務越復雜，干著越得勁，打怪之路的成就感越強），我們未做用戶訪談，而是將梳理出的產品建設目標與各團隊負責人進行討論，通過征詢大家建議的方式來驗證、修正我們的產品目標及策略導向：

三、 圍繞目標、梳理業務鏈路、設計產品Story

3.1 目標導向的產品設計策略

產品業務目標確定后，所有的產品設計工作都以目標為導向，進行業務拆解和方案輸出。產品建設目標更多是原則性指導，對產品工作的開展更多是方向性指導，但這是最快的產品解決之道。

示例1：借款人發起任意期限借款。

1. 這就要求我們的發標系統對借款人有固定期限調整為任意期限。
2. 借款人的期限任意，其本意是滿足借款人的業務靈活性。
3. 當借款人端足夠靈活時，投資人足夠靈活如何來確保1對1配對？這就是產品的發力點——1對1配對不可能，而是將現有的“資金流”、“資產流”的耦合解耦掉，通過撮合系統完成各自的“任性”。
4. 當上述3提出來時，合規問題怎么解決？這就是產品的發力點——將現有的“資金”、“資產”分拆進行編碼、穿透追蹤、“直接撮合”等新名詞、新概念、新場景、新解決方案就自動躍然紙上。
5. 當上述4提出來時，資金資產被無限拆分四舍五入最后的收益為零怎么解決？這就是產品的發力點——算法策略要考慮拆原始邊界（起投限額）、分拆粒度（最小可拆額）、撮合效率等新名詞、新概念、新場景、新解決方案就自動躍然紙上。
6. 當上述5提出來時，我們控制了資金流的粒度問題，借款人還款還的利息依舊是小數，收益四舍五入最后的收益為零怎么解決？這就是產品的發力點——算法策略要考慮回款歸集、滿額釋放、自動收斂（拆散的資金要具備自動合并收斂功能）策略等新名詞、新概念、新場景、新解決方案就自動躍然紙上。

示例2：面向借款人的滿標實時放款。

1. 這句話的背后訴求是“借款人滿標的時效性要提高、要比散標高”，否則通過資金分散本來可以將一個標投滿放款的，最后每個標上都有錢，都未滿標，而導致的滿標效率下降。
2. 當上述1提出來時，現有的系統如何解決呢？這就是產品的發力點，我們能否將資金集中調度、自動清算、手動清算、資金找標、標找資金、資金隊列、資金優先級、資產隊列、資產優先級、站崗資金等新名詞、新概念、新場景、新解決方案就自動躍然紙上。
3. 當上述2提出來時，資金被隨意調度，你這不是在搞資金池，不是違規給老板挖坑么？這就是產品的發力點，資金在用戶的存管賬戶上，資金調度指令有清算系統輸出、用戶授權清算系統自動撮合、資金資產依舊嚴格1對1等新名詞、新概念、新場景、新解決方案就自動躍然紙上。
4. 當上述3提出來時，如何向監管證明我們未設資金池？如何向用戶呈現其資金的流轉歷史動態？當借款人逾期啟動催收時，如何向法官提供清晰的債權憑證？這就是產品的發力點，委托服務合同、債權轉讓合同、轉讓通知、資金劃撥憑證、交易流水等新名詞、新概念、新場景、新解決方案就自動躍然紙上。

總之一句話、產品目標一旦確定，產品經理所作的所有工作只有一個“遇水架橋、遇山打洞”。在困難面前，沒有什么可以限制我們的創造力，相反淺嘗輒止、蜻蜓點水、思維懶惰、缺乏死磕的意志是無法勝任復雜產品設計、無法擔當大攻堅任務的。

上面的例子可以看出一個問題的解決，需要幾環、幾十環、甚至上百環的產品策略進行迂回包抄。很多時候，我們都死在“懶”上了，我們無法指望一個懶惰的產品經理能給團隊帶來多少價值，少挖坑就是對團隊最大的恩惠！我們多么渴望產品團隊中有那么幾個在思考上勤快縝密、心中有大局、考慮很細膩、且敢于行動的產品經理。

3.2 業務鏈路圖及產品story

在產品目標框架下，我們通過上面的“疊羅漢”邏輯思維，將瑣碎的解決方案進行再抽像、凝練、梳理出簡明扼要的業務鏈路圖。然后對業務鏈路圖進行推敲、細化、調整優化，下面分享一下我的業務鏈路圖梳理經驗：

• 業務鏈路圖中明確產品目標中的各參與角色，及其鏈路走向；
• 確定后再次逐一推敲其合理性、可優化性、概念可閱讀性、逆向可跑通性、邊界場景的可覆蓋性、整體可閉環性；
• 套娃策略：針對業務鏈路中的關鍵節點用子業務鏈路圖進行展開示意；
• 自己推敲基本滿意后，再征詢業務方的關鍵干系人，進行查漏補缺、方案驗證。

3.2.1?業務鏈路圖1：核心業務鏈路圖

集合理財計劃-核心業務鏈路圖

3.2.1.1 集合理財計劃-核心業務鏈路圖-設計思想

設計思想1：引入計劃池概念，計劃池作為理財的資金端入口進行資金采集，計劃池入口約定進入資金的收益規則、資金站崗規則、退出規則、合規層面的前置法律授權、風險層面的前置提醒等。

設計思想2：引入資金池概念，將用戶手動投資資金、自動投標資金、計劃未到期借款人還款的代復投資金、超級賬戶資金納入隊列考慮。這里的資金池不是法律禁止的“資金池”，而是“交易指令池”，在交易發生前，資金依舊在用戶賬戶上，只是處于鎖定授權狀態，用戶不可操作，平臺可操作。

設計思想3：引入資產池概念，將借款人的申請待融資資產、投資人贖回釋放的債權資產、超級賬戶調節資產納入資產池隊列，等待清算系統統一征用。

設計思想4：將上述兩個池的概念再次拆分為“待匹配池”、“待清算池”子概念。待匹配池可以人工干預調度、有運營動態調控（如需），待清算池是清算前的前奏，是為下一步的財務清算、結算提供物理的時間、空間邊界。

設計思想5：將清算概念再次拆分為自動、手動兩種模式，自動是每日凌晨自動運行（無人值守），手動是運營隨時可手動開啟——滿足業務放款的高時效性、高靈活性。

備注：底層架構設計到位、研發層面根據項目周期考慮可以自由定奪開發“手動”或“自動”還是兩個都開發。實際上只要架構設計合理，兩個都開發和開發一個的工作量基本是一樣的。

為什么？我們繼續進行抽象，自動模式是手動模式中的一種極端場景而已，只是增加一個自動觸發器的概念而已。該“手動”場景的置入，配合“合同”的約定及運營規則的市場調整，其靈活性和業務可擴展性的便利程度在我們的集合理財計劃的日常運營中充分發揮了其能量。相比市面各互金大廠的產品，此處的創新讓我們十分有成就感。

設計思想6：引入事務概念，通過“資金=資產”和“故障回退”，當某筆資金清算失敗時，整筆資金回退給用戶，禁止部分清算，避免誘發“收益策略”、“合規策略”等問題。

設計思想7：合規考慮1：未清算前，資金永遠在用戶的賬戶上；合規考慮2：資產先進入清算池，資金后進入清算池，也即資金找資產鏈路而非資產找資金鏈路；合規考慮3：委托服務合同、債權轉讓合同、風險揭示合同等。

設計思想8：大隊列、小隊列，自動清算模式下，根據資金/資產屬性及進場時間確定其清算優先級。

資金隊列優先級：

大隊列：復投資金;授權出借資金（含自動出借、預約出借）；預約出借資金；

小隊列：大隊列內部按時間逆序：發生時間越早優先級越高（時間相同按序號，序號越小優先級越高）。

資產隊列優先級：

大隊列：自動債轉（退出策略輸出的債權編號）；散標；手動債轉；

小隊列：大隊列內部按時間逆序：發生時間越早優先級越高（時間相同按序號，序號越小優先級越高）。

設計思想9：流動性調節（下面的章節詳細講解），通過運營工具、時間鎖定、限額、超級賬戶四級流動性調節工具來引導、干預、化解流動性風險。

3.2.1.2 集合理財計劃-配套新概念集合-邏輯推演

為了方便理解上述設計思想及底層的業務原理，也為了與原有的業務概念做區分，我將前述提到的新概念、新名詞、新場景等抽象為如下的概念組，通過這些概念組來輔助研發、運營、客服、風控、合規等崗位的兄弟來透徹地理解我們的集合計劃的運行原理、合規策略等困惑。

為什么要引入這些新的名詞或概念呢？主要是因為這是一個新場景和目標任務的復雜性，我們可以舉如下兩個例子來幫助我們來理解這種產品思維：

例1：當我們解某個復雜的數學題時，我們引入多個參數、動用不同的數學公式去推導論證。

例2：當我們從功能機時代轉到智能機時代，我們要引入很多新的概念來討論智能手機如何落地，譬如電容屏、電阻屏、滑動手勢、指紋解鎖、屏幕解鎖、顯存、系統版本、系統升級、系統補丁、系統皮膚、系統市場、內存管理、應用管理、云端同步、丟失模式、GPS、LBS等一系列新名詞、新概念與之配套）。

3.2.2 業務鏈路圖2：資金資產-清算撮合（調度指令）-清算執行

3.2.2.1 資金資產-清算撮合-設計原則

資金量化拆分原則：

設計原則1：相對分散，資金做到相對分散，避免同一人的同一筆大額資金落到同一個債權上；

設計原則2：潛在擴展，現階段申購資金主要投放到原生債權上，運行起來后要考慮債轉場景的小額承載力與編組資金的最大限度自洽；

設計原則3：有限拆分，首投資金不能被無限制拆分；

設計原則4：膨脹約束，復投資金不能被鏈式再度無限制裂變拆分；

設計原則5：小數收斂，當本息同時回款出現小數時，在不超過原則1的條件下，本息合并投資避免分別投資在未來潛在產生兩筆小數；

設計原則6：有限合理，如果可預期內業務擴展能接受，算法設計不易太復雜；

設計原則6：降低錯誤率：基于上述1~5減少程序計算量；

設計原則7：提升保障速度：基于上述1~6減少故障定位、災難恢復難度。

債權滿標原則：

設計原則1：滿標效率：債權滿標效率要相對高效，而非所有債權同時被等額消減；

設計原則2：債轉友好：投資人到期退出時，債權持有人不至于廣而無邊，而是有限受眾。

3.2.2.2 資金資產-清算撮合-業務鏈路圖

3.2.2.3 資金資產-清算撮合-設計思想

設計思想1：報名凍結策略，3.2.1中已介紹，申購資金進場是個業務概念，并非將投資人的資金真正的轉移了，只有資金在執行清算這一刻，才將投資人的資金用投資人賬戶劃撥到目標賬戶上（承接人或借款人）。

設計思想2：計算策略與清算策略，計算策略是計算資金池中的哪個用戶的多少資金被調撥到資產池中與哪筆債權進行配對，清算執行資金資產匹配的指令。計算策略在前、清算執行在后。

設計思想3：資金編碼：每筆資金都進行編碼追蹤，無論是申購（投資）資金、還是回款（復投）資金，都生成唯一資金編碼，也即給資金制作部家譜傳代指紋，通過資金編碼穿透追蹤資金去向。

設計思想4：資產編碼：每筆資產都進行編碼追蹤，無論是申請借款形成的資產、還是贖回釋放的轉讓資產，都生成唯一資產編碼，通過資產編碼穿透追蹤資產的核銷去向。

設計思想5：資金找債權，對標示例：學校組織各班去春游，一班的學號1坐1號班車，二班學號1坐2號班車，進行遍歷循環。

設計思想6：債權找資金，對標示例：學校組織各班去春游，1號班車到門口，先上一班，一班上完上二班，循環遍歷。

3.2.2.4 資金資產-清算撮合-方案設計

在研發團隊“無算法工程師”的客觀條件和要求“技術開發成本最低，工作量為1天”、“技術方案相對最優”的情況下，基于上述設計思想、設計原則，我整理了如下5套方案，其中方案3（綠色）為相對最優方案。

3.2.2.5 資金資產-清算撮合-收斂推演模擬

后期在與行業的朋友和互金協會的律師交流我們這套方案時，給予了高度評價，大團隊動用產品總監、產品經理、金融精算師、合規律師、算法工程師、架構師等歷時幾周討論、再花幾周構思、設計、測算、驗證，最后再動用2~3周的研發測試，搞得極其唬人（美其名曰智投或AI算法）和極其復雜（維護困難）。

備注：我們預留了2個決策參數未動用，是因為體量太小，約束條件過多，最后無法完成撮合。兩個未動用的參數為：投資人風險偏好、債權風險等級。如果啟用這兩個參數，其實也很簡單，只需要增加兩個約束條件即可：約束條件1：風險匹配；約束條件2：比例邊界約束。

3.2.3 業務鏈路圖3：資金贖回退出策略

3.2.3.1 贖回退出-業務鏈路圖

3.2.3.2 贖回退出-關鍵場景抽象定義

為了很好的理解贖回退出，我們先定義兩個概念，也即前面提到的“資產編碼”和這里新出現的“轉讓贖回引擎”。有了這兩個概念，下面我們分析處理“贖回”業務時就很容易有個代入感。

資產編碼規則：

• 散標債權場景：“散標債權場景”在 發標進入資產池場景下有存在意義，散標資產編碼=項目號。
• 非轉讓場景：“非轉讓場景”在用戶持有某債權，但又未發起轉讓場景下有存在意義；資產編碼=用戶持有本筆債權的交易流水號（直投場景對應直投交易流水號，轉讓持有對應轉讓交易流水號）。
• 轉讓發起場景：“轉讓發起場景”在用戶發起退出，債權按【轉讓發起引擎】計算對某筆債權進行退出場景下有意義；根據【轉讓發起引擎】，如果002資產“剩余債權”被全額輸送到【資產池】，該筆資產的資產編碼=002（歷史轉讓持有交易流水號）；根據【轉讓發起引擎】，如果002資產“剩余債權”未被全額輸送到【資產池】，則輸送份額的資產編碼為“002+年月日8位+12位循環遞增，示例：002-20181206-123456123456。

轉讓發起引擎：

• 根據上述退出策略計算用戶從持有的債權上撤出的時序、撤出金額，也即向【資產池】輸送債權，供【資金/資產-配對引擎】執行清算用；
• 【轉讓發起引擎】每輸出一個債權時，都生成一個唯一的編碼，具體定義見【資產編碼規則】描述；
• 退出釋放的債權價值動態變化，如果上述【轉讓發起引擎】輸出的資產未在當日被清算完畢，“資產編碼”不變、“資產本金”、“資產價值”做動態更新。

3.2.3.3 贖回退出-方案推演-邏輯提取

方案1：逐筆債權法

用戶發起的退出，經過【退出預處理引擎】處理后，輸出子債權包單元集，進入【資產待匹配池】，見下圖：

方案2：債權包整體法

用戶發起的退出，經過【退出預處理引擎】進行“余額沖銷”預處理后，債權包剩余價值，作為一個整體，進入【資產待匹配池】，見下圖：

很顯然，方案1更合理，原因：其一：方便清算引擎未來在出借訴求T與根債權的剩余T進行函數處理，收斂交易次數；其二：方案2無法有效規避離散問題。

3.2.3.4 贖回退出-設計思想

退出策略1：3種退出方式

1. 到期自動退出；
2. 用戶主動退出；
3. 監管及客觀不可控而有平臺代為強制退出。

退出策略2：退出金額控制算法降級策略

1. 退出金額=出借本金-∑已退出本金，可發起退出；
2. 退出金額=當日資產價值時，可發起退出；
3. 無論上述1還是2，退出發起金額=退出到款金額（原因是，退出期間債權繼續計息）；
4. 上述1~3確保底層支持，前臺用戶端是否支持部分贖回有前臺根據運營、市場需要自行控制。

退出策略3：清算時效

• D+0清算：主動退出場景：退出生效的時間條件是：D+T自動生效，D指發起退出的日期，T是退出申請成功時間后移的生效周期，T=5分鐘（本期）；自動退出場景：退出生效的時間條件是：D+T自動生效，D指項目到期日，如3天的項目，1號計息，D指的是4號；
• 清算時效價值：流動性吃緊時，運營自行調控T的長短規則，而不用修改程序。

退出策略4：歸屬原則

1. 用戶發起退出時，退出只對該出借id所在的鏈條生效，也即用戶如果有多個出借時，某一退出只能在限定的出借下發起；
2. 基于上述1，用戶的可退出金額、退出站崗資金、退出清算等判斷條件都是基于該出借id下面的資金、資產鏈條而定。

退出策略5：站崗資金優先退出

1. A類優先級：用戶發起退出時，已站崗資金優先發起退出；
2. B類優先級：當日到期應還“總額”部分——當日是否還無法確定，具體見【退出沖銷】定義：
3. C類優先級：剩余部分從持有債權中撤出——以資產上配置的本金作為計算邏輯（詳見【最接近原則退出】策略；
4. 逾期的債權禁止贖回，將風險控制在當前債權人頭上，不放大風險；
5. A、B、C順序執行——具體見【退出執行時序說明】；
6. 贖回站崗中發生逾期，清算時自動將該債權提出資產池（回到用戶持有債權明細），本債權在撤回轉讓前已轉讓部分繼續生效）。

備注：如果退出站崗期間，又發生回款資金時，繼續執行上述1——后果每天會到一部分。

退出策略6：退出沖銷

• 沖銷場景1：本出借下面存在“凍結余額”時自動與本出借下面的“生效退出”進行沖銷；
• 沖銷場景2：當日發生本出借下面的資產標的回款時，回款金額將優先與本出借下面的“生效退出”進行沖銷——也即回款金額直接回到用戶可用余額，沖銷剩余部分進入“凍結復投”-“復投出借池”序列；
• 沖銷場景3：【資金】與【債權】執行清算撮合時，系統自動檢測目標資金所對應的用戶id在該資金所歸屬的出借id下面是否存在【退出未清算】的任務，如有該資金與【退出未清算】進行自動沖銷，剩余資金執行【撮合清算算法】——具體見【全局說明-資金債權撮合流程】流程圖；
• 退出未清算特指：已生效的退出（已滿足“D+T”清算條件)但未完全退出的剩余差額部分。

退出策略7：最小本金原則退出（確保大本金剩余，進而確保平臺扣服務費有足夠盤面）

1. 退出資金X（部分退出的計算邏輯指本金，全量退出的計算邏輯指資產）；
2. 站崗資金Y（每日更新值）；
3. 執行退出Z=X-∑Y；
4. Z從該用戶目前持有債權中本金最小的債權先撤出；如果最小本金相同，標的結清日與當前時間段的優先級高；如果4.1中的標的到期日也相同，取債權號，債權號小的優先級高；
5. 如果上述最接近的拿回后仍不足以撤回，剩余差值繼續執行3~5。

3.2.3.5 贖回退出-流動性干預機制

設計訴求：超級賬戶作為流動性調節器，其前臺申購入口權限同普通用戶，可隨時進場護盤。為保障超級賬戶資金的自由調控性，超級賬戶持有的計劃產品可隨時發起退出，釋放債權，回收本金。

設計策略：

• user表增加“超級賬戶”參數，參數信息為：user表新增字段 super_user 0普通用戶, 1超級用戶；
• 擁有超級用戶身份的用戶進入”PC賬戶中心-輕松智投-計劃持有詳情頁”有獨立的“申請退出”入口；
• 在該入口，超級用戶可隨時發起贖回——贖回操作同正常贖回流程；
• 超級用戶的身份有財務部 直接提供賬戶，有研發人員直接在數據庫 配置，不提供獨立設置入口（特定有限幾個人用，沒必要開發獨立功能）。

備注：這種方案的好處是底層邏輯通用，入口層面有運營根據市場需要隨時可定制，屬于典型的中臺化思想。譬如后期有客戶投訴或平臺要清退時，運營或客服可啟動該開關，方便客戶隨時發起贖回而無需動用產品、研發、測試資源。

備注：更多流動性調節工具及機制見第6章節。

3.2.4 業務鏈路圖4：債權轉讓-資金資產交割-策略

3.2.4.1 債權轉讓-業務鏈路圖

贖回是業務概念，轉讓是法律層面個概念，資金資產交割是財務層面概念。先有贖回，后有轉讓，轉讓與資金資產交割同時發生。贖回場景相關的服務費扣除或貼息均在清算事物進行。

3.2.4.2 債權轉讓-方案推演-邏輯提取

如果我們要透徹地了解業務，依然必須把這個業務的子場景全部挖出來，研究其上下文語境及關聯關系，如下為我提取整理的“債轉場景”的相關概念，并對相關概念做了參數賦值，方便進行數學運算運算策略設計。

3.2.4.2.1 化繁為簡-場景切分

通過上圖我們可以看出債權轉讓涉及的計算參數多達28組，如果轉讓交割方案上考慮有遺漏、設計不科學、不能化繁為簡，缺乏可落地價值等，會直接把研發、測試累死。

為此，我們首先把債權價值這個概念給剝離、抽象出來，看下都涉及哪些業務場景。

3.2.4.2.2 角色提取-分潤關系推演

通過上圖我們將“債權價值”抽象、切割為“本金”、“利息”、“獎勵”、“折讓系數”以及“還款計劃發生逾期的（正常還款、部分還款）”等子部分組成，實現化繁為簡，這樣我們就跳過公式而討論對象。

沿著這個思路，我們用下圖向大家推演一下轉讓場景中涉及的角色、及分潤關系。

3.2.4.2 債權價值-配套新概念集合-邏輯推演-算法設計

用戶甲通過001號收益計劃持有債權A持有10天，轉給用戶乙（通過002號收益計劃持有債權A10天）再轉給用戶丙，每次轉讓交割時，債權價值是以底層債權A計算還是用出讓人的收益計劃角度計算呢？

譬如當用了下述計算方案時，會直接導致我們的研發兄弟跳樓。

當我們換為如下思路來處理債權價值時，將能極大的節省研發資源且對后面的業務維護更友好。

債權價值業務定義：

• 處于合規和底層清算標準一致性考慮，用戶甲轉給用戶乙的價值以轉讓對象為分析根本，而不易轉讓時甲的應得財富計算；
• 從借款項目約定的債權人付息計劃、平臺項目加息 2個角度出發，計算債權價值；
• 債權價值=債權本金+未結算利息+未結算獎勵；
• 債權價值是“廣義實時”，說明如下：昨日計算出的債權價值-今日還款變動量。

債權價值計算公式：

• 債權價值=昨日計算值-今日還款本金-還款利息-還款獎勵；
• 昨日計算值=前日計算值+昨日本金*(項目利率+項目加息+加息券加息)/365；
• 昨日本金=當日22：00后持有債權本金；

有了上述“債權價值”的最簡單的計算算法之后，我們仍需抽象（發明）出如下“概念組”來輔助我們（研發兄弟）去解決“債權轉讓-財務分潤”這個工程。

盡管又硬生生地提出一撘新概念，但業務的清晰度躍然紙上，且每個概念場景均是獨立的，可以解耦開發，也有利于測試校驗和后期的維護更新。

3.2.4.2 債權價值-還款核銷場景-邏輯推演-算法設計

通過上述新概念的引入，我們就可以通過如下數據報表把用戶A將持有的債權B轉給C，以及平臺的服務費和獎勵等所有場景給透視出來，為下一步的資金、資產的往來穿透追蹤提供底層支持。

3.2.5 業務鏈路圖5：借款人回款-交割分潤-產品設計策略

非計劃模式下，借款人還款的分潤模型很簡單，借款人還的錢有系統按照預先生成好的還款計劃進行分潤，也即借款人應得本、借款人應得息、平臺應得服務費、精度差平臺補償、以及獎勵下發。

計劃模式下，我們面臨如下一系列問題：

• 計劃未到期，某筆持有的債權到期；
• 計劃到期持有的債權未到期等問題；
• 復投面臨無資產的資金站崗問題或部分站崗部分復投成功；
• 一旦資金站崗，當發生多筆回款時，就出現資金合并問題；
• 如果用戶持有多筆計劃，都同時發生回款且都站崗，此時我們需要額外的考慮，也即回款要所在各自的申購框架下，為用戶的每一筆申購計劃單獨建賬套。否則，無法規避合規問題。

3.2.5.1 借款人回款-交割分潤-財務記賬-設計原則

回款凍結策略1：歸屬原則

回款凍結以回款掛靠的計劃為原則進行邊界統計。

回款凍結策略2：派息扣除原則

• 回款凍結解凍復投的值是將扣除當月應派息之和后進行處理（如涉及）；
• 復投解凍后的資金經過如下三個循環進入【資金待匹配池】，并生成資金編碼。利息派息引擎、退出沖銷引擎、復投凍結引擎。

回款凍結策略3：連續超長站崗退出原則

• 復投的站崗資金在100元以上的時間連續累計超過D日（含），D初始值=30，走退出策略；
• 退出時站崗資金全額退出——清算完畢后將剩余的復投資金全額退出（剩余金額=100元,且連續D日=100元，自動觸發）。

回款凍結策略4：業務降級策略

回款遵從散標風險匹配策略，具體資金執行時按用戶出借計劃時的風險進行匹配（寫進合同中）——這里進行了業務降級，因為投資人的風險承受能力是動態的。

凍結子場景的邏輯關系：

• 計劃凍結=回款預凍結+出借凍結+凍結監聽器+激活復投凍結；
• 全站累計凍結=計劃凍結+提現凍結+預約出借凍結。

3.2.5.2 借款人回款-交割分潤-財務記賬-業務鏈路圖

通過上述凍結策略完成借款人回款的資金鎖定，為后續相關流程開展提供前置保障。

3.2.5.3 借款人回款-交割分潤-財務記賬-凍結復投引擎

前面章節提到，為了防止資金被無限拆分而進一步誘發的“四舍五入”精度問題，我們需要做收斂控制。

最重要的一個收斂節點就是回款收斂，為此我們在“凍結復投引擎”中引入一個“收斂監聽器”概念，回款金額與已凍結的金額求和小于閥值時，自動收斂，超過閥值時，激活凍結資金到資金池中等待調用。

3.2.5.4 清算與還款互斥鎖定

清算執行時，需要關閉還款，因為還款一旦發生，債權價值發生變化，債轉交易基礎動搖，清算引擎的執行就會出現問題，詳見下圖：

3.2.6 業務鏈路圖6：撤銷申購、流標退款、失效退款策略

3.2.6.1 可撤銷申購-時效控制-禁止逆向邏輯

• 資金被部分清算后禁止逆向【撤銷申購】；
• 進入【資金清算池】的資金禁止【撤銷出借】，除非解凍。

3.2.6.2 可撤銷贖回-時效控制-禁止逆向邏輯

• 退出被部分清算后禁止逆向【撤銷退出】；
• 進入【資產清算池】的債權禁止【撤銷退出】，除非解凍。

3.2.6.3 自動流標1：未在承諾期內完成配標

1. 用戶出借（含預約）的資金未在各自的承諾期內完成出借，過24：00，針對未配標部分進行解凍退款；
2. 基于上述1，出借退款可能是部分的。

3.2.6.4 自動流標2：承諾期外發生流標

• 超過承諾期后，用戶出借資金中的某一部分如果發生流標了，則流標資金直接執行退款；
• 未超過承諾期的流標，不執行退款，繼續在下一輪清算過程中，進行配標；
• 復投資金發生的流標，不執行退款，繼續在下一輪清算過程中，進行配標。

四、“業務鏈路+產品story”思想指導下的“新增場景-表結構設計”

4.1 集合計劃計劃-表結構

4.2 申購記錄-表結構

4.3 資金待匹配池-表結構

4.4 贖回記錄-表結構

4.5 資產待匹配池-表結構

4.6 資金清算池待-表結構

4.7 資產清算池待-表結構

4.8 資金配標追蹤-表結構

4.9 還款去向追蹤-表結構

4.10 資金來源明細-表結構

4.11 贖回清算追蹤-表結構

4.12 債權流轉追蹤-表結構

五、新老功能沖突的產品處理策略

5.1 關聯影響梳理、解決方法論

產品經理除了會造輪子還需要會修輪子，除了上述12個新增業務主表外，系統原有的相關業務模塊也需要一個一個去梳理，哪些受影響，具體的影響點是什么？如何做調整？調整方案是否最優的？

一個產品經理如果只會造輪子而不知道如何復用、如何下手駕馭老輪子，不是一個好產品經理。

如何快速了解老業務、駕馭老業務呢？對于超大型項目，我的方法是：

1. 2份文檔：產品文檔+測試用例；
2. 1套權限：開通全權限，分別以不同的角色進行全鏈路業務體驗；
3. 橫向看、解構框架結構；
4. 縱向看、解構業務鏈路；
5. 逆向看、解構隱藏邏輯；
6. 執行上述5步過程時，做好知識點歸納總結筆記；
7. 精心思考，推敲每個模塊、每個功能點、每個業務鏈路當前的系統為什么這樣做？這樣做有什么考慮？有沒有別的替代方案？為什么當時的團隊不這樣做？
8. 就上述6和7的疑慮去請教原始產品、研發、測試及運營人員，更新自己的知識認知。

通過上述8個循環，基本上任何復雜的項目也就全裸在我們面前了，我把這項能力稱之為產品經理的“逆向業務解構能力”。

限于篇幅原因，我們就不不一一列舉具體的改造場景和如何改造了，下圖僅為后臺需要做同步改造的配套點：

5.2 關聯影響梳理、解決方法論

5.2.1 整合困難說明

上述所有關聯影響中影響最大的是交易記錄，原因如下：

• 歷史交易記錄是單式記賬法，新的業務場景是按復試記賬法，也即每筆交易從借貸兩個方向記錄；
• 歷史交易記錄的科目只有一級，新的交易記錄的科目是兩級；
• 歷史交易記錄的科目分類方式既有詞典庫分類又有前臺邏輯分類（處于用戶展示層考慮，把多個子分類用邏輯處理為一個分類，如各種獎勵場景）；
• 歷史交易記錄中基本無中間狀態，新的業務場景有大量的中間交易，處于合規需要，這些中間交易記錄需要呈現給用戶（前臺隱式呈現、后臺顯式）和支持監管隨時審查，也為了方便我們測試和分析業務。
• 交易記錄調整后必須與用戶的財富值、累計收益、代收收益、累計獎勵等自洽，不能出現不自洽的情況。
• 集合計劃為量化投資，交易記錄會呈現指數級放大，這樣會導致原有的交易記錄表出現性能瓶頸。

5.2.2 涉及訴求及改造目標

• 本表查看用戶的資金每一筆交易流動；
• 本表可區分用戶的資金進出明暗兩條線：明線展示給用戶，暗線不展示給用戶；
• 本表可查看用戶每筆資金發生前、發生后可用余額、資產、凍結等場景的變動值；
• 本表可查看每筆交易發生的場景、發生時間、交易對手、資金用途等；
• 整行黑色區域為平臺賬戶數據，不出現在交易記錄表中，這里僅供方便理解；
• 整行黃色區域為借款人數據，出現在交易記錄中，會出現配套的投資人數據、平臺數據，這里標記為黃色僅供開發人員理解業務邏輯。

5.2.3 改造策略及方法

• 數據排序：按交易時間逆序，創建越晚的id號排序越靠上；
• 交易流水：取具體的交易流水，虛擬交易見列表定義，原則上復用交易場景的交易id，如轉讓交易號、復投資金編碼，由于同一筆交易是有多個子項構成或者交易對手雙方都出現，交易流水可能會重復出現；
• 基于交易對手、引入參照系、發生額、變動后金額（參照系的可用余額），即每筆交易發生（真實、虛擬）均涉及兩組交易，每個系統都記賬，也即記錄兩筆賬；
• 進賬用+表示，出賬用-表示，進出均以參照系為中心，發生額為資金變動額，可用余額為參照系經過變動額（正負方向后）的更新值；
• 單一出借累計凍結是指某出借id下面的所有站崗資金，集合理財累計凍結是前述多個“單一出借累計凍結”之和；
• 數據更新：實時數據；
• 老數據：按擴容后的表結構對號入座（清洗數據）；
• 性能處理：默認只展示最近三個自然月的數據，超過三個月走冷數據查詢。

5.2.4 改造前

5.2.5 改造后

六、資金、資產、兌付流控策略

類活期計劃類的理財產品除了研發復雜外，流動性管控也是考驗平臺駕馭能力的一個指標。

一個優秀的產品經理不光會做功能，還得具備運營思維。我們的集合計劃系統在產品架構設計上為運營團隊進行了充分的考慮，這種多維度的流動性工具矩陣考慮基本上可以滿足當前、潛在任何的流動性危機，除非平臺發生惡性擠兌（實際上，我們還提供了最前置的合同層級的約定及配套交易結構置入）。

這套流動性調控機制在實務中確實發揮了其應有的能力，無論是平臺資產慌還是資金慌，無論是老板或運營團隊的任何突變想法、還是來自客服組接到的任何不可理喻的客訴。這套流控矩陣都能游刃有余、都無需再動用我們的研發資源進行迭代研發。

七、化繁為簡：學會把復雜的事通俗化、讓小白能理解

如果上面的內容看起來很枯燥，很燒腦，請看下我給我們客服團隊、運營團隊、風控團隊、老板做的一個培訓大綱。

通過這份大綱，受眾能快速了解我們的集合理財系統能達到什么目標？能滿足什么場景？相關場景如何操縱？以及一些核心問題是如何處理的，如合規問題、如流動性問題、如滿標效率問題、如成本問題等等。

以上是我們在集合理財項目中的一些實踐總結，限于文采拙劣和篇幅原因，未能精細呈現，海涵，歡迎大家交流切磋！

不同的行業、不同的業務場景、不同的崗位角色，會面臨不同的產品任務。但萬變不離其宗，方法相通，只要我們有產品盤感、業務敏感、邏輯嚴謹、靈通好學、干練帶風、狠下功夫，放到哪我們都一樣熠熠生輝。

產品之路很艱辛，也更能鍛煉人，尤其是中后臺、尤其是“中后臺+財務”這種大量底層的項目！在此祝廣大產品兄弟姐妹們不辱“產品”之title，做出好產品！

本文由 @九天牧人 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議