踩坑系列：一个状态字段的不合理设计，导致公司损失十多万

一、踩坑背景

公司运营人员从管理后台发现有个用户的账单长时间没有发起扣款，于是把这个用户的问题抛出来。

经过排查，是因为之前有位产品同事上线新的需求的时候，跟账单扣款任务有冲突。账单扣款的发起依赖扣款状态中的“银行卡代扣失败”进行后续业务的流转，而新上线的需求冲突会导致无法给账单的支付状态标记上“银行卡代扣失败”，导致对应的账单没有流转入后续其他扣款业务，最终导致公司被用户薅了十几万羊毛。

二、提出疑问

发现这个问题后，我联想到其他一个曾经发生过的问题，由于注销订单的“注销状态”被后续其他开发增加了新的状态“一键注销成功”，导致我的某些风控规则失效。不禁让我思考，为何总会发生这种需求冲突导致的 BUG。

三、分析原因

顺着这两个问题，我发现问题虽然一个是“状态”字段的判断逻辑不合理导致的；另一个是因为“状态”字段被改修导致的冲突，但是本质上都跟“状态”的定义和设计关系。

比如账单的扣款状态，理应就应该只有“未扣款、扣款中、扣款成功、扣款失败”，而不应该出现“银行卡代扣失败”这种字段。如果没有“银行卡代扣失败”这种字段，那么也不会有后续不合力的判断逻辑。

而注销订单新增“一键注销成功”这种状态更是荒诞，注销状态理应就是“未注销、注销成功、注销失败”，顶多再给一个中间状态“注销中”，“一键”这个业务类型，完全可以起一个“注销类型”字段去记录。

四、验证决策

决策之前再验证一下这种状态的做法其实是不合理之处，再来推演我们应该怎么办。

打比方我们开发一款出行产品，需要根据用户所在地理位置进行推荐内容。假设用户 A 所在地字段一开始就是单纯记录地理位置，如北京。后续迭代需求说要把用户“去到北京的出行方式”也记录一下，用来针对“坐飞机去北京”的用户处理其他需求。此时如果产品和开发都比较小白，直接在“地理位置”字段，遇到“坐飞机去北京”的用户直接更新为“北京-飞机”，那新的需求虽然满足了，但是之前旧功能肯定会有很多冲突。

所以我们在规划需求的时候，对于各种“状态”从产品端最好就思考清楚、定义好、写清楚，产品经理还是要尽可能避免“依赖开发”，有些新人开发甚至是老开发很多时候根本不管那么多，只管实现。而且一般公司也不像大厂，有那么多标准和测试资源，因此很容易出问题。

五、价值落地

踩坑，最怕的就是同一个坑一直没有填平，一直反复踩，还怕你自己不踩了，公司的其他人还在踩。

所以针对这个坑我打算在公司这么做：

开展一场内部分享或研讨，针对产研同学对“状态”字段的定义进行学习交流。

推动产品同学形成作业习惯，但凡遇到“状态”这个问题，需要思考完善之后写清楚，拒绝”依赖开发”，最好形成制度。

推动技术同学形成作业习惯，在迭代的时候对“状态”的修改要慎重，且需求没明确状态的情况下一定要反馈给对应的产品经理并重新讨论定夺。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！