针对连锁式多变量情境的跨职能假设(what-if)建模。与单一假设的压力测试不同,本技能模拟了跨所有业务职能同时发生的复合型逆境。适用于面对复杂风险情境、具有重大下行风险的战略决策,或当用户询问“如果 X 和 Y 同时发生会怎样?”时。
模拟跨所有业务职能的连锁性假设情境。不是单一假设的压力测试 —— 而是展示一个问题如何引发下一个问题的复合型逆境。
scenario planning (情境规划), war room (战况室), what-if analysis (假设分析), risk modeling (风险建模), cascading effects (连锁反应), compound risk (复合风险), adversity planning (逆境规划), contingency planning (应急规划), stress test (压力测试), crisis planning (危机规划), multi-variable scenario (多变量情境), pre-mortem (事前验尸)
python scripts/scenario_modeler.py # 带有连锁建模功能的交互式情境构建器
或者描述情境:
/war-room "如果我们失去了顶级客户且错过 Q3 融资会怎样?"
/war-room "如果 3 名工程师辞职且我们需要在 Q3 交付会怎样?"
/war-room "如果我们的市场收缩 30% 且竞争对手融资了 5000 万美元会怎样?"
/em:stress-test陈述每个变量,包括:
变量 A:顶级客户(28% ARR)发出 60 天终止通知
概率:15% | 时间线:90 天内
变量 B:A 轮融资比目标完成时间延迟 6 个月
概率:25% | 时间线:Q3
变量 C:首席工程师辞职
概率:20% | 时间线:未知
对于每个变量,每个相关的角色都要建模其影响:
| 领域 | 负责人 | 建模内容 |
|---|---|---|
| 现金与跑道 | CFO | 烧钱率影响、跑道变化、过桥贷款选项 |
| 营收 | CRO | ARR 缺口、流失连锁风险、销售管线 |
| 产品 | CPO | 路线图影响、产品市场契合度 (PMF) 风险 |
| 工程 | CTO | 交付速度影响、关键人员风险 |
| 人员 | CHRO | 人员流失连锁反应、招聘冻结的影响 |
| 运营 | COO | 产能、OKR 影响、流程风险 |
| 安全 | CISO | 合规时间线风险 |
| 市场 | CMO | CAC 影响、竞争风险敞口 |
这是核心内容。展示变量 A 如何触发某些领域的后果,进而触发变量 B 的效应:
触发因素:客户流失($560K ARR)
↓
CFO:跑道从 14 个月降至 8 个月
↓
CHRO:招聘冻结;留存风险增加(士气受打击)
↓
CTO:3 个开放的工程岗位被冻结;路线图推迟
↓
CPO:Q4 功能发布延迟 → 客户留存风险
↓
CRO:NRR 下降;现有账户的推进速度降低 → 更多流失风险
↓
CFO:[次生连锁反应 —— 如果不中断,可能会陷入死亡螺旋]
明确命名连锁反应。展示可以在哪里中断它。
模拟三种情境:
| 情境 | 定义 | 恢复 |
|---|---|---|
| 基础 (Base) | 一个变量发生;其他未发生 | 配合计划是可控的 |
| 压力 (Stress) | 两个变量同时发生 | 需要重大响应 |
| 严峻 (Severe) | 所有变量发生;全面连锁反应 | 关乎生存;需要董事会干预 |
对于每个严重程度级别:
定义可衡量的信号,以便在情境被证实之前告知你它正在展开:
客户流失风险触发点:
- 赞助人失联超过 3 周
- 使用量环比下降超过 25%
- 截至 12 月 1 日未确认 Q1 的 QBR(季度业务回顾)
融资延迟触发点:
- 流程启动 60 天后获得的投资意向书(term sheets)少于 3 份
- 领投方要求延长尽职调查(DD)超过 30 天
- 竞争对手以较低估值融资(市场信号)
工程人员流失触发点:
- 工程团队在 Glassdoor 上的动态
- 来自工程师的 2 个及以上推荐面试请求
- 在过去 3 个月内出现需要匹配市场报价的留人情况
对于每个情境:现在(在情境发生前)采取行动,以在情境确实发生时减少影响。
| 对冲措施 | 成本 | 影响 | 负责人 | 截止日期 |
|---|---|---|---|---|
| 建立 50 万美元信贷额度 | $5K/年 | 如果发生流失,可延长 3 个月跑道 | CFO | 60 天 |
| 为 3 名关键工程师提供 12 个月留存奖金 | $90K | 在融资期间锁定团队 | CHRO | 30 天 |
| 实现多元化,使每个客户的营收占比 <20% | 销售投入 | 降低单一客户风险 | CRO | 2 个季度 |
| 压缩融资时间线,启动并行流程 | CEO 时间 | 在跑道耗尽前完成融资 | CEO | 立即 |
每个战况室会议都会产生:
情境:[名称]
变量:[A, B, C]
最可能的路径:[哪种组合实际发生,以及概率]
严重程度级别
基础 (仅 A):[跑道/ARR 影响] —— 恢复:[X 行动]
压力 (A+B):[跑道/ARR 影响] —— 恢复:[X 行动]
严峻 (A+B+C):[跑道/ARR 影响] —— 生存风险:[是/否]
连锁映射图
[A → 领域影响 → B 触发点 → 领域影响 → 最终状态]
早期预警信号
- [信号 1 → 预示哪个情境]
- [信号 2 → 预示哪个情境]
- [信号 3 → 预示哪个情境]
对冲措施(现在采取这些行动)
1. [行动] —— 成本:$X —— 影响:[带来的好处] —— 负责人:[角色] —— 截止日期:[日期]
2. [行动] —— 成本:$X —— 影响:[带来的好处] —— 负责人:[角色] —— 截止日期:[日期]
3. [行动] —— 成本:$X —— 影响:[带来的好处] —— 负责人:[角色] —— 截止日期:[日期]
推荐决策
[一段话。做什么,按什么顺序做,以及为什么。]
每个情境最多 3 个变量。 超过 3 个就是噪音 —— 你无法为 5 个变量同时崩溃做有意义的准备。为那些真正令你担心的 3 个变量建模。
量化或估计。 “营收下降”没有用。“60 天内有 $420K ARR 风险”有用。如果不确定,请使用范围。
不要停留在第一阶效应上。 损害总是存在于连锁反应中,而不是最初的打击。
建模恢复,而不仅仅是影响。 每个情境都应该有一条“我们要怎么做”的路径。
将基础情况与敏感性分析分开。 不要把“可能发生的事”与“可能发生的最坏情况”混为一谈。
不要过度建模。 每个规划周期 3-4 个情境是合适的。更多会产生分析瘫痪。
种子轮 (Seed):
A 轮 (Series A):
B 轮 (Series B):
| 情境类型 | 主要角色 | 连锁反应至 |
|---|---|---|
| 营收未达标 | CRO, CFO | CMO (管线), COO (削减), CHRO (裁员) |
| 关键人员离职 | CHRO, COO | CTO (若是工程), CRO (若是销售) |
| 融资失败 | CFO, CEO | COO (延长跑道), CHRO (招聘冻结) |
| 安全漏洞 | CISO, CTO | CEO (沟通), CFO (成本), CRO (客户影响) |
| 市场转变 | CEO, CPO | CMO (重新定位), CRO (新细分市场) |
| 竞争对手动作 | CMO, CRO | CPO (路线图响应), CEO (战略) |
references/scenario-planning.md —— 壳牌(Shell)方法论、事前验尸、蒙特卡罗、连锁框架scripts/scenario_modeler.py —— 用于结构化情境建模的 CLI 工具