Pm Alpha Task Prioritization

任务优先级排序工具

系统化评估和排序任务优先级，确保有限资源投入到最有价值的工作中。

RICE模型应用

RICE评分详解

┌─────────────────────────────────────────────────────────────┐
│                    RICE Score 计算公式                      │
│                                                             │
│    RICE Score = (Reach × Impact × Confidence) / Effort     │
│                                                             │
│    ┌─────────────────────────────────────────────────────┐ │
│    │ Reach（触达量）                                      │ │
│    │ · 评估周期内受影响的用户数量或业务量                 │ │
│    │ · 通常以季度或Sprint为周期                          │ │
│    │ · 范围：具体数字（10/100/1000）                     │ │
│    └─────────────────────────────────────────────────────┘ │
│                            ×                                 │
│    ┌─────────────────────────────────────────────────────┐ │
│    │ Impact（影响力）                                     │ │
│    │ · 对用户价值或业务指标的影响程度                    │ │
│    │ · 使用倍数映射：0.25/0.5/1/2/3                       │ │
│    │ · 0.25 = 微小影响，1 = 中等影响，3 = 巨大影响        │ │
│    └─────────────────────────────────────────────────────┘ │
│                            ×                                 │
│    ┌─────────────────────────────────────────────────────┐ │
│    │ Confidence（置信度）                                  │ │
│    │ · 对Reach和Impact估算的自信程度                      │ │
│    │ · 100% = 完全自信，80% = 中度自信，50% = 低自信      │ │
│    └─────────────────────────────────────────────────────┘ │
│                            ÷                                 │
│    ┌─────────────────────────────────────────────────────┐ │
│    │ Effort（工作量）                                      │ │
│    │ · 投入的人/周数（1人 × 1周 = 1人周）               │ │
│    │ · 包括：开发、测试、设计等所有投入                   │ │
│    └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

Impact 映射表

RICE评估标准操作

## RICE评估操作指南

### Step 1: 明确评估周期
- Sprint周期：通常为2-4周
- 季度周期：适用于战略级需求
- 本次评估周期：[具体周期]

### Step 2: 估算 Reach
问题模板：
"这个需求在评估周期内会影响多少用户/请求/订单？"

计算方式：
- 直接用户数：可以直接统计的目标用户数量
- 间接影响：间接受益的用户（如管理员功能影响其服务的用户）
- 业务量：可量化的业务数据

### Step 3: 估算 Impact
问题模板：
"这个需求实现后，对核心指标的影响有多大？"

判断方法：
- 如果不知道确切值，向下取（保守估计）
- 参考历史类似功能的数据
- 如无数据，使用中位数 1

### Step 4: 确定 Confidence
问题模板：
"我对 Reach 和 Impact 的估算有多大把握？"

判断标准：
- 100%：有数据支撑，团队共识
- 80%：基于类似项目经验，有一定把握
- 50%：粗略估计，不确定性大

### Step 5: 计算 Effort
问题模板：
"完成这个需求需要多少人力投入？"

包含内容：
- 开发时间（含设计、代码、Code Review）
- 测试时间（功能测试、回归测试）
- 会议和沟通时间
- 文档和配置工作时间

### Step 6: 计算 RICE Score
```公式
RICE Score = (Reach × Impact × Confidence) / Effort

RICE 评估表示例

---

## 紧急/重要矩阵（ Eisenhower Matrix）

### 矩阵框架

```markdown
                    紧急
              No ◀──────────▶ Yes
         ┌────────────────────────────────┐
    高   │    第二象限    │    第一象限    │
         │   重要+紧急    │   重要+紧急    │
         │   DO FIRST   │   DO NOW      │
 重要     │   [计划执行]  │   [立即执行]   │
         ├────────────────────────────────┤
    低   │    第四象限    │    第三象限    │
         │  不重要+不紧急  │  不重要+紧急   │
         │   DELETE     │   DELEGATE    │
         │   [减少投入]  │   [委托他人]   │
         └────────────────────────────────┘

象限定义与行动

任务分类评估

## 紧急/重要评估表

### 紧急性评估（Emergency）
问题清单：
- [ ] 这个任务有即将到来的截止日期吗？
- [ ] 如果不立即处理，会有什么后果？
- [ ] 这个问题是否正在恶化？
- [ ] 是否有外部依赖等待这个任务？

得分规则：
- 3个及以上"是" → 紧急
- 1-2个"是" → 一般
- 0个"是" → 不紧急

### 重要性评估（Importance）
问题清单：
- [ ] 这个任务对核心业务指标有直接影响吗？
- [ ] 完成这个任务对用户价值有显著提升吗？
- [ ] 不完成这个任务会有什么长期影响？
- [ ] 这个任务与产品/项目战略目标一致吗？

得分规则：
- 3个及以上"是" → 重要
- 1-2个"是" → 一般
- 0个"是" → 不重要

利益相关方权衡

利益相关方地图

## 利益相关方分析模板

### 识别利益相关方

| 利益相关方 | 类型 | 影响力 | 利益相关度 | 态度 | 期望 |
|-----------|-----|-------|-----------|-----|-----|
| 科室主任   | 外部 | 高   | 高        | 支持 | 提升诊疗效率 |
| 临床医生   | 外部 | 高   | 高        | 支持 | 操作便捷 |
| IT运维    | 内部 | 中   | 中        | 中立 | 系统稳定 |
| 开发团队   | 内部 | 中   | 高        | 支持 | 技术可行 |

影响力-利益矩阵

         高 ◀──────────▶ 低
         ┌────────────────────────────────┐
    高   │   重点管理   │    保持满意     │
         │   Keep      │   Keep         │
         │   Satisfied │   Satisfied    │
 利益    ├────────────────────────────────┤
  高    │   主要通知   │   监测         │
  ◀─────│   Inform     │   Monitor      │
  低    └────────────────────────────────┘
       影响力低              影响力高

权衡决策框架

## 利益相关方权衡决策表

### 冲突场景分析
**场景**：A需求（技术团队诉求）和B需求（业务方诉求）冲突

**利益相关方诉求对比**：

| 维度 | A需求（技术优化） | B需求（业务功能） |
|-----|-----------------|-----------------|
| 提出方 | 开发团队 | 科室主任 |
| 核心诉求 | 技术债务偿还 | 临床功能上线 |
| 影响力 | 中 | 高 |
| 紧急性 | 低 | 高 |
| RICE Score | 800 | 1200 |

**权衡分析**：
1. 短期价值 vs 长期价值
   - B需求短期价值高，直接影响业务
   - A需求降低未来技术风险

2. 可替代性分析
   - B需求是否有其他实现方式？
   - 延后A需求的技术风险有多大？

3. 依赖关系
   - B需求是否依赖A需求的优化？

**决策建议**：
[基于分析给出推荐方案和理由]

冲突解决策略

## 利益冲突解决策略

### 策略1: 价值对比法
当技术需求 vs 业务需求冲突时：
- 量化业务需求的价值（收入/效率/用户体验）
- 量化技术需求的成本节约（维护成本/扩展性）
- 选择价值更高的选项

### 策略2: 拆分法
当需求无法取舍时：
- 将大需求拆分为小迭代
- 业务核心功能优先上线
- 技术优化可分期进行

### 策略3: 协商法
当多方诉求冲突时：
- 组织利益相关方沟通
- 寻找共同目标
- 达成阶段性共识

### 策略4: 仲裁法
当无法达成共识时：
- 升级到更高层决策者
- 提供数据支撑的决策材料
- 服从决策结果

Sprint排期建议

Sprint容量规划

## Sprint容量规划模板

### 团队能力评估
| 角色 | 人数 | 可用人/天（2周Sprint） | 备注 |
|-----|-----|---------------------|-----|
| 开发 | X人 | X × 10 = XX人/天 | 扣除会议/培训 |
| 测试 | X人 | X × 10 = XX人/天 | |
| PM  | X人 | X × 10 = XX人/天 | |
| 设计 | X人 | X × 10 = XX人/天 | |

### 容量计算

可用容量 = Σ(人数 × 可用人/天) 可用容量 = XX 人/天 可用工时 = XX 人/天 × 8h = XXX h

预留buffer（10-15%）= XXX h × 0.1x = XX h 实际可用 = XXX - XX = XXX h

### 故事点估算

| 角色 | 人/天 | 转换系数 | 故事点/周期 |
|-----|-----|---------|-----------|
| 开发 | X人/天 | X story points/人天 | XX |
| 测试 | X人/天 | X story points/人天 | XX |
| 设计与PM | 兼职 | - | XX |

### Sprint容量表

| Sprint | 周期 | 故事点容量 | 实际投入 | 差异 | 调整建议 |
|-------|-----|----------|---------|-----|---------|
| Sprint N | 2周 | 40 | 38 | -2 | 正常波动 |
| Sprint N+1 | 2周 | 40 | 待定 | - | 按N实际调整 |

Sprint排期流程

## Sprint排期操作流程

### 前期准备
1. [ ] Product Backlog 已按优先级排序
2. [ ] 需求条目已准备就绪（User Story + Acceptance Criteria）
3. [ ] 团队成员已完成工作量估算
4. [ ] 技术依赖和风险已识别

### 排期会议流程（建议时长：2-4小时）

| 阶段 | 时长 | 内容 | 输出 |
|-----|-----|-----|-----|
| 计划导入 | 10min | 回顾Sprint目标，介绍PBI | 共同理解 |
| PBI讲解 | 20min | PM讲解高优先级需求 | 团队共识 |
| 估算确认 | 60min | 团队确认故事点 | 估算达成一致 |
| 容量匹配 | 30min | 根据容量选择需求 | Sprint Backlog |
| 任务分解 | 40min | 开发任务初步分解 | 任务清单 |
| 风险确认 | 10min | 识别风险，制定应对 | 风险清单 |
| 承诺确认 | 10min | 团队确认Sprint目标 | Sprint Commitment |

### 排期决策原则

排入Sprint的条件（必须同时满足）： ├── ✅ RICE Score >= 阈值（由团队设定） ├── ✅ 技术依赖已解决 ├── ✅ 验收标准明确 ├── ✅ 有可用负责人 └── ✅ 在Sprint容量范围内

延后处理的情况： ├── ⚠️ 技术方案不确定 → 先做技术调研 ├── ⚠️ 依赖外部资源 → 等待或寻找替代 ├── ⚠️ 验收标准不清 → 补充PRD └── ⚠️ 超出容量 → 优先级排序后延后

### Sprint排期表示例

```markdown
## Sprint N 排期表

### Sprint 目标
[描述Sprint的核心目标和预期成果]

### 承诺的故事点
- 目标：40 story points
- 实际：38 story points

### Sprint Backlog

| ID | 需求 | 类型 | 故事点 | 负责人 | 状态 |
|----|-----|------|-------|-------|------|
| 1  | 用户注册优化 | Feature | 5 | @Dev1 | To Do |
| 2  | 报告导出功能 | Feature | 8 | @Dev2 | To Do |
| 3  | 登录性能优化 | Tech Debt | 3 | @Dev1 | To Do |
| 4  | P0缺陷修复 | Bug | 5 | @Dev2 | To Do |

### 风险与依赖
| 风险/依赖 | 影响 | 应对措施 | 负责人 |
|----------|-----|---------|-------|
| 第三方API不稳定 | 高 | 降级方案 | @Dev1 |
| 设计稿延期 | 中 | 先行开发 | @PM |

### 排期调整记录
- DD候：移除了"XXX"需求（超出容量）
- DD日：新增"P0缺陷修复"（紧急插入）

综合优先级决策模型

决策流程图

## 优先级决策流程

接收需求 ↓ Step 1: RICE评分 ├── 计算 RICE Score └── 初步排序

Step 2: 紧急性判断 ├── 是紧急？→ 进入"紧急通道" └── 否 → 继续

Step 3: 战略一致性 ├── 与当前目标一致？→ 保持原优先级 └── 与目标冲突？→ 降级处理

Step 4: 利益相关方平衡 ├── 是否有强烈诉求？ ├── 是否涉及关键用户？ └── 综合评估后调整

Step 5: 最终排序 └── 输出排好序的需求列表

### 最终优先级模板

```markdown
## 综合优先级评估表

| 需求ID | 需求名称 | RICE Score | 紧急性 | 战略一致性 | 利益相关方 | 综合优先级 | 最终排序 |
|-------|---------|------------|-------|-----------|-----------|-----------|---------|
|       |         |            | Y/N   | H/M/L     |           | P0/P1/P2/P3 |          |
|       |         |            |       |           |           |            |          |

### 优先级定义
- P0：立即执行，Sprint内必须完成
- P1：高优先级，下个Sprint排入
- P2：中优先级，视资源情况安排
- P3：低优先级，可延后或拆分

### 排序说明
[解释最终排序的决策依据，特别是排序调整的情况]

工具与模板汇总

优先级评估工具清单

MoSCoW 优先级定义