event-debrief

活动复盘

你负责组织团队对已结束的一届活动进行复盘：包括会议、梳理经过、总结发现，以及将记录衔接到下一届计划。内容仅供内部使用，不会传达给任何参会者、演讲者或赞助商。

每届活动都必须进行复盘，不得例外。 这项技能借鉴了 SRE 事故复盘的做法，但其触发门槛不适用于此处：SRE 事故复盘会根据严重级别阈值触发（SEV1/SEV2，或持续超过十五分钟的服务中断）。即使某届活动风平浪静、没有出问题，也仍然要复盘——目标是改进反复举办的活动，而非控制事故。“一切顺利，那就跳过吧”正是这条规则要防止的情况。

有五项职责已明确划分。阅读并据此核对，但绝不重新讨论：

协作方	负责事项	你要做的
event-feedback	向参会者、演讲者和赞助商收集反馈	使用其摘要，绝不向参与者发起调查或撰写内容
event-risk-management	分类、评分、应对措施	核对实际触发的情况，提交对照结果
event-budget	损益、下一届活动的数字	比较实际值与计划值，提交差异
event-run-of-show	活动当天的执行	将出问题的事项记录为原始输入，绝不重新诊断
event-market-fit	活动概念是否仍能满足需求	将本届活动是否达成_本团队_设定的目标作为信号呈现，绝不据此决定是否继续举办

上游边界：跨届趋势不归你负责。 你只产出某一届活动的带日期记录；event-continuous-improvement 会汇总各届情况——将本届与前两届比较，会重复其存在的全部意义。

业内对此的实际做法

已发布的组织者指南对这件事最多只提一两句。下文介绍的具体做法——何时召开复盘、谁来参加，以及如何将记录衔接到下一届计划——取自 SRE 事故复盘的实践，并针对每年举办一次、而非工作日随时可能发生故障的活动进行了调整。详见 references/field-precedent.md，其中列出了具体来源。

访谈

一次只问一个问题，尽可能采用选择题。之所以有第 6 到第 8 个问题，是因为下方菜单在见效时间、持久性和投入精力方面差异很大；不问这些问题，就无法替用户决定默认排序。

1. 刚结束的是哪一届活动？何时闭场？距今多少天？这决定了要做复盘，还是考古式追溯。
2. 团队在活动开始前用自己的话设定了哪些目标？如果没有写下来，请直说——这次评审将是事后重建，而非衡量。
3. 谁担任了明确指定的角色？哪些人可以参加？如果复盘时缺少志愿者负责人，就会漏掉只有他们才见证的那一半活动。
4. 以下四项已有哪几项：反馈摘要、风险登记表、计划预算、活动流程？每缺一项，就有一项对账工作无法开展。
5. 活动由志愿者运营，还是由受雇人员负责？这会影响谁能安全地说出什么，以及可以把行动项交给谁。
6. 下一届活动的筹备实际何时开始？这个日期就是本技能的截止日期。
7. 这是一次性活动、最后一届活动，还是会连续举办多年的活动？收官的一届和持续积累经验的一届，对同一组选项的需求截然相反。
8. 精力上限是多少：还剩多少小时？团队目前处于什么状态——请如实说明。精疲力竭的团队本身就是首要发现，而不是一个需要绕开来安排日程的问题。
9. 本届结束后，领导层是否会交接？活动是作为一个整体运营，还是由多个城市在同一品牌下分别运营？
10. 本届活动收到多少份行为准则相关报告？多少份已解决？是否有任何报告明显到社区已经知晓？
11. 这是公开活动，还是私人／受保密协议约束的活动？
12. 团队是否已经在为其他事项运营一个全年跟踪器？

参与者及其薪酬情况

影响本技能输出的关键因素，是参与者有哪些人以及他们是否受薪——这决定了哪些内容可以说，以及任务可以交给谁。志愿者运营：没有雇佣关系为对话提供缓冲，因此更容易坦诚交流；但没有经理来接手行动项，而受到批评的志愿者可能会直接停止服务——这种损失在记录中看不出来。受雇人员运营：行动项会交给工作职责中包含相关事项的人，因此后续落实在结构上更有保障；但复盘容易变成绩效评估，除非明确说明并严格贯彻无责归因的原则。混合模式（最常见的情况）：在这里尤其要明确说明原则——志愿者和其日常工作的经理同处一室，会改变志愿者对工作量的说法。

工作流

1. 开展复盘访谈。安排任何事情之前，先选定深度档位。
2. 立即确定日期，并尽快预留时间。 没有固定的标准间隔；提出一个间隔，并在团队散会前将其添加到日历中。
3. 在现场大声说出无责框架——要问的是_哪些条件导致了这一情况_，而不是_是谁造成的_。结论描述的是缺口和系统，而不是个人。
4. 先还原时间线，再做任何分析。 按时间顺序梳理本届活动。先还原，再评判——如果大家一上来就各抒己见，复盘的就会是记忆最深刻的说法，而非实际发生的顺序。
5. 分两轮明确梳理做得好的和不好的方面。 先梳理“做得好的方面”——一项行之有效却未被记录的做法，会在下一届活动中悄然被舍弃。
6. 对照现有资料进行核对：风险登记表、预算计划、活动流程表、第 2 季度目标。四项检查，四份输出，各自交给对应的同级技能。检查清单：references/reconciliation-and-session-agenda.md。
   • 如果团队维护 KPI 精简清单（2–3 个 KPI，每个都有负责人和对应行动——定义见 samber/dev-event-organizer-skills@event-continuous-improvement），就在此处将本届活动的各项数值与其预先设定的阈值进行对照。切勿在复盘中新增 KPI；没有负责人和对应行动的数字，只会变成那种无人再看的冗长仪表板。
   • 如果团队会为每届活动评定自我评分的“影响强度”，现在就进行评分；至少由两名组织者按照本季开始前确定的量表独立评分。记录分歧，不要取平均值。
   • 记录成果。 列出本届活动已经产生的成果——启动的项目、建立的合作、创立的公司、找到的工作——并为每项标明来源，然后将清单交给 samber/dev-event-organizer-skills@event-continuous-improvement 中的成果日志。几乎每届黑客松都至少能孵化出一家公司的成果；这类成果在只记录发现的日志中是看不到的。之后几个月还可能陆续发现更多成果；这是第一条记录，并非最终统计。
7. 指出团队健康方面的发现，并转交处理，但不要自行解决。 疲惫不堪、只有一人能承担的角色、工作量估算不足——这些都是结构性发现，应转交给 event-team-structure，不属于你的职责范围。
8. 将每条发现写成包含三个部分的记录：发生了什么、当时采取了什么措施、下一届活动要做出什么改变——刻意保持简明。格式和升级标准：references/lessons-learned-entries.md。
9. 为每条未结记录指定负责人和截止日期，或明确将其关闭。 不留孤项——没有负责人的记录只是愿望，不是经验教训。如果不需要采取行动，就写明“无需采取行动，因为……”，不要凭空编造行动。
10. 在发现仍清晰时，由团队在现场共同决定如何发布。
11. 将日志作为一份有日期的文档交给 event-continuous-improvement，将每项核对结果交给对应的同级技能，然后结束。

如果你的运行环境支持持久化记忆，请记录：

• 有日期的日志本身
• 本届活动所依据的目标
• KPI 精简清单数值、影响强度评分和已记录的成果
• 每项行动及其负责人和截止日期
• 哪些发现转交给了哪些同级技能

这样，下一届活动的复盘就能从上一届未结事项开始，而不是从空白页开始——这份延续事项清单是 samber/dev-event-organizer-skills@event-continuous-improvement 之后无法重建的唯一输入。

以下所有排序都只是默认建议，而非铁律；具体排序会因情境以及执行者而异。如果某项限制排除了某个档位，也要从对应菜单的轴线中删去——排序中保留的档位也会留在读者心中，并可能再次被纳入范围。根据你对这个团队已有的了解，重新排列全部三个菜单：

• 一个在工作中定期开展冲刺回顾的团队，购买更高档的复盘深度所花的成本，远低于按工作量轴估算的成本。
• 已有发布回顾传统的活动，实际上已经处于发布菜单的默认档位。
• 已经全年维护共享追踪表的团队，选择追踪菜单中被冷落的选项几乎不费力，因为这只是延续已有习惯，而不是新增一项常设工作。
• 团队中有一人身兼三职，这本身就已经得出了复盘深度菜单试图买来的发现。

复盘深度

分级菜单——真正能改变下一届活动的发现，按团队剩余精力购买。以下三种排序都属于判断，并非已发布的标准：组织者指南没有规定复盘形式。

• 工作量（小时、日程协调、引导）：多轨道书面回顾 > 分轨会议 > 书面预读加一次会议 > 一次会议
• 价值（发掘出的、原本可能被遗漏的发现）：多轨道书面回顾 > 分轨会议 > 书面预读加一次会议 > 一次会议
• 效率：书面预读加一次会议 > 一次会议 > 分轨会议 > 多轨道书面回顾

支配关系检查：4 个档位、6 组配对，没有严格支配关系——这只是通过设计实现的干净结果，而通过设计从来不算通过。 价值和工作量的排序完全相同，因此只有一种机制能阻止所有 6 组配对：能发掘更多发现的档位，必然严格耗费更多团队工时。没有第三个维度能阻止或解决任何一组配对；效率这一排序依赖后文的论证。

效率排序将中间两个档位颠倒，因为价值排名前两位的档位，同时也是工作量排名前两位的档位。活动结束后，时间是最紧缺的资源，而分轨协调所需的精力增长速度超过了它所能带来的细节增量。

• 一次会议——召开一次 60-90 分钟的会议，将笔记实时记录到带日期的日志中。
• 书面预读加一次会议（默认）——每个具名角色事先提交做得好／不好的事项清单；会议用于讨论，而非收集信息。这样可以获得较为安静的组织者所掌握的发现，并避免第一个发言者左右全场。
• 分轨会议——按工作流分别开展复盘，然后召开一次汇总会议。当具名工作流负责人确实独立开展工作时，升级到此档——没有一个会议室能容纳所有了解实际情况的人。
• 多轨道书面回顾（冷落的档位）——分轨会议加上每个轨道一份书面文档，汇总成一份完整的活动报告。它在价值和工作量方面都排名第一，因此效率排序绝不会选它。升级条件，以 Q9 为依据：领导层交接（新团队需要继承书面记录），或连锁／多城市活动（各地组织者会互相阅读彼此的回顾）。

当“团队”只有一两个人时，应删除两个基于轨道的档位，而不是将它们降级——两个人开五场分轨会议纯属形式主义。

回顾表

一次会议会产出会议纪要；一张整个周期内持续开放的常设表格，则能提供会议无法给予的空间，让异议在提出之后仍能留存。表格设五列——谁 / 观察 / 赞同 / 反对 / 评论——并允许任何人在任何时候添加一行，而不只是在预定会议期间。赞同和反对是独立的列，而不是会悄然关闭的评论串；一行应保持开放，直到团队确实准备好关闭它，而不是在会议结束时就关闭。

有些发现应保留为原始证词，而不是把每个人的声音都揉进一句总结。两个人对同一做法的描述相互矛盾——一个认为它太少见，另一个认为太频繁——这是真实的信号，综合平均后只剩下「似乎没问题」，反而会抹去它。当某个话题确实引发分歧时，应把双方的原话都留在表上，而不是只选声音更大的一方。

有记录的拒绝本身就是成果，而不是不作为。 直接在该行写下「不采取行动，因为［原因］」，就能避免同一建议在下一版中再次出现，仿佛从未被考虑过——这正是第 9 步要求为行动项遵循的「不采取行动」纪律，只不过应用在表格本身。对团队确实意见分歧的决定也应如此：在该行记录双方立场，而不是任由一方靠消耗战取胜，让之后重新审视此事的人仍能看到这场辩论。

有一种反复出现的分歧值得单独占一行：谁来评判本版的影响，是团队还是与会者问卷。组织者对此看法不一。应在该行保留双方的判断——团队的影响强度评分与问卷结果并列——而不是让任何一方取代另一方。

发布策略

分级菜单——用每单位的撰写、审核和曝光成本换取社区信任与问责。这是此处唯一真正带有曝光风险的菜单，因此需要加入合规成本这一维度。

• 工作量（撰写、匿名化、签字批准）：总结加复盘加透明度报告 > 总结加复盘 > 仅总结 > 不发布任何内容
• 价值（信任、促成修复的问责压力，以及可重复使用的公开产物）：总结加复盘加透明度报告 > 总结加复盘 > 仅总结 > 不发布任何内容
• 效率：总结加复盘 > 仅总结 > 总结加复盘加透明度报告 > 不发布任何内容
• 合规成本（触发审核、消耗可撤回性）：总结加复盘加透明度报告 > 总结加复盘 > 仅总结；不发布任何内容则不产生合规成本。

支配关系检查：4 个档位、6 组配对、没有严格支配关系——只是构造上干净，并不代表过关。 价值、工作量和合规成本都按同一顺序排列：获得更多信任的档位，在两个成本维度上都严格更差；即使与“不发布任何内容”相比也是如此，后者只是价值较低，并非白捡任何好处。这项检查没有发现问题；接下来要靠论证。

效率仍然倾向于复盘：到第 8 步，复盘结论已经以三段式形式存在，因此边际成本只是写两段话，而不是重新分析。尽管不发布任何内容没有成本，它的效率仍排最后，因为零除以零永远不会胜出，即使出于其他原因，这仍是正确选择。

合规成本的排序并非对工作量排序的改写：

• 总结——曝光风险是照片许可检查。

• 复盘——曝光风险来自合同：提及场地或餐饮供应商的结论可能与不贬损条款冲突，而且肯定会传到你明年还想合作的供应商那里。

• 透明度报告——曝光风险又有本质不同：匿名化需要行为准则流程本身签字批准，而且已发布的事件描述无法撤回。

• 不发布任何内容——结论留在团队日志中。

• 仅总结——发生了什么、数据、照片、致谢；不包含任何结论。DevOpsDays 对此程度的内容表示认可：撰写结果博客“可选，但强烈建议”。

• 总结加复盘（默认）——采用 Write the Docs Prague 2017 的形式：总结加一小段，说明哪些地方出了问题，以及下一届会做哪些改变。

• 总结加复盘加透明度报告（资源不足档位）——完整的 Prague 2017 产物，另加一份匿名化说明，介绍行为准则报告及其各自的处理方式。价值、工作量和合规成本都最高，因此效率不会选它。晋级条件，以 Q10 为准：报告已得到实际处理，且 event-code-of-conduct 的流程批准了匿名化；或者事件已足够公开，以至于保持沉默会被视为掩盖事实。

删除条件，以 Q11 为准：对于私人活动，或涉及人员敏感信息或受保密要求约束的结论，应删除所有公开档位，而不是降级处理。

行动项跟进的严谨性

分级菜单——每单位持续开销实际能进入下一版的经验教训。责任归属纪律很重要：每个行动项都需要一位具名负责人和一个日期，否则就会不了了之。

这并不假设已有工单系统；每一级都适用于团队现有的任何工具。这些级别取决于判断。

• 投入（设置、日程安排、维护）：持续跟进表并定期审查 > 计划结转 == 周期中检查 > 在条目中注明负责人和日期
• 价值（改变某些做法的发现所占比例）：持续跟进表并定期审查 > 计划结转 > 周期中检查 > 在条目中注明负责人和日期
• 效率：在条目中注明负责人和日期 > 计划结转 > 周期中检查 > 持续跟进表并定期审查

投入打平是有理有据的，并非犹豫不决：周期中检查和计划结转都只需在日历上添加一条安排，耗时不到半小时，而从复盘到该日期之间无需构建或维护任何东西——持续跟进表则不同，它是一项工作，而非一次日程安排。两者的价值并不相同：计划结转会把事项放进团队实际使用的文档，因此在投入打平时，它的比值更高。

• 在条目中注明负责人和日期——每个条目都注明一位具名负责人和一个日期，或明确写明“无需采取行动，因为”。几乎没有额外投入。避免事项无人跟进，仅此而已。
• 周期中检查——约几周后安排一次有日期的检查，确认有时限要求的事项已完成（与供应商沟通、退款、道歉、催收押金）。
• 计划结转——将每个未完成事项写入下一版的倒排工作计划，作为一项实际任务，交由 event-planning-timeline 处理。
• 持续跟进表并定期审查（资源不足的级别）——一份持续使用的跟进表，在不同版本之间按固定周期审查。价值和投入都最高，因此效率始终最低。晋级条件，以 Q12 为准：已存在用于其他事项的全年跟进表，或发现的问题需要由 event-team-structure 处理结构性工作（按定义，这类工作会在不同版本之间进行）。

默认做法：每个条目都注明负责人和日期，并进行计划结转。 对时限短于规划周期的事项，增加周期中检查。如果发现的问题必须在规划开始前解决（例如法律实体变更、继任安排缺口），则改用持续跟进表。

对于最终版或一次性版本，删除计划结转和持续跟进表，而不是将它们降级，仅保留负责人和日期规则。

根据访谈答案重新排序

按菜单分别说明每个答案调整了哪些选项，而不是悄悄重新排序。

访谈答案	深度	发布	跟踪
Q6 - 数周内开始规划	提升两个单次会议选项，降低两个按阶段跟进的选项（它们需要跨负责人协调日程，而期限不允许这样做）	几乎不调整，并明确说明这一点——回顾总结不在规划关键路径上，所以宁可延后，也不要缩短复盘时间	大幅提升计划延续选项——文档现在就会启用，项目本周就能加入
Q7 - 最终版或一次性版本	降低书面评审的优先级，除非后续组织会阅读它	提升回顾总结和透明度报告的优先级——对于收尾版本，公开记录是社区唯一能获得的记录，这也是 JSConf EU 和 !!Con 的声明仍被引用的原因	删除延续选项和常设跟踪器
Q7 - 持续积累的定期版本	-	-	提升延续选项和常设跟踪器
Q8 - 工作量上限低 / 团队已筋疲力尽	直接删除两个按阶段跟进的选项	降低透明度报告的优先级，因为匿名化最耗时，并保留回顾总结	降低常设跟踪器的优先级，默认选项保持不变——默认选项的意义就在于只需填写一个字段并粘贴一次

失败模式

• 当众指责。 一句“你漏了这个”就会把复盘变成绩效评估，之后的发现也就无人再提；在志愿者团队中，当事人可能再也不回来，而这份损失不会出现在记录中。开场时说明复盘的基调，并在第一次偏离时当场提醒。
• 因为本届活动顺利，就跳过复盘。 严重程度门槛是事故复盘传统中唯一明确不适用的机制。即使本届活动风平浪静，也有值得指出的做法，以免之后被弃用。
• 行动项无人负责。 负责人写着“大家”、截止日期写着“下次”的条目，无从追踪。指定一位负责人和一个日期，或明确将其结为无需采取行动。
• 为了显得周全而凭空制造行动项。 这是相反的失误，事故复盘实践对此有明确论述：如果某项发现不需要采取行动，就直说。
• 每个条目都做 5-Whys 分析。 对午餐安排出错进行五层因果分析，属于过度设计，还会挤占真正值得深入分析的发现。已发表的先例对每项发现只做三个浅层部分，完全不进行根因分析。
• 重新诊断当天的问题。 在复盘中重写提示单、重新评估风险登记表或重新建模预算，会抢走负责这些工作的协作技能，并产出一个其他人都不会采用的版本。交回一项发现，而不是一份重新设计方案。
• 把倦怠当成个人缺陷。 “他们承担得太多”不是一项发现；“一个人承担了三个角色，而且没有替补”才是。前者会终止讨论，后者则能导向结构性修复。
• 拖到没人记得细节时才复盘。 六周后，时间线只能根据记忆最深的三个人重新拼凑，细微的失误也就消失了。如果日期已经拖了这么久，就如实说明，并降低记录所作主张的确定性，而不要假装重建结果完整无缺。
• 跨届追踪趋势。 将本届活动的数据与前两届比较，是 samber/dev-event-organizer-skills@event-continuous-improvement 的工作。产出一份注明日期的记录；汇总工作应交给适当的环节。

衡量方式

已发布的指南说明了复盘何时进行、谁来参加，以及会产出什么文档，但没有规定有多少经验教训最终会落实——有来源依据的详情见 references/field-precedent.md。本技能只设定一个合格门槛，针对团队能完全掌控的唯一事项：

• 无人负责的条目为零（二元标准）。日志中的每个条目都必须有明确姓名的负责人和注明日期的截止期限，或者明确写明“无需采取行动，因为……”；逐行重读日志，为每项条目指定负责人和期限，或将其结案，直到满足要求。不符合这一标准的日志不是经验教训日志，只是会议记录。

其余指标是需要记录的信号，而不是需要达成的目标：

• 从活动结束到复盘的天数。记录下来，以便团队观察各届活动之间的趋势。
• 具名角色覆盖率：担任具名角色的人中，有多少人到场或提交了书面意见，占总人数的比例。与其他任何数据相比，较低的比例更能说明日志为何内容单薄。
• 行动项落实率（从第二届活动起才能衡量）：上一届活动的行动项中，有多少项实际完成。将其作为一项输入记录；趋势分析应由 samber/dev-event-organizer-skills@event-continuous-improvement 负责。
• 复盘时记录的成果（自行设定）：项目、合作、公司、工作。首次只统计数量；之后的成果会通过成果日志陆续记录。

调用示例

• “我们的大会周日结束了。我们该如何进行复盘，哪些人应该参加？”
• “我们收到了参会者的调查结果——该如何把这些结果和我们自己的笔记结合起来，整理成下一届真正会用到的内容？”
• “我们应该公开哪些地方出了问题，还是只在内部讨论？”
• “去年的复盘总结出了 15 条经验教训，但我们一条都没落实。这个流程出了什么问题？”
• “我们的一位组织者在复盘时说自己已经彻底精疲力竭了。我们该怎么处理？”
• “今年其实没出什么岔子。还值得花一个晚上复盘吗？”

预期输出：

• 一份带日期的经验教训记录，每条包含三个部分，并指定负责人和截止日期，或明确标注无需采取行动
• 将四项核对结果移交给分别负责风险登记表、预算、活动流程表和需求判断的关联技能
• 一份经分流的团队健康问题清单
• 一项说明理由的发布决定
• 明确说明已移交给 samber/dev-event-organizer-skills@event-continuous-improvement

参考资料

• references/lessons-learned-entries.md - 三部分记录格式，包含有来源依据的示例和一个反例、“为何未能及时发现”分类，以及将单条记录升级为 5 Whys 分析的严格标准。
• references/reconciliation-and-session-agenda.md - 会议议程，包含无责备的开场白脚本、时间线还原方法、四份核对清单及其移交格式、两个已发布的团队健康示例，以及移交给 event-continuous-improvement 的材料包。
• references/field-precedent.md - 已发布的组织者指南对活动后复盘的建议，以及为何此技能的会议机制改为借鉴 SRE 事故复盘的传统。