版本: v1.0
日期: 2026-01-20
用途: W2-W4 (4周) 风险管理、问题解决、决策记录
所有者: Project Manager
风险生命周期:
识别 (识别新风险或复现风险)
↓
评估 (评估概率、影响、优先级)
↓
规划 (制定缓解和应急计划)
↓
监控 (持续跟踪和更新状态)
↓
关闭 (风险消除或转化为问题)
🔴 高风险 (优先级 1)
├─ 概率: >50% 或 影响: 项目延期 >2周
├─ 处理: 立即启动缓解措施, 每日跟踪
├─ 上报: 立即向管理层报告
└─ 决策: 可能触发项目范围变更
🟡 中风险 (优先级 2)
├─ 概率: 20-50% 或 影响: 项目延期 1-2周
├─ 处理: 启动缓解措施, 每周跟踪
├─ 上报: 在周度评审中报告
└─ 决策: 可能调整计划或资源分配
🟢 低风险 (优先级 3)
├─ 概率: <20% 或 影响: 延期 <1周
├─ 处理: 建立应急计划, 按需跟踪
├─ 上报: 在月度总结中提及
└─ 决策: 一般不触发计划变更
╔═══════════════════════════════════════════════════════════════╗
║ 风险 ID: [RISK-XXX] ║
║ 创建日期: YYYY-MM-DD ║
║ 所有者: [姓名] ║
╠═══════════════════════════════════════════════════════════════╣
║ 风险描述 ║
├───────────────────────────────────────────────────────────────┤
║ [清晰、具体的风险表述，5句以内] ║
╠═══════════════════════════════════════════════════════════════╣
║ 影响范围: [影响的产品/功能/团队] ║
║ 触发条件: [什么情况会导致风险发生] ║
║ 概率: [高/中/低] (%) ║
║ 影响: [高/中/低] (项目延期天数/成本) ║
║ 优先级: [高/中/低] ║
╠═══════════════════════════════════════════════════════════════╣
║ 缓解措施 ║
├───────────────────────────────────────────────────────────────┤
║ 1. [行动] - 完成时间 ║
║ 2. [行动] - 完成时间 ║
║ 3. [行动] - 完成时间 ║
║ 监控指标: [如何判断缓解措施有效] ║
║ 决策点: [何时做是/否决策 - 触发应急计划] ║
╠═══════════════════════════════════════════════════════════════╣
║ 应急计划 (如果风险发生) ║
├───────────────────────────────────────────────────────────────┤
║ 方案 A: [备选方案] → [成本/延期] ║
║ 方案 B: [备选方案] → [成本/延期] ║
║ 优先选择: 方案 ? ║
║ 触发条件: [什么时候启动应急计划] ║
╠═══════════════════════════════════════════════════════════════╣
║ 状态: [识别→规划→监控→关闭] ║
║ 最后更新: YYYY-MM-DD ║
║ 审查日期: YYYY-MM-DD ║
╚═══════════════════════════════════════════════════════════════╝
【顶层风险概览】
总风险数: 4 (1 高, 2 中, 1 低)
╔════════╗
高 ║ 1 ║ RISK-001
╱────╞════════╡
│ 中 ║ 2 ║ RISK-002, RISK-003
│╱────╞════════╡
└ 低 ║ 1 ║ RISK-004
╚════════╝
【分周期风险演变】
W2 状态: 4 个风险 (全部可控)
W3 关键: RISK-001 决策点 (2月6日)
W4 关键: RISK-003 决策点 (2月10日)
【详细风险列表】
RISK-001: PTP 延迟优化失败 ⚠️ 高优先级
├─ 状态: 🟡 监控中
├─ 概率: 40%
├─ 影响: 高 (M2.1 推迟)
├─ 决策点: 2026-02-06 (W3 中期)
└─ Owner: Alice (PTP Lead)
RISK-002: TSN Linux 集成困难 🟡 中优先级
├─ 状态: 🟢 低风险
├─ 概率: 20%
├─ 影响: 中 (延期 1 周)
├─ 决策点: 2026-02-04 (首次集成)
└─ Owner: Bob (TSN Lead)
RISK-003: 硬件 PCB 设计延迟 🟡 中优先级
├─ 状态: 🟡 监控中
├─ 概率: 15%
├─ 影响: 高 (硬件验证延期)
├─ 决策点: 2026-02-10 (W4 开始)
└─ Owner: Charlie (HW Lead)
RISK-004: 跨系统集成问题 🟡 中优先级
├─ 状态: 🟢 低风险
├─ 概率: 35%
├─ 影响: 中 (延期 3-5 天)
├─ 决策点: 2026-02-12 (集成测试启动)
└─ Owner: 整个团队
🟢 标准决策 (Standard Decision)
├─ 定义: 低风险, 团队 lead 可自行决策
├─ 流程: 讨论 → 决策 → 执行 → 记录
├─ 时间: 1-2 小时
├─ 审批: Team Lead 签字
└─ 记录: 决策日志 (可选)
🟡 重要决策 (Major Decision)
├─ 定义: 中风险, 影响多个团队
├─ 流程: 讨论 → 选项评估 → PM 批准 → 执行 → 记录
├─ 时间: 4-8 小时
├─ 审批: PM + 相关 Team Lead
└─ 记录: 决策日志 (必需)
🔴 关键决策 (Critical Decision)
├─ 定义: 高风险, 影响项目范围/时间/成本
├─ 流程: 讨论 → 深度分析 → 方案对标 → 高层评审 → 决策 → 执行 → 记录
├─ 时间: 1-3 天
├─ 审批: PM + Team Leads + 管理层
└─ 记录: 决策日志 (必需) + 高层汇报
START: 识别需要决策的事项
│
├─ 影响范围与风险评估
│ ├─ Low → 标准决策流程
│ ├─ Medium → 重要决策流程
│ └─ High → 关键决策流程
│
├─ 【标准决策】(Low Risk)
│ ├─ 1. Team Lead 与相关人员讨论
│ ├─ 2. 快速决策 (讨论时间 <1小时)
│ ├─ 3. 执行决策
│ └─ 4. 可选记录到决策日志
│
├─ 【重要决策】(Medium Risk)
│ ├─ 1. Team Leads 讨论与评估
│ ├─ 2. 列举选项 (2-3 个)
│ ├─ 3. 风险/收益分析
│ ├─ 4. PM 批准
│ ├─ 5. 执行
│ └─ 6. 记录到决策日志
│
├─ 【关键决策】(High Risk)
│ ├─ 1. Team Leads + PM 讨论
│ ├─ 2. 深度问题分析 (影响评估)
│ ├─ 3. 列举选项 (3+ 个)
│ ├─ 4. 方案对标 (表格对比)
│ ├─ 5. 高层评审会 (30-60 min)
│ ├─ 6. 执行获批的方案
│ ├─ 7. 记录到决策日志
│ └─ 8. 向利益相关方沟通结果
│
└─ END: 决策执行 + 跟踪
关键原则:
✓ 透明: 所有决策过程可见
✓ 数据驱动: 基于事实和分析
✓ 及时: 不要拖延关键决策
✓ 可逆: 尽可能选择可逆的方案
✓ 可审计: 所有决策有记录
╔═══════════════════════════════════════════════════════════════╗
║ 决策 ID: [DEC-XXX] ║
║ 日期: YYYY-MM-DD ║
║ 决策者: [PM / Team Lead 名字] ║
║ 类型: [标准/重要/关键] ║
╠═══════════════════════════════════════════════════════════════╣
║ 标题: [简短的决策主题, 10 字以内] ║
╠═══════════════════════════════════════════════════════════════╣
║ 背景信息 ║
├───────────────────────────────────────────────────────────────┤
║ [为什么需要这个决策？ 1-2 段落] ║
║
║ 关键数据或发现:
║ - [关键发现 1]
║ - [关键发现 2]
║ - [关键发现 3]
╠═══════════════════════════════════════════════════════════════╣
║ 可选方案评估 ║
├───────────────────────────────────────────────────────────────┤
║ 方案 A: [方案描述]
║ 优点: [1]
║ 缺点: [1]
║ 成本: [工时/金钱]
║ 风险: [可能的问题]
║ 评分: [6/10]
║
║ 方案 B: [方案描述]
║ 优点: [1]
║ 缺点: [1]
║ 成本: [工时/金钱]
║ 风险: [可能的问题]
║ 评分: [8/10]
║
║ 方案 C: [方案描述]
║ 优点: [1]
║ 缺点: [1]
║ 成本: [工时/金钱]
║ 风险: [可能的问题]
║ 评分: [4/10]
╠═══════════════════════════════════════════════════════════════╣
║ 最终决定 ║
├───────────────────────────────────────────────────────────────┤
║ 选择方案: B (方案描述)
║ 选择理由:
║ 1. [关键理由 1]
║ 2. [关键理由 2]
║ 3. [关键理由 3]
║
║ 影响范围:
║ - PTP Team: [具体影响]
║ - TSN Team: [具体影响]
║ - HW Team: [具体影响]
║
║ 实施计划:
║ - Step 1: [操作] by [日期]
║ - Step 2: [操作] by [日期]
║ - Step 3: [操作] by [日期]
║
║ 成功标准: [如何验证决策有效]
╠═══════════════════════════════════════════════════════════════╣
║ 备选方案记录 ║
├───────────────────────────────────────────────────────────────┤
║ [记录为什么没有选择其他方案]
║
║ 为什么不选 A: [理由]
║ 为什么不选 C: [理由]
╠═══════════════════════════════════════════════════════════════╣
║ 审查 ║
├───────────────────────────────────────────────────────────────┤
║ 批准者签字: _________________ 日期: __________
║ 审查评论:
║ [如有需要补充的意见]
║
║ 后续审查日期: YYYY-MM-DD
║ [决策 6 周后是否需要再评估？ 何时？]
╚═══════════════════════════════════════════════════════════════╝
【示例 1 - 标准决策】
DEC-001: SYNC 消息周期选择
├─ 类型: 标准决策 (Team Lead 自行决策)
├─ 日期: 2026-02-03
├─ 决策者: Alice (PTP Team Lead)
│
├─ 背景:
│ 需要选择 PTP SYNC 消息的发送周期。
│ 影响: 同步收敛速度和网络带宽占用
│
├─ 选项:
│ A: 1 秒周期 → 更快收敛, 更多流量
│ B: 16 秒周期 → 省带宽, 收敛稍慢
│
├─ 最终决定: 选项 B (16s 周期)
│ 理由: 在局域网中 16s 收敛足够快, 而且省带宽
│
├─ 影响: 消息处理代码, 单元测试周期调整
├─ 实施: 更新 PTP 规范文档 (2 小时工作量)
└─ 审查: 2026-02-07 (W3 评审会确认)
【示例 2 - 重要决策】
DEC-002: TSN 流量分类方法
├─ 类型: 重要决策 (跨团队, PM 批准)
├─ 日期: 2026-02-05
├─ 决策者: PM (基于 Bob/Alice 建议)
│
├─ 背景:
│ 需要决定 TSN 如何识别和分类流量。
│ 影响: 调度准确性和实现复杂度
│
├─ 选项:
│ A: 硬编码 (简单, 不灵活)
│ B: 基于 5-tuple (灵活, 需要实现分类器)
│ C: 基于 VLAN tag (灵活, 需要外部配置)
│
├─ 评估:
│ A: 评分 4/10 (太不灵活)
│ B: 评分 7/10 (但实现复杂, 性能影响大)
│ C: 评分 8/10 (灵活且实现简单, 假设网络支持)
│
├─ 最终决定: 选项 C (VLAN tag)
│ 理由:
│ 1. 最灵活, 无需代码修改即可调整分类
│ 2. 实现最简单 (硬件 VLAN 识别)
│ 3. 性能影响最小 (硬件分类)
│
├─ 影响:
│ - TSN Team: 需要实现 VLAN 识别 (新增 20 LOC)
│ - 测试: 需要 VLAN 交换机或虚拟化支持
│ - 运维: 需要 VLAN 配置文档
│
├─ 实施计划:
│ - Week 1: 在测试环境配置 VLAN
│ - Week 2: 实现 VLAN 识别代码
│ - Week 3: 测试与优化
│
├─ 后续审查: 2026-02-16
│ 验证: VLAN 分类是否按预期工作?
│ 性能是否满足 <100µs 目标?
│
└─ 状态: ✅ 已实施
【示例 3 - 关键决策】
DEC-003: 硬件 PCB 制造计划
├─ 类型: 关键决策 (高风险, 成本影响)
├─ 日期: 2026-02-10
├─ 决策者: PM (基于 Charlie/管理层意见)
│
├─ 背景:
│ W3 末发现硬件 PCB 设计进度滞后 20%, 无法在 W4 完成。
│ 必须立即决策: 继续赶工还是调整范围/时间表?
│ 影响: M2.1 发布时间, 项目成本, 团队工作量
│
├─ 选项评估表:
│ ┌──────────────┬────────────────┬──────┬────────┐
│ │ 选项 │ 成本 │ 延期 │ 评分 │
│ ├──────────────┼────────────────┼──────┼────────┤
│ │ A. 赶工完成 │ +¥5000 (加班) │ 0d │ 3/10 │
│ │ B. 外包PCB │ +¥3000 (外包) │ 3d │ 7/10 │
│ │ C. 推迟M2.1 │ 无 │ 7d │ 6/10 │
│ │ D. 降低M2.1 │ -¥5000 (省人力)│ 0d │ 8/10 │
│ │ 范围 │ │ │ │
│ └──────────────┴────────────────┴──────┴────────┘
│
├─ 深度分析:
│ A (赶工):
│ - 风险: 质量下降, 错误增加, 验证时间不足
│ - 影响: 可能硬件有 bug, 需要重新设计
│ - 成本: ¥5000 + 潜在返工 ¥10000+
│
│ B (外包):
│ - 风险: 沟通延迟, 返工困难
│ - 影响: M2.1 推迟 3-5 天, 但质量有保证
│ - 成本: ¥3000, 可控
│
│ C (推迟):
│ - 风险: 影响后续计划 (M2.2 启动延迟)
│ - 影响: 市场上市推迟 1-2 周
│ - 成本: 团队等待成本
│
│ D (降低范围):
│ - 风险: M2.1 功能减少, 市场吸引力下降
│ - 影响: 只发布 PTP 或 TSN 之一
│ - 成本: 最低, 但市场反应未知
│
├─ 最终决定: 选项 B (外包 PCB 设计)
│ 理由:
│ 1. 成本可控 (¥3000 在预算内)
│ 2. 风险最小化 (第三方有经验)
│ 3. 时间延迟最小 (3d vs 7d)
│ 4. 质量有保证 (不依赖过度劳动)
│
├─ 实施计划:
│ - Day 1: 联系 3 家 PCB 设计公司, 获取报价
│ - Day 2: 签订合同, 移交原理图
│ - Day 3: PCB 公司开始设计 (预期 5-7 天完成)
│ - Day 8: 接收设计, 审查
│ - Day 9: 提交制造
│
├─ 影响范围:
│ - 成本预算: +¥3000
│ - 时间表: M2.1 推迟 3 天 (2 月 16 → 2 月 19)
│ - 团队: Charlie (HW Lead) 释放 50% 时间 (监督而非设计)
│
├─ 成功标准:
│ - PCB 设计在 2 月 15 日前完成
│ - 设计审查通过 (无重大问题)
│ - 成本 ≤ ¥3000
│ - 不延迟后续硬件验证 (M2.2 计划)
│
├─ 高层评审:
│ - 参会: PM + Charlie + Engineering Director
│ - 时间: 2026-02-10 14:00-15:00
│ - 输出: 批准和资金授权
│
├─ 沟通计划:
│ - 团队: 明确说明决策理由和影响
│ - 管理层: 汇报成本增加和时间表调整
│ - 市场: 准备发布时间推迟的说明
│
└─ 后续审查: 2026-02-15
验证: PCB 设计是否按期完成?
设计质量是否满足要求?
是否需要返工?
🔴 阻塞问题 (Blocker) - 优先级 P0
├─ 定义: 直接阻止工作进行, 无法绕过
├─ 例子: 编译不通过, 测试框架崩溃, 代码合并冲突无法解决
├─ 处理: 立即上报 Team Lead, 停止其他工作, 全力解决
├─ 时间: SLA 2 小时内必须有可用解决方案
└─ 升级: 1 小时内无解决方案 → 升级到 PM
🟠 高优先级 (High) - 优先级 P1
├─ 定义: 严重影响进度, 需要立即处理
├─ 例子: 单元测试覆盖率下降 >10%, 性能回退, 硬件设计有缺陷
├─ 处理: 当天解决, 可能需要加班
├─ 时间: SLA 8 小时内必须解决或制定应急计划
└─ 升级: 8 小时内无进展 → 升级到 PM
🟡 中优先级 (Medium) - 优先级 P2
├─ 定义: 影响质量或计划, 需要在本周内解决
├─ 例子: 代码审查意见, 文档更新, 测试用例补充
├─ 处理: 排入本周任务列表, 正常工作流程
├─ 时间: SLA 2 天内必须有处理计划
└─ 升级: 问题累积或影响扩大 → 升级到 P1
🟢 低优先级 (Low) - 优先级 P3
├─ 定义: 改进性质, 不影响功能或计划
├─ 例子: 代码注释优化, 文档格式调整, 硬件布局美化
├─ 处理: 任务不紧张时处理, 或累积后统一处理
├─ 时间: 无特定 SLA
└─ 升级: 问题数量过多 → 列入下个迭代计划
问题优先级影响矩阵:
影响范围
───────────────────────
整个项目 一个模块 个人任务
────────── ───────── ────────
P0 P0 P1 P0 P1 P2 P1 P2 P3
P0 ────── ────── ──────
紧急
程度 P1 ────── ────── ──────
P2 ────── ────── ──────
问题发现
│
├─ Team Member 创建 Issue (GitHub)
│ └─ 标签: [priority], [module], [type]
│ 分配: 相关 Team Lead
│
├─ 【阻塞 P0 问题】
│ ├─ 1. 立即通知 Slack
│ ├─ 2. Team Lead 停止其他工作
│ ├─ 3. 1 小时内确定方案或升级
│ ├─ 4. 如需要: 拉群讨论 (15 min)
│ └─ 5. 执行解决方案
│
├─ 【高优先级 P1 问题】
│ ├─ 1. Issue 创建, Team Lead 分配
│ ├─ 2. 当天讨论与评估
│ ├─ 3. 制定解决方案
│ ├─ 4. 分配给成员, 设定完成时间
│ └─ 5. 每日跟踪进度
│
├─ 【中优先级 P2 问题】
│ ├─ 1. Issue 创建, Team Lead 分配
│ ├─ 2. 加入本周任务列表
│ ├─ 3. 2 天内制定解决计划
│ └─ 4. 本周内解决
│
└─ 【低优先级 P3 问题】
├─ 1. Issue 创建, 标记为 Low Priority
├─ 2. 累积至 5+ 个后统一讨论
└─ 3. 列入下个迭代或当任务宽松时处理
【升级触发器】
如果问题满足以下任一条件, 立即升级优先级:
规则 1: P2 无进展 3 天 → 升级到 P1
规则 2: P3 累积 ≥5 个相同类型 → 升级到 P2
规则 3: 影响范围扩大 (单模块 → 多模块) → 升级一级
规则 4: 发现相关问题 (同一系统) → 升级一级
规则 5: 时间紧急 (决策点临近) → 升级一级
规则 6: P1 无进展 8 小时 → 升级到 P0 + 通知 PM
【活跃问题列表 - W2-W4】
ID 优先级 标题 状态 分配 修改日期
────────────────────────────────────────────────────────────
001 P0 代码框架编译崩溃 ✅ 已解决 Alice 2026-01-27
002 P2 编译器警告 ⏳ 处理中 Bob 2026-01-29
003 P3 文档格式不一致 ⏳ 待处理 Charlie 2026-01-30
...
变更 = 计划范围、进度或成本的改变
变更分类:
🟢 小范围变更 (Scope: <1 天工作量)
├─ 审批: Team Lead
├─ 流程: 讨论 → 评估 → 批准 → 执行
├─ 记录: Issue or Email
└─ 例: 添加一个新的测试用例, 修改变量名
🟡 中等变更 (Scope: 1-3 天工作量)
├─ 审批: PM + 相关 Team Leads
├─ 流程: 讨论 → 影响评估 → PM 批准 → 执行 → 记录
├─ 记录: 变更请求表
└─ 例: 调整 API 设计, 添加新功能, 重构一个模块
🔴 重大变更 (Scope: >3 天工作量 或 涉及时间/成本)
├─ 审批: PM + 所有 Team Leads + 管理层
├─ 流程: 讨论 → 详细影响评估 → 方案评审 → 高层决策 → 执行 → 记录
├─ 记录: 变更请求表 + 决策日志
└─ 例: 替换 CPU 芯片, 修改架构, 删除功能
╔═══════════════════════════════════════════════════════════════╗
║ 变更请求 (Change Request) - CR-XXXX ║
║ 提交日期: YYYY-MM-DD ║
║ 提交者: [姓名] ║
║ 优先级: [高/中/低] ║
╠═══════════════════════════════════════════════════════════════╣
║ 变更标题 ║
├───────────────────────────────────────────────────────────────┤
║ [简洁的变更描述, 10 字以内] ║
╠═══════════════════════════════════════════════════════════════╣
║ 变更内容 ║
├───────────────────────────────────────────────────────────────┤
║ [详细描述要改变什么，为什么需要改变]
║
║ 影响范围:
║ - [受影响的模块 1]
║ - [受影响的模块 2]
║ - [受影响的人员 / 团队]
╠═══════════════════════════════════════════════════════════════╣
║ 影响评估 ║
├───────────────────────────────────────────────────────────────┤
║ 工作量: [预计工作小时数]
║ 成本: [额外成本，如有]
║ 时间表影响: [对 W3/W4 计划的影响]
║ 风险: [可能引入的新风险]
║ 质量影响: [可能对测试覆盖率的影响]
║
║ 可以不执行吗? [是/否，如果是，成本是什么?]
╠═══════════════════════════════════════════════════════════════╣
║ 审批信息 ║
├───────────────────────────────────────────────────────────────┤
║ 审批者签字: _________________ 日期: __________
║
║ 审批意见: [批准/条件批准/拒绝 + 理由]
║
║ 如果条件批准，条件是: [列举条件]
║
║ 后续行动: [如果批准，谁负责实施？何时完成？]
╚═══════════════════════════════════════════════════════════════╝
【预计变更】(可能的)
- API 接口调整 (基于集成测试反馈) - 中变更
- 硬件设计微调 (性能优化) - 小变更
- 测试覆盖率目标调整 (如遇到困难) - 中变更
【已批准变更】(本阶段)
暂无已批准的变更 (W2-W4 范围确定)
【变更审查】
变更审查周期: 每周五 (与周度评审同时)
下一次: 2026-02-07 (W3 周度评审)
☐ 风险寄存器已更新 (所有活跃风险)
☐ 新风险已识别并评估
☐ 缓解措施按时进行
☐ 决策点已核查 (是否需要触发决策)
☐ 应急计划已讨论 (如有新的 P0/P1 风险)
☐ 问题已升级 (如有阻塞)
☐ 变更请求已审批 (如有)
☐ 问题清晰定义 (为什么需要这个决策)
☐ 至少 2 个选项已评估
☐ 风险/收益分析已完成
☐ 利益相关方已参与讨论
☐ 决议已记录到决策日志
☐ 实施计划已制定
☐ 后续审查日期已确定
制定日期: 2026-01-20
启动日期: 2026-01-27 (W2)
维护者: Project Manager
下一次更新: 2026-01-27 (W2 开始)