去年我们团队上线了一个客户期待已久的报表功能，结果刚发布三天就被打回重做。不是技术问题，也不是需求理解偏差，而是用户根本找不到入口。

这听起来像个笑话，但当时没人笑得出来。项目周期三个月，前后开了17次需求会，开发自测、联调、UAT一轮不落，最后却栽在一个‘显而易见’的设计上。复盘会上，大家轮流检讨，气氛沉闷。直到我拿出一个橙色封面的笔记本，说：‘咱们先翻翻之前的错题吧。’

这个本子，是我们从教育时代借来的‘错题本思维’——把每一次项目出错当成一道‘错题’，记录下来，分析原因，标注知识点，定期回顾。起初只是我个人的习惯，后来慢慢变成了团队的小传统。

比如那次报表入口的问题，我在错题本里找到了两条‘同类项’：

• 第三条：2023年Q2，订单导出功能藏在三级菜单，用户调研时80%的人没找到；
• 第八条：2023年Q4，新消息提醒图标太小，客服收到37条投诉。

两条问题看似无关，但归因后都指向同一个‘知识盲区’：我们太依赖内部视角，总以为‘逻辑通顺=体验顺畅’。于是我们在错题本旁边加了一条‘解题思路’：所有新功能上线前，必须由非项目成员进行‘盲测’，且不得给予任何引导。

这个做法很简单，但它改变了我们的复盘方式。以前的复盘往往是情绪宣泄或责任划分，而现在更像是‘查漏补缺’。我们不再问‘谁搞砸了’，而是问‘这道题我们以前做过吗’？

错题本里还记了一些更细碎的东西。比如有一次，测试环境配置错了导致回归测试白做，我们在本子里画了个流程图，标出环境检查的三个关键节点，并附上一句提醒：‘别让重复劳动成为惯性’。后来这个节点被做成了一份 checklist，现在每次发版前都会自动弹出提醒。

有人问我，为什么不直接用Jira或飞书文档记？我说，工具不重要，关键是‘错题’这个概念带来的心理暗示。当你把它叫做‘问题记录’，大家本能地想回避；但叫‘错题’，反而有种学生时代的坦然——谁还没做错过题呢？

而且，错题本不需要完美格式。可以手写，可以贴截图，甚至可以画个表情包吐槽。这种低门槛让它更容易坚持。我们现在的错题本已经发展到电子版，用的是一个叫蓝点通用管理系统的工具。它最大的好处是‘像搭积木一样设计表单’，我们可以自定义字段，比如‘错误类型’、‘涉及模块’、‘认知偏差类型’，还能设置自动提醒，每月推送一次‘高频错题TOP5’。

最让我意外的是，有次新来的实习生主动提出要‘借阅错题本’。她说，看这些老问题比读需求文档更快理解团队的‘雷区’。那一刻我觉得，这本子已经不只是纠错工具，它成了某种隐性知识的载体。

最近一次项目评审，有个同事在讨论交互方案时突然说：‘等等，这布局是不是又犯了第12题的错误？’大家一看，还真是——又是把核心操作放在了视觉盲区。我们笑了，但这次是因为避坑成功。

管理不一定要靠制度或KPI推动。有时候，一个小小的认知转换，比如把失败当成可分类、可检索、可练习的‘题目’，就能让团队少走很多弯路。错题本不会让项目变得完美，但它让我们犯的错，至少不那么廉价。