去年夏天，我在接手一个客户系统对接项目时，犯了个低级错误——把测试环境的配置参数复制到了生产部署文档里。虽然上线前被同事发现并修正，但这件事让我在项目复盘会上被点名批评。更尴尬的是，翻看之前的项目记录，我发现类似的‘重复踩坑’居然有三次。

那晚我坐在工位上，没急着改PPT，而是打开笔记本，新建了一个叫‘错题本’的文件夹。不是开玩笑，就是学生时代那种错题本——抄下错题、分析原因、写正确解法。我把它搬到了项目管理里。

第一次记录是那次配置错误。我写清楚：问题描述、发生阶段、根本原因（急于赶进度，跳过交叉检查）、补救措施，以及‘标准动作’：今后所有部署文档必须附带《环境差异核对表》，且由另一人签字确认。我把这个文档链接贴进了我们用的蓝点通用管理系统里的‘项目知识库’模块。

两周后，团队成员小李在处理接口超时问题时，顺手查了查‘错题本’，发现三个月前另一个项目遇到过类似情况，原因是缓存未刷新。他直接调出当时的排查路径和脚本，两小时就解决了问题。他在系统里更新了这条记录，补充了新的触发场景。

这让我意识到，‘错题本’不只是个人反思工具，它可以成为团队的风险预警机制。

于是我们开始正式推行。每个项目阶段结束后，我们开15分钟‘错题会’，不追责，只归因。每个人提一个自己或团队遇到的‘差点翻车’的瞬间。问题不一定要大——比如‘客户临时变更需求没走流程’，或是‘邮件沟通导致信息遗漏’。我们把这些录入系统，打上标签：流程类、沟通类、技术类、外部依赖……

蓝点系统的好处是，这些条目可以自定义字段，还能设置关联关系。比如某条‘客户变更未备案’的问题，我们可以关联到‘需求变更流程’这个工作流，并自动触发提醒：若未来项目中有人提交变更申请但未填写影响评估，则系统弹窗提示‘参考错题#203’。

渐渐地，我们的‘错题本’从最初的8条，扩展到47条。有些条目甚至反向推动了流程优化。比如有次连续两个项目都因第三方API响应慢导致延期，我们在错题分析中发现，根本原因是没有提前做压力测试。于是我们在项目启动模板里新增了一项‘第三方服务预检清单’，并设为必填。

最让我意外的是，这个做法改变了团队的沟通氛围。以前出问题，大家第一反应是‘别让领导知道’；现在反而会说‘赶紧记进错题本，免得别人也踩坑’。有一次实习生误删了测试数据，本来吓得不敢吭声，后来主动登记了一条错题，还附上了恢复步骤。我不仅没批评他，还在周会上表扬了这种‘暴露问题’的行为。

我们还玩了个小游戏：每月评选‘最有价值错题’。标准不是问题多严重，而是是否具有预防价值。获奖的错题会被置顶，并生成一张‘风险提示卡’，嵌入相关项目的仪表盘。比如‘未验证用户权限变更导致越权访问’这条，就被做成红色警示条，挂在所有涉及权限调整的任务页面上方。

这套方法没法写进ISO流程手册，也没法量化成KPI，但它实实在在减少了重复性失误。上季度审计时，内审人员翻到我们的错题记录，笑着说：‘你们这是把PDCA循环做成了错题订正本啊。’

其实我没那么高大上的理论，我只是觉得，管理不该总盯着‘最佳实践’，有时候，管好‘常见错误’更见效。毕竟，项目不是靠完美计划推进的，而是靠不断避开过去的坑走出来的。

现在新来的同事入职，我给他们的第一份资料不是SOP手册，而是一份加密链接——打开是过去一年的错题合集。我说：‘先看看我们都蠢过啥，再开始干活。’