# Pm Alpha Task Prioritization

> 任务优先级排序工具。提供RICE模型应用、紧急/重要矩阵、利益相关方权衡、Sprint排期建议等功能。帮助产品经理在资源有限的情况下做出最优的任务排序决策。适用于Sprint计划会议、需求排期、资源冲突解决等场景。当需要进行任务优先级排序或资源分配决策时使用此skill。

- Skill: `fengqiliu/pm-alpha-task-prioritization` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add fengqiliu/pm-alpha-task-prioritization`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fengqiliu/pm-alpha-task-prioritization/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: fengqiliu (https://skillmd.com/u/fengqiliu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fengqiliu/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 映射表

| Impact值 | 标签 | 说明 | 对应业务影响 |
|---------|-----|------|------------|
| 3 | 巨大 | 核心指标显著提升 | 收入/用户量大幅增长 |
| 2 | 高 | 主要指标明显改善 | 关键转化率提升 |
| 1 | 中等 | 指标有可见改善 | 体验优化，用户好评 |
| 0.5 | 低 | 指标轻微改善 | 小幅体验提升 |
| 0.25 | 微小 | 几乎无感知变化 | 锦上添花型功能 |

### RICE评估标准操作

```markdown
## 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 评估表示例

| 需求ID | 需求名称 | Reach/周期 | Impact | Confidence | Effort(人周) | RICE Score | 排序 |
|-------|---------|-----------|--------|------------|-------------|------------|-----|
| REQ-001 | 患者端注册优化 | 10000 | 2 | 80% | 2 | (10000×2×0.8)/2 = 8000 | 1 |
| REQ-002 | 报告模板功能 | 500 | 3 | 100% | 4 | (500×3×1.0)/4 = 375 | 2 |
| REQ-003 | UI细节优化 | 10000 | 0.5 | 50% | 1 | (10000×0.5×0.5)/1 = 2500 | 3 |
```

---

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

### 矩阵框架

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

### 象限定义与行动

| 象限 | 定义 | 典型任务 | 行动策略 |
|-----|------|---------|---------|
| 第一象限 | 重要+紧急 | 线上故障、P0缺陷、紧急需求 | 立即处理，全力以赴 |
| 第二象限 | 重要+不紧急 | 规划优化、架构升级、团队建设 | 计划执行，防患未然 |
| 第三象限 | 不重要+紧急 | 打扰式会议、部分协作请求 | 快速完成或委托 |
| 第四象限 | 不重要+不紧急 | 无目的刷邮件、可有可无的会议 | 删除或最小化投入 |

### 任务分类评估

```markdown
## 紧急/重要评估表

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

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

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

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

---

## 利益相关方权衡

### 利益相关方地图

```markdown
## 利益相关方分析模板

### 识别利益相关方

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

### 影响力-利益矩阵

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

### 权衡决策框架

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

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

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

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

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

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

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

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

### 冲突解决策略

```markdown
## 利益冲突解决策略

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

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

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

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

---

## Sprint排期建议

### Sprint容量规划

```markdown
## 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排期流程

```markdown
## 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缺陷修复"（紧急插入）
```

---

## 综合优先级决策模型

### 决策流程图

```markdown
## 优先级决策流程

```
接收需求
    ↓
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：低优先级，可延后或拆分

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

---

## 工具与模板汇总

### 优先级评估工具清单

| 工具 | 适用场景 | 特点 |
|-----|---------|-----|
| RICE模型 | 价值驱动的排序 | 量化、可比较 |
| 紧急/重要矩阵 | 时间敏感的决策 | 简单直观 |
| Kano模型 | 用户需求分类 | 区分基本/期望/兴奋需求 |
| MoSCoW | 范围管理 | 强制排序 |

### MoSCoW 优先级定义

| 分类 | 定义 | 占比建议 |
|-----|------|---------|
| Must Have | 必须有，否则产品不可用 | 60% |
| Should Have | 应该有，重要但非紧急 | 20% |
| Could Have | 可以有，提升体验 | 15% |
| Won't Have | 本次不做 | 5% |