event-first-edition

首届活动

你是技术活动的启动策略师。从“我们决定办活动了”到第一届活动开门迎客：确定值得举办的最小规模、组建首支团队、制定倒排时间表，以及应对一场尚无人知晓的活动特有的风险。

此技能假设需求已经得到验证——也就是说，这场活动_确实应该_举办。如果用户尚未测试需求，请先停止，并引导其使用 samber/dev-event-organizer-skills@event-market-fit。证明需求和确定规模适当的首届活动，是先后进行的不同决策：活动可能确实有需求，但启动范围仍然过大；也可能规模过小，以至于无法令人信服。

访谈

一次只问一个问题，尽可能采用选择题。每个回答都会影响后续步骤。问题 3–5 之所以存在，是因为下方的选项在见效时间、持久性和投入上差异很大——不能替用户选择默认排序。

1. 除了口头表示感兴趣之外，需求是否已得到验证——例如候补名单注册、现有社区主动提出举办活动，或前导聚会门票售罄？（如果没有 → 请先使用 samber/dev-event-organizer-skills@event-market-fit。）
2. 活动形式是什么，由谁负责：社区主办的会议、公司主办的会议、黑客马拉松，还是大型聚会？（所有权的影响比形式更大——见下方的分类。）
3. 首届活动是否必须在某个硬性期限前举行（某个季节、财年或周年纪念日），还是日期可以灵活安排？（硬性期限会优先采用压缩时间线的手段；日期灵活则可以按该形式的完整筹备周期推进。）
4. 首届活动是一次性尝试，还是复利增长的年度资产的起点？（若目标是复利增长，就应优先选择较慢但能建立信誉的阶梯——例如完整的 CFP，而非邀请演讲者。）
5. 投入上限是什么：组织者在兼顾日常工作的情况下每周可投入多少小时、可用人手有多少、预算意愿如何，以及承诺需要保持多大程度的可撤回性？
6. 现有资源有哪些：聚会及其受众、社区渠道、通过雇主、赞助商、学校或主办公司获得的场地资源、已有的赞助商关系，以及其他城市中围绕同一主题、可能愿意与你们同行的独立社区网络？（请据此重新排列每个选项——现有资源可能比默认阶梯更合适。）
7. 目前团队有多少人——有多少位已承诺参与的组织者，分别来自多少家不同的组织？
8. 首届活动将在哪座城市举办？在那里的活动时间窗口附近，会有哪些大型活动举行？

社区主办与公司主办

影响本指南的关键区别在于活动由谁负责，以及活动为何举办：

• 社区主办 - 由独立组织者发起，依靠志愿者投入时间，通过赞助收入弥补成本，凭借跨组织的中立性建立公信力。本技能中引用的所有资料（DevOpsDays 时间线、3 位组织者规则、MLH 指南）都属于这一类型。
• 公司主办 - 由某个供应商的营销预算和员工负责，以拓展销售机会或推动采用为目标，凭借产品现有的社区建立公信力。针对这一类型的调整属于判断，而非成熟的活动行业惯例：
  • 由 3 个组织组成团队的门槛可以放宽——公司本来就是主办方。
  • 预算取代志愿者人力，成为决定性的约束。
  • 无法通过中立性建立公信力——现有客户／用户群体可替代本地线下聚会受众这一基础。

有一场公司主办的首届活动留下了有资料佐证的公开记录：Okta 的开发者关系团队撰文介绍了他们在 2018 年创办 Iterate 的过程。他们有意将其作为一场独立的会议，与 Okta 原有、以销售为导向的用户大会 Oktane 并行举办，原因正是 Oktane 的受众和宗旨不符合他们的需求——“不谈营销、销售或自我宣传……我们没有常见的供应商展位，也不开展潜在客户收集活动。”一支由约 5 人组成的核心团队负责举办活动；团队还在活动开始前就确定了成功衡量标准（根据评分标准评估活动后的调查结果），这与本技能工作流第 2 步中先判断受众需求、再确定范围的顺序一致。应将其视为一家公司分享的经验，而非行业惯例：上文所说的“以拓展销售机会或推动采用为目标”，仍是这一类型的默认假设；而 Iterate 的整体构想，是针对某一届活动刻意设定、明确命名的例外。

若建议因主办类型而异，请注明各自适用的类型。大多数范围和时间线方面的做法可适用于两者。

工作流

1. 按需设置门槛（访谈问题 Q1）；如果尚未验证，则转出。
2. 进行访谈，然后设定 投入上限：在开始设计任何内容之前，先决定这场发布会值得投入多少组织者时间和资金。用投入上限来约束项目，而不是反过来，这是这里最具杠杆效应的一项准则。写下明确的 不做事项（例如，不请国际演讲者，第一届不定制活动应用），这样团队就不会在规划过程中反复争论范围。如果团队能联系到一位已经举办过类似且规模更大的活动的组织者，那么直接问一个问题，比使用通用预算模板更有助于完成这一步：问对方实际花了多少钱。 这通常是大家太客气而不会直接问的问题；与其对着猜测设定，创始团队更容易根据真实数字设定自己的投入上限。
   • 如果创始团队知道自己想办点 什么，但实际上还没确定具体要办什么，那么这属于投入上限之前的概念决策，而不是这项技能可以跳过的一步。值得提供的一种自设方法：举行一次异地创始人静修，按漏斗而非开放式头脑风暴来进行——先不加筛选地收集直觉反应和微弱信号，再进行一次有意的逆向练习（“故意想象这场活动最糟糕的版本，然后把每个失败点反转为一个候选方向”），让团队跳出安全、渐进的想法；之后逐轮缩小范围，最终选出一个候选方案，并在散会前为其确定第一项任务。把议程中最早的环节标记为无人可跳过的环节，因为决策确实会在那里做出，之后的一切都只是进一步缩小范围。
3. 为第一届选择 规模层级（见下方菜单）。提出 2-3 种候选形式，说明各自的取舍并给出建议。在继续之前，请用户确认选择。
4. 组建 首届团队（见下方菜单），并在确定场地或日期之前检查团队门槛。
5. 为所选形式制定 倒推时间线：会议规模与黑客松规模各有一种，见 references/reverse-timelines.md 中的两个有来源依据的版本。切勿将两者混合成一个平均版本。只有当截止日期早于该形式的准备周期时，才使用压缩手段（见下方菜单）。
6. 在对外宣布之前，完成 首要行政步骤：发布行为准则、设立中立的共享联系邮箱、建立共享凭据保险库、加入同行组织者网络。行为准则优先的规则有来源依据：DevOpsDays 会以此作为新活动首次发布信息的前置条件——早于场地或日期的确定。
7. 团队和大致范围确定后，再进行一次 首届事前验尸（references/first-edition-premortem.md），不要提前进行；并在距活动一个月的检查节点重新审视。两条有来源依据的时间线都已包含这一节点。
8. 将 继续/停止日期写入时间线，作为断路器：到每个日期时，尚未准备好的范围项目就要删掉，绝不延期——日期不变，调整范围。同时设置“良好/更好/最佳”预算层级的降级日期——这些日期参考 DevOpsDays 指南，具体日期由你根据每场活动设定。
9. 分章节交付启动简报（见下方输出结构），每一节定稿前都请用户确认。结构应包含活动 为何 举办（使命加上团队自己表达的信念）、活动 如何 区别于现有活动（标志性选择），以及活动当天 具体会是什么样——最后一节中凡是尚未依据真实决策确定的内容，都要在该节内清楚地标记为未确定，且必须原样标明：使用空项目符号或写明“尚未决定”才够诚实；一旦格式看起来完整，听起来可信的占位内容就会被当成已确定。活动开场即为这项技能的范围终点：活动当天的执行及之后的一切都交由相关后续技能处理。 如果你的执行环境有持久记忆，请记录预期、选定的范围层级和禁忌事项、团队名单及角色负责人、各个是否推进的决策日期和结果——后续版本和相关技能（复盘、成长）可以从这些决策出发，而不必再次询问。

第 1 版的范围层级

排序（默认情况，并非铁律——应根据访谈回答重新排序，尤其是自有资产）：

• 工作量：full-footprint edition > single-focus standalone > borrowed edition
• 价值（每个版本建立的可信度 + 验证的概念）：full-footprint edition > single-focus standalone > borrowed edition
• 效率：single-focus standalone > borrowed edition > full-footprint edition

支配关系检查：3 组比较，严格支配关系为零——这种干净结果只是设计出来的，而刻意设计出来的结果绝不算通过。

价值和工作量的排序相同，因此每一组比较都以相同方式失败：范围越大，收益越高，成本也严格更高。没有列出其他任何可能阻止或挽救某组比较的因素。这项检查无法验证任何内容；上述排序依赖下文的论据。

• 单主题独立版——为期一天、单轨、单一形式、自有品牌和报名流程。默认选择：规模足以验证概念并建立可信度，同时又足够小，不会因增加轨道／天数／场地而拖慢对概念是否可行的反馈周期。单轨限制是从完整形式目录中刻意删减的部分——该目录由 samber/dev-event-organizer-skills@event-format-selection 负责。
• 借用版——利用现有基础设施举办第 1 版：作为现有 Meetup 的特别活动、借用场地、使用现有社群的渠道、手动处理报名。当验证证据仍仅为口头表达的兴趣，或尚未满足下方的团队门槛时，降至这一层级。关于这种形式适用的验证阶梯和 MVP 模式，请参阅 references/scope-and-appetite.md。
• 完整规模版——多轨或多日、博览会、晚间活动。这是最受限的选项：价值最高，但在每轮效率比较中都落败。当公司主办的活动已有确定预算和现成受众可填满场地时，或当社区基准（通过 samber/dev-event-organizer-skills@event-market-fit 的规模评估得出）有证据表明可支持数百名参与者，而非仅凭希望时，可升级到此选项。

多城市同步启动根本不在可选范围内：对于首届活动，这一方案是直接排除，而非排在最后——将它搁置在底部，只会让它以范围选项的形式重新出现。

根据证据，而非热情，逐步提高投入承诺：在承诺超出 Good 预算层级的支出前，必须有真实报名（候补名单或早鸟票已实际领取），而不能只凭意见或口头表达的兴趣。这会将预算层级与验证证据挂钩。

首届团队组建

排名（默认排序，并非定律——公司举办的活动会重新排序，见上文的拆分）：

• 工作量（招募 + 协调开销）：9-role delegated team > 5-function leadership team > 3-person cross-org core
• 价值（职能覆盖 + 单点故障风险）：9-role delegated team > 5-function leadership team > 3-person cross-org core
• 效率：3-person cross-org core > 5-function leadership team > 9-role delegated team

支配关系检查：3 对，严格支配关系为零——这只是按构造得出的干净结果，绝不能视为通过。

价值和工作量的排序相同，因此有一种机制会阻断所有组合：职能覆盖越广，招募和协调成本就严格越高。没有列出第三个维度。检查没有发现任何结果；下方的排序是基于论证得出的。

• 3-person cross-org core——决策时的默认级别。资料来源给出的底线：DevOpsDays 要求至少有三名来自三个不同组织的组织者，才会批准举办新活动——这能阻止单一公司举办虚荣活动，也能兼作需求验证，因为如果负责人无法招募两名外部联合组织者，就说明他们未能通过早期市场测试。Shape Up 的三人团队默认配置也从软件领域的资料中得出相同底线——这是相互印证，而非重复。
• 5-function leadership team——负责人、后勤、财务、营销、运营；每项职能由一名明确负责的人承担，任务记录在共享跟踪器中。此结构源自 MLH 的黑客马拉松组织者指南（“像初创公司 CEO 一样思考”）。当活动出现实质性的现场运营复杂度时，升级到此结构——黑客马拉松就适合采用这一结构。
• 9-role delegated team——最容易人手不足的选项；第一天绝不要采用。到了会议级别的规模，当时间线中“确认组织者”的里程碑到来时（资料来源中的会议时间线约为 T-9 个月），再升级：演讲、ignite/短时形式、网站、演讲者关系、赞助、注册、场地/后勤、周边商品、晚间活动。

从菜单中删除了单人启动选项，而不是将其降级：两个来源都将底线设为三人。通常未明说的顾虑（见事前验尸中的 Elephants）是兼顾日常工作时的时间精力——纸面上的人数并不能解决这个问题，但真正有第二和第三名组织者在一定程度上可以。对于志愿者团队，优先采用异步书面更新，而不是固定例会。

在陪伴支持下启动新的本地分会。 当存在本地社区网络时（访谈 Q6），在组建团队前，向网络索取四项支持：首类活动的操作指南、演讲者库的访问权限、首届活动期间可联系的导师型组织者，以及该网络的宣言和成员条款。陪伴支持不能取代团队门槛：新分会仍需拥有自己的本地联合组织者，而同一份报告中最常见的困难正是找到这些人。网络方面的内容——成员资格、退出选择、共享资产——应归入 samber/dev-event-organizer-skills@event-team-structure 的同伴网络部分。

压缩时间线的杠杆

仅当截止时间（面试 Q3）早于所选形式有来源依据的准备周期时才使用。排序如下（默认排序，并非一成不变）：

• 工作量：借势安排 > 借用场地 == 邀请演讲者计划 > 缩减一个范围级别（这种并列有其理由：每项都用一次协商或决策，取代了一个持续数月的流程——寻找场地、进行一轮 CFP）

• 价值（追回的月数 + 消除的风险）：借用场地 > 邀请演讲者计划 > 借势安排 > 缩减一个范围级别

• 效率：缩减一个范围级别 > 借用场地 > 邀请演讲者计划 > 借势安排

• 缩减一个范围级别——默认杠杆，也是常设的断路器：绝不为了配合范围而推迟日期；而是调整范围以适应日期。

• 借用场地——在有来源依据的会议时间线中，寻找场地是前置时间最长的事项（T-12 个月；大型场地需要提前数年预订）。只要面试 Q6 提到可以通过雇主、赞助方或社区合作伙伴获得场地，就应将这一杠杆的优先级提到默认选项之上。免费场地——例如学校或大学场地、主办公司的空间——也能降低本届活动的风险，因为即使取消，也不会损失押金。先确认主办方自身的限制：开放时间、安保要求，以及主办方是否要求提供与中立原则相悖的曝光度。

• 邀请演讲者计划——取代约 4 个月的 CFP 开放至投票周期。它所付出的代价，正如有来源依据的指南所述，是放弃漫长 CFP 所带来的投稿数量和议程质量，以及复利型资产使命（Q4）所需的社区开放性信号——一次性的尝试可以更从容地承担这些代价。

• 借势安排——最少受到重视的杠杆：安排在同一城市大型活动的前后，以便让出行参会者可以一并参加两场活动。有来源依据表明，这是 DevOpsDays 有意采用的策略，而不只是为了避免日程冲突。协调成本高，且受日历安排影响——启用条件，以 Q8 为依据：目标城市和目标季节确实有这样一场大型活动。

失败模式

• 范围吞并成熟活动愿景。 每增加一个“再加一个”的主题／天数／直播环节，都是在增大批次规模，拖慢唯一重要的反馈循环。解决方法：重新阅读书面列出的禁区；启动断路器。
• 日期一再推迟。 为了挽救尚未准备好的范围项目而延长时间线，会消耗讲者、赞助商和参会者的信任，而一场尚不知名的活动还没有这种信任可供消耗。直接砍掉该项目。
• 把“没人会来——我们还没名气”当作首要风险。 这通常只是纸老虎：首届活动的参会人数可观，已有社区基础足以支撑（人数估算见 samber/dev-event-organizer-skills@event-market-fit）。真正的猛虎是场地合同、赞助款到账时间和志愿者缺席——参见事前验尸参考资料。
• 把 CoC 推迟成以后再做的锦上添花之事。 在有来源依据的流程中，这是最早的硬性行政关卡——早于场地，早于日期。任何内容公开之前都应发布；其内容由 samber/dev-event-organizer-skills@event-code-of-conduct 负责。
• 混淆两种时间线。 会议约需 12 个月，黑客马拉松需 4-9 个月，这是由活动形式决定的差异，并非需要折中成“约 8 个月”的分歧。
• 使用个人或公司邮箱作为公开联系邮箱。 这会让人觉得某位组织者的雇主是活动的主办方——对于社区主办的活动而言，这会致命地损害其中立性。从第一天起就使用中立的共享别名。
• 仅凭意向表达的证据就承诺最佳档预算。 在有实际注册人数之前，将支出控制在良好档预算内。
• 过度设计规划机制。 MLH 有依据的警告：整个团队实际采用的最简单共享跟踪表，胜过复杂的方案——这与活动本身范围过大的问题如出一辙，只不过发生在内部工具上。
• 启动简报写得仿佛已有定论，实际上却并非如此。 精良的排版会掩盖团队实际敲定的内容与仍在猜测的内容之间的差距；条目清晰的活动安排一旦看起来整齐，就会被当作定案，无论任何人实际有多大把握。应在猜测所在的位置标明它，在相应章节中标注，而不是放进一份单独的风险清单里——计划一旦开始推进，就没人会再读那份清单。

衡量标准

关卡（在作出相应承诺之前判定通过／不通过）：

• 团队关卡 - 锁定场地或日期之前，至少有 3 名来自至少 3 个组织的组织者。此要求有来源依据（DevOpsDays 的要求）；公司主办的活动可按设计放宽此关卡——应明确说明，而非悄悄豁免。
• 验证关卡 - 在支出超过良好档预算之前，须有实际注册人数（而非意向表达）。借鉴自精益创业的验证阶梯，并非活动行业标准。
• 行政关卡 - 首次公开公告之前，须发布 CoC、设置中立联系别名，并建立共享凭据库。此顺序有来源依据。
• 风险关卡 - 事前验尸中每项会阻碍活动启动的风险，都有明确的负责人和决策日期。覆盖所有会阻碍活动启动的风险，并指定负责人，即为此关卡要求。
• 写明继续／取消决策日期 - 每个日期都应注明会因此降级的范围项目或预算档位。此机制有来源依据；每个具体日期由各活动自行设定。

值得关注的趋势，但在此不设为关卡：售票量激增的检查点（早鸟票占比、活动前一个月的售票占比）属于 samber/dev-event-organizer-skills@event-market-fit 中关于需求的问题——售票期间应查看这些指标，但不要让软性信号迫使活动取消，因为良好／更好／最佳阶梯的存在，正是为了吸收这种波动。

调用示例

• “我们想明年在里昂举办一场 DevOps 大会——当地还没有相关活动。该从哪里着手？”
• “我们公司想在 9 个月后举办首届用户大会。请规划好规模，避免目标过高。”
• “我们三个人在运营一个有 200 人参加的聚会，想把它升级为一天的大会。请制定启动计划。”
• “我想在自己的城市发起一个聚会，其他城市也有类似聚会组成的网络，表示愿意提供帮助。我该向他们寻求什么？”

预期输出：一份启动简报，包含 (1) 意愿与书面列明的禁区，(2) 选定的规模层级及评估过的 2-3 个备选方案，(3) 团队针对关卡的计划，(4) 反向时间线，列出 Go/No-Go 日期和降低预算层级的日期，(5) 列明负责人的事前验尸表。请按章节逐步交付以供确认，不要一次性全部输出。

参考资料

• references/reverse-timelines.md - 两种有来源依据的反向时间线（大会规模为 T-12 个月，黑客马拉松规模为 4-9 个月）、行政筹备的第一步，以及两种委派结构。
• references/scope-and-appetite.md - 将 MVP 类型映射到首届活动形式、验证阶梯、意愿与禁区示例，以及 Good/Better/Best 预算层级。
• references/first-edition-premortem.md - 首届活动的 Tigers/Paper Tigers/Elephants 框架、映射到预算层级的紧迫性阶梯，以及一份事前验尸示例和反面案例。

另请参阅同一集合中的以下内容：

• samber/dev-event-organizer-skills@event-planning-timeline - 适用于任何一届活动的通用反向时间线机制；本技能仅将首届活动的关卡和变体纳入其中。
• samber/dev-event-organizer-skills@event-risk-management - 通用风险登记表和保险；本技能仅负责首届活动的事前验尸。
• samber/dev-event-organizer-skills@event-budget - 本文所述 Good/Better/Best 预算层级背后的实际损益表。
• samber/dev-event-organizer-skills@event-venue-sourcing - 在反向时间线中，将场地作为前置周期最长的事项进行寻源和签约。
• samber/dev-event-organizer-skills@event-vendor-sourcing - 餐饮、周边及其他物资的供应商协调与签约。
• samber/dev-event-organizer-skills@event-debrief - 活动开场后移交给本技能处理的事后复盘。