我负责过两个大型电商项目标重构，但把第二个项目记得更清楚。

那时候公司为了赶双 11，临时把全栈团队聚拢在一个临时机房搭建，连热备服务器都没有，结局大促那天服务器直接崩了，数据得用半夜人工同步那会儿。我别看没直接写源码，但我全程盯着，骂了一堆人，最终强迫他们把架构拆散了，买了阿里云的弹性实例集群和异地多活方案。 那时候最头疼的是数据一致性。订单进来后，需求与此同时更新库存、扣减订单、生成快递单，还有通知各个渠道。为了省那点代码量，我们一启动想直接合并数据库表，结局一数据量大，写个锁就卡死半天，就连把交易给插队，用户投诉了。我让他们先用了 Redis 做缓存，把热点库存查缓存，写数据库查数据库；但对于那种不能缓存的库存，比如某些生鲜类的，我们务必保证库存是实时的。 我就让团队把接口拆得更细，库存服务、订单服务、物流服务彻底解耦。每个服务只负责自己的一亩三分地，库存服务只认 Redis，订单服务只认 MySQL。

这样别看代码多了，但系统稳多了。双 11 那几天，我们模拟了凌晨 3 点的数据峰值，发了一百万个订单，别看 Redis 间或会爆，但核心数据库出于加了更多索引和分片，压力小大量。最终系统扛住了，并且比预期快了 40%。 在公司复盘会上，我讲了一整夜事，说“代码不是写出来的，是练出来的”。

那时候我认定，项目管理最大的价值，就是防止团队走弯路，特别是防止在需求和技术博弈中把自己搭进去。我抵制那种为了赶进度，把本该拆分的模块强行拼在一起的活。 记得有一次，客户急迫地要上线一个新功能，说“等下周上线”。我拦住他们，直接冻结了进度，让他们先听我说说风险。我说：“功能做好了，上线了，要是系统挂了，钱呢？用户信吗？目前客户急，是死守功能还是死守数据保险？”那团队炸了锅。最终我提出，先做 MVP（最小可行性产品），模块间先用伪代码或软链接连起来，真正联调的时候发现冲突，再动真格。结局上线半小时内，系统就崩溃了。 那天晚上，我在群里骂了一顿。我说：“你们不是工程师，你们不是产品经理，你们只是去搬砖的。

要是你们能做一个放得下的系统，目前能上线吗？要是目前上线，半年赶明儿还能用吗？”那负责人把脸都红了，他承诺赶明儿每个大功能都要先做个沙盘推演，就算上线后出了事，也要有回滚机制和兜底方案。 从那赶明儿，我教了团队一套新的流程：需求不明确，先画原型；原型不落地，先做 Mock；Mock 不联调，先写接口文档；接不了，再写代码。我就连要求每个新项目，务必用自动化脚本跑一遍数据迁移，跑不通，绝不准上线。 实际上我也见过一些出色的管理案例，比如某互联网大厂，他们把项目拆成 100 个小块，每个块都有独立的 KPI，就连把项目分成 A 和 B 两个并行的版本，保证同步。他们不要求所有人一次性做完所有东西，而是准“并行工程”。他们接纳一局部人做完，一局部人再启动，反正最终目标只有一个：按时按质交付。 我认定项目管理就是要在“人”和“事”之间找平衡。人忒松散，项目就做不起来；事忒复杂，人就得累死。最好的管理，是让人愿意承担风险，与此同时也给了充足的资源去应对风险。就像我那个临时集群的案例，要是我们当初能预见到双 11 会有这种流量，为啥不提前半年规划稳定架构呢？ 目前回头看，我自己那套“先稳后快”、“先软后硬”的方式，别看有时候显得啰嗦，就连有点拖后腿，但换来的是系统的健壮性和团队的信心。在项目里，我不喜爱把话说得忒满，出于有时候话说了，发现不合适，团队就散了。但我信任，只有把这些坑一个个填了，路才能真正走通。 故此，下次看到团队为了赶上线熬夜通宵，结局系统连点都点不动，要么上线当天差点宕机，我得站出来，哪怕语气再冲，也要第一工夫拉回节奏。

毕竟，系统跑得快不快，不是靠激情，是靠对风险的敬畏和对数据的负责。我宁愿自己多操劳一点，也要把底裤都穿厚一点。