产品复盘实例:回顾一个互金APP1.0版本踩过的各种坑
文章未作者结合自身实际经验总结,希望能够给产品路上的各位PM带来一些帮助。
项目简介
最近在国内某家人气互联网金融平台的资产端做一些产品工作,公司相对传统一些,放贷以线下渠道为主。最近公司想铺设线上进件渠道,公司整体在这方面经验不多,所以我来打这个排头兵。这个APP(下称产品A)从7月份立项开始,快速进入开发,8月因故延期,9月上线后几天就遭受了大多数现金贷产品都会遇到的问题——被大量羊毛骗贷群体冲击,因而暂时关闭了进件。后与某著名贷款超市B合作,接通后发现对方推过来的客户质量极差,遂暂停合作。此文写在APP 1.1 版本上线之际,是我对这个产品一个较为全面的复盘。
关于复盘
产品复盘的重要性不言而喻,复盘形式有很多种,条件允许情况下,我认为应该以团队为单位进行复盘。无奈我目前所在的公司这方面氛围差一些,所以我是从个人和公司的角度,进行了一些总结。因为我只是做了一些脱敏处理,一些细节只有内部人员才清楚,所以希望读者主要关注产品的思路和经验总结,感谢阅读。
下为正文:
- 项目:某现金贷A
- 项目时长:2017-7立项 至 2017-10暂停
产品设计阶段:
问题一、立项时没有定义好问题和场景:
产品A所要解决的问题体现在两个方面:
- 对用户来说,这个产品要解决的问题是现金贷借贷中,下款难,审核慢,期限太长的问题(做的短期)。
- 对于公司来说,这个产品要解决的问题在于提供一个线上自主进件的渠道,作为整个公司产品向线上转化的一个补充,同时也是短期现金贷产品线的一个分支。
两者之间是有关联的,通过解决用户的问题而解决公司的问题。然而在产品的立项阶段,对于用户这边,并没有定义的很清楚,所谓的下款慢、下款难、流程繁琐的问题是我在1.0上线后才总结出来的,并且随后才设计了对核心流程进行迭代的计划。这让我们在产品初期没有把握到特别清晰的一个方向,做了一些和这件事无关的工作。相应的,我们对典型用户和典型场景定义的也不够。让我们轻视了羊毛党这个破坏性很强的用户群体,这也是造成项目暂停的主要原因。
改进点:
- 立项时定义好产品的目的、典型用户、典型场景,做好这些工作,可以使产品路径变得清晰,减少很多困扰和无用功。
问题二、产品文档不够完整清晰
开发前从接到任务(周三)到评审需求(周一)一共只给了我四天的产品规划时间,间接导致设计文档比较不达标。
PRD存在一些问题:
- 流程图不够清晰,
- 状态机没有全部列出,
- 有些细则没有写清楚。
设计稿存在一些问题:
- 不够完整,缺失部分页面
- 没有设计规范,给开发留下比较大的空间
- 时间压得紧,甚至是一边出稿一边开发,也就没有返工的余地
- 没有页面流转
和许多互金公司一样,我们的开发人员分布在两个城市,对于这种两地联合开发的模式,产品文档尤为重要。因为这部分的问题,客户端出现了比较多自由发挥的地方,花了一些时间去统一,最后成品细节也比较粗糙。
改进点:
- 业务压力大,也要争取时间,磨刀不误砍柴工,
- 我已经更新了自己的PRD模板,
- 要让设计师出设计规范。
开发至上线阶段:
问题一、需求变更
开发过程中存在三次需求变更:
- 白名单:白名单是包括在最初的方案里的,初衷是为了限制前期用户范围。随着讨论的推移,这个功能慢慢被废弃了,但兵荒马乱中我没有及时发现这点,形成了返工。
- 返修需求则是业务没有考虑清楚,直接沿用了之前的流程,后来风控负责人提出了质疑,认为返修会暴露风控规则。其实返修这个需求,在线下渠道里,是给销售让步的一个需求,线上自主进件里自然就不需要了。一个风控需求,来源却是销售,如果不熟悉系统,多做求证的话,确实难以触及。
- 做到一半时,风控部门和领导们开会,把贷中模型更换了,但相关信息没有同步到我这边,直到项目末期我才从别的事情问出这个变化来,但是按照既定排期已经无法更改。
改进点:
- 需求同步问题:需要做到两点:一是在线文档更新,第二要对项目内成员全员通知。第一点很简单,主要要更新及时,并且文档要标出更新了哪里。第二点这次没有达到,就算在QQ群里说了好几次,都会被开发人员忽略掉,要面对面通知才行。目前我想到的一个方法专门建一个通知群,里面不进行任何讨论,也不能进行任何回复,可以做成群主禁言的QQ群那种形式,在上面进行通知,以免消息被讨论淹没。
- 所有涉及产品的信息都要同步到PM这里来,不是领导开会的时候定一下,程序自己就会改过来的,我们公司可能在这方面经验还不够。
问题二、项目进度不准确
项目出现了一次延期,原因是捆绑了其他业务需求,结果另一个项目延期了。项目叠加提高了项目的交叉风险,原本每个项目成功率80%,捆绑后变成80*80=64%,实际上捆绑还会带来额外的代码合并风险。
在项目排期的时候,所需时间是根据开发和测试进度估计的,后来领导一问,测试进度马上压缩了大半,说明测试时间存在弹性比较大,造成项目进度估计不准确。
改进点:
- 避免大项目捆绑上线。
- 产品、开发、测试统一估计缓冲区,避免重复估计。
问题三、因设计产生的bug
- 在测试阶段发现,有两个功能产生的bug最多,分别是返修和信息缓存。造成这两个功能bug多的原因是这两个功能都在业务主流程中,且逻辑较为复杂,涉及状态多。
- 发布之后出现了一个比较严重的bug:上线发布时,运维人员配置规则链错误,导致进来的用户走成了旧的规则链。第二天风控反馈后才发现。然而这个问题只有风控那边才会发现。
- 北京贷后方面也产生了两个比较严重的问题:
- 贷后放款时没有扣下x%的手续费:本次产品中x%的手续费是新增规则,贷后需要部署新规则,对此我和贷后产品有反复确认过,但贷后最终上线时还是没有上这个功能。对此我觉得有两点可以有改进的余地,第一是今后新产品上线时,可以进行全流程测试,其中资金问题走财务报销,这需要北京方面配合。第二是对于关键风险点,如果条件允许,可以做风险备案。
- 产品A没有走会签流程,所以贷后各方面没有被通知到。会签流程只有运营部的人知道,属于运营部的工作漏洞,但会严重影响产品的正常使用。
改进点:
- 尽量简化产品逻辑,尤其是在产品初期,复杂的功能应尽量做的简洁,不仅利于开发,也利于体验。
- 在条件允许的情况下,应该避免PRD出现模棱两可的情况。
- 发布验证的时候,风控最好能在线,尽量要求三方做验证,因为有些问题我们发现不了。
- 对于这种贷款产品,尽量能验完全流程,把放款也验了,公司提供一下报销。
- 尽可能地熟悉公司的一些产品上线制度。
- 对于一些不靠谱的业务部门,如果不能换人,产品需要负担起一些更多的确认工作。
上线后运营阶段:
问题一、羊毛党数量超出估计
上线后用户量超出了我们的估计,产生了以下问题:
- 第三方查询接口成本太高,用户量剧增后造成总成本过高。
- 因为低估了用户量,在一期中没有把机审的功能做上去,结果造成审批人手严重不足。
- 用户质量极差,通过率极低,造成以上两点资源无谓损耗,以至关闭了项目。
改进点:
- 其实这种问题我不是第一次遇到,只是没想到骗贷产业经过两年发展了这么多,光光是来尝试进件我们就承受不了。之前友商给的信息是上线后最高每天300单左右,但产品A单ios每天都有1000单,后来即使关闭了,第一个月也有两万的ios安装量,骗贷群体庞大。对于这种比较大的风险,可以提前准备好“开关”,或采用类似于“灰度发布”的形式,逐步开放。
- 很重要的一点,当业务方不熟悉市场,零经验,比较怠惰的时候,我身为比他们有经验的PM,应该主动去调研一下市场,由我来估计相应的风险,并且向业务方说明某些需求的必要性,争取延期。
- 成本核算很重要。
问题二、产品运营分工比较奇特
公司因为线上经验太少,运营比较缺乏线上运营的意识,所以有些线上运营的工作其实是我这边在做。
- 一些运营文案上的内容,最好还是要让相应的策划人员来做。
- 渠道推广的页面设计、文案,最好是由运营来规划。
- 应用市场的推广应交与ASO人员。应用的分发并不是单纯的往市场上一放那么简单,虽然我通过分发应用,亲身了解了其中的一些小99。但从公司层面来看,我们公司有5款以上的APP,竟然没有半个有ASO经验的人,效率确实比较低,效果也不太好。
改进点:
- 公司如果要发展线上业务,不是出两款线上产品这么简单的,需要的是整个架构、人员、意识的转变。
- PM应该尽可能聚焦在产品工作上,先把产品做好了,再考虑去学习了解其他事。
问题三、合作方不给力
合作方B是国内某知名贷款超市,产品A接的第一个渠道,采用的形式是API对接,B的用户在其APP进件后推给我们,后发现接入效果并不好暂停。对接过程中有以下问题:
- 对典型用户和典型场景没有清晰的描述,这也是后来造成问题的关键。对于B的用户,没有分析它的成份,轻信对方所说的客户质量。结果一运行,客户质量都差得很,根本没法用。
- 我们可以通过B后台控制进件量,但开发过程中我们(包括技术总监)都忽略了一个问题,B的客户进件的速度非常快,平均每秒能有5单左右,峰值可以达到20单/秒,加上每单的大小又在2M以上,对我们的带宽有不小的压力。这个问题直到上线之后才发现。
- 对接这种大公司,对方根本不会给你定制,全部都是按照他的规则对接,如果开发前没有排除所有问题,开发到一半发现问题,就会很麻烦。这点我在一开始有意识到,但是有几个问题还是没有估计到,比如第2点说的阻塞带宽。
- 商务上并没有走的很清楚,其中一条是:B推过来的用户,如果超时了我们没收到,他照样要收钱。这是对我们非常不利的条款,但是直到上线后,我和对方产品沟通时才得知这一点,而业务完全不知道。而且B疑似是脚本自动给我们推客户,所以进来的很快,然后都很差。
- 开发过程中,发现对方放在网上的文档中心有部分信息是过时的,提高了我们的开发难度。
改进点:
- 跟A一样的问题,也是跟A一样的结果,立项的时候要对典型用户和典型场景做详细描述。在对接三方时,可以考虑向对方要一些数据来跑模型,确定对方的客户确实能达到通过率。而不是对方说可以就可以,风控口头说可以10%,就能10%,事实上竟然没有半个客户能通过我们的风控审核。
- 对接渠道时要考虑流量压力和用户行为模式,尤其是那些定制不了的大客户。
- 设计阶段要确认对方的接口文档是最新的。
问题四、无法快速迭代
在产品立项时,计划是先上一个MVP版本,然后以很高的频率去做迭代。然而上线后由于种种问题项目暂缓、没有专门的开发人员、被渠道占用资源,导致迭代变得极其缓慢,两个月只出了一个版本,下一个版本还要等半年,这种迭代速度对于一个初创产品来说,可以说是废了。
改进点:
- 公司如果要做一款产品,最好能分配专门的研发人员,就算是一个人也可以,不然产品遇到问题后无法迭代,就等于一个废品,做一个废一个。如果开发人员不够,就不要轻易立项,浪费精力。把有限的开发聚焦在好的资源上,而不是为了做而做。
- 虽然有人说项目制过时了,但是对于一般的企业来说,还是项目制比较易于执行。
- PM一定要有主动权,能够把握住产品的节奏,聚焦于三件事以内。如果产品上线初期,就到处拉资源推广,延缓了产品的正常迭代,那如果拉来的资源不顶用呢?产品本身又没有进步,两头落空。这个问题非常广泛地存在于中等公司的初创项目中,必须注意。
本文由 @深蓝色萧邦 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自PEXELS,基于CC0协议
现在在对接渠道api求经验呐,加v私聊一下吧
现金贷现在确实火热,但是也很有考究呢