停止甩锅式复盘：小团队项目复盘的决策校准模型

引言：复盘不是批斗会

我见过太多小团队开复盘会，开场白是“这个项目哪里出了问题”，半小时后变成“到底是谁没按时交付”。结果呢？要么互相推诿，要么把责任揽到一个人头上，然后散会。下个项目，同样的问题换个马甲又来了。

复盘的本意是“重新审视”，目的是从经验中学习。但人性倾向让我们很容易滑入归因陷阱——找一个责任人，然后觉得问题解决了。实际上，单点归因几乎从来解决不了系统问题。

我踩过的坑

有一年我负责一个内部工具项目，上线后用户反馈很差，很多功能根本没人用。复盘时，第一个反应是“需求调研没做透”。大家开始追责：谁做的用户访谈？谁写的需求文档？气氛越来越僵，一个人默默扛了下来，说“是我的问题”。会议草草结束。

但第二周我单独和每个人聊了一遍，发现真正的瓶颈不是调研质量，而是决策过程：我们在三个关键节点上，都因为时间压力选择了“高层觉得对”的方案，而没有验证假设。复盘时没有人提起这些决策背后的信息与假设，因为大家默认“那是领导拍板的”，所以复盘变成了对执行层的检讨。

那次之后我意识到：复盘真正的对象应该是“决策”，而不是“人”。

决策校准模型：三步法

所谓决策校准，就是审视每个重要决策当时的信息、假设、选项和选择逻辑，然后评估这些环节的质量。目标是让下次类似场景的决策更可靠。

第一步：列出关键决策点

复盘开始时，团队一起把项目周期内所有影响最终结果的关键决策点列出来。不一定很多，通常5-10个就够。从立项、技术选型、排期安排、功能裁剪，到测试策略、上线节奏，每个节点都是一个决策点。

例如：

• 是否接受某个客户的需求变更？
• 技术方案选择A还是B？
• 是否延期一周来修已知Bug？

第二步：对每个决策点填写表格

拿一张白板或文档，每一行记录一个决策点，包含以下字段：

这一步的价值在于：把隐性的假设和理由显性化。很多时候，复盘时发现当时的信息其实并不充足，或者假设根本不成立，只是大家没有公开质疑。

第三步：诊断决策质量

填完表格后，团队一起判断每个决策的质量。不需要打分，而是找问题模式：

• 信息偏差：做决策时是否只有单一信源？有没有忽略关键数据？
• 锚定效应：是否被某个先入为主的数字或方案锚定了？
• 集体盲点：是否所有人都默认某件事成立，但没有验证？
• 时间压力：是否因为deadline而仓促决定，放弃了更好的选项？

以上不是要批判谁，而是识别出团队决策系统的薄弱环节。

一份30分钟复盘会检查清单

对于小团队，开两小时复盘会不现实。我试过一个精简版本：

1. 准备阶段（会前5分钟）：主持人收集关键事件和决策点，列一个清单，发给所有参与者。
2. 会中（25分钟）：
   • 前5分钟：沉默阅读清单，每个人标记2-3个自己认为最重要的决策点。
   • 后20分钟：按“投票”结果，深入讨论票数最高的2-3个决策点。严格按上面的表格走，不跳入解决方案。
3. 会后（5分钟）：每个人写一条行动计划——下次遇到类似场景，我会提醒自己注意什么。

注意：复盘会的主持人最好是项目外的第三方，或者不直接参与项目决策的人，避免情绪卷入。

边界与注意事项

• 决策校准模型不是为了找“正确选项”。当时的选择基于当时的信息，我们不需要事后聪明。我们关心的是：决策流程是否有系统性的漏洞。
• 如果团队信任极低，可以先从“个人复盘笔记”开始，再慢慢过渡到集体复盘。
• 这个模型不适合紧急危机复盘（比如上线重大故障），那种场景需要更快的根本原因分析。

尾声

复盘不是为了修复过去，而是为了校准未来的决策模型。当你把注意力从“谁错了”转移到“哪里可以变得更好”时，团队才会真正开始成长。

PaxLee