去年3月的一个周三下午，我正在公司茶水间泡咖啡，手机突然响了。
"喂，张总，出事了。"电话那头是我们项目经理小李，声音有点抖，"客户说系统上线后数据全乱了，他们财务总监正在发火。"
我手一抖，咖啡洒了一半。
这个项目是给一家连锁餐饮企业做的会员管理系统，合同金额8万。对我们来说不算小单子，当时为了拿下这个客户，我们报价比市场价低了将近一半。客户一开始还担心便宜没好货，我拍着胸脯说："您放心，我们用AI辅助开发，效率高，成本自然能压下来。"
现在好了，打脸来得太快。
我冲到会议室，小李已经满头大汗地在那里等着了。屏幕上显示着客户的系统后台，会员充值记录乱七八糟，有的显示充了1000块，实际到账只有100块，有的干脆重复扣款。
"什么时候发现的？"我问。
"半小时前，客户财务对账的时候。"
"影响多少数据？"
"大概...300多条充值记录。"
我深吸一口气。300多条，意味着可能有几十个会员的账户金额是错的。这在餐饮行业是致命的——会员要是发现自己钱少了，闹起来就是大事。
"先别慌，"我说，"把备份调出来，我们一条条核对。"
那天的场景我现在还记得很清楚。五个人，对着三台电脑，从下午3点干到凌晨1点。眼睛都看花了，外卖吃了两份，咖啡喝了无数杯。
问题的根源其实很简单：我们在做充值功能的时候，有一个边界条件没考虑到——当用户连续快速点击充值按钮时，系统会生成重复订单。测试的时候没人这么干过，谁能想到真有人手这么快？
"这种bug你们测试的时候没发现？"后来客户财务总监在电话里问我，语气很冲。
我老实承认："是我们的疏忽，测试场景覆盖不全。"
"那现在怎么办？我的会员要是发现钱不对，我怎么交代？"
"所有数据我们已经修复完毕，另外，"我顿了顿，"这个项目我们不收钱了。"
电话那头沉默了几秒。
"你说什么？"
"8万块，全额退款。系统您继续用，后续维护我们免费做一年。"
挂掉电话，小李瞪大眼睛看着我："张总，这单我们不赚钱了？"
"不但不赚钱，还倒贴。"我苦笑，"但你说怎么办？让客户把这事捅到行业里，以后谁还敢找我们？"
那天晚上我回到家，老婆已经睡了。我坐在客厅沙发上，盯着天花板发呆。
说实话，那时候我有点怀疑自己。创业第三年，团队从3个人扩到12个，单子越来越多，但问题也越来越多。这次的数据混乱事件，表面是个小bug，实际上暴露的是我们流程上的漏洞——测试不够严谨，上线前的检查清单形同虚设，项目经理对风险的预判能力不足。
我给自己倒了杯酒，开始想：如果重新来过，这件事该怎么避免？
测试用例必须覆盖极端场景。正常人不会连续点十次充值按钮，但系统得防着不正常的人——或者说，得防着所有可能的情况。
上线前要有数据校验机制。关键业务数据，得像银行对账一样，每天自动核对一遍，发现问题立即报警。
最重要的是，团队得建立"假设会出问题"的心态。以前我们太乐观了，总觉得"应该没问题"。现在我知道了，做软件最危险的就是"应该"这两个字。
第二天一早，我把团队召集起来，开了个复盘会。没有批评，没有甩锅，就是一条条梳理：问题怎么发生的、为什么没发现、以后怎么避免。
会后，我让人写了一份《上线检查清单》，整整两页纸，从代码审查到测试用例，从数据备份到回滚方案，事无巨细。每个项目上线前，必须逐条打勾确认。
那个餐饮客户后来成了我们的长期合作伙伴。系统运行到现在两年多了，没再出过问题。他们老板有一次跟我说："张总，当初你们主动退款那件事，我觉得你们靠谱。钱可以慢慢赚，责任心这东西，装不出来。"
我笑了笑，没说话。
其实那次事件之后，我们内部定了个规矩：所有项目，必须预留20%的缓冲时间做测试。宁可进度慢一点，也不能带着隐患上线。这个规矩让我们少赚了一些快钱，但也让我们少踩了很多坑。
做软件开发这行，我越来越觉得，技术能力是一方面，更重要的是对风险的敬畏。客户把业务交给你，是信任你。这份信任，比那几万块钱重要得多。
上个月，那个餐饮客户又找我们做一个新功能，报价的时候我说："这次我们报12万，不议价。"
他们老板愣了一下，然后笑了："行，就12万。你们值这个价。"
你看，有些坑，踩过了才知道是坑。但有些信任，失去了就再也回不来了。
有问题想聊？欢迎在评论区留言，或者私信我。看到都会回。
