项目简介

最近在国内某家人气互联网金融平台的资产端做一些产品工作，公司相对传统一些，放贷以线下渠道为主。最近公司想铺设线上进件渠道，公司整体在这方面经验不多，所以我来打这个排头兵。这个APP（下称产品A）从7月份立项开始，快速进入开发，8月因故延期，9月上线后几天就遭受了大多数现金贷产品都会遇到的问题——被大量羊毛骗贷群体冲击，因而暂时关闭了进件。后与某著名贷款超市B合作，接通后发现对方推过来的客户质量极差，遂暂停合作。此文写在APP 1.1 版本上线之际，是我对这个产品一个较为全面的复盘。

关于复盘

产品复盘的重要性不言而喻，复盘形式有很多种，条件允许情况下，我认为应该以团队为单位进行复盘。无奈我目前所在的公司这方面氛围差一些，所以我是从个人和公司的角度，进行了一些总结。因为我只是做了一些脱敏处理，一些细节只有内部人员才清楚，所以希望读者主要关注产品的思路和经验总结，感谢阅读。

下为正文：

• 项目：某现金贷A
• 项目时长：2017-7立项 至 2017-10暂停

产品设计阶段：

问题一、立项时没有定义好问题和场景：

产品A所要解决的问题体现在两个方面：

1. 对用户来说，这个产品要解决的问题是现金贷借贷中，下款难，审核慢，期限太长的问题（做的短期）。
2. 对于公司来说，这个产品要解决的问题在于提供一个线上自主进件的渠道，作为整个公司产品向线上转化的一个补充，同时也是短期现金贷产品线的一个分支。

两者之间是有关联的，通过解决用户的问题而解决公司的问题。然而在产品的立项阶段，对于用户这边，并没有定义的很清楚，所谓的下款慢、下款难、流程繁琐的问题是我在1.0上线后才总结出来的，并且随后才设计了对核心流程进行迭代的计划。这让我们在产品初期没有把握到特别清晰的一个方向，做了一些和这件事无关的工作。相应的，我们对典型用户和典型场景定义的也不够。让我们轻视了羊毛党这个破坏性很强的用户群体，这也是造成项目暂停的主要原因。

改进点：

1. 立项时定义好产品的目的、典型用户、典型场景，做好这些工作，可以使产品路径变得清晰，减少很多困扰和无用功。

问题二、产品文档不够完整清晰

开发前从接到任务（周三）到评审需求（周一）一共只给了我四天的产品规划时间，间接导致设计文档比较不达标。

PRD存在一些问题：

1. 流程图不够清晰，
2. 状态机没有全部列出，
3. 有些细则没有写清楚。

设计稿存在一些问题：

1. 不够完整，缺失部分页面
2. 没有设计规范，给开发留下比较大的空间
3. 时间压得紧，甚至是一边出稿一边开发，也就没有返工的余地
4. 没有页面流转

和许多互金公司一样，我们的开发人员分布在两个城市，对于这种两地联合开发的模式，产品文档尤为重要。因为这部分的问题，客户端出现了比较多自由发挥的地方，花了一些时间去统一，最后成品细节也比较粗糙。

改进点：

1. 业务压力大，也要争取时间，磨刀不误砍柴工，
2. 我已经更新了自己的PRD模板，
3. 要让设计师出设计规范。

开发至上线阶段：

问题一、需求变更

开发过程中存在三次需求变更：

1. 白名单：白名单是包括在最初的方案里的，初衷是为了限制前期用户范围。随着讨论的推移，这个功能慢慢被废弃了，但兵荒马乱中我没有及时发现这点，形成了返工。
2. 返修需求则是业务没有考虑清楚，直接沿用了之前的流程，后来风控负责人提出了质疑，认为返修会暴露风控规则。其实返修这个需求，在线下渠道里，是给销售让步的一个需求，线上自主进件里自然就不需要了。一个风控需求，来源却是销售，如果不熟悉系统，多做求证的话，确实难以触及。
3. 做到一半时，风控部门和领导们开会，把贷中模型更换了，但相关信息没有同步到我这边，直到项目末期我才从别的事情问出这个变化来，但是按照既定排期已经无法更改。

改进点：

1. 需求同步问题：需要做到两点：一是在线文档更新，第二要对项目内成员全员通知。第一点很简单，主要要更新及时，并且文档要标出更新了哪里。第二点这次没有达到，就算在QQ群里说了好几次，都会被开发人员忽略掉，要面对面通知才行。目前我想到的一个方法专门建一个通知群，里面不进行任何讨论，也不能进行任何回复，可以做成群主禁言的QQ群那种形式，在上面进行通知，以免消息被讨论淹没。
2. 所有涉及产品的信息都要同步到PM这里来，不是领导开会的时候定一下，程序自己就会改过来的，我们公司可能在这方面经验还不够。

问题二、项目进度不准确

项目出现了一次延期，原因是捆绑了其他业务需求，结果另一个项目延期了。项目叠加提高了项目的交叉风险，原本每个项目成功率80%，捆绑后变成80*80=64%，实际上捆绑还会带来额外的代码合并风险。

在项目排期的时候，所需时间是根据开发和测试进度估计的，后来领导一问，测试进度马上压缩了大半，说明测试时间存在弹性比较大，造成项目进度估计不准确。

改进点：

1. 避免大项目捆绑上线。
2. 产品、开发、测试统一估计缓冲区，避免重复估计。

问题三、因设计产生的bug

1. 在测试阶段发现，有两个功能产生的bug最多，分别是返修和信息缓存。造成这两个功能bug多的原因是这两个功能都在业务主流程中，且逻辑较为复杂，涉及状态多。
2. 发布之后出现了一个比较严重的bug：上线发布时，运维人员配置规则链错误，导致进来的用户走成了旧的规则链。第二天风控反馈后才发现。然而这个问题只有风控那边才会发现。
3. 北京贷后方面也产生了两个比较严重的问题：

• 贷后放款时没有扣下x%的手续费：本次产品中x%的手续费是新增规则，贷后需要部署新规则，对此我和贷后产品有反复确认过，但贷后最终上线时还是没有上这个功能。对此我觉得有两点可以有改进的余地，第一是今后新产品上线时，可以进行全流程测试，其中资金问题走财务报销，这需要北京方面配合。第二是对于关键风险点，如果条件允许，可以做风险备案。
• 产品A没有走会签流程，所以贷后各方面没有被通知到。会签流程只有运营部的人知道，属于运营部的工作漏洞，但会严重影响产品的正常使用。

改进点：

1. 尽量简化产品逻辑，尤其是在产品初期，复杂的功能应尽量做的简洁，不仅利于开发，也利于体验。
2. 在条件允许的情况下，应该避免PRD出现模棱两可的情况。
3. 发布验证的时候，风控最好能在线，尽量要求三方做验证，因为有些问题我们发现不了。
4. 对于这种贷款产品，尽量能验完全流程，把放款也验了，公司提供一下报销。
5. 尽可能地熟悉公司的一些产品上线制度。
6. 对于一些不靠谱的业务部门，如果不能换人，产品需要负担起一些更多的确认工作。

上线后运营阶段：

问题一、羊毛党数量超出估计

上线后用户量超出了我们的估计，产生了以下问题：

1. 第三方查询接口成本太高，用户量剧增后造成总成本过高。
2. 因为低估了用户量，在一期中没有把机审的功能做上去，结果造成审批人手严重不足。
3. 用户质量极差，通过率极低，造成以上两点资源无谓损耗，以至关闭了项目。

改进点：

1. 其实这种问题我不是第一次遇到，只是没想到骗贷产业经过两年发展了这么多，光光是来尝试进件我们就承受不了。之前友商给的信息是上线后最高每天300单左右，但产品A单ios每天都有1000单，后来即使关闭了，第一个月也有两万的ios安装量，骗贷群体庞大。对于这种比较大的风险，可以提前准备好“开关”，或采用类似于“灰度发布”的形式，逐步开放。
2. 很重要的一点，当业务方不熟悉市场，零经验，比较怠惰的时候，我身为比他们有经验的PM，应该主动去调研一下市场，由我来估计相应的风险，并且向业务方说明某些需求的必要性，争取延期。
3. 成本核算很重要。

问题二、产品运营分工比较奇特

公司因为线上经验太少，运营比较缺乏线上运营的意识，所以有些线上运营的工作其实是我这边在做。

1. 一些运营文案上的内容，最好还是要让相应的策划人员来做。
2. 渠道推广的页面设计、文案，最好是由运营来规划。
3. 应用市场的推广应交与ASO人员。应用的分发并不是单纯的往市场上一放那么简单，虽然我通过分发应用，亲身了解了其中的一些小99。但从公司层面来看，我们公司有5款以上的APP，竟然没有半个有ASO经验的人，效率确实比较低，效果也不太好。

改进点：

1. 公司如果要发展线上业务，不是出两款线上产品这么简单的，需要的是整个架构、人员、意识的转变。
2. PM应该尽可能聚焦在产品工作上，先把产品做好了，再考虑去学习了解其他事。

问题三、合作方不给力

合作方B是国内某知名贷款超市，产品A接的第一个渠道，采用的形式是API对接，B的用户在其APP进件后推给我们，后发现接入效果并不好暂停。对接过程中有以下问题：

1. 对典型用户和典型场景没有清晰的描述，这也是后来造成问题的关键。对于B的用户，没有分析它的成份，轻信对方所说的客户质量。结果一运行，客户质量都差得很，根本没法用。
2. 我们可以通过B后台控制进件量，但开发过程中我们（包括技术总监）都忽略了一个问题，B的客户进件的速度非常快，平均每秒能有5单左右，峰值可以达到20单/秒，加上每单的大小又在2M以上，对我们的带宽有不小的压力。这个问题直到上线之后才发现。
3. 对接这种大公司，对方根本不会给你定制，全部都是按照他的规则对接，如果开发前没有排除所有问题，开发到一半发现问题，就会很麻烦。这点我在一开始有意识到，但是有几个问题还是没有估计到，比如第2点说的阻塞带宽。
4. 商务上并没有走的很清楚，其中一条是：B推过来的用户，如果超时了我们没收到，他照样要收钱。这是对我们非常不利的条款，但是直到上线后，我和对方产品沟通时才得知这一点，而业务完全不知道。而且B疑似是脚本自动给我们推客户，所以进来的很快，然后都很差。
5. 开发过程中，发现对方放在网上的文档中心有部分信息是过时的，提高了我们的开发难度。

改进点：

1. 跟A一样的问题，也是跟A一样的结果，立项的时候要对典型用户和典型场景做详细描述。在对接三方时，可以考虑向对方要一些数据来跑模型，确定对方的客户确实能达到通过率。而不是对方说可以就可以，风控口头说可以10%，就能10%，事实上竟然没有半个客户能通过我们的风控审核。
2. 对接渠道时要考虑流量压力和用户行为模式，尤其是那些定制不了的大客户。
3. 设计阶段要确认对方的接口文档是最新的。

问题四、无法快速迭代

在产品立项时，计划是先上一个MVP版本，然后以很高的频率去做迭代。然而上线后由于种种问题项目暂缓、没有专门的开发人员、被渠道占用资源，导致迭代变得极其缓慢，两个月只出了一个版本，下一个版本还要等半年，这种迭代速度对于一个初创产品来说，可以说是废了。

改进点：

1. 公司如果要做一款产品，最好能分配专门的研发人员，就算是一个人也可以，不然产品遇到问题后无法迭代，就等于一个废品，做一个废一个。如果开发人员不够，就不要轻易立项，浪费精力。把有限的开发聚焦在好的资源上，而不是为了做而做。
2. 虽然有人说项目制过时了，但是对于一般的企业来说，还是项目制比较易于执行。
3. PM一定要有主动权，能够把握住产品的节奏，聚焦于三件事以内。如果产品上线初期，就到处拉资源推广，延缓了产品的正常迭代，那如果拉来的资源不顶用呢？产品本身又没有进步，两头落空。这个问题非常广泛地存在于中等公司的初创项目中，必须注意。