去年夏天，我们部门接了一个客户定制系统开发项目。时间紧，需求变更是家常便饭，开发过程中各种问题层出不穷。每次上线后开复盘会，大家坐在一起七嘴八舌地说‘上次那个接口超时没人跟进’‘测试环境配置又错了’，可说归说，下一次还是照样踩坑。

我作为项目负责人，实在受不了这种‘重复交学费’的节奏。正好那段时间我家孩子上小学，老师让每个学生准备一个‘错题本’，把做错的题目抄下来，分析原因，定期复习。我突然就想：能不能给项目也建个‘错题本’？

一开始我只是在飞书文档里新建了个表格，取名叫《项目问题错题集》。每出现一次生产问题、流程卡点或沟通失误，我就拉相关同事一起填三栏内容：

• 问题描述（发生了什么）
• 根因分析（为什么发生）
• 改进措施（下次怎么避免）

比如有一次，用户反馈导出功能失败。排查发现是数据库连接池被耗尽。我们在错题本里记录：

问题：导出任务并发过高导致DB连接池满，服务不可用 根因：未对批量操作做限流，监控告警阈值设置不合理 改进：增加导出任务队列+限流策略；调整Prometheus连接数告警阈值

这看起来像是普通的事故记录，但关键在于——我们开始定期翻这个本子。每周五下午，我会花20分钟带着团队快速过一遍最近新增的条目。慢慢地，大家养成了习惯：遇到问题第一反应不是甩锅，而是问‘这个要不要记到错题本里？’

更意外的是，这个做法还改变了团队的协作氛围。以前复盘会容易变成‘批斗大会’，现在因为错题本是中立的记录工具，大家更愿意主动暴露问题。QA小李甚至提议：‘咱们能不能把常见错误做成检查清单，集成到提测流程里？’

于是我们真的做了个‘上线前自查清单’，包含12项高频雷区，比如缓存预热是否完成、新接口是否有降级方案等。后来新人入职，我们也会让他先看三个月内的错题本，比读文档直观多了。

但很快我们遇到了瓶颈：文档里的错题本越来越长，查找困难，也无法和实际工作流打通。比如某条改进措施写着‘增加限流’，但没人跟踪这个任务是否落地。我想把它变成一个真正的管理闭环，而不仅仅是个记录本。

这时候我接触到了蓝点通用管理系统。它最打动我的一点是：你可以完全自定义数据结构和流程，不需要写代码。于是我用它重建了我们的错题管理体系。

我在蓝点里创建了一个‘项目问题库’应用，每条记录就是一个‘错题’，字段包括问题类型、责任人、状态（待分析/已改进/已验证）、关联项目等。更重要的是，我可以为每条记录添加‘待办任务’，比如‘修改Nginx超时配置’，并指派给运维同事，设置截止日期。

最实用的是自动化规则。当一个问题标记为‘已改进’后，系统会自动在两周后创建一个‘效果验证’任务，确认该问题是否真的没再发生。如果同一类问题重复出现三次，就会触发升级提醒，发给技术主管。

我还把错题本和我们的企业微信打通。每次新增高优先级问题，自动推送通知；每周一早上，系统会生成一份‘本周需关注的历史问题’摘要，推送给全体成员。

用了三个月后，我们团队的线上事故率下降了67%，而复盘会议时间缩短了一半——因为很多问题在错题系统里已经闭环了，会上只需聚焦新情况。

其实‘错题本’本质上是一种组织记忆的沉淀机制。很多团队不是没有复盘，而是复盘完就结束了，知识留在了会议室，没走进日常操作。而当我们用结构化的方式持续积累这些‘失败经验’，它们反而成了最有价值的资产。

现在其他部门也开始来取经。上周行政部还问我：‘你们能不能做个“活动筹备错题本”？上次年会签到排长队的问题，可不能再犯了。’

有时候管理的突破，不在于用了多先进的方法论，而是把一个朴素的想法，认真地做深、做透。