文章未作者结合自身实际经验总结，希望能够给产品路上的各位PM带来一些帮助。
文章未作者结合自身实际经验总结，希望能够给产品路上的各位PM带来一些帮助。
项目简介
最近在国内某家人气互联网金融平台的资产端做一些产品工作，公司相对传统一些，放贷以线下渠道为主。最近公司想铺设线上进件渠道，公司整体在这方面经验不多，所以我来打这个排头兵。这个APP（下称产品A）从7月份立项开始，快速进入开发，8月因故延期，9月上线后几天就遭受了大多数现金贷产品都会遇到的问题——被大量羊毛骗贷群体冲击，因而暂时关闭了进件。后与某著名贷款超市B合作，接通后发现对方推过来的客户质量极差，遂暂停合作。此文写在APP 1.1 版本上线之际，是我对这个产品一个较为全面的复盘。
关于复盘
产品复盘的重要性不言而喻，复盘形式有很多种，条件允许情况下，我认为应该以团队为单位进行复盘。无奈我目前所在的公司这方面氛围差一些，所以我是从个人和公司的角度，进行了一些总结。因为我只是做了一些脱敏处理，一些细节只有内部人员才清楚，所以希望读者主要关注产品的思路和经验总结，感谢阅读。
下为正文：
- 项目：某现金贷A
- 项目时长：2017-7立项 至 2017-10暂停
产品A所要解决的问题体现在两个方面：
两者之间是有关联的，通过解决用户的问题而解决公司的问题。然而在产品的立项阶段，对于用户这边，并没有定义的很清楚，所谓的下款慢、下款难、流程繁琐的问题是我在1.0上线后才总结出来的，并且随后才设计了对核心流程进行迭代的计划。这让我们在产品初期没有把握到特别清晰的一个方向，做了一些和这件事无关的工作。相应的，我们对典型用户和典型场景定义的也不够。让我们轻视了羊毛党这个破坏性很强的用户群体，这也是造成项目暂停的主要原因。
改进点：
开发前从接到任务（周三）到评审需求（周一）一共只给了我四天的产品规划时间，间接导致设计文档比较不达标。
PRD存在一些问题：
设计稿存在一些问题：
和许多互金公司一样，我们的开发人员分布在两个城市，对于这种两地联合开发的模式，产品文档尤为重要。因为这部分的问题，客户端出现了比较多自由发挥的地方，花了一些时间去统一，最后成品细节也比较粗糙。
改进点：
开发过程中存在三次需求变更：
改进点：
项目出现了一次延期，原因是捆绑了其他业务需求，结果另一个项目延期了。项目叠加提高了项目的交叉风险，原本每个项目成功率80%，捆绑后变成80*80=64%，实际上捆绑还会带来额外的代码合并风险。
在项目排期的时候，所需时间是根据开发和测试进度估计的，后来领导一问，测试进度马上压缩了大半，说明测试时间存在弹性比较大，造成项目进度估计不准确。
改进点：
- 贷后放款时没有扣下x%的手续费：本次产品中x%的手续费是新增规则，贷后需要部署新规则，对此我和贷后产品有反复确认过，但贷后最终上线时还是没有上这个功能。对此我觉得有两点可以有改进的余地，第一是今后新产品上线时，可以进行全流程测试，其中资金问题走财务报销，这需要北京方面配合。第二是对于关键风险点，如果条件允许，可以做风险备案。
- 产品A没有走会签流程，所以贷后各方面没有被通知到。会签流程只有运营部的人知道，属于运营部的工作漏洞，但会严重影响产品的正常使用。
改进点：
上线后用户量超出了我们的估计，产生了以下问题：
改进点：
公司因为线上经验太少，运营比较缺乏线上运营的意识，所以有些线上运营的工作其实是我这边在做。
改进点：
合作方B是国内某知名贷款超市，产品A接的第一个渠道，采用的形式是API对接，B的用户在其APP进件后推给我们，后发现接入效果并不好暂停。对接过程中有以下问题：
改进点：
在产品立项时，计划是先上一个MVP版本，然后以很高的频率去做迭代。然而上线后由于种种问题项目暂缓、没有专门的开发人员、被渠道占用资源，导致迭代变得极其缓慢，两个月只出了一个版本，下一个版本还要等半年，这种迭代速度对于一个初创产品来说，可以说是废了。
改进点：
本文由 @深蓝色萧邦 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自PEXELS,基于CC0协议返回搜狐，查看更多
责任编辑：