案例分享，从0到1了解一个完整项目-技术圈

产品新人进入公司，由于经验不足，通常都是负责产品部分模块，很少有机会能接触到从0到1的完整项目，对产品的全局思考会比较欠缺。

刀哥分享一个去年参与的项目，这个项目刀哥全程参与，产品经理也就是刀哥一个人，主要负责产品需求分析、方案设计、项目管理等工作，希望这个案例，能帮助产品新人对产品从0到1的过程有更全面的了解。

此外刀哥还会分享这个项目的设计文档。之前刀哥写过一篇如何写PRD的文章，很多读者希望能提供一个比较完整的案例，这份设计文档就是完整的案例，包括PRD和原型等，希望对大家有帮助（关注公众号『刀哥说』，可以获取完整的设计文档）。

这个项目是按照MVP（最小可行化产品）理念，实现的第一个版本，功能比较精简，但是完全可以支撑业务。

这篇文章分几个部分来讲：项目背景、产品架构、各系统设计思路、设计文档分享。

01. 项目背景

这个项目做的是一款小额信贷产品。

什么是小额信贷？

小额信贷，又叫现金贷，是针对申请人发放的消费类贷款业务，具有方便灵活的借款与还款方式，以及实时审批、快速到账的特性。

从2015年开始，现金贷作为消费金融一个重要的分支在中国开始强势崛起。以一二线城市以线上为主，三四线城市以线下为主。

2017年12月1日，监管部门下发《关于规范整顿“现金贷”业务的通知》，强化年化利率36%的政策红线，提高贷款资质的要求，限制网络小贷牌照发放。

截至2018年1月，现金贷平台融资渠道遭全面封堵，除了银行和ABS产品融资渠道遭封堵，资本市场融资渠道也在收紧。

行业自此进入监管时代，各平台开始探索场景消费、东南亚出海等转型方向。

这个项目也是国内一家公司，为了进军东南亚地区，而开展的。

刀哥的职责就是帮这家公司实现产品从0到1，协调业务技术等部门共同完成目标。

产品核心用户

公司希望组建自己的IT团队，搭建一套完整的系统，支撑C端和B端业务，待线上业务跑通以后，开始扩张。

C端用户主要是借款人，核心需求是更便利的借到钱、资金利率低、还款方便、资金合规；

B端用户是公司内部人员，主要分为这几类：

推广：负责在Facebook、Twitter等渠道进行广告投放，对增长负责，希望能监测渠道投放的ROI；

审核：负责对提交借款申请的客户进行资质审核，包括但不限于电话审核、资料审核、社交媒体审核等，对通过率和逾期率等指标负责；

风控：负责信审规则制定，风控策略制定，包括但不限于准入条件、机审规则、评分卡、黑名单等，对逾期率、坏账率等负责，是金融产品中最重要的职能；

财务：审核部门审核通过后，负责请款、放款，对放款量，放款时效等指标负责；

催收：负责对逾期客户进行催收，包括但不限于电催、短信、社交媒体、委托外部催收等，主要对催回率负责；

数据：负责数据统计与分析，定期产出各类报表，给管理层及风控等部门提供决策依据，对数据准确性、时效性等指标负责；

业务模型

02. 产品架构

上面我们已经分析了各类角色并梳理了他们的需求，下面我们就设计通过哪些系统/功能来满足这些需求，做产品架构。

产品架构，就是从产品应用层面对产品进行合理的架构，产品架构跟研发的技术架构不一样。

刀哥做产品的逻辑核心分为三步：搭框架、定流程、扣细节。

搭框架就是做产品架构（或者功能架构），遍历出满足各类用户需求的系统（或功能），并按照某种纬度进行合理架构，产出产品架构图或思维导图。

定流程就是梳理不同角色完成同一业务目标的先后顺序和逻辑，主要产出泳道图、活动图、状态机图、时序图等。

扣细节就是完善界面原型，对交互和界面做详细的设计。

根据以上的用户需求，我们整理出以下产品架构图：

这是个MVP产品，比较精简，复杂的信贷系统远远比这个复杂，这个版本也没有接入太多第三方接口，主要也是为了节约开发时间成本，缩短开发周期。

03. 各系统设计思路

这个部分，我们来定流程并阐述系统核心功能点，以呈现设计思路。

首先，为了对全流程有个大概认知，我梳理了一个全业务流程图。

按照行业通用的说法，一般将整个业务流程分为这几个核心步骤：

贷前（提交借款申请）
贷中（机审、人工审核）
贷后（放款、还款、催收）

在整个流程中，都围绕『订单』进行流转，在不同阶段，订单的状态不同，结合业务流程，可以梳理出订单的所有状态，产出状态机图。

平铺出来

审核状态

初始状态（待机审）
机审拒绝（审批拒绝）
机审通过（待分配）
待审核（已分配）
驳回
拒绝

放款状态

审批通过（待放款）
已取消
放款中
放款失败
已放款

还款状态

正常结清
提前结清
逾期结清
逾期

这个步骤非常重要，需要有些什么状态，通常需要和数据、业务、技术等一起商议决定，因为这关系到数据统计和技术实现。

这是订单的状态机图，还有另外一些『单据』也需要梳理状态机，比如还款账单、催收里的案件单，这些后面会说到。

业务的起点是用户通过APP提交一笔借款申请，那我们首先来看下APP。

1、APP

框架：

简化版的产品框架图，表达产品的核心功能模块

核心业务流程：

这个流程只是提交借款申请，所以我把他叫做核心业务流程，其实还有一些分支流程，比如注册、登录、还款等，这些流程在做具体功能设计的时候需要详细设计。但是最开始一定要梳理最核心的业务流程，让大家知道这个产品的大致全貌。

APP的核心设计要点：

注册登录。为了提升注册转化率，尽可能简化注册流程，使用验证码登录，登录后自动注册的方式可以减少用户的操作成本；
提交借款申请。这个步骤需要填写的资料很多，需要做合理的步骤引导和信息模块分类。在这个流程中还需要用户授权获取通讯录、抓取已安装APP；
驳回后重新提交。客户提交资料有误，可能会被打回，需要考虑驳回后再次提交流程；
还款。客户需要方便的查看还款方式，一期仅支持线下还款，不支持线上还款。

前面说了，做产品三大步骤：搭框架、定流程、扣细节，已经做了前2步，第三步就是扣细节，扣细节部分通过原型+PRD呈现，文章最后我会附上APP的原型和PRD，可以作为参考。

2、审核系统

框架：

订单提交成功后，就流转至审核系统，我们来看看审核系统有些什么核心功能。

审核系统是信贷业务里最重要的系统之一，审核系统与风控系统和很多三方数据有着频繁的数据交互，在他们的共同作用下，最大程度预测客户的还款意愿和还款能力。审核系统一定程度上决定着金融产品最重要的逾期、坏账等指标。

在做功能架构时，要尽量详尽，让相关人员看了系统的功能架构图后，能了解系统的全貌。

此外，在写PRD时，主要也是按照功能架构图的功能点进行逐一描述。

核心业务流程：

审核系统核心设计要点：

分配订单。订单由APP提交至审核系统后，需要按照订单类型、提交时间、地区等纬度进行分单，由于前期单量比较收啊，我们只做人工分单，后期单量提升后可考虑自动分单。
审核。订单分配至审核员后，审核员进行审核，审核人员使用频率很高的是审核页面，审核页面信息较多，设计时需要重点考虑，对信息模块和核心操作进行合理布局。审核有通过、拒绝、驳回的选项，通过后订单进入资金系统；拒绝后流程结束；驳回后客户需重新提交进件资料。
生成合同、账单。在审核通过时，需要给客户生成电子合同，由于电子合同里有账单等信息，所有需要『预生成』账单，放款后对账单更新。
国际化。由于审核人员在其他国家，需要对所有文案做国际化处理，支持多国语言，这玩意是个体力活，没找到自动翻译的插件，只能人工处理，相当耗费时间。在界面信息展示时，也要考虑到多国语言显示长度不一致带来的问题。
角色权限。审核系统有三个角色：审核经理、审核组长、审核专员，审核经理负责团队管理，做绩效考评，有分单、查看所有数据的权限；审核组长负责小组的团队管理，绩效考评，有分单、查看小组数据的权限，审核员主要负责审核执行，有查看自己数据，操作审核等权限。由于有数据权限的需求场景，在做权限系统时，不仅设计了菜单权限，还设计了数据权限。