去年年中，我们团队接手了一个客户定制开发项目。说是定制，其实就是一堆零散需求堆在一起，客户自己都说不清楚到底要什么。我作为技术主管，头一个月几乎每天都在救火——前端说后端接口没给，后端说产品原型改了三次都没通知，测试提的bug修了又返工。

那段时间，晨会变成了‘甩锅大会’。每个人都在解释为什么不是自己的问题。我试过用甘特图、看板、每日站会，甚至搞了个红黄绿风险标识贴在白板上，但问题还是不断重复出现：同样的部署失败、同样的字段缺失、同样的权限配置遗漏。

直到有一天，我在翻女儿的书包时看到她的数学‘错题本’。每道做错的题都被抄下来，旁边写着错误原因和正确解法。我突然意识到：我们团队缺的不是任务管理工具，而是一个‘错误复盘记录本’。

于是我在蓝点通用管理系统里新建了一个模块，取名叫‘项目错题集’。规则很简单：每次出现问题（无论是开发bug、流程卡顿还是沟通误会），负责人都要填写一条记录，包含四个字段：

• 问题描述（发生了什么）
• 根本原因（为什么发生）
• 影响范围（谁被影响了，耽误了多久）
• 预防措施（下次怎么避免）

最开始大家觉得是额外负担，有人抱怨‘又要填表’。我就带头填。第一周我填了三条：

1. 测试环境数据库未同步导致联调失败 → 原因是发布清单漏了数据脚本 → 措施：在部署 checklist 中增加‘数据变更项确认’
2. 客户说功能不对 → 原来是原型图版本混淆 → 措施：所有需求文档必须标注版本号和更新时间
3. 接口响应超时 → 因为缓存未预热 → 措施：上线后立即执行缓存初始化脚本，并写入运维手册

两周后，有同事主动来找我：‘上次那个缓存问题，我在新项目上线前就提前跑了脚本，果然避免了一次故障。’

更有趣的是，这个‘错题集’慢慢成了新人入职的必读材料。以前新人总犯同样的错，现在他们会在动手前先查‘有没有人踩过坑’。有个实习生甚至根据错题集整理出了一份《高频雷区避坑指南》，还做成小卡片贴在工位上。

我们还加了个小功能：每个错题可以关联到具体的项目、任务或流程节点。比如某条关于‘审批流卡住’的记录，直接链接到OA系统里的审批模板。这样一来，不是单纯记录问题，而是把教训嵌入到了工作流中。

最让我意外的是，客户也喜欢上了这个机制。我们在月度汇报时附上‘本月典型问题与改进’，客户觉得我们特别透明靠谱。有次他们内部会议还引用了我们的错题分析，说‘你们比我们自己还了解我们的流程漏洞’。

其实‘错题本’本质上是一种轻量级的知识沉淀。它不像传统的知识库那么正式，也不需要写长篇大论。一条记录可能就三句话，但它直击痛点，且带有明确的行动指引。关键在于‘可检索’和‘可关联’——如果不能快速找到相关案例，再好的总结也是摆设。

我们用的蓝点通用管理系统在这方面挺省心。它的表单和视图都可以自定义，不需要写代码就能把‘错题集’做成带筛选、搜索和关联关系的数据模块。后来我们还加了自动提醒：当某个新任务涉及曾出过问题的模块时，系统会弹出历史错题提示。

现在我们团队有个不成文的规定：发现问题不批评，但必须进错题集。久而久之，大家不再害怕暴露问题，反而觉得‘又可以记一笔经验了’。有一次部署顺利完成，有同事开玩笑说：‘今天太顺利，都没得记，感觉少点什么。’

最近我把这个做法推广到了其他项目组。财务部门也开始建‘报销错题本’，行政组搞了‘活动筹备常见失误集’。虽然名字听起来有点学生气，但效果是真的好——有些错误，真的只需要被认真记录一次，就再也没发生过。