去年夏天，我接手了一个总在延期的内部系统升级项目。团队不大，六个人，开发、测试、产品各两位。按理说这种规模的项目不该拖这么久，但每次站会都像在翻旧账：‘这个需求之前不是说不用改吗？’‘上周你明明答应今天给接口文档的。’‘测试环境又挂了？这已经是第三次了。’

我试过各种方法：更详细的甘特图、每日任务打卡、甚至搞了个积分榜奖励准时交付的人。可问题总是换个形式冒出来。直到有天我去妹妹房间找充电器，看见她书桌上摊开的数学错题本。

她高三，老师要求把每次考试做错的题抄下来，写明错误原因——是计算粗心？概念不清？还是审题偏差？然后重做一遍，最后标注‘同类题再错预警’。我盯着那本子看了五分钟，突然意识到：我们团队缺的不是计划能力，而是对‘管理错误’的系统性复盘机制。

第二天晨会，我没提进度，而是拿出一个共享文档，标题就叫《本项目错题集》。我带头写了第一条：

错误事项：用户权限模块返工三次 发生时间：2023-08-14 根本原因：需求评审时未明确‘角色继承’逻辑，开发按经验实现，测试用例覆盖不全 补救措施：补充权限树原型图，增加边界测试场景 预防策略：所有涉及规则判断的需求，必须附流程图或决策表

起初大家觉得尴尬，像在写检讨。我就先从自己开始，记录了一次因我协调不力导致的联调延误。慢慢地，有人开始主动添加条目。测试小李写了一条关于环境配置遗漏的记录，还贴上了检查清单截图；前端老张发现某个交互逻辑反复修改，追溯后发现是产品经理口头传达的变更没留痕，于是他干脆在错题条目里嵌了个录音片段转文字的摘要。

有趣的是，这些记录逐渐变成了新成员的‘避坑指南’。实习生第一天就被安排看最近五条高频错误，比读十页项目文档都管用。我们还设了个‘月度错题王’称号——不是批评，而是表彰那些暴露关键问题的人。毕竟，能被记录下来的错误，说明已经解决了。

三个月后，项目终于上线。复盘会上，技术主管说了一句让我记到现在：‘咱们这个错题本，比任何燃尽图都更能反映真实进展。’

后来我把这套方法推广到其他项目组。有人担心会不会变成‘追责工具’，其实关键在于怎么用。我们的原则是：只记事，不记人；聚焦流程漏洞，而非个人失误。比如同样是接口延迟，如果是某人连续忘记提交代码，那是绩效问题；但如果因为缺乏自动化通知机制导致信息滞后，那就是值得收录的‘错题’。

最近我在蓝点通用管理系统上重建了这个错题库。以前靠Excel和在线文档，分类和检索很麻烦。现在用蓝点的自定义数据模型，我建了‘错误类型’‘影响模块’‘复发频率’几个字段，还能关联到具体的任务单和版本号。最方便的是设置自动提醒——当某个‘错误模式’出现两次以上，系统就会给相关负责人发预警。比如‘测试环境数据库未备份’这类低级错误，一旦触发条件，连实习生态度都严肃起来了。

有次客户参观我们项目管理流程，看到这个动态错题墙，问这是不是某种AI风险预测系统。我笑着说，其实就是把学生时代的笨办法，用数字化工具放大了。真正的管理智慧，有时候不在复杂的算法里，而在敢于正视自己摔过的每一个跟头。

上周整理旧手机，翻到项目初期的会议录音。对比现在的站会记录，最大的变化不是语速变快了，而是大家开口第一句从‘我觉得有问题’变成了‘这情况在错题本第7条有记录，建议这样处理……’