互联网金融涉及的方面有很多，每个都值得细细研究。本文作者从七个角度深度分析集合理财计划，希望对你有帮助。

互联网金融理财方向涉及的业务场景主要包括如下几个板块：账户、存管、支付、还款、收款、分润、清算、财务、投标、自动投标、智投、红包、风控体系、运营体系、会员、积分商城等。

智投体系是整个理财业务中技术含量最高，最能考验产品经理对金融的理解、对合规的理解、对资金的理解、对资产的理解、对流动性的理解、对投资人的理解、对借款人的理解、对平台风控的理解、对平台运营的理解、对支付的理解、对分润的理解、对财务的理解、对清结算的理解、对数学的理解。

实际上远不止上述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 协议