event-continuous-improvement

活动持续改进

你负责处理跨届活动的所有事项：

• 从两份或更多带日期的复盘日志中发现趋势。
• 区分哪些发现是噪声，哪些是信号。
• 持续维护汇总学习日志。
• 审核该日志，确保其可信。
• 将结果反馈给负责落实变更的人。

单届活动不归你负责。 samber/dev-event-organizer-skills@event-debrief 会复盘一届已结束的活动，并将带日期的日志交给你。它自身的上游边界不允许跨届趋势分析，因为拿一届活动与前两届比较，会重复另一个同类工具存在的全部理由。切勿重新执行它的分析、重新审视单届活动的发现，或生成它产出的成果。

更多范围已有明确归属。阅读以下每个同类工具的说明，将事项交给它处理，切勿替它做决定：

同类工具	负责范围	你要做的
event-market-fit	需求信号趋势：售罄速度、销售速度、回购率、赞助商续约	你的趋势是运营层面的（服务台再次忙不过来，同一供应商两次出问题）——交接时要明确说明这一区别
event-growth-strategy	是否扩张以及如何扩张	“参会人数超过 300 人后出现的瓶颈”是你交给它的证据，绝不是建议
event-team-structure	接班规划、单点故障、倦怠	留意相同的结构性发现是否在多届活动中反复出现——持续维护的日志本身就是一种单点故障缓解措施
event-planning-timeline	工作何时开展	由你决定要做哪些变更以及原因
event-vendor-sourcing	单个供应商自身的绩效记录	问题再次出现后，将是否重新预订的结论交给它；这是该供应商档案的证据，不是普遍性主题

你不会直接收到参会者反馈：event-feedback 收集反馈，event-debrief 对其进行整理，而你只能看到通过该日志传递来的内容。

组织者指南涵盖什么，以及其适用范围止于何处

请把这点明确告诉用户，因为它限定了下文所有论断的范围。

• 一份组织者指南涵盖了第一次交接，而实际差距比看上去更窄。 MLH 的 Organizer-Resources/keeping-records.md 提供了频率、受众、两项产出和一个完整示例，全部针对第一届到第二届。DevOpsDays 的 organizing.md 只在这个主题下提到一条行为准则。两者都没有追踪某项发现从第一届延续到第三届或第四届。完整引文和示例：references/log-format-and-audit.md。
• 唯一真正的结构性证据来自 Git 历史。 DevOpsDays 的 organizing.md 是一份共享指南文档，在组织团队多次彻底更替后，仍通过小幅定向修改而非定期重写得以留存。这证明了持久保存、由多人共同编辑的文档能够经受人员更替；但它并非趋势日志格式的模板，因为其中既没有按届记录的带日期条目，也完全没有趋势注释。
• 软件改进实践中有两个片段可以沿用，并且在每次出现时都标明为借鉴内容。 改进循环本身并不适用：SaaS 改进循环假设按每次运行或每季度进行，而活动每年才改进一次，团队也只有部分成员更替。可沿用的是 printing-press-retro 的归档门槛（references/filing-gate-and-trend-evidence.md），以及 ce-compound-refresh 的 Keep/Update/Consolidate/Replace/Delete 分类（references/log-format-and-audit.md）。
• 一份会议管理报告提到了这种实践本身，而非其具体做法。 Fraser 和 Mancl 在 2023 年发布的会议未来报告中，将回顾称为“会议利益相关者推动会议持续改进的一项重要管理实践”；回顾会在活动结束后以组织者会议的形式进行，并配合活动后调查来“识别趋势（逐年变化）”，明确面向“系列会议”。这支持了跨届持续开展这项实践，但没有规定“活动结束后”之外的具体频率、按届记录的日志格式或发生次数门槛。

以这种方式命名该实践有来源依据。日志格式、发生次数门槛、下文的各项选项，以及 references/ 中的所有模板，都是本技能自行设计的内容。不要将其中任何内容说成是已确立的组织者实践。

访谈

每次只问一个问题，尽可能采用选择题形式。之所以有第 5 至第 7 个问题，是因为下方菜单在见效时间、持久性和投入程度上差异很大；没有这些信息，就不能替用户确定默认顺序。

1. 这场活动已经举办了几届？其中有几届留有书面记录？第二个数字是判断趋势的唯一依据。
2. 这些记录目前是什么形式——完全没有书面记录、聊天记录、每届一份文档，还是包含字段的结构化记录？
3. 从你保存的最早记录至今，组织团队有多少人换过——没人换过、部分换过、大部分换过，还是整个团队都换成了新人？本届活动是否计划交接给其他人？
4. samber/dev-event-organizer-skills@event-debrief 中的条目是否采用三部分表单，并包含负责人和日期，还是形式更宽松？不同届次之间是否有可比较的数字，还是只有文字结论？过去是否有哪届活动曾明确因为记录在案的某项发现而做出改变？
5. 下一届活动何时开始筹备，或者何时决定是否举办？这个日期就是此技能的截止日期；如果趋势在计划写好之后才得出，就毫无影响。
6. 这是一次性活动或收官之届，还是计划持续举办多年、不断积累经验的活动——大约还会举办多少届？
7. 两届活动之间的投入上限是多少：有多少可用时间？目前是否有人负责两届之间的工作？
8. 日志存放在哪里？预计谁会在筹备开始前打开它？请说出具体人名。“团队”这个答案只会让日志无人重读。

延续性或轮换

无论活动面向企业买家还是周末爱好者，归档门槛、复现次数统计、主题分组、审计分类和路由规则都完全相同，逐字不差。

真正会改变输出的因素是下一届有多少团队成员仍是原班人马，因为这决定了日志需要记录什么：

• 团队延续——同一批人连续举办多届活动。记忆在一定程度上可以替代日志，陷阱也正在于此：正因为眼下没人需要日志，日志才会一直内容单薄。直到有人离开时，缺口才会显现。写日志时，要想到那位不在场的继任者。
• 部分人员更替——最常见的情况。一些发现留在日志里，一些留在某个人脑海中，却没人能说清哪些在哪里。主题分组在这种情况下值得投入：回归的组织者和新组织者会用不同的措辞描述同一个反复出现的问题。
• 团队完全轮换——例如特许经营活动、轮换城市举办模式，或由新团队接手活动。此时，日志是完整的交接机制，而非锦上添花。DjangoCon Europe 为此增设了一个由往届组织者组成的支持工作组，以及一项常设活动支持职能，因为仅凭书面记录无法完成交接。

工作流

1. 开展访谈。如果 Q1 的答案是一个版本的记录，就停止趋势分析并说明原因：归档这个版本，开始记录日志，明年再继续。这项技能有一半无法使用，假装情况并非如此只会凭空制造模式。
2. 接收日志，不要重新运行访谈。 将 samber/dev-event-organizer-skills@event-debrief 按版本整理的带日期日志视为既定事实。如果某条记录内容单薄或含糊，请注明缺失之处；绝不要重建它所对应的版本。
3. 让每条记录都通过信号门槛再归档。 借鉴 printing-press-retro 的归档门槛：只有当某条记录在活动自身的条件下可复现，且能推广到一次以上的情况时，才能成为候选项。一次性故障若已处理且没有造成损失，属于预期工作，不是发现。归档时要去个人化：samber/dev-event-organizer-skills@event-debrief 的无责框架必须延续到一份比其中人员存续更久的文档中。门槛标准、正反归档实例和去个人化规则：references/filing-gate-and-trend-evidence.md。
4. 先分组，再计数。 将措辞不同的记录归入主题，然后统计主题的重复次数，而非记录条数。出现两次即为候选项，出现三次即为模式。每次指出趋势时，都要说明它属于这两者中的哪一种。
5. 审慎地逐项决定要做出哪些改变。 避免打包变更：一个计划若同时包含四项改变，就无法判断哪项改变带来了什么结果。将每项改变写成三个部分：
   • 要改变什么。
   • 证据为何足以支持这项改变。
   • 如何在下一届活动中判断它是否奏效。
6. 将每项改变交给相应负责人。
   • 运营变更：交给 samber/dev-event-organizer-skills@event-planning-timeline，作为下一届活动计划中的实际任务。
   • 任何与需求有关的事项：交给 samber/dev-event-organizer-skills@event-market-fit。
   • 任何与规模有关的事项：交给 samber/dev-event-organizer-skills@event-growth-strategy。
   • 任何反复出现的结构性事项：交给 samber/dev-event-organizer-skills@event-team-structure，并附上重复次数，作为单次复盘无法提供的证据。
   • 任何指向某家供应商自身表现的事项，例如是否再次预订、是否需要重写简报、是否需要调整数量：交给 samber/dev-event-organizer-skills@event-vendor-sourcing，记录在该供应商自己的档案中，而不是留在通用日志里，否则下一届活动的采购负责人可能不会想到去那里查看。
7. 持久保存日志，按照下方第一个菜单选定的层级保存，并向团队说明，这是用于缓解关键人风险的措施。
8. 按第三个菜单选定的频率审查累计日志。 将每条记录归类为 Keep、Update、Consolidate、Replace 或 Delete，这些分类借鉴自 ce-compound-refresh，但须诚实地做一项修正：它的事实依据是可随时检查的代码库，而你的依据是下一届活动的实际结果，只有事后才会出现。因此，这种审查只能是回顾性的，而非持续进行的。格式、分类规则和交接资料包：references/log-format-and-audit.md。
9. 闭环。 在规划周期结束前，说明上一周期的哪些刻意变更已经落实，以及结果如何。如果改进循环从不检查自身产出，那就只是一套归档系统。

如果你的运行框架具备持久记忆，请记录日志本身：每条已归档记录的主题、首次出现的版本和出现次数；每项刻意变更及其依据和检查方式；每次路由交接。这是整个技能集合中唯一一项价值完全取决于记录能否在间隔一年的多次运行之间留存、并让未参与撰写的人读懂的技能。 以下每个排序都只是默认方案，并非铁律。如果某项约束排除了一个梯级，也要从该菜单的轴线中删掉它：排序中保留下来的梯级会留在读者脑海里，并再次成为范围。请根据你对这个团队已有的了解，重新排列这三个菜单。

• 一份共享的版本控制文档，已经能以很低的成本满足持久化梯级的需求。
• 如果每一届都由同一个人负责，目前还没有主题分组的问题，但人员更替问题会更严重。
• 从未实施过有意变更的团队，没有东西可供审计或关闭。

日志持久化方案

排序菜单——按每单位持续维护成本衡量，能够经受时间考验并在人员更替后保留下来的跨届趋势。梯级及其排序是本技能自行构建的，并非已发布标准：组织者指南提供历久弥新的操作指导，而不是可照搬的带日期学习日志。

• 工作量（设置、每届维护、改造现有内容）：结构化条目记录 > 数值序列 > 追加式文档 > 仅向后传递
• 价值（能发现哪些模式，以及不在现场的人能否读懂）：结构化条目记录 > 追加式文档 > 数值序列 > 仅向后传递
• 效率：追加式文档 > 结构化条目记录 > 数值序列 > 仅向后传递

价值和工作量的中间梯级排序不同，这正是将两者分开排列的意义。数值序列比追加式文档成本更高，因为每届都必须用相同方式测量这些数字，否则就得有人重新还原数据。它的价值也更低：运营趋势通常以文字描述（“服务台又挤满了”），而数字主要回答由 samber/dev-event-organizer-skills@event-market-fit 负责的需求问题。仅向后传递的效率排名最后，尽管几乎不花成本，因为它无法带来任何跨届价值，而零除以零永远算不出有胜算的比率。

• 仅向后传递 - 规划开始时，重新阅读上一届的总结日志。不做任何汇总；问题是否重复，取决于恰好记得这件事的人。
• 追加式文档 - 一份持续更新的带日期文档；每届都在带日期的标题下追加归档发现。真实的结构性证据支持这一梯级：DevOpsDays 的组织指南历经 11 年、由 20 多位贡献者共同维护，仍然保持这种文档形式。只借鉴它经受时间考验这一点，绝不要照搬其历久弥新的指导形式。
• 数值序列 - 一张小表格，每届记录同一组少量数字，数据取自总结中用于自我衡量的目标。
• 结构化条目记录 - 每条归档发现都带有以下字段：主题、首次出现的届次、出现次数、状态、处理结果、负责人。重复出现会变得可计数，而不再只是靠人记忆。不论团队现有工具是什么，都将其描述为一种记录；切勿指定工具。

默认梯级：追加式文档，从开始记录第二届起适用。被忽略的选项：结构化条目记录——价值排名第一，工作量也排名第一，因此效率永远不会选中它。晋升条件，以及记录稀疏或不一致时应直接删除哪些梯级：references/reranking-by-interview-answers.md。

趋势检测深度

排序菜单——单位分析时间内值得采纳且有依据的模式。这些阶梯及其排序由本技能自行构建。两次与三次的出现规则沿用一种更古老的跨领域惯例，用于区分巧合与模式，即“事不过二，三次成规律”，而非针对活动行业的校准。没有任何组织者指南规定这个数字本身，而它所支撑的门槛借鉴自软件实践。

• 工作量（阅读、聚类、整理证据）：书面趋势回顾 > 配对数字解读 > 主题归类 == 重复次数
• 价值（能经受实际计划检验的审慎调整）：书面趋势回顾 > 主题归类 > 重复次数 > 配对数字解读
• 效率：主题归类 > 重复次数 > 书面趋势回顾 > 配对数字解读

工作量相同是有理据的，并非犹豫不决：计数是在聚类 过程中 进行的，因为不计算成员数量，就无法将条目归为主题。与计数相比，归类增加的边际成本只是一次判断，而非额外数小时；因此，价值可以明确打破平局。

• 重复次数——按原文统计每个归档条目出现于多少届活动。
• 主题归类——将描述同一根本原因的条目聚为一类（胸牌打印、服务台排队和挂绳分拣属于同一个签到主题），然后统计该主题。它在价值上优于原始计数，因为同一问题每届活动、每位组织者都会用不同措辞描述。统计条目会漏掉你真正要找的那些反复出现的问题。
• 配对数字解读——将某个主题的重复次数与同几届活动的数据并列查看，判断它是否与任何可衡量指标相关。在这里价值最低：数字很少能裁定签到服务台是否再次出问题；若确实有指标变化，通常应由 samber/dev-event-organizer-skills@event-market-fit 负责解读。
• 书面趋势回顾——每个规划周期编写一份简短文档，列出每个候选趋势及其各届活动的证据和处理结果，并在规划启动会之前传阅。

默认阶梯：主题归类，统计的是主题的重复次数，而非原始条目。受冷落的选项：书面趋势回顾——价值最高，工作量也最大，因此效率排序永远不会选中它。晋升条件，以及应彻底删除哪些阶梯：references/reranking-by-interview-answers.md。

日志审计节奏

排序后的菜单——团队到第 5 届时仍然信任的日志，按持续开销单位购置。分类借鉴自 ce-compound-refresh。这些节奏、档位和排序是本技能自行制定的。

• 工作量（周期、负责人、每轮小时数）：固定审计负责人 > 启动审查加结束审查 > 启动审查 > 阅读时审计
• 价值（仍然属实的条目，以及短到可以重读的日志）：启动审查加结束审查 > 固定审计负责人 > 启动审查 > 阅读时审计
• 效率：启动审查 > 启动审查加结束审查 > 阅读时审计 > 固定审计负责人

价值和工作量的首位排序不同，原因在于领域本身的特点：这里唯一的事实依据是下一届的实际结果，因此，_在结果出现时_进行审计能验证日历周期审计无法验证的内容，而且成本低于全年维护日志。这使结束审查的价值高于固定负责人，但工作量也更低；这就是为什么效率排序仍以单纯的启动审查为首。

• 阅读时审计 - 只对趋势审查期间碰巧查看到的条目进行分类。其他所有内容都会不断累积，未经审查。
• 启动审查 - 在规划开始前通读整份日志一遍，将每个条目分类为保留、更新、整合、替换或删除。
• 启动审查加结束审查 - 在相同的审查基础上，于本届活动结束后再进行一轮审查，针对每项有意进行的更改，将相关条目与实际结果进行对照。最省事的方式是重新打开同一份更改记录，追加两列，而不是另写报告：这是否确实带来了改善，是或否，以及原因。这样，这份记录本身就成为验证工具，而不是又一份没人看的文档。
• 固定审计负责人 - 指定一人全年负责日志，按固定周期审计，不受规划日程影响。

默认档位：启动审查。 资源紧张时的选项：固定审计负责人——工作量排名第一、价值排名第二、效率排名最后，因此比率永远不会选中它。晋升条件以及应直接删除哪些档位：references/reranking-by-interview-answers.md。

KPI 候选清单与结果日志

这是来自一线的经验，并非已确立的实践。

追踪大量 KPI 不会带来任何改变。应改用候选清单：

1. 选择 2-3 个 KPI，绝不超过此数。每个 KPI 都需要指定负责人，以及一项能够推动其变化的行动；缺少其中任何一项的 KPI 都应删除，而不是搁置。
2. 当社区属于同业网络时，区分本地 KPI 与网络 KPI（samber/dev-event-organizer-skills@event-team-structure）。分会负责推动自己能够改变的指标；只有网络才能推动的指标，则由网络负责。
3. 从报告中的候选项中选择：社交媒体关注者、视频观看次数或订阅者、每场活动后自动发送问卷所得的满意度、财务状况、活动和演讲者数量、新参与者与回访者的比例、女性占比、由此创立的项目或公司，以及组织者为每场活动评定的自评“影响强度”分数。
4. 在查看每项指标前设定阈值（自行设定），并在此处跨届查看 KPI；受需求形态影响的 KPI（新参与者与回访者的比例、售罄情况）仍应转至 samber/dev-event-organizer-skills@event-market-fit。
5. 保留一份结果日志——记录因活动而启动的项目、建立的合作关系、创立的公司和找到的工作，在每场活动后追加，并在启动审查时重新查看，因为这些结果可能在数月后才显现，也能揭示影响力随时间变化的趋势。

组织者对由谁评判影响力意见不一——团队还是参会者问卷。两者都要记录。如果两者之间的差距持续两个届次，就应将其视为 samber/dev-event-organizer-skills@event-positioning 的调查发现，而不是需要打破的平局。

带注意事项的候选项表、候选清单卡片、影响强度评分规则和结果日志模板：references/kpi-shortlist-and-outcome-log.md。

根据访谈答案重新排序

根据 Q1、Q3 和 Q5 至 Q8，重新排列上面全部三个菜单，并明确说出哪个答案让哪个选项发生了变化，而不要悄悄调整顺序。完整细分内容按菜单和答案逐项列出：references/reranking-by-interview-answers.md。

失败模式

• 凭两条数据就断言趋势。 出现两次，只能算候选项；据此宣称趋势，不过是给巧合附上了一个计划。说“候选项”，再观察一届，除非判断错误的代价微不足道。
• 重复做复盘的工作。 重新分析某一届活动、重新评估其风险、重写其中的条目——这些都属于 samber/dev-event-organizer-skills@event-debrief，只会产出同一份文件的第二个版本，而没人会采用它。接受日志中的记录，不要另做分析。
• 把需求趋势当成运营问题。 “回来的人少了”是 samber/dev-event-organizer-skills@event-market-fit 要处理的需求信号。“连续第三年，签到都花了九十分钟”才是你要处理的问题。如果搞反了，就会拿运营修正方案去解决需求问题——活动办得有声有色，但观众已经不再来了。
• 没人会在规划前重读的日志。 这是最可能发生的失败，因为它看起来像成功：记录存在、格式规范，但规划会议仍完全由在场最响亮的记忆主导。明确谁会打开它，以及他们会在什么时候打开。
• 只会不断增长的日志。 这是从另一条路径走向上述失败的结果。没有审查，三届活动前已被取代的条目仍会被视为有效记录，日志也会变得太长，没人愿意重读。进行审查，确保没有任何条目未经核查。
• 一届活动中捆绑四项改动。 这样就无法归因，下一周期的收尾审查也无从下结论。每次只做一项有意为之的改动，整个循环才有可能被衡量。
• 在持久化日志中点名。 在现场令人不适的绩效批评，写进一份由从未见过当事人的人阅读的文件后，就会变得无法辩护。记录结构性发现，将其转交给 samber/dev-event-organizer-skills@event-team-structure，不要在记录中写出姓名。
• 包含十五项 KPI 的仪表板。 报告了每个数字，却没人负责，也没有任何改进。精简到 2-3 项，每项都明确负责人和行动；否则仪表板就会变成没人重读的档案。
• 只从一方衡量影响。 由团队评判的影响会美化付出的努力；参会者问卷则会漏掉数月后才显现的结果。两者都要保留，并将结果日志一并纳入。
• 照搬软件行业的节奏。 季度审查、每个冲刺的回顾和每次运行前的关卡，都默认周期远短于一届活动。借鉴其归档纪律，不要照搬其日历。
• 没人再按设计使用，却为了门面保留的产物。 如果团队已悄悄不再完整遵循某张评分表、清单或流程步骤，那么问题出在产物，而不是团队。在同一轮审查中核查它，并且只通过以下两种方式之一修正，绝无第三种：让设计本身的产出变得足够明显，使人不可能再跳过它；或者简化设计，让它符合人们的实际做法。因为重写会让人觉得是在承认失败，就保留没人用的版本——这才是真正的失败。

衡量

先从指导内容的适用范围入手，因为它决定了这项技能有权设定哪些数字。MLH 的组织者指南涵盖了第一次交接：其节奏、产出和示例都围绕第一届到第二届展开。除此之外的一切阈值都由你设定；从软件持续改进工具中引入目标，会把借来的数字伪装成组织者实践。

因此，只有一个数字值得设定。这项技能只设定一个通过阈值，针对团队唯一能完全掌控的事项：

• 审计一轮后，未分类条目数为零（自行设定，二元）。持久化日志中的每个条目都标注为保留、更新、合并、替换或删除；仍有效的条目还要标注主题和出现次数。持续迭代，直到满足这一条件。未达标的日志只是档案，而档案是没人会重读的东西。

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

• 留存的届数（自行设定）。每项趋势判断都受此数字限制；将其与判断一并记录。
• 可追溯至已归档模式的有意变更占比（自行设定），而非源自规划讨论中的意见。占比较低意味着日志只是装饰。
• 上一周期变更的完成率（自行设定）：有多少变更已落地，又有多少已核查结果。samber/dev-event-organizer-skills@event-debrief 会记录各届的落实情况；届与届之间的趋势由你来判断。
• 规划前是否打开过日志，以及由谁打开（自行设定，每个周期二元）。这个指标很直接，也是判断这些做法是否奏效的最佳单一预测指标。
• KPI 候选清单的规模和负责人（自行设定）：2-3 个 KPI，每个都要有指定负责人和行动。超过 3 个，或有任何一个没有负责人，都属于发现的问题。
• 每届的结果日志条目数（自行设定）：项目、合作、公司。只与自己之前的届数比较。

调用示例

• “这是我们的第四届，我敢说每年报名环节都会出问题。我们到底该怎么解决，而不是每年重新发现一次？”
• “我们在共享文档里积累了三年的复盘笔记，但没人会打开。规划开始前该怎么处理这些笔记？”
• “今年组织团队里有一半是新人。我们该如何避免他们事事都从头摸索？”
• “上一届我们根据反馈调整了日程。怎么判断调整是否奏效？”
• “我们的学习日志有 40 条记录，我觉得其中一半可能已经不准确了。”
• “出席人数连续第二年下降。这是这项技能能处理的问题吗？”
• “我们的聚会追踪 20 个数字，但没有一个会带来任何改变。哪些应该保留？”

预期输出：

• 一组已归档条目，按主题分组；每条都标注出现次数，并注明是候选项还是模式。
• 一份简短的有意变更清单，列出每项变更的依据，以及用于确认结果的检查方式。
• 将需求、规模、结构、供应商和日程方面的后续事项转交给负责这些事项的相关技能。
• 持久化等级和审计频率，并说明选择理由。
• 一份包含 2-3 张卡片的 KPI 候选清单（适用时区分本地与网络指标），以及一份结果日志。
• 每项判断都标明是已发布的组织者实践，还是这项技能自身的判断。

另请参阅，同一集合

文中提及的相关技能：请参阅本文件顶部的相关技能表。还有一项不在该表中：samber/dev-event-organizer-skills@event-budget 用于规划和追踪某一届的资金，而逐届攀升的成本条目属于这项技能需要解读的趋势，绝非该技能需要重新建模的内容。