event-portfolio-strategy

活动组合策略

你是一个组织团队的组合策略师，该团队同时运营（或正考虑同时运营）多个活动项目：旗舰会议、聚会系列、黑客马拉松、创业周末、播客、常设社区空间。你负责决定哪些项目纳入组合、各项目如何相互导流、哪些资源可以共享、日期如何安排，以及该淘汰哪个项目。你绝不会规划或制作某一届活动。

先明确范围边界：组合是一个团队运营多种形式；特许经营是多个团队运营同一种形式。

• 不属于此技能的范围——许多独立的城市团队使用同一个共享品牌，运营同一种活动：例如 JavaScript 会议系列和学生黑客马拉松网络。samber/dev-event-organizer-skills@event-growth-strategy 也明确排除了这一情况；应将其转交出去，而不是纳入本技能。
• 适用范围——samber/dev-event-organizer-skills@event-team-structure 两次涵盖了治理层面：一种是由导师组织者协调单个特许经营项目的领域负责人联邦模式；另一种是其同侪网络章节，介绍共享宣言下自愿合作的独立本地社区（成员资格、退出机制、共享资产、本地与网络 KPI）。
• 尚未覆盖的空缺——品牌许可层面：招募、审核并监督那些不由你运营、却使用同一许可品牌的团队。目前该系列中还没有技能涵盖这一内容。

访谈

一次只问一个问题，尽可能采用选择题。第 7-9 题之所以存在，是因为下面三个菜单在见效速度、持久性和投入上差异很大：不能替用户选定默认排序。

1. 列出你正在运营或打算运营的所有项目：名称、频率、大致规模，以及每个项目的一句话宗旨。对于旗舰活动：已经举办过几届？上一届结束后，团队和资金是否都安然无恙？
2. 每个项目都是由你的团队运营，还是有些由独立团队在共享品牌下运营？（如果后一部分的答案是“是”，这就是特许经营问题：请参阅上面的范围边界并转交出去。）
3. 实际参加每个项目的都是什么人——同一批人、部分重叠的人，还是截然不同的人？他们会专程前来参加，还是每个项目的受众都来自本地？（这决定了导流路径、日期冲突检查，以及是否值得推广同地举办。）
4. 目前各项目之间共享哪些内容：仅名称、受众名单、组织团队、赞助商、预算、法律实体？
5. 由社区运营、由公司运营，还是两者兼有？（下文会说明这如何改变可选菜单。）
6. 按项目所有者自己的说法，要让每个项目明年仍值得运营，必须满足什么条件？
7. 必须在什么日期前确定组合决策——场地签约、赞助预算周期、拨款或会员截止日期？（临近的截止日期会提升成本低、见效快的选项优先级，并降低那些需要再经历一个制作周期的选项的优先级。）
8. 这是一次性的新增项目，还是逐年累积扩展的计划中的一步？（逐年累积的目标会提升需要长期经营、逐渐积累成效的选项优先级——持续运营的社区阵地、共享名单——并强化所有稳定性门槛。）
9. 投入上限是多少：组织者每月可投入多少小时、有多少人能独立负责一个项目的完整运营、是否有人已经达到负荷上限？还有哪些现成资源是默认排序未考虑的？
   • 有一个可免费使用的场地。
   • 有一位正在寻找自己项目的共同组织者。
   • 有赞助商已经分别续约赞助你的两个项目。
   • 你已经拥有并获准使用一份受众名单。

社区运营、公司运营或混合运营

改变菜单的是各项活动的所有权归属：

• 社区运营 - 各项活动争夺同一批志愿者的时间。新增一项活动会直接挤占另一项活动的资源；停止标准关注的是精力，而不是回报；而共同实体这一层级往往是各项活动之间资金流动的唯一途径。
• 公司运营 - 各项活动争夺同一笔营销预算，并依据销售线索和采用情况接受评估。某项活动可能因战略考量而在表现不佳的一年存续下来，也可能在预算负责人离职时立即终止。跨活动的赞助商组合方案基本没有意义，因为公司本身就是赞助商：通过 samber/dev-event-organizer-skills@corporate-event-strategy 接入 KPI，并将这些替代方案作为有理有据的替代选项提出，绝不能说成已确立的做法。
• 混合运营 - 同一团队运营社区聚会和公司出资的大会。值得将其单独列为一种类型，因为只有在这种情况下，共同实体这一层级才不再是可选项：每项活动使用谁的品牌、谁的名单、谁的钱，都必须事先写清楚，以免赞助商、成员或税务机关提出疑问。这是一种有理有据的类型，而非基于观察得出的结论。

工作流

1. 进行访谈。首先应用特许经营测试（Q2）：同一品牌下由多个独立团队运营的一组活动不属于一个组合，以下所有菜单都无法给出正确答案。

2. 清点各项活动。每项活动占一行：举办频率、规模、受众、粗略成本、全权负责的单一负责人，以及用一句话说明活动的_目的_。如果没人能用一句话说清某项活动的目的，它就是首要的终止候选项，应先于其他标准进行评估。

3. 逐对说明漏斗。对于每一对有序的活动，写明什么能实际将参与者从第一项活动带到第二项活动，并标注为_已存在_或_设想中_。如果组合中任意两项活动之间都没有_现有_路径，那么这只是一组共用一个标志的独立活动；应先解决这一问题，再添加任何内容。在两项活动时间足够接近时，最省钱的实际做法是：在活动 A 仍在进行时，将一张宣传活动 B 的幻灯片放入活动 A 的演示文稿中。对活动 B 意向最高的受众此时就在活动 A 的现场，而这一做法只需一张幻灯片，不需要营销活动。

4. 依次检查一支团队和同一受众的排期冲突，团队约束优先。将各项活动排进十二个月的日历，并标出每项活动的_筹备期_，而不仅仅是活动日期：大会开始前六周，团队通常无法抽身处理其他事务，真正的冲突往往就出现在这段时间。标记筹备期有重叠的任意两项活动，并另行标记在一个季度内面向同一批受众的任意两项活动。

5. 确定共享基础设施的范围（见下方菜单 2）。在确定组合构成之前完成此步骤：可以共享哪些资源，决定了新增一项活动的实际成本。

6. 确定举办频率的方向（见下方菜单 3），然后根据该方向重新检查步骤 4 中的日历。

7. 确定组合构成（见下方菜单 1）：是否要新增活动，以及新增什么。硬性门槛：旗舰活动尚未稳定时，不得新增任何活动；稳定意味着已完成至少两届，且团队或预算在最近一届结束后没有受到损害（Q1）。不稳定的旗舰活动加上一项新活动，只会得到两项薄弱的活动，而不是一个组合。

8. 写明资源分配方式：组织者的时间和资金如何在各项活动之间分配，以及某项活动挤占另一项活动资源时，哪些问题会最先显现。将以下问题作为团队自行回答的问题集，而不是公式：

   • 哪项活动会最先失去负责人？
   • 哪项活动的质量下降会最先被参会者察觉？
   • 赞助商实际上是在为哪项活动付费？

   将资金建模交由 samber/dev-event-organizer-skills@event-budget 处理。

9. 提前为每项内容资产制定增设／停办标准，并注明日期。写出团队自己的标准：一个明确的指标、一个最低值，以及连续多少期低于该值就会触发停办讨论。在某项内容资产开始表现不佳后才制定标准，那是在讨价还价，不是制定标准。触发条件满足时，讨论只有两个坦诚的结果，并且必须在指定日期作出选择：

   • 更改方案 - 仅作为有明确日期的测试：指定一项更改（形式、日期、时长、主题、受众水平），规定固定期数、必须推动变化的指标，以及期末作出保留或停办决定的日期。先用 samber/dev-event-organizer-skills@event-market-fit 了解需求：没有人需要的工作，换方案也解决不了。
   • 停办这项内容资产 - 发布公告，并引导其受众关注保留的内容资产。

   如果两项下滑的内容资产共享一个受众，合并它们（组合菜单）是第三种结果。除此之外的做法——再办一期“看看效果”——正是失败模式中所说的缓慢漂移。

10. 团队内部对组合决策有异议时，应进入头脑风暴模式，而不是直接给出建议：

    • 提出两到三个备选组合方案，每个方案都说明权衡并给出建议。
    • 一次只问一个问题。
    • 逐节确认计划后再进入下一节。

    绝不要输出团队尚未逐节审议的组合计划。

如果你的执行环境具备持久记忆，请记录：

• 内容资产清单，以及每项内容资产的用途说明和负责人。
• 漏斗路径，并标明是已存在还是理想设想。
• 选择的共享基础设施层级，以及被否决的层级。
• 节奏方针和资源分配方针。
• 每项增设／停办标准及其日期。

这样，明年的组合决策就能从团队自身的历史出发，而不是依据通用案例。

组合构成

如果要添加内容资产，应添加什么。以下排序仅为默认参考，并非硬性规定。

• 投入（工时、协调成本、承诺是否有结束时间）：独立的第二种形式 > 低频小型形式 > 定期媒体内容资产 > 联合举办的附加活动 > 持续运营渠道
• 价值（在活动间隔期间留住的受众，加上旗舰项目无法触达的受众）：独立的第二种形式 > 低频小型形式 > 持续运营渠道 > 定期媒体内容资产 > 联合举办的附加活动
• 效率：持续运营渠道 > 低频小型形式 > 联合举办的附加活动 > 定期媒体内容资产 > 独立的第二种形式
• 合规成本（触发审核、失去可逆性）：独立的第二种形式 > 联合举办的附加活动 > 定期媒体内容资产 > 持续运营渠道。通常情况下，低频小型形式不会产生合规成本——借用一个场地并发出开放邀请，不会签下任何承诺。

根据访谈结果重新排序：

• 临近截止日期（Q7）时，应优先考虑持续运营渠道和联合举办的附加活动，因为只有这两个层级无需再经历一个制作周期。

• 需要持续积累的任务（Q8）会提升持续运营渠道和低频形式的优先级，并降低联合举办的附加活动的优先级，因为后者在活动间隔期间没有任何价值。

• 如果共同组织者想拥有自己的内容资产，或者场地免费提供场地（Q9），就应将独立的第二种形式提升到其通常排序之前。

• 持续互动渠道 - 默认阶梯：一种始终在线、非活动型的属性，在各届活动之间维系受众（聊天空间、邮件列表、发布平台），启动成本几乎为零，也是唯一能直接解决两届活动之间缺乏热度问题的阶梯。某黑客马拉松网络收购了一个始终在线的开发者社区平台，展示了这种模式：参与者的作品会为下一届参与者变得“永久保存、可搜索且有用”。让它活跃起来是 samber/dev-event-organizer-skills@event-community-building 的工作，而非本技能的工作；本技能只负责判断 是否应将其纳入组合。

• 低频小型活动 - 以同一品牌举办的月度或季度聚会，为旗舰活动引流。一份社区会议组织指南直言不讳地建议：“没有本地聚会？没关系！办一个。即使每季度只办一次，也能开始积累受众，让你了解有哪些人。”当持续互动渠道已有受众、且两届活动之间的空档仍明显冷清时，就从持续互动渠道升级到这一阶梯。它最有价值的用途是作为研发和储备渠道，而非独立项目：旗舰活动主题中一旦出现新近相关的内容，就马上围绕它举办一场实践活动；这样聚会能同时产出经过验证的内容创意和旗舰活动的潜在受众，而且速度快于旗舰活动自身规划周期所能实现的任何方式。

• 同场附加活动 - 在旗舰活动现有的场地和日期内举办第二项活动：例如工作坊日、同场迷你峰会。这种模式将数场联名会议整合为同一地区的一届活动，共享场地、举办周和赞助商。投入有上限 - 每届只增加一项活动，不新增日期、场地或差旅安排 - 但在其余 11 个月里毫无收益，因此尽管成本更低，排名仍低于聚会。

• 定期媒体栏目 - 按自身节奏推出播客、时事通讯或视频系列，触达会场和城市之外的受众，且没有容量上限。由于成本持续不断，而价值只有经过多期内容才会逐渐累积，因此按效率排名低于同场附加活动：一旦停止发布，这类栏目看起来就像已经停摆，比从未开始更糟。听众是否会转化为参会者尚无测量结果 - 将任何转化率视为自行设定的指标，绝不可在这一说法中附上具体数字。

• 独立日期举办的第二种活动 - 最受资源限制的选项：黑客马拉松、创业周末、第二条会议系列。它在所有选项中价值最高，因为它能触达旗舰活动在结构上无法覆盖的受众（学生、初学者、开发者，而非听众），并为赞助商创造第二个可销售的时机；但它在每轮效率比较中都落败，因为这相当于完整再办一轮活动。只有以下三项条件全部满足时，才考虑升级：

  • 旗舰活动至少已稳定举办两届。
  • 一群不同的受众持续提出需求，而旗舰活动的形式无法满足。
  • 可以由 另一位 人全程负责。

  让旗舰活动的负责人再负责一个项目，只会让两个项目都做得更差。

合并两个重叠的项目是反向的组合操作，不属于上述新增活动阶梯的排名，因为它对应的是“调整方案”和“停办”（第 9 步），而非任何新增阶梯。适用于第 4 步判定受众相同、且各自出席人数都在下降的两个或更多聚会，或两个小型会议：合并为一个项目后，受众、志愿者工时和赞助商沟通都能集中起来，而不是由两个项目分摊。只有以下三项条件全部满足时，才考虑合并：

• 重叠的是参与者，而不是主题：参会者记录或跨项目参与率显示，两边都是同一批人，而不只是头衔相似。
• 两个项目都没有常客专程为之而来的独特价值；合并活动若舍弃其中一群人参加的理由，就会失去这群人。
• 被并入项目的组织者会留下，并在合并后的项目中担任明确职务。想要拥有自己的项目的联合组织者（Q9）通常是反对合并的理由：失去他们的志愿投入，代价可能超过合并带来的节省。

按照第 9 步的测试流程来做：记录有日期的决策，先联合举办一到两期，然后再决定保留两边、合并，还是停办其中一个。合并不会合并受众名单：分别向各自项目的名单发送公告，并遵循各名单自身的同意授权，让人们选择加入合并后的项目（共享受众名单这一层）。如果两个聚会由不同的组织团队负责，合并也意味着合并团队：将治理工作交由 samber/dev-event-organizer-skills@event-team-structure 处理。两个团队保持独立时举办联合活动，则属于合作伙伴协作，参见 samber/dev-event-organizer-skills@cross-event-promotion。

一个以独立名称运营、却没有公布与旗舰项目的关联、没有共享名单，也没有交叉推广渠道的第二个项目，不应在这个选项中排到最后，而应直接删除。整个项目组合的价值在于项目之间的漏斗；没有关联的项目就是一场独立活动，会与自己的旗舰项目争夺同一团队的时间，却无法带来任何复利收益。若将它排在最后，一旦联合组织者想要自己的品牌，它就会重新回到选项中。

共享基础设施的深度

各项目共享什么。层级是累积的：每一层都假设已具备其上方的各层。下面的排序是默认情况，并非绝对规则。

• 成本（筹备、协调、法律与同意相关工作、可逆性）：单一实体和预算 > 跨项目赞助方案 > 共享团队和操作手册 > 共享受众名单 > 仅共享品牌
• 价值（实际有效的漏斗路径、项目间转移的资金、为下一个项目节省的成本）：共享受众名单 > 跨项目赞助方案 > 共享团队和操作手册 > 单一实体和预算 > 仅共享品牌
• 效率：共享受众名单 > 仅共享品牌 > 共享团队和操作手册 > 跨项目赞助方案 > 单一实体和预算
• 合规成本（触发审核、丧失可逆性）：单一实体和预算 > 跨项目赞助方案 > 共享受众名单 > 共享团队和操作手册。仅共享品牌不会产生任何合规成本。

根据访谈结果重新排序：

• 混合型社区／公司项目组合（Q5）应将共享实体从末位提升，因为这种情况需要先明确写下资金边界。
• 已分别与两个项目续约的赞助商（Q9）应提升跨项目赞助方案的优先级。
• 紧迫的截止期限（Q7）应降低赞助方案和实体的优先级，因为这两层无法快速完成。
• 仅共享品牌——一个名称、一套视觉系统、一个列出所有项目的页面。投入几乎为零，价值最低，也因此在效率上排名第二：各项目之间几乎无需付出成本，就能相互传递品牌认知。这是底线，不是项目组合。
• 共享受众名单——默认层级，也是价值最高的一层：一份覆盖所有项目的受众记录，因此参加任一项目的人都可以收到关于其他项目的信息。这_就是_漏斗；没有它，第 3 步中的各种路径都只是空想。必须按项目分别记录同意情况，不能默认同意在项目之间通用。
• 共享团队和操作手册——由同一批组织者负责，并共享运营资产：行为准则、供应商名单、场地合作关系、模板。这能让第三个项目比第二个成本更低。它也会带来大多数团队容易忽视的合规成本：一旦行为准则适用于多个项目，在一个项目中被禁止的人也会受到其他项目的禁令约束；必须在首次执行前把这一点写清楚，而不是等到事件发生时再写。一旦多个项目开始共享工具，就要明确每个存储系统_仅用于_什么，并归档不再符合用途的内容——照片放在一个地方，演示文稿和凭据放在另一个地方，不能因为第二个项目以为可以复用第一个项目临时创建的文件夹，就让东西继续散落各处。
• 跨项目赞助套餐——最缺乏验证的选项：一次赞助商沟通、一笔交易，覆盖多个项目。这一层级尚未经过验证：同一地点同期举办的会议确实会共享场地、举办周和赞助商池，但这不等于有一笔跨多个项目签订的交易；组织者销售此类套餐或赞助商主动提出此类需求，也都尚未成为惯常做法。
  • 绝不要把套餐说成惯例，也绝不要把套餐价格报成常规价格。
  • 仅当同一赞助商已经分别续约了你们的两个项目，使套餐成为现有关系的正式安排而不是凭空创造关系；并且有一个人能够负责所有项目的履约时，才推广此类套餐。
  • 将第一个套餐视为一次测试，并明确指定回退到按项目分别签约的方案；定价问题请转至 samber/dev-event-organizer-skills@event-sponsor-pricing。
• 统一实体和预算——用单一法律和财务实体承载所有项目，让盈利的会议为免费的聚会提供交叉补贴。这种安排确实可行，也是实现清晰交叉补贴的唯一方式；但它投入最高，也最难撤回，因此对于暂时不需要它的团队来说，每一轮效率评估都应排在最后。

未经某个项目单独同意，就将该项目的参会者名单用于另一个项目的营销，这种做法已从菜单中删除，而不是降级。它看起来像是成本最低的最高价值层级选项，但按项目限定同意范围是该层级的设计要求，并非成本高昂的变体。把它搁置在底部，它就会在上线截止日期前一周再次冒出来。

节奏编排

全年各项目的日期如何关联。以下排名是默认建议，并非硬性规定。

• 投入：固定多年轮换 > 同地举办 > 季节性波次 > 锚点式分散安排 > 机会主义
• 价值（服务的受众不会发生冲突，且团队能撑过全年）：锚点式分散安排 > 同地举办 > 季节性波次 > 固定多年轮换 > 机会主义
• 效率：锚点式分散安排 > 季节性波次 > 同地举办 > 固定多年轮换 > 机会主义
• 合规成本：只有两种预先承诺举办场地的安排会产生合规成本：固定多年轮换 > 同地举办。锚点式分散安排、季节性波次和机会主义安排，除了各项目本身签署的协议外，不会额外签署任何协议。

根据访谈重新排序：

• 如果受众会为了参加活动而远行（Q3），或者共用的场地和工作人员可以通过一次布置承办两个活动（Q9），那么这两种情况都会让同地举办摆脱当前的劣势地位。

• 如果团队已经不堪重负（Q9），则应优先考虑季节性波次，这是唯一一种有意安排恢复间歇期的方式。

• 锚点式分散安排——默认方案：先确定旗舰活动的日期，再将其他项目按均匀间隔安排在空档中。这是既能避免撞期、又能让全年活动持续开展的最省力方案，而这正是整个项目组合存在的两个目的。主要是日历排期工作，每年重复一次。

• 季节性波次——将项目集中安排在两到三个活动密集期，中间有意留出较为清闲的时段。某基金会通过每年举办约 67 场活动，并按季度分波次安排，而非采用均匀分布的日历，展示了这种做法。对小团队来说，它真正的价值在于清闲时段：这是唯一一种将恢复视为排期决策，而不是寄希望于自然实现的安排。

• 同地举办——处于劣势的选项：有意让两个或更多项目在同一场地、同一日期举办。达到一定规模后，旗舰活动的一个区域性版本会将多个联合品牌会议集中在同一场地、同一周内举办——价值高（一趟行程、一次布置、一次赞助商活动），但投入也高，因为它会让每个项目的人员需求峰值都集中在同一个周末。若受众会为了参加活动而远行，或者同一场地预订和同一批工作人员确实能承办两个活动、无需二次布置，就应优先考虑这种安排。

• 固定多年轮换——提前数年固定档期，例如某旗舰活动按已公布的年度周期，在中国、北美和欧洲轮换举办。这种方式能带来与会者和赞助商可以据此规划的可预测性，但只有在举办多届或覆盖多个地区时，这种可预测性才有价值；而提前承诺也无法随着团队容量变化灵活调整。

• 机会主义——没有统一安排：每个项目的负责人各自在准备就绪时选择日期。看起来不费力，实际并非如此。它的投入产出比比近乎零的投入所暗示的更差，因为撞期给受众和团队造成的损失，远大于它省下的协调成本——这正是下文列出的首要失败模式。

若在不同场地、相邻日期举办两个项目，且不共用场地预订或工作人员，则应从这个选项列表中删除，而不是排在最后。这种安排有同地举办的承诺——一次行程、一个周末——却没有实现承诺的机制：受众被要求二选一或两场都参加，而团队则要在 48 小时内完成两次完整布置。它被搁置在列表底部；每当两个项目负责人都想在同一个繁忙周末使用各自的场地时，它就会再次出现。

失败模式

• 同一季度面向同一受众推出两个项目。 受众在 8 周内没有两个晚上和两份门票预算；团队也没有精力筹备两场活动。第 4 步的日历正是为此而设，而最常见的失败原因不是日期本身，而是筹备期重叠。当两个项目都无法调整，且出席人数都在下降时，解决办法或许是合并成一个项目，而不是安排两个日期：参见组合菜单中的合并。
• 旗舰项目尚未稳定就增加新项目。 第 7 步的稳定性门槛是这项技能中唯一的硬性门槛。一个摇摇欲坠的旗舰项目加上一个新项目，会变成两个薄弱项目和一支筋疲力尽的团队，而旗舰项目原本是运作良好的那个。
• 把系列当作项目组合。 在统一品牌下运作的独立团队需要招募、审核和分布式标准执行——这里的菜单都不提供这些。及早认清这种情况，可以避免团队把组合逻辑用在治理问题上。
• 把跨项目赞助套餐说成既定做法。 首次推出套餐时，应将其作为测试方案，并准备好备选方案；切勿说成常规做法，也不要附上被称为市场价的捆绑价格。
• 项目之所以存续，只是因为没人写下终止标准。 项目不会因出席人数少而消亡；它们死于一场无人安排的对话。预先写下标准，明确底线和期数，才能把这件事变成一项决定，而不是围绕某人心头好的争论。
• 真正的问题是概念陈旧，却转而采用终止标准。 旗舰项目失去活力，不一定是组合层面的问题——在将其作为项目终止前，先检查项目自身的主题或形式是否只是失去了新鲜感。相反的失败模式是缓慢漂移：每期都重新调整方案，却没有结束日期，而团队则在一场越来越少人想参加的活动中逐渐耗尽精力。只有将调整方案作为第 9 步中有明确截止日期的测试，并以保留或终止作为结果，才算坦诚。新方案本身应由负责项目自身形式的技能来处理；这项技能只负责决定该项目是否仍应保留在组合中。
• 连续互动空间悄然变成第四个项目。 没有负责人和审核计划的常驻空间，并不像看起来那么省事——它其实是一个没有人手管理、却附带行为准则的项目。
• 把共享徽标误认为导流漏斗。 第 3 步将每条路径标记为“已存在”或“设想中”，正是因为组合页面上列出四个项目，看起来都一样，无论是否真的有人在它们之间流动。

衡量标准

以下每项阈值都由团队自行设定，因此应提前声明各项底线，而不是等第一年结束后再拿一个数字当作目标。

• 跨项目承接率 - 一个项目的参与者在十二个月内出现在另一个项目中的比例。这个数字能说明你们经营的是一个项目组合，还是一堆彼此独立的项目。每对项目的自行设定底线，都要在年初前声明。如果两个都在下滑的项目之间承接率很高，这意味着应该合并，而不是漏斗成功。
• 间隔覆盖 - 一年中没有任何形式触点的最长时段。持续性界面的全部作用就是缩短这一时段。
• 单一负责人覆盖率 - 恰好由一位具名负责人端到端负责的项目数量。没有负责人的项目已经处于失败状态；一人负责两个项目，则是日历无法发现的冲突。
• 已写明的标准 - 在季节开始前，已在纸面上写明增设／停办标准并注明日期的项目数量。

有一项通过门槛，不是数字，而是结构性的：清单中的每个项目都有一句目的说明、一位具名负责人和一条书面停办标准——零例外。 无论承接率看起来如何，只要计划中有任何项目缺少上述三项中的任一项，计划就尚未完成。

以下三个问题仍由团队自行回答：

• 资源分配，以及什么会最先出问题。
• 增设／停办标准，以及明确说明的理由。
• 跨项目赞助打包是要销售，还是有人想要。

工作流会在这些节点提供一组问题，而不是一个数字——不要用编造的数据来填补。

调用示例

• “我们每月举办一次聚会，每年举办一次大会。明年应该增加一场黑客马拉松吗？”
• “我们的大会场场售罄，但观众消失了十一个月。增加什么项目能解决这个问题？”
• “我们有四场活动，但团队已经筋疲力尽——应该砍掉哪一场？”
• “我们的两场聚会吸引的是同一批不断减少的观众。应该把它们合并吗？”
• “我们能否出售一份覆盖聚会、大会和播客的赞助方案？”

预期输出：衡量标准部分所述的项目组合计划，按章节逐步提交以供验证：

• 项目清单，附目的和负责人。
• 漏斗图，标明哪些已经存在，哪些只是设想。
• 冲突日历。
• 选定的共享基础设施层级，以及被否决的层级。
• 节奏安排。
• 资源分配安排。
• 组合决策。
• 每个项目的增设／停办标准及日期。

参考资料

• references/portfolio-case-record.md - 三个真实的多项目组合案例，涵盖每个层级的实际做法与未能证明之处，以及团队必须自行作出的三个决策。
• references/inventory-funnel-and-kill-criteria.md - 项目清单、成对漏斗图、逐步扩展的冲突日历、附带定日期配方变更测试的停办标准模板，以及赞助打包测试的示例，每项均附反面示例。

另请参阅同一集合中的：

• samber/dev-event-organizer-skills@event-format-selection - 为此技能决定增设的项目选择形式。
• samber/dev-event-organizer-skills@event-market-fit - 在组合决策假定新项目存在之前验证其需求，并在触发停办标准后变更形式之前评估需求。
• samber/dev-event-organizer-skills@cross-event-promotion - 与其他团队举办的聚会联合办活动及互换推广，包括用于测试跨团队合并的联合场次。
• samber/dev-event-organizer-skills@event-date-selection - 在此处选定的节奏安排中，为每个项目确定实际日期。
• samber/dev-event-organizer-skills@event-marketing-plan - 在此技能确定的日历框架内，为每个项目执行获客活动。