我们团队有七个人，做的是企业内部数字化工具的定制开发。听起来挺高大上，其实每天都在处理各种‘小事故’：某个字段没校验、流程节点卡住、用户反馈说按钮找不着……问题不大，但反复出现就让人头疼。

去年年中，我提议搞个‘错题本’——不是给学生用的那种，而是专属于我们项目的错误记录系统。起初大家觉得滑稽，‘我们都工作了，还搞错题本？’但三个月后，这个不起眼的工具成了我们每周例会的核心材料。

错题本不是检讨书，是改进线索库

我参考的是中学时老师让整理数学错题的方式：记录题目、写错过程、分析原因、写下正确解法。我们把它迁移到项目管理中：每出现一次可复现的问题（比如流程审批漏推消息），就在错题本里建一条记录，包含四个字段：

• 问题描述：具体发生了什么？
• 发生场景：哪个模块？谁操作的？
• 根因分析：是逻辑漏洞？配置遗漏？还是沟通偏差？
• 解决方案：怎么改的？后续如何避免？

一开始，大家填得很敷衍。‘消息没推送’写成‘系统抽风’，‘用户不会用’归因为‘培训不够’。后来我带头示范，把一条‘客户提交表单后状态未更新’的问题拆解到代码层：原来是前端提交成功后没触发状态同步接口，而接口本身又缺少失败重试机制。这条记录贴在群里，大家才意识到，‘哦，原来可以挖这么深’。

从‘救火’到‘查隐患’：错题本的进阶用法

半年下来，我们积累了47条错题记录。某次周会上，我突发奇想，把所有记录按‘根因类型’做了分类统计。结果发现，38%的问题出在‘流程配置遗漏’，23%是‘字段权限未设置’，17%为‘用户引导不足’。真正属于代码缺陷的不到15%。

这个数据让我们调整了重点：不再一味追求开发速度，而是加强上线前的配置检查清单（checklist），并为每个新功能配套制作两页纸的‘使用须知’文档。我们还把高频出错的配置项做成模板，在新项目启动时直接复用。

更意外的是，产品经理开始主动翻错题本。她发现，好几个‘用户不会操作’的问题，其实是界面信息层级不合理导致的。于是她在新版本设计中增加了操作引导浮层，并把关键按钮位置标准化。上线后，同类问题下降了七成。

为什么传统复盘会容易流于形式？

我们以前也做项目复盘，但往往是项目结束才开一次会，大家围在一起回忆‘哪里做得不好’。问题在于：记忆模糊、责任模糊、改进措施也模糊。有人说是测试没测出来，测试说需求文档没写清，最后往往变成互相甩锅。

错题本的关键，是把复盘动作‘原子化’——每个问题单独记录、即时归因、明确闭环。它不要求你一次性解决所有问题，而是让你持续积累‘小认知’。就像学数学，做对一道难题可能靠运气，但弄懂一道错题，能力就实实在在长一分。

我们用什么工具做的错题本？

最开始是Excel表格，后来换成了蓝点通用管理系统。选它的原因是：我们可以完全自定义数据结构，把‘错题记录’做成一个独立的数据模型，关联项目、负责人、解决状态等字段。更重要的是，它支持设置自动化提醒——比如某条记录超过三天未关闭，就会自动@责任人。

我们还用它搭了个简单的看板：左侧是待分析问题，中间是根因确认中，右侧是已闭环。每周例会前，系统自动生成本周新增错题报表，大家提前阅读，会上直接讨论改进方案，效率高了很多。

有同事开玩笑说，这系统像是给我们的‘管理bug’打补丁。但它真正的价值，是让改进变得可视、可追踪、可持续。现在新来的成员入职第一周，就会被要求读最近十条错题记录——比看文档更快理解团队的‘坑点地图’。

前几天，有个客户参观我们的工作台，看到错题本看板，问：‘这是你们的质量管理体系？’我笑了笑说：‘算是吧，不过我们管它叫“成长日志”。”