risk-management

name	risk-management
description	识别和管理项目风险时使用。适用于项目启动、阶段评审、变更评估。优先使用 PMBOK 风险矩阵 + 缓解方案 + 触发条件。

风险管理（Risk Management）

参考来源：PMBOK Risk Management、Atlassian Project Risk

适用场景

• 项目启动时识别已知风险
• 阶段评审时更新风险清单
• 变更评估时识别新风险
• 跨工作流协作的风险点识别

核心原则

1. 风险不是问题
   风险 = 可能发生的事件
   问题 = 已经发生的事件

2. 风险要早识别
   越晚发现的风险代价越高

3. 不能消除所有风险
   只能降低概率或影响

4. 风险要持续跟踪
   不是列一次就完了，每个阶段都要更新

风险矩阵

                影响
              低    中    高
        ┌─────┬─────┬─────┐
   高   │ 中  │ 高  │ 严重 │
概   ├─────┼─────┼─────┤
率   中 │ 低  │ 中  │ 高  │
        ├─────┼─────┼─────┤
   低   │ 低  │ 低  │ 中  │
        └─────┴─────┴─────┘

行动策略：
  严重：立即处理 / 改变方案
  高：详细计划 / 预留资源
  中：监控 / 触发时响应
  低：记录 / 不主动处理

风险结构

每个风险必须包含：

1. 描述
   - 风险事件（什么会发生）
   - 触发条件（什么情况下会发生）

2. 概率（低/中/高）
   - 高：>50% 会发生
   - 中：20~50%
   - 低：<20%

3. 影响（低/中/高）
   - 高：项目延期 / 上线失败 / 关键路径中断
   - 中：单个工作流延迟 / 部分功能受影响
   - 低：可恢复 / 工作量小

4. 风险等级 = 概率 × 影响

5. 缓解方案（Mitigation）
   - 降低概率：怎么避免发生
   - 降低影响：发生了怎么减少损失

6. 应急预案（Contingency）
   - 真的发生了怎么办

7. 触发条件
   - 什么信号说明风险正在发生

8. 负责人 / 工作流

项目常见风险类别

技术风险

- 第三方 API 不稳定
- 性能瓶颈（数据库/接口）
- 技术选型不当
- 兼容性问题
- 安全漏洞

资源风险

- 工作流能力不足
- 工具不可用（缺工具/版本不兼容）
- 算力不足（AI 模型）
- 外部依赖延迟

需求风险

- PRD 不清晰
- 需求频繁变更
- 验收标准不可测
- 干系人意见冲突

进度风险

- 关键路径延误
- 联调时间不足
- 测试覆盖不足
- 部署窗口紧张

质量风险

- 测试覆盖不足
- 性能未验证
- 安全未评审
- 文档缺失

风险登记表模板

## 项目风险清单

| # | 风险描述 | 类别 | 概率 | 影响 | 等级 | 触发条件 | 缓解方案 | 应急预案 | 负责工作流 |
|---|---------|------|------|------|------|---------|---------|---------|----------|
| R1 | 第三方支付 API 限流 | 技术 | 中 | 高 | 高 | 单分钟请求 > 100 | 实现本地缓存 + 重试 | 切换备用支付 | backend-engineer |
| R2 | API 设计完成时间延后 | 进度 | 中 | 中 | 中 | API 设计 > 30min | 提前提供 Mock | 前端先用 Mock 开发 | api-designer |
| R3 | QA 测试发现严重 Bug | 质量 | 中 | 高 | 高 | Bug 数 > 10 | 加强代码评审 | 回滚到上版本 | qa-engineer |
| R4 | 部署窗口不足 | 进度 | 低 | 高 | 中 | 凌晨部署窗口 < 1h | 提前演练 | 推迟到下次 | devops-engineer |
| R5 | 用户反馈与预期不符 | 需求 | 低 | 中 | 低 | 上线后差评率 > 10% | 内测验证 | 紧急修复 | product-manager |

工作流程

1. 项目启动时：
   - 用风险类别清单做头脑风暴
   - 至少识别 5~10 个风险
   - 给每个风险评分（概率 × 影响）
   ↓
2. 高/严重等级的风险：
   - 制定详细缓解方案
   - 预留资源和缓冲
   ↓
3. 中等级的风险：
   - 监控触发条件
   - 准备应急预案
   ↓
4. 低等级的风险：
   - 记录但不主动处理
   ↓
5. 每个里程碑：
   - 复审风险清单
   - 更新概率和影响
   - 关闭已不存在的风险
   - 添加新发现的风险
   ↓
6. 项目结束：
   - 复盘哪些风险真的发生了
   - 沉淀到 field-journal

质量自检

□ 是否识别了至少 5 个风险（少于 5 个说明可能漏了）
□ 每个风险是否有触发条件（不能是"可能会出问题"）
□ 高/严重风险是否有详细缓解方案
□ 是否标注了负责工作流（不能"全员负责"）
□ 应急预案是否可执行（不能"加班赶工"）
□ 是否包含了非技术风险（资源、需求、进度）

常见坑

1. 风险清单是空的——团队太乐观，认为不会出问题
2. 风险太宽泛——"可能会延期" → 应该是具体什么会延期
3. 缓解方案是废话——"加强沟通" "提高质量"
4. 不跟踪风险——列一次就放着，不更新
5. 没有触发条件——风险发生了都不知道
6. 应急预案不可执行——"加人加班" 不是预案
7. 只看技术风险——忽略需求、资源、进度风险
8. 风险等级评得过低——为了"看起来项目没风险"

风险监控指标

项目级风险指标：
  - 高/严重风险数量（应该 ≤ 3）
  - 风险关闭率（每个里程碑应该关闭 30%+）
  - 新增风险率（不应该一直增长）
  - 实际发生的风险占比（评估识别能力）

风险自身指标：
  - 触发频率（接近触发条件的次数）
  - 缓解效果（执行缓解后概率/影响是否下降）

配套模板

• templates/risk-register-template.md — 风险登记表 + 风险矩阵可视化 + 风险复审模板

与其他 skill 的协作

上游：
  wbs-decomposition → 任务拆解时识别每个任务的风险
  critical-path → 关键路径上的风险优先处理
  orchestration → 并发编排带来的资源冲突风险

下游：
  milestone-gate → 高风险任务作为门禁重点
  change-control → 变更评估时识别新风险
  progress-tracking → 监控风险触发条件
  retrospective → 复盘风险识别和应对