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