Reference sources: PMBOK Risk Management,Atlassian Project Risk
Applicable Scenarios
- Identify known risks at project initiation
- Update the risk list during phase reviews
- Identify new risks during change assessments
- Identify risk points in cross-workflow collaboration
Core Principles
1. 风险不是问题
风险 = 可能发生的事件
问题 = 已经发生的事件
-
Risks must be identified early The later a risk is discovered, the higher the cost
-
Not all risks can be eliminated Only the probability or impact can be reduced
-
Risks must be tracked continuously It is not done after listing once; it must be updated at every phase
## 风险矩阵
```text
影响
低 中 高
┌─────┬─────┬─────┐
高 │ 中 │ 高 │ 严重 │
概 ├─────┼─────┼─────┤
率 中 │ 低 │ 中 │ 高 │
├─────┼─────┼─────┤
低 │ 低 │ 低 │ 中 │
└─────┴─────┴─────┘
行动策略：
严重：立即处理 / 改变方案
高：详细计划 / 预留资源
中：监控 / 触发时响应
低：记录 / 不主动处理
Risk Structure
Each risk must include:
1. 描述
- 风险事件（什么会发生）
- 触发条件（什么情况下会发生）
2. 概率（低/中/高）
- 高：>50% 会发生
- 中：20~50%
- 低：<20%
3. 影响（低/中/高）
- 高：项目延期 / 上线失败 / 关键路径中断
- 中：单个工作流延迟 / 部分功能受影响
- 低：可恢复 / 工作量小
4. 风险等级 = 概率 × 影响
5. 缓解方案（Mitigation）
- 降低概率：怎么避免发生
- 降低影响：发生了怎么减少损失
6. 应急预案（Contingency）
- 真的发生了怎么办
7. 触发条件
- 什么信号说明风险正在发生
8. 负责人 / 工作流
Common Project Risk Categories
Technical risk
- 第三方 API 不稳定
- 性能瓶颈（数据库/接口）
- 技术选型不当
- 兼容性问题
- 安全漏洞
Resource risk
- 工作流能力不足
- 工具不可用（缺工具/版本不兼容）
- 算力不足（AI 模型）
- 外部依赖延迟
Requirements risk
- PRD 不清晰
- 需求频繁变更
- 验收标准不可测
- 干系人意见冲突
Schedule risk
- 关键路径延误
- 联调时间不足
- 测试覆盖不足
- 部署窗口紧张
Quality risk
- 测试覆盖不足
- 性能未验证
- 安全未评审
- 文档缺失
Risk Register Template
## 项目风险清单
| # | 风险描述 | 类别 | 概率 | 影响 | 等级 | 触发条件 | 缓解方案 | 应急预案 | 负责工作流 |
|---|---------|------|------|------|------|---------|---------|---------|----------|
| 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 |
Workflow
1. 项目启动时：
- 用风险类别清单做头脑风暴
- 至少识别 5~10 个风险
- 给每个风险评分（概率 × 影响）
↓
2. 高/严重等级的风险：
- 制定详细缓解方案
- 预留资源和缓冲
↓
3. 中等级的风险：
- 监控触发条件
- 准备应急预案
↓
4. 低等级的风险：
- 记录但不主动处理
↓
5. 每个里程碑：
- 复审风险清单
- 更新概率和影响
- 关闭已不存在的风险
- 添加新发现的风险
↓
6. 项目结束：
- 复盘哪些风险真的发生了
- 沉淀到 field-journal
Quality Self-Check
□ 是否识别了至少 5 个风险（少于 5 个说明可能漏了）
□ 每个风险是否有触发条件（不能是"可能会出问题"）
□ 高/严重风险是否有详细缓解方案
□ 是否标注了负责工作流（不能"全员负责"）
□ 应急预案是否可执行（不能"加班赶工"）
□ 是否包含了非技术风险（资源、需求、进度）
Common Pitfalls
- The risk list is empty— The team is too optimistic and thinks nothing will go wrong
- Risks are too broad— "may be delayed" → it should be specifically what will be delayed
- Mitigation plans are meaningless— "strengthen communication" "improve quality"
- Risks are not tracked— Listed once and left there, not updated
- No trigger conditions— You do not even know when the risk occurs
- Emergency plans are not executable— "add people and work overtime" is not a plan
- Only looking at technical risks— Ignoring requirements, resource, and schedule risks
- Risk levels are rated too low— In order to "make the project look risk-free"
Risk Monitoring Metrics
项目级风险指标：
- 高/严重风险数量（应该 ≤ 3）
- 风险关闭率（每个里程碑应该关闭 30%+）
- 新增风险率（不应该一直增长）
- 实际发生的风险占比（评估识别能力）
风险自身指标：
- 触发频率（接近触发条件的次数）
- 缓解效果（执行缓解后概率/影响是否下降）
Supporting Templates
templates/risk-register-template.md— Risk register + risk matrix visualization + risk review template
Collaboration with Other Skills
上游：
wbs-decomposition → 任务拆解时识别每个任务的风险
critical-path → 关键路径上的风险优先处理
orchestration → 并发编排带来的资源冲突风险
下游：
milestone-gate → 高风险任务作为门禁重点
change-control → 变更评估时识别新风险
progress-tracking → 监控风险触发条件
retrospective → 复盘风险识别和应对