我们团队上个月上线了一个新功能，结果第一天就崩了两次。用户投诉、客服告急、技术连夜回滚。老板没骂人，只问了一句：‘同样的坑，咱们踩过几次了？’

我坐在会议室里，脑子里突然跳出高中数学老师的样子——她总让我们整理‘错题本’，把做错的题抄一遍，写清楚哪里错了、为什么错、正确思路是什么。我当时觉得烦，现在想想，这不就是最朴素的复盘工具吗？

可我们现在的复盘会是怎么开的？一群人坐在一起，PPT翻来翻去，问题列了一堆，最后结论往往是‘沟通不够’‘时间太紧’。听起来都对，但下次还犯。

那天晚上，我决定试试把‘错题本’搬到项目管理里。不是比喻意义上的，而是真的建一个‘项目错题库’。

我打开蓝点通用管理系统，新建了一个数据表，字段很简单：

• 问题描述（一句话说清发生了什么）
• 发生阶段（需求、设计、开发、测试、上线）
• 根本原因（不能写‘人为失误’，要具体到动作，比如‘接口文档未更新导致前端调用错误’）
• 影响范围（多少用户受影响、损失多少时长）
• 补救措施（当时怎么解决的）
• 预防方案（以后怎么避免）
• 关联任务（自动关联到具体的项目或迭代）

第一周，我拉着几个核心成员填了三个历史问题。有个是去年埋下的雷：某个按钮点击后无响应，查了半天发现是测试环境和生产环境的配置参数不一致。当时解决了就完了，没人记。结果这次又因为类似问题出事。

我把这个案例放进错题库，标注‘环境配置校验缺失’，然后在流程管理里加了一条规则：每次发布前，必须上传环境比对截图，并由测试负责人确认。系统自动检查该步骤是否完成，否则无法进入下一环节。

你别说，这种‘把教训变成流程卡点’的做法，比开会强调十遍都管用。

更意外的是，团队开始主动往错题库里填内容了。以前大家怕复盘会变成追责会，现在反而愿意记录——因为这不是为了追究谁，而是为了‘让系统记住’。有个开发小哥甚至开玩笑说：‘我现在犯错都有仪式感了，得先想好怎么写进错题本。’

有次我们讨论一个新功能的设计，有人提出个方案，另一个同事马上说：‘等等，这跟Q2那个失败的需求逻辑很像，要不要查下错题本？’一查，果然，上次就是因为类似的路径分支太多，导致用户流失率上升15%。我们当场调整了设计。

错题本慢慢从‘事故记录’变成了‘决策参考’。它不像OKR那么宏大，也不像看板那样可视化，但它有一种冷峻的真实感——你知道哪些路是真走过、真摔过跤的。

我还做了个小功能：每个月自动生成一份‘错题月报’，不是汇报给领导用的，而是推送给所有成员，标题就叫《本月我们又避开了哪些坑》。数据来自错题库中被触发预防机制的条目。上个月显示，我们成功拦截了4次潜在故障，其中两次直接引用了半年前的案例。

有人说这太琐碎，不像是正经管理方法。可我觉得，管理本来就不是非要高屋建瓴。有时候，一个能记住过去错误的系统，比十个完美计划都靠谱。

前几天新来的实习生问我，能不能把错题本导出来当学习资料。我说当然可以，而且不限格式——PDF、Excel、甚至打印成册都行。她惊讶地说：‘原来我们公司真的有人认真记错题啊？’

我笑了笑，没告诉她，这本子现在已经是项目启动的标配附件了。每次立项，第一件事不是画甘特图，而是先查错题库，看看有没有‘前车之鉴’。

管理工具有很多种，有的追求效率，有的强调协同，而我想要的，是一个能‘记住教训’的系统。它不需要多聪明，只要别让我们重复犯同样的错。