入职了一家新公司，在进入新公司接收到的第一个项目，就是重构承保系统～作为连接用户与保险公司的桥梁，承保系统作为整个保险线上系统的核心，掌控着所有的交易进出，作为最基础的系统模块，其重要性不言而喻。
作为产品经理，设计一个扩展性强的的承保管理系统，需要在了解业务基础上，产出整体产品方案。
以下是我的整体设计思路。以下简称为订单系统～
当被接受到一个新项目时，我一般需要用到项目管理的以下5个步骤：
- 项目启动
- 项目需求设计
- 项目计划
- 项目执行和监控
- 项目收尾
这里简单说下这5个步骤：
项目启动：
- 一个项目能够启动，至少是在领导层面得到认可的，在这个阶段需要确认项目背景、项目启动原因、项目目标、项目预期完成时间、项目干系人等内容。
- 并且作为项目负责人，在确认项目后，产出整个项目SOP计划表，包含调研周期、流程设计周期、业务评审时间、技术评审等重要里程碑节点。
- 若有些工作是需要在线下进行，同样需要维护进行每天check进度。
项目需求设计：
- 当完成了“项目启动”阶段后，接下来就是需求设计阶段了。这个作为产品是必备项目，不作过多阐述。
项目计划：需求技术评审后，就进入“项目计划”阶段
- 缓冲期：需求评审后，我一般会给到研发3-4个工作日查看具体需求，这个阶段需要研发设计表结构、以及梳理接口等规则设计
- 工作任务拆解：为了使风险降到最低，研发在拆解具体任务时需细化到最小颗粒度，提供每个子任务的负责人、开始时间、结束时间等。具体呈现的产物一般多为甘特图。
- 技术方案评审：提供排期后，需要技术发起技术方案评审，在此阶段产品可与研发多沟通，确保表结构设计具有扩展性。
- 优先级排序：各种任务会存在关联和依赖关系
- 风险控制：风险控制其实应该是贯穿在项目管理的任何阶段的。提前考虑风险，提前将风险暴露。在我的项目经历中，一般是跟外部团队合作时风险更高。
项目执行和监控：在进入开发阶段后，主要是对项目的过程进行跟踪，需要把控整体项目进度。
- 及时跟进：在开发过程中，有任何影响项目进度问题，都需要产品及时跟进及时解决，包括团队成员请假等问题
- 每日站会：给一个项目制定一个固定的沟通渠道，这样才能让团队成员沟通效率变高
- 项目周报：作为项目负责人，需要对外部汇报整体项目进展。当然周报只是一个形式，若是有其他里程碑节点，同样需要及时汇报给相关方。
项目收尾：这个阶段一般包括“验收”环节和项目上线后的”复盘“环节。
- 验收：包括产品、交互设计等验收，以及上线前运营、销售同事的上线前准备工作
- 复盘：这一个阶段，我一般会分为“项目团队复盘”以及“个人知识体系复盘”。
- “项目团队复盘”主要是与项目、与团队执行情况复盘，对项目的亮点、困难点、不足等归纳总结。对于不足之处，采取弥补机制，并在下一个项目或者迭代需求中验证；
- “个人知识体系复盘”是对于不足之处，反思自己的知识体系是否有空缺，及时更新。
本文目录：
0、前言
1、项目启动：业务现状和背景调研
2、项目需求设计：
订单系统需求设计思路
做重构项目需避免的坑
我在该项目中的收获和遇到的挑战
3、项目计划：按计划行事
4、项目执行和监控：项目过程管理
5、项目收尾：亮点、不足、挑战
本篇先讲述项目启动、以及需求设计思路。
01、项目启动：业务现状和背景调研
因为订单系统属于保险最基本运作的系统，业务人员所参与较小，主要为产品驱动，在此阶段我所做的订单需求调研主要包括以下几部分：
首先先放方法，在做需求调研时，我一般会做战略层和战术层的调研，
战略层：一般主要是针对项目在公司目前阶段的地位、以及相关的目标、背景等调研；
战术层：主要是明确业务流程和业务细节。一般会做流程和角色调研、外围系统接口调研、合规调研等内容。
1、项目背景调研：
为什么重构订单系统？目前的订单系统存在什么问题？期望重构的效果是怎样的？
在此阶段主要了解项目背景、项目价值、项目目标、项目初步预期情况。
一般系统重构的原因不外乎以下几点：
系统维护成本高；系统架构无法满足灵活多变的业务发展；公司组织架构调整，技术语言需调整
那如何评估项目重构的目标？
一般在做目标评估时，我一般采用的方法论有3个：定性描述、定量描述、场景化描述
当无法定量描述时，最好采用场景化描述，避免使用定性描述。
订单系统重构的目标，用场景化的描述是：
减少因技术语言更换而引起业务无法继续开展的问题，保证业务可以继续开展，保持系统稳定性。
想法可能不太成熟，可做探讨～
2、投保出单业务调研：
了解目前都存在什么业务场景？
- 是否有一年期的意外险、医疗险，是否有多年缴的重疾险、寿险？
- 是否有团险业务？——考虑数据表结构，主要是订单表、保单表的对应关系。
- 是否有车险业务？
- 是否全都是C端用户出单的场景？——考虑订单关联的账号体系模块。
- 是否存在B端商户/机构出单的场景？——考虑订单关联的账号体系模块。
- 是否存在代理人业务出单的场景？——考虑订单关联的账号体系模块、以及代理费、推广费等存储展示。
- 是否存在跟单售卖场景？比如携程的跟单售卖
- 是否存在一个产品可多被保人合并支付场景？——考虑数据建模模块，是否拆分成主订单和子订单，以及订单表和被保人表的关系
- 若是存在多被保人合并支付，是否允许其中一个子订单单独支付？——考虑订单系统和支付系统的交互字段
- 是否存在月交分期续期的场景？
- 目前是否已有线上续保业务？若是有续保业务，了解目前每款产品续保的规则、续保后的产品、续保宽限期等内容。
- 是否存在用户预付款不出单的场景？比如用户提前付款，但到店消费后才承保。
- 是否存在线上支付线下出单场景？这种情况一般是因为产品较为特殊，保司不单独提供承保出单接口，只能线下出单。
- 是否有一些及时生效的产品？比如旅行意外险等。这个涉及到保单状态定时任务的规则。
- 了解目前业务日均承保单量？方便技术的性能设计。
- 了解是否有个别产品的应收金额和实收金额不同？—按监管要求，应该是相同的。
3、退保业务调研
- 了解目前所有线上产品所运行的退保方式：
是用户在我们这退保，我们请求保司的退保接口通知；
还是用户在保司退保，保司同步我们退保信息。
是保司退款，还是我们经代公司退款；
若是经代公司退款，则是系统自动退款，还是线下退款给用户，以及结算前后各个产品的退款方式
- 了解目前日均退保单量，方便了解需求优先级。
- 了解若是多被保人合并支付，是否可以允许只退保其中1单？
4、续期业务调研
- 了解历史对接续期产品的续期规则——不同保险公司的续期日不同，这个规则会造成可能用户付款了，但是保单在保司系统失效的问题。
5、续保业务调研
这块因目前公司业务还未涉及到，因此并未在系统设计时考虑～
续保业务其实也是一个很复杂的业务，可以单独拿出来说～
6、外周系统调研
因为订单系统涉及到上游的产品工厂模块、费用政策模块、下游的结算系统模块等。所以这一步主要搞清楚订单系统和其他系统的调用关系。
因技术语言原因，之前的老系统几乎都要重构，所以订单的上游系统就要与新模块产品工厂做调用。
如果其他系统不是自己负责，是其他团队负责，那么一定要明确好各个系统的目前状态、对接人、接口规则、接口提供时间等内容。
作为产品经理，一定要评审前做好调研，评审时给研发讲清楚，后续拉对接群，随时跟进就行。否则等到开发时再与其他团队沟通，风险高、项目延期风险大。
7、老订单系统梳理
做重构，无非就是拆解旧逻辑，定义新逻辑。
因之前我对订单系统较熟悉，所以拆解旧逻辑时，对我的挑战不是很大，我只看了老系统的遗留需求文档、数据库表结构、数据表所有字段、后台管理页面、移动端订单页面后，基本就明白了。
若是对重构的系统不熟悉不了解业务的话，建议还是认真梳理老系统的业务流程图、结构图、交互图、数据实体关系等内容，理清楚后再着手梳理新系统的设计。
8、合规调研
因保险行业属于强监管行业，所以产品在做需求分析和需求设计时，就需要和法务沟通，也可基于历史工作经验判断后沟通～
- 在跟单业务场景中，订单数据是否可以存储在集团其他业务线内，就需要和法务同事沟通；
- 可回溯对订单架构的要求
- 版本管理对订单架构的要求
02、需求设计
1、订单系统整体规划
整体的订单系统因为较复杂，研发资源有限，所以根据业务情况以及研发资源，整体的订单系统拆分成了4个版本进行迭代。
V1.0——主要是API产品投保核保承保+1个历史产品对接，目的是先跑通主流程
V2.0——主要是续期+1个历史续期产品对接，先跑通续期流程
V3.0——主要是退保+历史剩余产品接口对接，跑通退保退款流程
V4.0——主要是历史数据迁移
2、梳理核心业务流程
如何梳理核心业务流程，我一般采用的方法是：先找到核心业务流程，然后再分析业务流程。
如何找到核心业务流程：
- 主流程：核心的服务请求，业务流程的起点一般是响应外部客户的服务请求，以及找到合适的终点是什么
- 分支流程：实际上是属于主业务流程的，但是由于业务独立，不容易整合到同一张流程图中，所以单独拆分了
- 异常流程：比如电商的退货退款，保险的退保退款等
如何分析业务流程：
- 分工：涉及到哪些角色
- 活动：每个角色做什么事情
- 协作：这些活动如何协作起来
- 分支：针对不同情况的处理流程
- 产物关系：会传递什么文档等
那对于在线投保来说，核心主流程肯定是投保了，异常流程为退保，分支流程为续期和续保业务
主流程-投保
投保流程涉及到的角色有5个，其中产品系统是最为复杂的，后续仔细讲下产品系统；支付系统是专门对接第三方支付平台
系统交互顺序图：
在此处有几点需要注意的：
- 核保失败的记录是否需要存入订单表、投保人表、被保人表等相关表，这个需要根据业务情况判断核保失败的订单会有后续追单措施吗？
- 对于保单表的写入时间是否可以提前？具体技术方案可与技术沟通～
- 对于保司核保成功后，会返回投保单号等信息，存储在订单表，还是新建一张表等信息。
- 对于触发承保的时机并不一定是在支付后，如跟单业务预付款业务，用户提前付款，但到店消费后才承保；
异常流程-退保退款
因为退保退款流程较为复杂，所以单独作为一个异常流程梳理
首先说下退保：
我们目前阶段的业务退保场景：用户线下柜台/致电保司退保后，保司将退保信息以API接口/邮件通知我们退保信息，退款由我们中介公司发起。
业务发展趋势：后续若订单增速较快，以及完善用户体验路径，可能会引导用户在我们中介平台操作退保退款。
梳理API对接退保信息流程：
线下邮件通知退保信息流程：
在整个退保场景中，所设计的角色有4个：用户、保司、保险中介公司订单系统、保险中介支付系统。
这里面承担最大角色的还是订单系统
- 退保成功后需要更改保单状态、退保单状态、以及需要在退保单表写入一条退保记录，对于后续做财务结算系统时很方便呀～
- 退款成功后需要更改退款流水表状态、以及主订单表和子订单表状态
- 需要考虑是否支持部分退款；
部分退款有2个形式
1、假设一个主订单关联3个子订单，可以针对其中1个子订单退款，而不是必须全部一起退
2、针对其中一个子订单退款，可以部分退款，而不是退全部保费，比如用户实付保费100元，退款退60元。
分支流程-月缴续期
- 续期使用的是三方支付平台的“委托代扣能力”，因为是高级支持能力，所以需要联系微信支付商务单独邮件申请开通，开通后微信商户平台才可配置相关权限。
- 委托代扣有2种形式，支付中签约和纯签约，对应的流程是不同的
- 续期需考虑在续期日和宽限期内的扣费规则
分支流程-续保
结合公司业务发展情况，我们业务暂时且在后续1年内不会做续保业务，所以这块的分支流程并未做到系统中支持，可放至后期迭代。
虽然目前未做到续保业务，但我在做系统设计时仍然需要考虑到此处的数据流转，表结构的设计等内容，避免后续迭代时，对系统改造成本太高。
2、订单和保单业务属性
订单属性
保单属性
- 订单和保单属性划分
可能会有人疑惑就这个属性的划分。说说我划分的原因
我的观点是只要最终没承保成功，那么其实都不算保单，都只是生成订单。
那对于一些基础保障信息，如保障期限、缴费期限、起期、止期，在生成订单时都会被记录，并且在待支付场景下展示给用户。
所以最终这些都记录在订单层面，生成保单查询时按照关联关系查询即可。
- 订单属性
- 险种信息存储的原因主要是因为用户在移动端投保页面选择的附加责任需存储；若对接的所有产品没有让用户选择附加服务，则险种信息可不在订单系统存储，直接读取订单关联的产品责任即可～
- 下单用户信息中，还会存在B端商户的商户ID、代理人用户UID等信息
- 在订单信息中，对于跟单售卖场景，可能还会存在关联集团主站业务的订单ID.
- 支付信息中，支付平台流水号、以及收费方式、支付方式的字段主要是为了财务对账时使用
- 在保障用户信息中，证件号类型可针对B端商户展示营业执照号等
- 保单属性
- 在保单信息中，需根据业务模式判断是否存储发票信息等字段
另外订单属性的每个字段来源、以及规则都应该在需求评审时给研发讲清楚，涉及到字段信息，此处不详细赘述～
3、系统架构
系统架构
上下游系统
简单画了下订单的系统架构图，方便研发理解～
4、实体业务建模
术业有专攻，我认为产品经理梳理实体建模，是对业务架构的一个抽象归纳，仅供研发参考，并且当研发都是新人不是很懂业务时，产品梳理实体建模可起到重要作用～
- 主订单表和子订单表的关系：主要是考虑对于同一个产品，可支持多被保人投保，并且生成多张保单的情况。不适用于团险～
- 子订单表和投保人表：一个订单对应一个投保人
- 子订单表和被保人表：针对一些特殊产品，比如全家桶产品，为家庭投保，一个订单，一个投保人，多个被保人，一个保单。
- 子订单表和保单表：一个子订单对应一个保单
- 子订单表和支付流水表：支付流水表其实收银台系统也会存储。另外去请求收银台时，是拿主订单表的订单号去请求。续期会存在一个子订单对应多个支付流水～
- 子订单表和续期扣款计划表：针对续期产品，在第一期支付成功后，就会生成其余11期的扣款计划记录。在续期支付成功后，订单并不会变化，只是在支付明细表会有多个记录
- 子订单表和责任明细表：一个子订单会对应多个责任
- 保单表和退保单表：1个保单会生成1个退保单。因为退保的前提肯定会有保单，所以和保单表关联
- 子订单表和退款流水表：退款的前提是有订单，但不一定有保单，如支付成功出单失败，就没有保单记录。需要与子订单表关联～
5、状态机
主流程的状态：
主流程的状态其实都比较简单，是正常的状态。
如前面所说，保单表是在生成保单后才写入的，所以保单表里只有一些保单相关的状态。
每个状态的定义、触发时机、状态变更规则、以及状态变更涉及到定时任务，每个定时任务的执行顺序，以及执行时间～都需要详细给研发讲述清楚。这里列举一个说明下：
已到期：
每天0点10分执行定时任务：将“保障止期”是今天0点的，或者是昨天23:59:59的，且状态是“已过犹豫期”的保单更改状态为“已到期”
因为不同保司返回的保障止期规范不同：有的保司返回的是0点，有的是返回的23:59:59。
待续费：
定义：针对的是分期产品，首月付款后后续进行委托代扣
每天0点15分执行定时任务：将保单的缴费频率是“月交、半年交、季度交”的，将“应缴日期”是今天0点的，且保单状态是“已过犹豫期“的保单更改状态为”待续费”
退保状态：
前面有说，因为我们退保并未做线上
场景是：用户线下柜台/致电保司退保后，保司将退保信息以API接口/邮件通知我们退保信息。
所以退保不会有“退保中”的状态，只会有“退保完成”状态
另外关于“退保”，当有退保数据时，我的建议是新建一张退保单表，在该表里写入一条退保记录，而不是在保单表里写入退保记录。这样做的好处有2点：
- 在后续财务结算对账时能够分辨清楚
- 退保单需要记录退保金额、退保时间、退保原因等相关字段，放在退保单表里不是很兼容。
退款状态：
退款状态比较简单，需订单系统主动发起支付，常规状态～
