去年夏天，我负责公司一款新功能模块的上线。团队不大，五个人，但节奏紧、需求变更多，光是版本迭代就改了十几稿。每次评审会上，开发同事都会问：‘这个逻辑之前不是定好了吗？怎么又变了？’

说实话，我也懵。不是不想记，而是事情太多，会议纪要、口头沟通、临时调整……信息像沙子一样从指缝漏走。直到有次上线前夜，我们发现一个关键接口调用方式和设计文档对不上，查了一晚上才发现是两周前一次临时讨论中口头改的，没人记录。

那次事故后，我决定换个方式记问题。我不是老师，但突然想到我女儿上小学时老师让她们建‘数学错题本’——把做错的题抄下来，写清错因和正确解法，定期翻看。我在想：项目里反复出的问题，能不能也这么管？

于是，我建了个简单的表格，取名‘产品错题本’。每遇到一次因沟通不清、理解偏差或流程疏漏导致的问题，就当成一道‘错题’录入。字段也不复杂：问题描述、发生场景、根本原因、影响范围、解决方案，外加一栏‘如何避免再犯’。

刚开始大家觉得有点傻，像在写检讨。但我没强推，只是每次例会开头花三分钟分享一条‘错题’。比如有一次测试报了个bug，说是‘用户提交后状态没更新’，查到最后发现是前端缓存没清，而根本原因是需求文档里没写清楚状态刷新机制。这条就被记了下来，后续所有涉及状态变更的需求，我都主动补上一句‘是否需要实时刷新？缓存策略是什么？’

慢慢地，团队开始主动往‘错题本’里填内容。开发小李有一次甚至说：‘这周我发现两个地方都用了同样的错误判断逻辑，还好翻了下错题本，不然又要重来。’

更意外的是，这个本子还成了新人入职的‘避坑指南’。以前带新人，总得靠口述‘这个模块以前出过什么问题’，现在直接甩个链接过去，他们自己就能看明白哪些坑已经被踩过了。

后来我把这个做法分享给其他项目经理，有人笑称这是‘反向知识管理’——不记成功经验，专记失败教训。但我觉得，恰恰是这些‘错题’最有价值。成功可能有运气成分，但失败往往暴露的是系统性漏洞。

其实这个‘错题本’本身并不稀奇，本质上就是一个结构化的问题日志。但它之所以能起作用，是因为我们把它当成了一个可学习、可检索、可迭代的工具，而不是事后追责的台账。

说到这里，不得不提我们后来用的工具。最开始是在Excel里维护，后来转到在线协作文档，但总归不够灵活。比如想按‘前端问题’或‘需求变更类’分类查看，就得手动筛选；想关联到某个具体任务，也得靠复制粘贴。

直到我试了蓝点通用管理系统。它是个无代码平台，可以自定义数据结构和流程。我把‘错题本’搬了进去，每个‘错题’变成一条数据记录，字段可以自由增减，还能关联到具体的项目、任务甚至负责人。最让我满意的是它的视图功能：我可以创建不同的看板，比如按‘问题类型’分组的表格视图，或者按‘解决进度’排列的看板视图。甚至设置了自动提醒，每当新增一条‘高频错误类型’，就会通知相关成员。

有次市场部同事看到我们的错题本，开玩笑说：‘你们这是把项目做成了题库啊。’我说：‘没错，而且我们目标是让这个题库越来越厚，但新题越来越少。’

现在，这个‘错题本’已经成了我们团队的标准配置。不只是产品，连技术架构评审和运营活动复盘也开始用类似的模板。它不解决所有问题，但至少让我们不再重复掉进同一个坑里。

有时候我觉得，管理的本质不是追求完美流程，而是建立一种‘容错—学习—改进’的机制。就像学生时代那本皱巴巴的错题本，真正教会我们的，从来不是标准答案，而是‘我为什么会错’。