Risk Assessor

风险评估

风险评估技能可帮助团队主动识别、分析、确定优先级并缓解项目风险，防止风险演变成问题。它运用系统化的风险管理框架，发现威胁、评估其发生概率和影响，并制定可执行的缓解策略。

此技能擅长开展事前验尸练习、创建风险登记表、评估概率和影响、制定应急计划，以及建立早期预警指标，以便在风险破坏项目之前及时发现。

风险评估遵循这样的原则：处理风险的最佳时机是在它演变成危机之前。主动进行风险管理有助于做出更好的决策、制定切合实际的计划，并减少意外。

核心工作流

工作流 1：开展风险评估

步骤：

1. 识别风险

   • 事前验尸练习：设想项目已经失败；是什么导致了失败？
   • 头脑风暴：团队提出潜在风险
   • 类别审查：检查常见风险类别
     • 技术：架构、性能、安全性、可扩展性
     • 进度：截止日期、依赖项、资源可用性
     • 资源：团队能力、技能缺口、预算限制
     • 外部：市场变化、监管要求、供应商依赖
     • 质量：Bug、技术债、用户体验
     • 组织：利益相关者意见一致、优先级变化
   • 历史分析：回顾过去项目中的问题
   • 专家意见：咨询安全、法律等领域的专家

2. 记录风险

   • 针对每项风险，记录以下信息：
     • 描述：风险是什么？
     • 类别：风险属于哪种类型？
     • 触发因素：什么情况会导致风险发生？
     • 影响：风险发生后会怎样？
     • 负责人：谁负责监控和管理这项风险？

3. 评估概率

   • 评估风险发生的可能性：
     • 低（1）：发生概率 < 10%
     • 中（2）：发生概率为 10-50%
     • 高（3）：发生概率 > 50%
   • 根据数据、经验和专家判断进行评估
   • 记录概率评估所依据的假设

4. 评估影响

   • 评估风险发生后的严重程度：
     • 低（1）：轻微延误或成本增加
     • 中（2）：对进度或范围造成重大影响
     • 高（3）：项目失败或对业务造成重大影响
   • 从多个维度考虑：时间、成本、质量、声誉
   • 采用最坏情况思维

5. 确定风险优先级

   • 计算风险分数 = 概率 × 影响
   • 按分数确定优先级（1-9 分制）：
     • 严重（7-9）：立即处理
     • 高（4-6）：制定缓解计划
     • 中（2-3）：定期监控
     • 低（1）：跟踪，但不采取主动缓解措施
   • 聚焦优先级最高的 5-10 项风险

**输出：**包含已识别、评估并确定优先级的风险的风险登记表。

工作流 2：制定缓解策略

针对每项高优先级风险：

1. 选择策略类型

   • 规避：消除风险（更改方法、移除功能）
   • 缓解：降低风险发生概率或影响（增加测试、聘请专家）
   • 转移：将风险转移给第三方（保险、供应商 SLA）
   • 接受：承认风险，并规划风险发生时的应对措施

2. 制定缓解计划

   • 制定降低风险的具体措施
   • 指定负责人和截止日期
   • 明确成功标准
   • 估算成本和工作量
   • 识别依赖项

3. 制定应急计划

   • “如果风险发生，我们将……”
   • 备用选项和替代方案
   • 恢复时间目标
   • 面向利益相关者的沟通计划
   • 资源需求

4. 定义早期预警指标

   • 表明风险正在显现的先行指标
   • 监控频率和方式
   • 触发应急计划的阈值
   • 负责监控的人员和接收警报的人员

**输出：**责任分工明确的风险缓解计划和应急计划。

工作流 3：监控和更新风险

每周：

1. 审查早期预警指标
2. 如果条件发生变化，更新概率／影响
3. 检查缓解措施的状态
4. 添加新识别的风险
5. 关闭已解决或已过时的风险

每月：

1. 全面审查风险登记册
2. 评估缓解措施的有效性
3. 向利益相关方报告主要风险
4. 根据新信息调整优先级
5. 更新应急计划

触发时：

• 如果风险发生，启动应急计划
• 记录发生的情况和经验教训
• 更新风险模型，以供未来项目使用

工作流 4：事前验尸练习

团队引导会议（60 分钟）：

1. 设定场景（5 分钟）

   • “想象一下，现在是 6 个月后，这个项目惨败了”
   • “我们正在进行事后复盘，以了解哪里出了问题”
   • “是什么导致了失败？”

2. 个人头脑风暴（10 分钟）

   • 每个人静静写下失败场景
   • 鼓励创造性思考，也鼓励提出令人不安的想法
   • 不要审查或筛选

3. 轮流分享（20 分钟）

   • 每个人分享自己的场景
   • 将所有内容记录在共享白板上
   • 不争论、不辩解，只倾听

4. 归类并确定优先级（15 分钟）

   • 将类似的失败模式归为一组
   • 投票选出最可能发生或影响最大的情况
   • 找出 5-10 个主要失败场景

5. 转化为风险（10 分钟）

   • 将失败情景重新表述为当前风险
   • 添加到风险登记册
   • 指定初步负责人

输出： 根据团队集体智慧识别出的风险清单。

快速参考

操作	命令／触发语
评估风险	"assess risks for [project]"
事前验尸	"run pre-mortem for [project]"
风险登记册	"create risk register"
更新风险	"update risk status"
主要风险	"what are the top risks"
缓解计划	"create mitigation plan for [risk]"
应急计划	"plan contingency for [risk]"
风险报告	"generate risk report"

最佳实践

• 营造安全氛围：鼓励坦诚地识别风险；奖励及早提出问题
• 以悲观者的视角思考：识别风险时，假设墨菲定律成立（凡是可能出错的事，终将出错）
• 尽可能量化：评估概率和影响时，使用数据和指标，而不只是直觉
• 聚焦主要风险：无法缓解所有风险；应聚焦优先级最高的风险
• 每项风险都要有人负责：每项风险都需要指定一名负责人来监控并推动缓解措施
• 未雨绸缪：在平静时制定的应急计划，胜过危急时刻仓促制定的计划
• 定期审查：风险会不断变化；每周审查能让登记册保持最新且可执行
• 借鉴历史经验：过去项目的失败是识别未来风险的绝佳教训
• 随着了解加深而更新概率：随着项目推进，根据新信息调整概率
• 不要忽视令人不安的事实：你不愿讨论的风险往往最危险
• 透明沟通：与利益相关方分享主要风险；意外会摧毁信任
• 在谨慎与推进之间取得平衡：风险管理不应让行动停滞，而应为行动提供依据

风险类别检查清单

技术风险

• 未经验证或全新的技术
• 性能或可扩展性方面的担忧
• 安全漏洞
• 集成复杂性
• 技术债负担
• 基础设施可靠性
• 数据迁移挑战

进度风险

• 时间表过于激进或不切实际
• 依赖其他团队／项目
• 关键里程碑未能对齐
• 低估复杂性
• 假期或休假冲突
• 外部截止期限压力

资源风险

• 团队产能不足
• 依赖关键人员（巴士系数）
• 技能差距或培训需求
• 预算限制
• 优先事项冲突
• 人员流失或离职

外部风险

• 供应商可靠性或变更
• 监管或合规要求变更
• 市场状况变化
• 竞争对手行动
• 客户需求不确定
• 第三方 API 稳定性

质量风险

• 测试覆盖不足
• 需求复杂或不明确
• 代码质量或架构不佳
• 用户体验问题
• 无障碍或合规方面的缺口
• 浏览器／设备兼容性

组织风险

• 利益相关方意见不一致
• 决策权限不明确
• 项目中途调整优先级
• 政治或组织层面的动态变化
• 沟通中断
• 跨团队协作挑战

风险矩阵

                    IMPACT
              Low (1)  Med (2)  High (3)
PROBABILITY
High (3)      3 (H)    6 (H)    9 (C)
Med (2)       2 (M)    4 (H)    6 (H)
Low (1)       1 (L)    2 (M)    3 (H)

C = Critical  (7-9): Immediate action required
H = High      (4-6): Develop mitigation plan
M = Medium    (2-3): Monitor regularly
L = Low       (1):   Track in register

缓解策略决策树

Can we eliminate this risk entirely?
  YES → AVOID strategy (change approach)
  NO ↓

Can we significantly reduce probability or impact?
  YES → MITIGATE strategy (take action)
  NO ↓

Can someone else manage this better?
  YES → TRANSFER strategy (outsource, insure)
  NO ↓

ACCEPT strategy (plan contingency)

风险登记表模板

## Risk Register - [Project Name]

Last Updated: [Date]

### Critical Risks (Score 7-9)

#### R-001: [Risk Title]
- **Description**: [What is the risk?]
- **Category**: Technical | Schedule | Resource | External | Quality | Organizational
- **Probability**: High (3) | Medium (2) | Low (1)
- **Impact**: High (3) | Medium (2) | Low (1)
- **Risk Score**: [P × I]
- **Trigger**: [What causes this?]
- **Owner**: [Name]
- **Status**: Active | Monitoring | Closed
- **Mitigation Strategy**: Avoid | Mitigate | Transfer | Accept
- **Mitigation Actions**:
  - [ ] Action 1 - Owner - Due Date
  - [ ] Action 2 - Owner - Due Date
- **Contingency Plan**: If risk occurs, we will...
- **Early Warning Indicators**: [What to watch for]
- **Last Reviewed**: [Date]

### High Risks (Score 4-6)
[Same format as above]

### Medium Risks (Score 2-3)
[Same format as above]

常见项目风险及缓解措施

风险：关键开发人员在项目中途离职

• 缓解措施：结对编程、编写文档、共享知识
• 应急措施：备用承包商、延长时间表
• 指标：团队成员缺乏投入、出现求职迹象

风险：需求发生重大变更

• 缓解措施：采用敏捷方法、定期与利益相关方沟通、聚焦 MVP
• 应急措施：协商范围、调整时间表
• 指标：利益相关方不满、市场反馈

风险：第三方 API 变得不可靠

• 缓解措施：实施缓存、重试逻辑、熔断机制
• 应急措施：更换供应商、自行构建
• 指标：错误率上升、延迟激增

风险：性能未达到要求

• 缓解措施：尽早进行性能测试、审查架构
• 应急措施：安排优化冲刺、扩展基础设施
• 指标：负载测试失败、用户投诉

风险：发现安全漏洞

• 缓解措施：安全审查、渗透测试、依赖项扫描
• 应急措施：事件响应计划、回滚流程
• 指标：安全警报、CVE 通知

风险：项目超出预算

• 缓解措施：准确估算、预留缓冲、跟踪成本
• 应急措施：缩减范围、申请追加资金
• 指标：消耗速率超过预期

集成点

• 项目规划器：在规划阶段识别风险
• 冲刺规划器：在冲刺规划时审查风险
• 任务管理器：跟踪缓解措施的待办事项
• 回顾主持人：总结风险相关经验
• 利益相关方沟通：报告风险状态
• 事件管理：触发应急计划