prioritization-effort-impact

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

目录

1. 目的
2. 适用场景
3. 它是什么？
4. 工作流程
5. 常见模式
6. 评分框架
7. 护栏
8. 快速参考

目的

通过将事项映射到投入（成本/复杂度）与影响（价值/收益）的 2x2 矩阵中，把令人应接不暇的待办列表和选项列表转化为清晰、可执行的优先级。识别快速见效项（高影响、低投入），并将其与重大押注（高影响、高投入）、时间黑洞（低影响、高投入）和填充项（低影响、低投入）区分开来。

适用场景

在以下情况下使用此技能：

• 待办事项过多：有 20 项以上的事项（功能、错误、任务、想法），需要决定执行顺序
• 资源受限：时间、预算或人手有限，必须做出取舍
• 战略规划：为季度/年度路线图选择计划、项目或投资
• 需要快速见效：利益相关者希望快速看到进展；你需要找到高影响、低投入的事项
• 明确取舍：团队争论“应该做 A 还是 B？”，却没有明确比较投入和影响
• 目标不一致：不同利益相关者（工程、产品、销售、高管）的优先级相互冲突
• 频繁切换上下文：同时进行的项目过多；需要专注于最重要的事项
• 新任 PM/领导者：接手待办列表，需要系统化的优先级排序方法

常见触发场景：

• “我们有 50 个功能请求，应该从哪里开始？”
• “哪些事项能快速见效？”
• “应该先做迁移，还是先做新功能？”
• “如何确定技术债务和新功能的优先级？”
• “怎样才能用最少的投入获得最大的回报？”

它是什么？

投入–影响矩阵（也称影响–投入矩阵、快速见效矩阵或 2x2 优先级矩阵）从两个维度对每个事项进行绘制：

• X 轴：投入（时间、成本、复杂度、风险、依赖关系）
• Y 轴：影响（价值、收入、用户收益、战略契合度、风险降低）

四个象限：

High Impact │
            │  Big Bets       │  Quick Wins
            │  (do 2nd)       │  (do 1st!)
            │─────────────────┼─────────────
            │  Time Sinks     │  Fill-Ins
            │  (avoid)        │  (do last)
Low Impact  │
            └─────────────────┴─────────────
              High Effort       Low Effort

**示例：**包含 12 个事项的功能待办列表

事项	投入	影响	象限
添加“导出为 CSV”按钮	低（2d）	高（许多用户）	快速见效项 ✓
重建整个身份验证系统	高（3mo）	高（安全性）	重大押注
将徽标像素对齐做到完美	高（1wk）	低（美观）	时间黑洞 ❌
修正页脚中的拼写错误	低（5min）	低（无关紧要）	填充项

**决策：**首先做“导出为 CSV”（快速见效项），接着安排重建身份验证系统（重大押注），放弃追求徽标完美对齐（时间黑洞），批量修正拼写错误（填充项）。

工作流

复制此清单并跟踪进度：

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：可忽略到变革性）。请相关领域专家参与，以确保准确性。高级评分方法（如斐波那契数列、T 恤尺码或 RICE）请参阅 resources/methodology.md。

步骤 3：绘制矩阵并确定象限

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

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

安排项目顺序：优先处理快速见效项，其次处理重大押注项（待快速见效项积累势头后），空闲时处理填充项，除非有必要，否则避免时间黑洞项。路线图结构请参阅 resources/template.md。

步骤 5：验证并沟通决策

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

常见模式

按领域划分：

• 产品待办事项：快速见效项 = 小幅用户体验改进，重大押注项 = 新工作流，时间黑洞项 = 对边缘情况追求完美
• 技术债务：快速见效项 = 配置修复，重大押注项 = 架构改造，时间黑洞项 = 过早优化
• 漏洞分类：快速见效项 = 影响大且容易修复的漏洞，重大押注项 = 复杂的关键漏洞，时间黑洞项 = 外观问题
• 战略计划：快速见效项 = 流程调整，重大押注项 = 市场拓展，时间黑洞项 = 虚荣指标
• 营销活动：快速见效项 = 邮件培育，重大押注项 = 品牌改造，时间黑洞项 = 小规模 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 更简单（影响 × 置信度 × 易行性）
• 价值与复杂度：与工作量-影响评估相同，只是标签不同
• 延迟成本：当时间安排很重要时（因推迟而损失的收入）