prioritization-effort-impact

优先级排序：投入-影响矩阵

工作流

复制此清单并跟踪进度：

Prioritization Progress:
- [ ] Step 1: Gather items and clarify scoring
- [ ] Step 2: Score effort and impact
- [ ] Step 3: Plot matrix and identify quadrants
- [ ] Step 4: Create prioritized roadmap
- [ ] Step 5: Validate and communicate decisions

步骤 1：收集事项并明确评分标准

收集所有待排序的事项（功能、缺陷、计划等），并定义投入和影响的评分尺度。投入和影响的定义请参阅评分框架。结构请使用 resources/template.md。

步骤 2：评估投入和影响

为每个事项评估投入（1-5：微不足道到巨大）和影响（1-5：可忽略到变革性）。请相关领域专家参与，以确保准确性。有关 Fibonacci、T 恤尺码或 RICE 等高级评分技巧，请参阅 resources/methodology.md。

步骤 3：绘制矩阵并识别象限

将事项放入 2x2 矩阵，并归类为快速见效项（高影响、低投入）、重大投入项（高影响、高投入）、填充项（低影响、低投入）和时间黑洞项（低影响、高投入）。典型的象限分布请参阅常见模式。

步骤 4：制定优先级路线图

安排事项顺序：先处理快速见效项，再处理重大投入项（在快速见效项带来势头之后），空闲时处理填充项，除非确有必要，否则避免时间黑洞项。路线图结构请参阅 resources/template.md。

步骤 5：验证并沟通决策

使用 resources/evaluators/rubric_prioritization_effort_impact.json 进行自查。确保评分有理有据、纳入利益相关方的观点，并清楚说明决策及其依据。

常见模式

按领域划分：

• 产品待办事项：快速见效项 = 小幅 UX 改进，重大投入项 = 新工作流，时间黑洞项 = 追求边缘情况的完美
• 技术债务：快速见效项 = 配置修复，重大投入项 = 架构改造，时间黑洞项 = 过早优化
• 缺陷分类：快速见效项 = 影响大且容易修复的问题，重大投入项 = 复杂的关键缺陷，时间黑洞项 = 外观问题
• 战略计划：快速见效项 = 流程微调，重大投入项 = 市场扩张，时间黑洞项 = 虚荣指标
• 营销活动：快速见效项 = 邮件培育，重大投入项 = 品牌改造，时间黑洞项 = 小规模 A/B 测试

按利益相关方优先级划分：

• 高管关注：快速见效项（进展可见）+ 重大投入项（战略影响）
• 工程团队关注：技术债务中的快速见效项 + 重大投入项（平台工作）
• 销售团队关注：能推动交易的快速见效项 + 重大投入项（重要功能）
• 客户关注：快速见效项（缓解痛点）+ 重大投入项（变革性价值）

典型象限分布：

• 快速见效项：10-20%（少见的高价值机会）
• 重大投入项：20-30%（具有战略意义且耗费资源）
• 填充项：40-50%（大多数待办事项中都有许多低价值事项）
• 时间黑洞项：10-20%（出乎意料地常见，往往伪装成“打磨完善”）

危险信号：

• ❌ 没有快速见效项：可能高估了投入或低估了影响
• ❌ 全部都是快速见效项：评分很可能没有正确校准
• ❌ 时间黑洞项很多：缩小范围或否决这些事项
• ❌ 投入/影响评分全是 3：需要拉开差异（使用 1-2 和 4-5）

评分框架

工作量维度（选择相关维度）：

• 时间：工程/执行所需小时数（1=小时，2=天，3=周，4=月，5=季度）
• 复杂度：技术难度（1=微不足道，5=新颖/前所未有）
• 风险：失败概率（1=安全，5=高风险）
• 依赖项：外部阻碍因素（1=无，5=涉及多个团队/审批）
• 成本：资金投入（1=$0-1K，2=$1-10K，3=$10-100K，4=$100K-1M，5=$1M+）

影响维度（选择相关维度）：

• 受影响用户：覆盖范围（1=<1%，2=1-10%，3=10-50%，4=50-90%，5=>90%）
• 业务价值：收入/节省（1=$0-10K，2=$10-100K，3=$100K-1M，4=$1-10M，5=$10M+）
• 战略契合度：对 OKR 的贡献（1=间接相关，5=对战略至关重要）
• 用户痛点：问题严重程度（1=锦上添花，5=阻碍/危机）
• 风险降低：缓解风险的价值（1=较小，5=关乎存亡）

综合评分：

• 简单：各维度取平均值（工作量 = 平均值（时间、复杂度），影响 = 平均值（用户、价值））
• 加权：乘以重要性权重（工作量 = 0.6×时间 + 0.4×复杂度）
• 斐波那契数列：使用 1、2、3、5、8 代替 1-5，以表示指数级差异
• T 恤尺码：将 S/M/L/XL 映射为 1/2/3/5

评分示例（功能：“添加深色模式”）：

• 工作量：时间=3（2 周），复杂度=2（CSS），风险=2（小问题），依赖项=1（没有阻碍）→ 平均值 = 2.0（低）
• 影响：用户=4（80% 的用户希望拥有），价值=2（提升留存率，不增加收入），战略=3（设计系统目标），痛点=3（眼睛疲劳）→ 平均值 = 3.0（中高）
• 结果：影响中高、工作量低 → 快速见效！

防护原则

确保质量：

1. 纳入多元视角：不要让一个人独自评分（工程团队会高估工作量，销售团队会高估影响）

   • ✓ 征询工程、产品、销售和客户成功团队的意见
   • ❌ PM 独自为所有项目评分

2. 拉开分数差距：如果所有项目的评分都是 3，就说明你没有进行优先级排序

   • ✓ 强制排序或使用更大的评分范围（1-10）
   • ✓ 目标分布：少量 1/5 分，较多 2/4 分，很多 3 分
   • ❌ 所有项目评分都在 2.5-3.5 之间

3. 质疑极端评分：高影响、低工作量的项目很少见（如果有 10 个，就说明有问题）

   • ✓ 用“为什么我们还没做这个？”来检验是否确实能快速见效
   • ❌ 一厢情愿（低估工作量、高估影响）

4. 让评分过程透明：记录每项评分的理由

   • ✓ “工作量=4，因为需要 3 个团队、新建基础设施，周期为 6 周”
   • ❌ 只写“工作量=4”，没有任何理由

5. 定期重新审视评分：随着情况变化，工作量/影响也会变化

   • ✓ 每季度或发生重大变化后（新技术、团队规模变化）重新评分
   • ❌ 使用 2 年前的评分

6. 不要忽略依赖项：低工作量项目若受高工作量前置条件阻碍，就不能算快速见效

   • ✓ “任务的工作量=2，但依赖于工作量=5 的迁移”
   • ❌ 孤立地为任务评分

7. 谨防以“战略性”为由推翻评分：高管把所有事情都说成“高影响”，会破坏优先级排序

   • ✓ “战略性”是一个维度，不是一票否决权
   • ❌ “CEO 想要” → 自动评分为 5

快速参考

资源：

• 快速入门：resources/template.md - 2x2 矩阵模板和评分表
• 高级技术：resources/methodology.md - RICE、MoSCoW、Kano、加权评分
• 质量检查：resources/evaluators/rubric_prioritization_effort_impact.json - 评估标准

成功标准：

• ✓ 确定 1-3 个可立即执行的速赢项目
• ✓ 将重大赌注排入切实可行的路线图（不要过度承诺）
• ✓ 削减或推迟耗时项目（低投资回报率项目）
• ✓ 评分依据透明且站得住脚
• ✓ 利益相关方对优先级达成一致
• ✓ 路线图留有容量缓冲（不要把 100% 的时间都排满）

常见错误：

• ❌ 闭门评分（没有征求利益相关方的意见）
• ❌ 忽视工作量（乐观偏差：“所有事情都很简单”）
• ❌ 忽视影响（做容易做的事，而不是有价值的事）
• ❌ 分析瘫痪（追求完美评分，而不是足够好的优先级排序）
• ❌ 不对耗时项目说“不”
• ❌ 路线图安排过满（每周都排满重大赌注）
• ❌ 忘记维护和支持所需时间（假设项目容量为 100%）

何时使用替代方法：

• 加权评分（RICE）：当你需要比 2x2 更细致的评估时（覆盖范围 × 影响 × 置信度 / 工作量）
• MoSCoW：当需要在范围或截止日期固定的情况下确定优先级时（必须/应该/可以/不会）
• Kano 模型：当评估客户满意度时（基本型/期望型/兴奋型功能）
• ICE 评分：比 RICE 更简单（影响 × 置信度 × 易行性）
• 价值与复杂度：与工作量-影响评估相同，只是标签不同
• 延迟成本：当时间安排很重要时（因推迟而损失的收入）