去年年中，我们团队接了一个客户定制系统开发项目。按理说流程很熟了——需求调研、原型确认、开发排期、测试上线。可刚进开发两周，就接连冒出三个‘我以为你懂’的坑：UI设计没考虑深色模式适配，后端接口漏了分页参数，前端调用时还把字段名拼错了。

项目复盘会上，大家低头不语。项目经理老陈没批评谁，反而在白板上画了个表格，标题叫‘已踩坑登记表’。他第一条写：‘未定义字段命名规范，导致前后端对接出错’。然后说：‘以后每个环节发现的问题，不管大小，都记这儿。谁填的，署名，但不追责。目标不是找人背锅，是别再重复摔跤。’

这东西后来被我们戏称为‘项目错题本’。

最开始没人愿意写。写了就像自曝其短。直到测试组的小李填了一条：‘第14条用例执行时环境突然挂了，重搭花两小时——建议每日构建后自动备份镜像’。这条不仅没被骂，反而运维配合加了定时快照。后来有人发现，填一条有效错题，比在会上提十个改进建议都管用。

我们慢慢给它加了点规则：

• 每条必须包含‘场景’‘后果’‘根因’和‘建议动作’；
• 用颜色标记严重程度，红色是阻塞性问题，黄色是效率损耗，绿色是优化机会；
• 每周五下午由轮值同事主持‘错题串讲’，十分钟讲三条，讲完归档。

有次一个新来的后端填了条红标问题：‘API文档更新滞后于代码，查逻辑要翻Git历史’。结果第二天，架构师就拉了个自动化脚本，每次提交代码自动提取注释生成文档快照。他说：‘以前总觉得文档是负担，现在看，它是防错成本最低的投入。’

这本子越积越厚，但我们开会时间反而少了。以前每周站会一半时间在同步‘谁卡在哪’，现在很多人提前看了错题本，自己绕开雷区。更意外的是，大家开始主动暴露小失误了。有一次我把自己误删数据库索引的事也记了上去，本以为会被笑话，结果三天后有两个同事私聊我，说他们也干过类似的事，现在都加了删除前二次确认脚本。

后来我们想把它电子化，试过Excel共享表，总是版本混乱；用过Wiki页面，检索太麻烦；还用过某个敏捷工具的缺陷模块，功能太重，光填个表单就要七步。

最后用了蓝点通用管理系统。关键是它能自定义数据结构——我们建了个‘风险错题’模型，字段包括项目阶段、问题类型、影响模块、解决状态，还能关联附件截图或日志片段。最贴心的是支持‘模板快速录入’，手机上三步就能提交一条。我们还设了个看板，按‘待分析’‘已验证方案’‘已闭环’分类，一目了然。

有次客户临时变更需求，前端组长直接从错题库里调出半年前类似变更引发的兼容性问题记录，附上了当时的修复方案，说服客户多给了两天缓冲期。他说：‘这比拍胸脯保证“没问题”靠谱多了。’

现在新成员入职，HR不再只发制度手册，还会递上一份打印装订的《近一年高频错题精选》。有次实习生看完感慨：‘原来犯错也能变成团队资产？’

其实我们也不是鼓励犯错，而是不想让同一个错误消耗团队两次注意力。管理的本质，有时候不是防止跌倒，而是让每一次跌倒都留下路标。

最近我们把错题本延伸到了流程设计环节。每次启动新项目，先打开历史库，花半小时‘预演失败’：如果这个模块权限设计不合理，会引发什么连锁反应？如果第三方接口响应慢，有没有降级预案？这种‘负面脑暴’一开始大家放不开，现在反倒成了最有产出的会议之一。

上周我看到测试组新建了一条：‘连续三次部署未触发告警，怀疑监控阈值设置不合理’。提交人是实习生。旁边已经有人评论：‘建议增加异常流量模拟测试任务。’

这本子还在长。