| name | pm-alpha-task-prioritization |
| description | 任务优先级排序工具。提供RICE模型应用、紧急/重要矩阵、利益相关方权衡、Sprint排期建议等功能。帮助产品经理在资源有限的情况下做出最优的任务排序决策。适用于Sprint计划会议、需求排期、资源冲突解决等场景。当需要进行任务优先级排序或资源分配决策时使用此skill。 |
任务优先级排序工具
系统化评估和排序任务优先级，确保有限资源投入到最有价值的工作中。
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评估标准操作
## 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缺陷、紧急需求 | 立即处理，全力以赴 |
| 第二象限 | 重要+不紧急 | 规划优化、架构升级、团队建设 | 计划执行，防患未然 |
| 第三象限 | 不重要+紧急 | 打扰式会议、部分协作请求 | 快速完成或委托 |
| 第四象限 | 不重要+不紧急 | 无目的刷邮件、可有可无的会议 | 删除或最小化投入 |
任务分类评估
## 紧急/重要评估表
### 紧急性评估（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：低优先级，可延后或拆分
### 排序说明
[解释最终排序的决策依据，特别是排序调整的情况]
工具与模板汇总
优先级评估工具清单
| 工具 | 适用场景 | 特点 |
|---|
| RICE模型 | 价值驱动的排序 | 量化、可比较 |
| 紧急/重要矩阵 | 时间敏感的决策 | 简单直观 |
| Kano模型 | 用户需求分类 | 区分基本/期望/兴奋需求 |
| MoSCoW | 范围管理 | 强制排序 |
MoSCoW 优先级定义
| 分类 | 定义 | 占比建议 |
|---|
| Must Have | 必须有，否则产品不可用 | 60% |
| Should Have | 应该有，重要但非紧急 | 20% |
| Could Have | 可以有，提升体验 | 15% |
| Won't Have | 本次不做 | 5% |
