我一直相信，管理其实并不总是高大上的事情。很多时候，就是用点小工具、小方法，让团队的日常运作变得顺滑一点。我所在的公司是做SaaS软件开发的，我们团队不大，八个人，从产品到开发、测试、运营都有。最近一年，我尝试用一种“错题本”思维来做项目复盘，效果出乎意料地好，想和大家聊聊这个经验。

“错题本”思维是什么

我最初的灵感来源其实很简单。大家小时候应该都做过错题本吧？就是把做错的题目记下来，再分析为什么错，下次避免犯同样的错。其实在项目管理里，这个思路也能用。

很多公司都在搞“复盘”，但我发现，绝大多数复盘会议最后只是开个会，大家说点问题，写在文档里，过几天就没人再看。问题反复出现，团队士气也被消磨了一点点。于是我决定借用“错题本”的方法，做个小实验。

操作方法：怎样把“错题”用起来

1. 问题收集要具体
   项目结束后，我们会每个人都写下自己在过程中遇到的“坑”——具体到事件、决策、操作，比如“代码合并时未同步新分支导致冲突”、“需求文档未及时同步运营同事”等。不是泛泛而谈，而是要具体到操作细节。

2. 用在线协作工具整理
   我们用Notion建了一个“错题本”数据库，每条错题都可以@相关负责人，还能打标签，比如“需求沟通”、“代码管理”、“测试流程”等，这样方便以后检索。

   

3. 复盘会只看“错题本”
   每次复盘会，就不是大家回忆着聊，而是打开“错题本”，一条条翻。每个问题都要求写上“下次要怎么做”，比如“代码合并流程增加一次review环节”，“需求文档同步设立固定时间点”。

4. 定期回看“历史错题”
   两个月后，我们会专门有一次小型会议，把之前的“错题”拿出来复查一遍：哪些问题还在犯？哪些已经解决？哪些变成了新的流程？

细节经验分享

1. 不要让“错题本”变成“黑名单”

一开始，有人担心写“错题”会不会很丢脸，影响同事关系。我的做法是，强调“错题本”不是用来追责，而是给团队留参考。比如我们规定，错题可以匿名提交，或者用“我们”而不是“某个人”来描述问题。渐渐地，大家发现其实没什么大不了，反而觉得坦白问题很解压。

2. 让“错题”与流程改进直接挂钩

有个很实际的例子：之前我们迭代上线总是因为测试时间不够，导致线上bug频发。写进“错题本”后，我们增加了“功能开发完成后必须预留两天测试”的流程。两个月下来，bug率下降了三分之一。

3. 用标签细分问题领域

有时候问题很零散，难以归类。我们用标签区分“需求”、“开发”、“测试”、“沟通”、“工具”等类别。这样复查的时候，一眼就能看出哪个环节最容易出错，对症下药。

4. 把“错题”做成知识库

慢慢地，我们的“错题本”变成了团队的知识库。新同事入职前，我会让他看一遍“历史错题”，这样很多坑他一开始就能避开。团队流动性带来的经验断层，大大减少。

一些意外的发现

说实话，我原来只是想让大家少踩点坑，没想到还有一些意外收获。

• 团队氛围变得更坦诚了
  以前大家不太愿意承认自己哪里做得不好，现在变得敢说、敢问，因为大家知道这是为团队好，不是找茬。

  

• 流程优化变得有迹可循
  以前流程变动都是靠感觉，现在每次调整都能追溯到具体的“错题”，大家接受度反而更高。

• 自驱力增强
  看到“错题本”里有自己参与解决的问题，大家都有成就感。

小结

“错题本”思维其实很朴素，就是把错误变成团队的共同财富。它不是什么高深的管理学理论，也不需要复杂的软件工具，甚至只要一份共享表格就能做。我觉得，这种方法特别适合小团队，或者正在成长中的团队。很多管理工具和理论，只有真正结合实际、落地到细节，才会有用。

如果你也觉得团队老是“踩同样的坑”，不妨试试“错题本”思维。也许，管理的进步，就是积累下来的小错题，一点一点堆出来的。