jrs低调看直播nba-免费版

nba直播集合理财计划:资金资产撮合系统、财务

时间:2021-05-23 19:40

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

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

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

  实际上远不止上述14组知识能力的要求,基本上平台原有的所有功能都需要做配套协同。譬如,用户总账体系下的虚拟子账户的处理、投资人收益体系、平台红包体系、电子合同体系(海量债权下的电子合同成本考虑)、提前还款违约金分润逻辑、逾期垫付逻辑等都需要整体考虑。

  我们在这方面并无项目经验,但我们用了“2个产品-3个后台研发-1个前端-2个测试”前前后后历时3个月的上线。下面向大家分享一下自认为我们的一些创新和心得,尤其是一个优秀的产品经理在“底层逻辑思维”和“过程方法论”方面的能力要求和这种硬能力对各种复杂问题的杀伤能力。

  如何在一天内或者说一个小时内把某个需要几个月完成的清晰搞清楚呢?如何确定自己的技术路线并确保比现有的方案都更优雅呢?如何来说服你的老板、业务团队、技术团队、法务团队、风控团队呢?

  产品经理必须具备业务盘感,也即一说即明、一点即破。如果是木头疙瘩,老板或上司讲了3分钟了,自己还一头露水,没有头绪,那就是缺乏盘感。有盘感不代表需要立即知道怎么做,但知道需求方要什么?明白需求方需求背后的需求。

  产品经理必须具备自己的工作方法论,问题无穷尽、任务无穷尽、行业无穷尽,但“理”基本相通。譬如这里是了解竞品,我们需要知道竞品分析的核心要素、标准打法、快捷打法分别是什么?

  平时有关注,直接拿来用,平时未积累,网上5分钟提取出Top10名单(行业细分方向每组选2个左右)。

  投资规则、计息规则、赎回规则、红包规则、合同条文(通过关键条文推断底层业务逻辑和产品策略)、极端场景(通过极端场景推断底层的业务逻辑和产品策略,譬如提前还款、提前退出、逾期、资金站岗、强制退出等)。

  由于智投业务极其复杂,为了解决“快”、为了确保剖析“深”、为了确保考虑面“广”、为了确保结论“客观”、为了规避被“掉链子员工”绑架,我当时采用了小组行动。

  我及另外2个产品组员三人分头行动、交差覆盖,最后会审结论,集体review、把有争议的问题再量化分解继续求证。

  产品经理日常工作中无非是针对如下三种问题来发挥自己的能力、实现自己的价值:

  场景2和3都比较虚,前者是老板或客户一句话我们就知道怎么办,后者是无中生有造天地。但两者都对产品经理硬功夫有很高的要求,能胜任的基本都是能独当一面的不可多得人才。

  场景2考验的是我们是否有极强的产品盘感?能否综合多业务的不同场景抽象总结平台核心价值?能否清晰定义产品功能和系统边界?能否形成长短期的一体化产品方案?能否在业务理解、产品决策、执行和远景规划上是否有全面把控能力和关键阵地攻取能力?

  场景3考验的是我们的产品创新意识及商业思考力,是否善于在复杂的商业环境和生态需求中进行抽象总结并找到切入点,通过产品创新设计将商业化策略进行落地,利用产品能力实现无中生有拿到结果的能力。

  如下为我们老板说“咱们要上计划,你们看下怎么做”一句话,我结合业务需求梳理凝练的我们的产品建设硬指标。

  由于这是一个新的陌生的阵地,可以直接甩开膀子放手干(我最喜欢这种任务、任务越复杂,干着越得劲,打怪之路的成就感越强),我们未做用户访谈,而是将梳理出的产品建设目标与各团队负责人进行讨论,通过征询大家建议的方式来验证、修正我们的产品目标及策略导向:

  产品业务目标确定后,所有的产品设计工作都以目标为导向,进行业务拆解和方案输出。产品建设目标更多是原则性指导,对产品工作的开展更多是方向性指导,但这是最快的产品解决之道。

  当借款人端足够灵活时,投资人足够灵活如何来确保1对1配对?这就是产品的发力点——1对1配对不可能,而是将现有的“资金流”、“资产流”的耦合解耦掉,通过撮合系统完成各自的“任性”。

  当上述3提出来时,合规问题怎么解决?这就是产品的发力点——将现有的“资金”、“资产”分拆进行编码、穿透追踪、“直接撮合”等新名词、新概念、新场景、新解决方案就自动跃然纸上。

  当上述4提出来时,资金资产被无限拆分四舍五入最后的收益为零怎么解决?这就是产品的发力点——算法策略要考虑拆原始边界(起投限额)、分拆粒度(最小可拆额)、撮合效率等新名词、新概念、新场景、新解决方案就自动跃然纸上。

  当上述5提出来时,我们控制了资金流的粒度问题,借款人还款还的利息依旧是小数,收益四舍五入最后的收益为零怎么解决?这就是产品的发力点——算法策略要考虑回款归集、满额释放、自动收敛(拆散的资金要具备自动合并收敛功能)策略等新名词、新概念、新场景、新解决方案就自动跃然纸上。

  这句话的背后诉求是“借款人满标的时效性要提高、要比散标高”,否则通过资金分散本来可以将一个标投满放款的,最后每个标上都有钱,都未满标,而导致的满标效率下降。

  当上述1提出来时,现有的系统如何解决呢?这就是产品的发力点,我们能否将资金集中调度、自动清算、手动清算、资金找标、标找资金、资金队列、资金优先级、资产队列、资产优先级、站岗资金等新名词、新概念、新场景、新解决方案就自动跃然纸上。

  当上述2提出来时,资金被随意调度,你这不是在搞资金池,不是违规给老板挖坑么?这就是产品的发力点,资金在用户的存管账户上,资金调度指令有清算系统输出、用户授权清算系统自动撮合、资金资产依旧严格1对1等新名词、新概念、新场景、新解决方案就自动跃然纸上。

  当上述3提出来时,如何向监管证明我们未设资金池?如何向用户呈现其资金的流转历史动态?当借款人逾期启动催收时,如何向法官提供清晰的债权凭证?这就是产品的发力点,委托服务合同、债权转让合同、转让通知、资金划拨凭证、交易流水等新名词、新概念、新场景、新解决方案就自动跃然纸上。

  总之一句话、产品目标一旦确定,产品经理所作的所有工作只有一个“遇水架桥、遇山打洞”。在困难面前,没有什么可以限制我们的创造力,相反浅尝辄止、蜻蜓点水、思维懒惰、缺乏死磕的意志是无法胜任复杂产品设计、无法担当大攻坚任务的。

  上面的例子可以看出一个问题的解决,需要几环、几十环、甚至上百环的产品策略进行迂回包抄。很多时候,我们都死在“懒”上了,我们无法指望一个懒惰的产品经理能给团队带来多少价值,少挖坑就是对团队最大的恩惠!我们多么渴望产品团队中有那么几个在思考上勤快缜密、心中有大局、考虑很细腻、且敢于行动的产品经理。

  在产品目标框架下,我们通过上面的“叠罗汉”逻辑思维,将琐碎的解决方案进行再抽像、凝练、梳理出简明扼要的业务链路图。然后对业务链路图进行推敲、细化、调整优化,下面分享一下我的业务链路图梳理经验:

  设计思想1:引入计划池概念,计划池作为理财的资金端入口进行资金采集,计划池入口约定进入资金的收益规则、资金站岗规则、退出规则、合规层面的前置法律授权、风险层面的前置提醒等。

  设计思想2:引入资金池概念,将用户手动投资资金、自动投标资金、计划未到期借款人还款的代复投资金、超级账户资金纳入队列考虑。这里的资金池不是法律禁止的“资金池”,而是“交易指令池”,在交易发生前,资金依旧在用户账户上,只是处于锁定授权状态,用户不可操作,平台可操作。

  设计思想3:引入资产池概念,将借款人的申请待融资资产、投资人赎回释放的债权资产、超级账户调节资产纳入资产池队列,等待清算系统统一征用。

  设计思想4:将上述两个池的概念再次拆分为“待匹配池”、“待清算池”子概念。待匹配池可以人工干预调度、有运营动态调控(如需),待清算池是清算前的前奏,是为下一步的财务清算、结算提供物理的时间、空间边界。

  设计思想5:将清算概念再次拆分为自动、手动两种模式,自动是每日凌晨自动运行(无人值守),手动是运营随时可手动开启——满足业务放款的高时效性、高灵活性。

  备注:底层架构设计到位、研发层面根据项目周期考虑可以自由定夺开发“手动”或“自动”还是两个都开发。实际上只要架构设计合理,两个都开发和开发一个的工作量基本是一样的。

  为什么?我们继续进行抽象,自动模式是手动模式中的一种极端场景而已,只是增加一个自动触发器的概念而已。该“手动”场景的置入,配合“合同”的约定及运营规则的市场调整,其灵活性和业务可扩展性的便利程度在我们的集合理财计划的日常运营中充分发挥了其能量。相比市面各互金大厂的产品,此处的创新让我们十分有成就感。

  设计思想6:引入事务概念,通过“资金=资产”和“故障回退”,当某笔资金清算失败时,整笔资金回退给用户,禁止部分清算,避免诱发“收益策略”、“合规策略”等问题。

  设计思想7:合规考虑1:未清算前,资金永远在用户的账户上;合规考虑2:资产先进入清算池,资金后进入清算池,也即资金找资产链路而非资产找资金链路;合规考虑3:委托服务合同、债权转让合同、风险揭示合同等。

  设计思想8:大队列、小队列,自动清算模式下,根据资金/资产属性及进场时间确定其清算优先级。

  小队列:大队列内部按时间逆序:发生时间越早优先级越高(时间相同按序号,序号越小优先级越高)。

  小队列:大队列内部按时间逆序:发生时间越早优先级越高(时间相同按序号,序号越小优先级越高)。

  设计思想9:流动性调节(下面的章节详细讲解),通过运营工具、时间锁定、限额、超级账户四级流动性调节工具来引导、干预、化解流动性风险。

  为了方便理解上述设计思想及底层的业务原理,也为了与原有的业务概念做区分,我将前述提到的新概念、新名词、新场景等抽象为如下的概念组,通过这些概念组来辅助研发、运营、客服、风控、合规等岗位的兄弟来透彻地理解我们的集合计划的运行原理、合规策略等困惑。

  为什么要引入这些新的名词或概念呢?主要是因为这是一个新场景和目标任务的复杂性,我们可以举如下两个例子来帮助我们来理解这种产品思维:

  例1:当我们解某个复杂的数学题时,我们引入多个参数、动用不同的数学公式去推导论证。

  例2:当我们从功能机时代转到智能机时代,我们要引入很多新的概念来讨论智能手机如何落地,譬如电容屏、电阻屏、滑动手势、指纹解锁、屏幕解锁、显存、系统版本、系统升级、系统补丁、系统皮肤、系统市场、内存管理、应用管理、云端同步、丢失模式、GPS、LBS等一系列新名词、新概念与之配套)。

  设计原则1:相对分散,资金做到相对分散,避免同一人的同一笔大额资金落到同一个债权上;

  设计原则2:潜在扩展,现阶段申购资金主要投放到原生债权上,运行起来后要考虑债转场景的小额承载力与编组资金的最大限度自洽;

  设计原则5:小数收敛,当本息同时回款出现小数时,在不超过原则1的条件下,本息合并投资避免分别投资在未来潜在产生两笔小数;

  设计原则1:满标效率:债权满标效率要相对高效,而非所有债权同时被等额消减;

  设计原则2:债转友好:投资人到期退出时,债权持有人不至于广而无边,而是有限受众。

  设计思想1:报名冻结策略,3.2.1中已介绍,申购资金进场是个业务概念,并非将投资人的资金真正的转移了,只有资金在执行清算这一刻,才将投资人的资金用投资人账户划拨到目标账户上(承接人或借款人)。

  设计思想2:计算策略与清算策略,计算策略是计算资金池中的哪个用户的多少资金被调拨到资产池中与哪笔债权进行配对,清算执行资金资产匹配的指令。计算策略在前、清算执行在后。

  设计思想3:资金编码:每笔资金都进行编码追踪,无论是申购(投资)资金、还是回款(复投)资金,都生成唯一资金编码,也即给资金制作部家谱传代指纹,通过资金编码穿透追踪资金去向。

  设计思想4:资产编码:每笔资产都进行编码追踪,无论是申请借款形成的资产、还是赎回释放的转让资产,都生成唯一资产编码,通过资产编码穿透追踪资产的核销去向。

  设计思想5:资金找债权,对标示例:学校组织各班去春游,一班的学号1坐1号班车,二班学号1坐2号班车,进行遍历循环。

  设计思想6:债权找资金,对标示例:学校组织各班去春游,1号班车到门口,先上一班,一班上完上二班,循环遍历。

  在研发团队“无算法工程师”的客观条件和要求“技术开发成本最低,工作量为1天”、“技术方案相对最优”的情况下,基于上述设计思想、设计原则,我整理了如下5套方案,其中方案3(绿色)为相对最优方案。

  后期在与行业的朋友和互金协会的律师交流我们这套方案时,给予了高度评价,大团队动用产品总监、产品经理、金融精算师、合规律师、算法工程师、架构师等历时几周讨论、再花几周构思、设计、测算、验证,最后再动用2~3周的研发测试,搞得极其唬人(美其名曰智投或AI算法)和极其复杂(维护困难)。

  备注:我们预留了2个决策参数未动用,是因为体量太小,约束条件过多,最后无法完成撮合。两个未动用的参数为:投资人风险偏好、债权风险等级。如果启用这两个参数,其实也很简单,只需要增加两个约束条件即可:约束条件1:风险匹配;约束条件2:比例边界约束。

  为了很好的理解赎回退出,我们先定义两个概念,也即前面提到的“资产编码”和这里新出现的“转让赎回引擎”。有了这两个概念,下面我们分析处理“赎回”业务时就很容易有个代入感。

  散标债权场景:“散标债权场景”在 发标进入资产池场景下有存在意义,散标资产编码=项目号。

  非转让场景:“非转让场景”在用户持有某债权,但又未发起转让场景下有存在意义;资产编码=用户持有本笔债权的交易流水号(直投场景对应直投交易流水号,转让持有对应转让交易流水号)。

  转让发起场景:“转让发起场景”在用户发起退出,债权按【转让发起引擎】计算对某笔债权进行退出场景下有意义;根据【转让发起引擎】,如果002资产“剩余债权”被全额输送到【资产池】,该笔资产的资产编码=002(历史转让持有交易流水号);根据【转让发起引擎】,如果002资产“剩余债权”未被全额输送到【资产池】,则输送份额的资产编码为“002+年月日8位+12位循环递增,示例-6。

  根据上述退出策略计算用户从持有的债权上撤出的时序、撤出金额,也即向【资产池】输送债权,供【资金/资产-配对引擎】执行清算用;

  【转让发起引擎】每输出一个债权时,都生成一个唯一的编码,具体定义见【资产编码规则】描述;

  退出释放的债权价值动态变化,如果上述【转让发起引擎】输出的资产未在当日被清算完毕,“资产编码”不变、“资产本金”、“资产价值”做动态更新。

  用户发起的退出,经过【退出预处理引擎】处理后,输出子债权包单元集,进入【资产待匹配池】,见下图:

  用户发起的退出,经过【退出预处理引擎】进行“余额冲销”预处理后,债权包剩余价值,作为一个整体,进入【资产待匹配池】,见下图:

  很显然,方案1更合理,原因:其一:方便清算引擎未来在出借诉求T与根债权的剩余T进行函数处理,收敛交易次数;其二:方案2无法有效规避离散问题。

  D+0清算:主动退出场景:退出生效的时间条件是:D+T自动生效,D指发起退出的日期,T是退出申请成功时间后移的生效周期,T=5分钟(本期);自动退出场景:退出生效的时间条件是:D+T自动生效,D指项目到期日,如3天的项目,1号计息,D指的是4号;

  清算时效价值:流动性吃紧时,运营自行调控T的长短规则,而不用修改程序。

  B类优先级:当日到期应还“总额”部分——当日是否还无法确定,具体见【退出冲销】定义:

  C类优先级:剩余部分从持有债权中撤出——以资产上配置的本金作为计算逻辑(详见【最接近原则退出】策略;

  赎回站岗中发生逾期,清算时自动将该债权提出资产池(回到用户持有债权明细),本债权在撤回转让前已转让部分继续生效)。

  备注:如果退出站岗期间,又发生回款资金时,继续执行上述1——后果每天会到一部分。

  冲销场景1:本出借下面存在“冻结余额”时自动与本出借下面的“生效退出”进行冲销;

  冲销场景2:当日发生本出借下面的资产标的回款时,回款金额将优先与本出借下面的“生效退出”进行冲销——也即回款金额直接回到用户可用余额,冲销剩余部分进入“冻结复投”-“复投出借池”序列;

  冲销场景3:【资金】与【债权】执行清算撮合时,系统自动检测目标资金所对应的用户id在该资金所归属的出借id下面是否存在【退出未清算】的任务,如有该资金与【退出未清算】进行自动冲销,剩余资金执行【撮合清算算法】——具体见【全局说明-资金债权撮合流程】流程图;

  退出未清算特指:已生效的退出(已满足“D+T”清算条件)但未完全退出的剩余差额部分。

  退出策略7:最小本金原则退出(确保大本金剩余,进而确保平台扣服务费有足够盘面)

  设计诉求:超级账户作为流动性调节器,其前台申购入口权限同普通用户,可随时进场护盘。为保障超级账户资金的自由调控性,超级账户持有的计划产品可随时发起退出,释放债权,回收本金。

  user表增加“超级账户”参数,参数信息为:user表新增字段 super_user 0普通用户, 1超级用户;

  拥有超级用户身份的用户进入”PC账户中心-轻松智投-计划持有详情页”有独立的“申请退出”入口;

  超级用户的身份有财务部 直接提供账户,有研发人员直接在数据库 配置,不提供独立设置入口(特定有限几个人用,没必要开发独立功能)。

  备注:这种方案的好处是底层逻辑通用,入口层面有运营根据市场需要随时可定制,属于典型的中台化思想。譬如后期有客户投诉或平台要清退时,运营或客服可启动该开关,方便客户随时发起赎回而无需动用产品、研发、测试资源。

  赎回是业务概念,转让是法律层面个概念,资金资产交割是财务层面概念。先有赎回,后有转让,转让与资金资产交割同时发生。赎回场景相关的服务费扣除或贴息均在清算事物进行。

  如果我们要透彻地了解业务,依然必须把这个业务的子场景全部挖出来,研究其上下文语境及关联关系,如下为我提取整理的“债转场景”的相关概念,并对相关概念做了参数赋值,方便进行数学运算运算策略设计。

  通过上图我们可以看出债权转让涉及的计算参数多达28组,如果转让交割方案上考虑有遗漏、设计不科学、不能化繁为简,缺乏可落地价值等,会直接把研发、测试累死。

  为此,我们首先把债权价值这个概念给剥离、抽象出来,看下都涉及哪些业务场景。

  通过上图我们将“债权价值”抽象、切割为“本金”、“利息”、“奖励”、“折让系数”以及“还款计划发生逾期的(正常还款、部分还款)”等子部分组成,实现化繁为简,这样我们就跳过公式而讨论对象。

  沿着这个思路,我们用下图向大家推演一下转让场景中涉及的角色、及分润关系。

  用户甲通过001号收益计划持有债权A持有10天,转给用户乙(通过002号收益计划持有债权A10天)再转给用户丙,每次转让交割时,债权价值是以底层债权A计算还是用出让人的收益计划角度计算呢?

  当我们换为如下思路来处理债权价值时,将能极大的节省研发资源且对后面的业务维护更友好。

  有了上述“债权价值”的最简单的计算算法之后,我们仍需抽象(发明)出如下“概念组”来辅助我们(研发兄弟)去解决“债权转让-财务分润”这个工程。

  尽管又硬生生地提出一撘新概念,但业务的清晰度跃然纸上,且每个概念场景均是独立的,可以解耦开发,也有利于测试校验和后期的维护更新。

  通过上述新概念的引入,我们就可以通过如下数据报表把用户A将持有的债权B转给C,以及平台的服务费和奖励等所有场景给透视出来,为下一步的资金、资产的往来穿透追踪提供底层支持。

  非计划模式下,借款人还款的分润模型很简单,借款人还的钱有系统按照预先生成好的还款计划进行分润,也即借款人应得本、借款人应得息、平台应得服务费、精度差平台补偿、以及奖励下发。

  回款遵从散标风险匹配策略,具体资金执行时按用户出借计划时的风险进行匹配(写进合同中)——这里进行了业务降级,因为投资人的风险承受能力是动态的。

  通过上述冻结策略完成借款人回款的资金锁定,为后续相关流程开展提供前置保障。

  前面章节提到,为了防止资金被无限拆分而进一步诱发的“四舍五入”精度问题,我们需要做收敛控制。

  最重要的一个收敛节点就是回款收敛,为此我们在“冻结复投引擎”中引入一个“收敛”概念,回款金额与已冻结的金额求和小于阀值时,自动收敛,超过阀值时,激活冻结资金到资金池中等待调用。

  清算执行时,需要关闭还款,因为还款一旦发生,债权价值发生变化,债转交易基础动摇,清算引擎的执行就会出现问题,详见下图:

  产品经理除了会造轮子还需要会修轮子,除了上述12个新增业务主表外,系统原有的相关业务模块也需要一个一个去梳理,哪些受影响,具体的影响点是什么?如何做调整?调整方案是否最优的?

  一个产品经理如果只会造轮子而不知道如何复用、如何下手驾驭老轮子,不是一个好产品经理。

  通过上述8个循环,基本上任何复杂的项目也就在我们面前了,我把这项能力称之为产品经理的“逆向业务解构能力”。

  限于篇幅原因,我们就不不一一列举具体的改造场景和如何改造了,下图仅为后台需要做同步改造的配套点:

  历史交易记录是单式记账法,新的业务场景是按复试记账法,也即每笔交易从借贷两个方向记录;

  历史交易记录的科目分类方式既有词典库分类又有前台逻辑分类(处于用户展示层考虑,把多个子分类用逻辑处理为一个分类,如各种奖励场景);

  历史交易记录中基本无中间状态,新的业务场景有大量的中间交易,处于合规需要,这些中间交易记录需要呈现给用户(前台隐式呈现、后台显式)和支持监管随时审查,也为了方便我们测试和分析业务。

  交易记录调整后必须与用户的财富值、累计收益、代收收益、累计奖励等自洽,不能出现不自洽的情况。

  集合计划为量化投资,交易记录会呈现指数级放大,这样会导致原有的交易记录表出现性能瓶颈。

  本表可区分用户的资金进出明暗两条线:明线展示给用户,暗线不展示给用户;

  本表可查看用户每笔资金发生前、发生后可用余额、资产、冻结等场景的变动值;

  整行黄色区域为借款人数据,出现在交易记录中,会出现配套的投资人数据、平台数据,这里标记为黄色仅供开发人员理解业务逻辑。

  交易流水:取具体的交易流水,虚拟交易见列表定义,原则上复用交易场景的交易id,如转让交易号、复投资金编码,由于同一笔交易是有多个子项构成或者交易对手双方都出现,交易流水可能会重复出现;

  基于交易对手、引入参照系、发生额、变动后金额(参照系的可用余额),即每笔交易发生(真实、虚拟)均涉及两组交易,每个系统都记账,也即记录两笔账;

  进账用+表示,出账用-表示,进出均以参照系为中心,发生额为资金变动额,可用余额为参照系经过变动额(正负方向后)的更新值;

  单一出借累计冻结是指某出借id下面的所有站岗资金,集合理财累计冻结是前述多个“单一出借累计冻结”之和;

  类活期计划类的理财产品除了研发复杂外,流动性管控也是考验平台驾驭能力的一个指标。

  一个优秀的产品经理不光会做功能,还得具备运营思维。我们的集合计划系统在产品架构设计上为运营团队进行了充分的考虑,这种多维度的流动性工具矩阵考虑基本上可以满足当前、潜在任何的流动性危机,除非平台发生恶性挤兑(实际上,我们还提供了最前置的合同层级的约定及配套交易结构置入)。

  这套流动性调控机制在实务中确实发挥了其应有的能力,无论是平台资产慌还是资金慌,无论是老板或运营团队的任何突变想法、还是来自客服组接到的任何不可理喻的客诉。这套流控矩阵都能游刃有余、都无需再动用我们的研发资源进行迭代研发。

  如果上面的内容看起来很枯燥,很烧脑,请看下我给我们客服团队、运营团队、风控团队、老板做的一个培训大纲。

  通过这份大纲,受众能快速了解我们的集合理财系统能达到什么目标?能满足什么场景?相关场景如何操纵?以及一些核心问题是如何处理的,如合规问题、如流动性问题、如满标效率问题、如成本问题等等。

  以上是我们在集合理财项目中的一些实践总结,限于文采拙劣和篇幅原因,未能精细呈现,海涵,欢迎大家交流切磋!

  不同的行业、不同的业务场景、nba直播不同的岗位角色,会面临不同的产品任务。但万变不离其宗,方法相通,只要我们有产品盘感、业务敏感、逻辑严谨、灵通好学、干练带风、狠下功夫,放到哪我们都一样熠熠生辉。

  产品之路很艰辛,也更能锻炼人,尤其是中后台、尤其是“中后台+财务”这种大量底层的项目!在此祝广大产品兄弟姐妹们不辱“产品”之title,做出好产品!

  太细心了,学习学习。另外,问下 里面提到的 策略模型url在哪里看到,求助求助

  感谢鼓励,按合规思路做活期的工程量太大,刚才重新读了一遍,部分地方写的比较晦涩,大家在阅读中如果有疑虑的及时讲,我通过评论补丁的方式予以补充说明,希望能对大家有帮助。

  听到很多言论说在中国程序员是吃青春饭的,那么产品经理呢,也吃青春饭吗?

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。