zhaoxuya520 风险管理（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 个说明可能漏了）
□ 每个风险是否有触发条件（不能是"可能会出问题"）
□ 高/严重风险是否有详细缓解方案
□ 是否标注了负责工作流（不能"全员负责"）
□ 应急预案是否可执行（不能"加班赶工"）
□ 是否包含了非技术风险（资源、需求、进度）
常见坑
- 风险清单是空的——团队太乐观，认为不会出问题
- 风险太宽泛——"可能会延期" → 应该是具体什么会延期
- 缓解方案是废话——"加强沟通" "提高质量"
- 不跟踪风险——列一次就放着，不更新
- 没有触发条件——风险发生了都不知道
- 应急预案不可执行——"加人加班" 不是预案
- 只看技术风险——忽略需求、资源、进度风险
- 风险等级评得过低——为了"看起来项目没风险"
风险监控指标
项目级风险指标：
- 高/严重风险数量（应该 ≤ 3）
- 风险关闭率（每个里程碑应该关闭 30%+）
- 新增风险率（不应该一直增长）
- 实际发生的风险占比（评估识别能力）
风险自身指标：
- 触发频率（接近触发条件的次数）
- 缓解效果（执行缓解后概率/影响是否下降）
配套模板
templates/risk-register-template.md— 风险登记表 + 风险矩阵可视化 + 风险复审模板
与其他 skill 的协作
上游：
wbs-decomposition → 任务拆解时识别每个任务的风险
critical-path → 关键路径上的风险优先处理
orchestration → 并发编排带来的资源冲突风险
下游：
milestone-gate → 高风险任务作为门禁重点
change-control → 变更评估时识别新风险
progress-tracking → 监控风险触发条件
retrospective → 复盘风险识别和应对