这篇文章从项目背景、产品架构、各系统设计思路、设计文档分享这几个部分来讲，在做产品项目的时候，没有完整的项目经验应该怎么去进行思考。
产品新人进入公司，由于经验不足，通常都是负责产品部分模块，很少有机会能接触到从0到1的完整项目，对产品的全局思考会比较欠缺。
刀哥分享一个去年参与的项目，这个项目刀哥全程参与，产品经理也就是刀哥一个人，主要负责产品需求分析、方案设计、项目管理等工作。希望这个案例，能帮助产品新人对产品从0到1的过程有更全面的了解。
此外刀哥还会分享这个项目的设计文档。之前刀哥写过一篇如何写PRD的文章，很多读者希望能提供一个比较完整的案例，这份设计文档就是完整的案例，包括PRD和原型等，希望对大家有帮助。
这个项目是按照MVP（最小可行化产品）理念，实现的第一个版本，功能比较精简，但是完全可以支撑业务。
这篇文章分几个部分来讲：项目背景、产品架构、各系统设计思路、设计文档分享。
一、项目背景
这个项目做的是一款小额信贷产品。
什么是小额信贷？
小额信贷，又叫现金贷，是针对申请人发放的消费类贷款业务，具有方便灵活的借款与还款方式，以及实时审批、快速到账的特性。
从2015年开始，现金贷作为消费金融一个重要的分支在中国开始强势崛起。以一二线城市以线上为主，三四线城市以线下为主。
2017年12月1日，监管部门下发《关于规范整顿“现金贷”业务的通知》，强化年化利率36%的政策红线，提高贷款资质的要求，限制网络小贷牌照发放。
截至2018年1月，现金贷平台融资渠道遭全面封堵，除了银行和ABS产品融资渠道遭封堵，资本市场融资渠道也在收紧。
行业自此进入监管时代，各平台开始探索场景消费、东南亚出海等转型方向。
这个项目也是国内一家公司，为了进军东南亚地区，而开展的。刀哥的职责就是帮这家公司实现产品从0到1，协调业务技术等部门共同完成目标。
1. 产品核心用户
公司希望组建自己的IT团队，搭建一套完整的系统，支撑C端和B端业务，待线上业务跑通以后，开始扩张。
C端用户主要是借款人，核心需求是更便利的借到钱、资金利率低、还款方便、资金合规；
B端用户是公司内部人员，主要分为这几类：
推广：负责在Facebook、Twitter等渠道进行广告投放，对增长负责，希望能监测渠道投放的ROI；
审核：负责对提交借款申请的客户进行资质审核，包括但不限于电话审核、资料审核、社交媒体审核等，对通过率和逾期率等指标负责；
风控：负责信审规则制定，风控策略制定，包括但不限于准入条件、机审规则、评分卡、黑名单等，对逾期率、坏账率等负责，是金融产品中最重要的职能；
财务：审核部门审核通过后，负责请款、放款，对放款量，放款时效等指标负责；
催收：负责对逾期客户进行催收，包括但不限于电催、短信、社交媒体、委托外部催收等，主要对催回率负责；
数据：负责数据统计与分析，定期产出各类报表，给管理层及风控等部门提供决策依据，对数据准确性、时效性等指标负责。
业务模型
二、产品架构
上面我们已经分析了各类角色并梳理了他们的需求，下面我们就设计通过哪些系统/功能来满足这些需求，做产品架构。
产品架构，就是从产品应用层面对产品进行合理的架构，产品架构跟研发的技术架构不一样。
刀哥做产品的逻辑核心分为三步：搭框架、定流程、扣细节。
搭框架就是做产品架构（或者功能架构），遍历出满足各类用户需求的系统（或功能），并按照某种纬度进行合理架构，产出产品架构图或思维导图。
定流程就是梳理不同角色完成同一业务目标的先后顺序和逻辑，主要产出泳道图、活动图、状态机图、时序图等。
扣细节就是完善界面原型，对交互和界面做详细的设计。
根据以上的用户需求，我们整理出以下产品架构图：
这是个MVP产品，比较精简，复杂的信贷系统远远比这个复杂，这个版本也没有接入太多第三方接口，主要也是为了节约开发时间成本，缩短开发周期。
三、各系统设计思路
这个部分，我们来定流程并阐述系统核心功能点，以呈现设计思路。
首先，为了对全流程有个大概认知，我梳理了一个全业务流程图。
按照行业通用的说法，一般将整个业务流程分为这几个核心步骤：
贷前（提交借款申请）
贷中（机审、人工审核）
贷后（放款、还款、催收）
在整个流程中，都围绕『订单』进行流转，在不同阶段，订单的状态不同，结合业务流程，可以梳理出订单的所有状态，产出状态机图。
平铺出来：
审核状态
初始状态（待机审）
机审拒绝（审批拒绝）
机审通过（待分配）
待审核（已分配）
驳回
拒绝
放款状态
审批通过（待放款）
已取消
放款中
放款失败
已放款
还款状态
正常结清
提前结清
逾期结清
逾期
这个步骤非常重要，需要有些什么状态，通常需要和数据、业务、技术等一起商议决定，因为这关系到数据统计和技术实现。
这是订单的状态机图，还有另外一些『单据』也需要梳理状态机，比如还款账单、催收里的案件单，这些后面会说到。
业务的起点是用户通过APP提交一笔借款申请，那我们首先来看下APP。
1. APP
框架：
简化版的产品框架图，表达产品的核心功能模块
核心业务流程：
这个流程只是提交借款申请，所以我把他叫做核心业务流程，其实还有一些分支流程，比如注册、登录、还款等，这些流程在做具体功能设计的时候需要详细设计。但是最开始一定要梳理最核心的业务流程，让大家知道这个产品的大致全貌。
APP的核心设计要点：
注册登录。为了提升注册转化率，尽可能简化注册流程，使用验证码登录，登录后自动注册的方式可以减少用户的操作成本；
提交借款申请。这个步骤需要填写的资料很多，需要做合理的步骤引导和信息模块分类。在这个流程中还需要用户授权获取通讯录、抓取已安装APP；
驳回后重新提交。客户提交资料有误，可能会被打回，需要考虑驳回后再次提交流程；
还款。客户需要方便的查看还款方式，一期仅支持线下还款，不支持线上还款。
前面说了，做产品三大步骤：搭框架、定流程、扣细节，已经做了前2步，第三步就是扣细节，扣细节部分通过原型+PRD呈现，文章最后我会附上APP的原型和PRD，可以作为参考。
2. 审核系统
框架：订单提交成功后，就流转至审核系统，我们来看看审核系统有些什么核心功能。
审核系统是信贷业务里最重要的系统之一，审核系统与风控系统和很多三方数据有着频繁的数据交互，在他们的共同作用下，最大程度预测客户的还款意愿和还款能力。审核系统一定程度上决定着金融产品最重要的逾期、坏账等指标。
在做功能架构时，要尽量详尽，让相关人员看了系统的功能架构图后，能了解系统的全貌。
此外，在写PRD时，主要也是按照功能架构图的功能点进行逐一描述。
核心业务流程：
审核系统核心设计要点：
分配订单。订单由APP提交至审核系统后，需要按照订单类型、提交时间、地区等纬度进行分单，由于前期单量比较收啊，我们只做人工分单，后期单量提升后可考虑自动分单。
审核。订单分配至审核员后，审核员进行审核，审核人员使用频率很高的是审核页面，审核页面信息较多，设计时需要重点考虑，对信息模块和核心操作进行合理布局。审核有通过、拒绝、驳回的选项，通过后订单进入资金系统；拒绝后流程结束；驳回后客户需重新提交进件资料。
生成合同、账单。在审核通过时，需要给客户生成电子合同，由于电子合同里有账单等信息，所有需要『预生成』账单，放款后对账单更新。
国际化。由于审核人员在其他国家，需要对所有文案做国际化处理，支持多国语言，这玩意是个体力活，没找到自动翻译的插件，只能人工处理，相当耗费时间。在界面信息展示时，也要考虑到多国语言显示长度不一致带来的问题。
角色权限。审核系统有三个角色：审核经理、审核组长、审核专员，审核经理负责团队管理，做绩效考评，有分单、查看所有数据的权限；审核组长负责小组的团队管理，绩效考评，有分单、查看小组数据的权限，审核员主要负责审核执行，有查看自己数据，操作审核等权限。由于有数据权限的需求场景，在做权限系统时，不仅设计了菜单权限，还设计了数据权限。
3. 资金系统
框架：
核心业务流程：
资金系统还有一个比较重要的流程是展期。
客户在应还日前，交了展期费用后，可以申请展期，展期后应还日延后一个周期。
展期业务流程：
前面说到还款账单也是一种『单据』，以下是还款账单的状态机图：
资金系统核心设计要点：
放款。符合放款条件的订单，导出后进行线下放款，放款成功后，线上更新订单状态，系统生成客户的还款计划；
修改银行卡。放款前，客户可能会要求修改收款银行卡，需要设计此功能；
还款。客户还款后，会通知客服或财务人员，财务人员需在系统手动更新账单状态，还款有部分还款和结清两种方式。
4. 催收系统
框架：
核心业务流程：
案件状态机：
催收系统核心设计要点：
入案。催收系统核心处理的就是案件，所谓案件，就是一种供催收人员管理的订单类型，案件是在客户发生逾期时产生，案件分为以下几种等级（类型）：
案件分配。产生案件后，有案件分配权的用户将案件分配给催收员；
案件处理。催收员通过电话或社交工具联系客户进行催收，记录催收跟进记录，客户还款后，催收员发起还款申请，审核通过后，更新案件和账单状态；
核销管理。催收员发起还款申请，财务人员对其进行审核，审核通过后，对该笔账单进行核销操作。
以上就是这个项目里核心系统的设计思路，虽然看上去东西并不是特别多，但其实是非常重要，功能框架可能涉及一期的研发工作量，业务流程关系到产品的合理性，一定把这两个东西先考虑清楚，再去设计具体的细节（界面、交互）。
很多产品新人特别喜欢一开始就做原型交互，沉迷于酷炫的效果，这其实是一种本末倒置的做法，没有合理的设计，再酷炫的效果都是徒劳。
俞军老师在他《俞军产品方法论》里提到：
产品是企业与用户进行价值交换的媒介。一个好的产品应该由有三个属性：有效用、有利润、可持续。
非常赞同，好的产品一定是有效用能挣钱并且可以持续的，缺一不可。
所以我们要花更多心思去研究产品的效用、商业价值。
