时间:2022-11-15 15:21:53来源:法律常识
转型为产品的两个月内,贷后系统是经手的第一个完整的需求,意义重大且连续爬坑。
接到需求时,知道贷后系统需要实现3个功能——逾期账单查询、销账功能和贷后短信催收功能。对其中的销账功能毫无头绪,所以一开始做的惨不忍睹。现在回想起来觉得做的差的主要原因是:对销账功能涉及到的角色定义不清晰。
销账主要涉及到两个角色:一个是由催收或运营承担的销账申请角色;另一个是由财务承担的销账审批/复核角色。在清楚销账相关的角色后,其实功能实现的思路基本上就有了。
账单需要销账的情况往往是用户还不上钱,经过催收后用户答应还一部分,当然也可能完全不还。在这种情况下,用户不会去考虑自己欠了几期,需要还多少。而是看自己有多少钱,有多少还多少。
这种情况下只有针对单笔账单的销账入口,是无法满足实际需求的。在评审会被无情指出漏洞后,吭哧吭哧埋坑,设计了针对账单和借款单的销账入口。
针对单笔账单的销账:
针对借款单的销账:
在销账的正常流程外,还会出现销账拒绝(财务不认可该笔销账,有可能是还款凭证不清晰等原因)或销账失败(前后端数据不同步,前端已还款,没有及时同步后台重复还款导致销账失败)。
我原先的设计是让账单详情和还款详情中的“销账申请”变为“销账拒绝”/“销账失败”,且在历史销账列表和销账申请列表中产生一笔销账单。但技术在实现的时候,没有做“销账申请”到“销账拒绝”的字样转变。
其实,在被告知的当下我并不认同他的方案,但现在想想又觉得这个更符合正常的思维习惯。会出现这种情况,应该是对常用控件缺乏基本熟悉,乱开脑洞。
其实其他的坑还有很多,但上面的3个坑的影响最大。
作为一只幼年产品,默默挖坑默默填坑,希望在不断进阶的道路上,少给自己和别人挖坑,做个填坑小能手。
本文由 @钱佳婵 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议