贷后系统总结经历过的个坑

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