欢迎光临
我们一直在努力

产品复盘实例:回顾一个互金APP1.0版本踩过的各种坑

产品复盘实例:回顾一个互金APP1.0版本踩过的各种坑

项目简介

最近在国内某家人气互联网金融平台的资产端做一些产品工作,公司相对传统一些,放贷以线下渠道为主。最近公司想铺设线上进件渠道,公司整体在这方面经验不多,所以我来打这个排头兵。这个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一定要有主动权,能够把握住产品的节奏,聚焦于三件事以内。如果产品上线初期,就到处拉资源推广,延缓了产品的正常迭代,那如果拉来的资源不顶用呢?产品本身又没有进步,两头落空。这个问题非常广泛地存在于中等公司的初创项目中,必须注意。
赞(0)
未经允许不得转载:电商之家 » 产品复盘实例:回顾一个互金APP1.0版本踩过的各种坑

登录

找回密码

注册