需求优先级矩阵用“价值”和“投入”两个维度给需求打分定位，再叠加紧急度、合规风险等修正项，帮助团队在一张表里排出处理顺序。本文提供可直接复制到文档或表格工具中的空白矩阵表与评分记录表，逐字段说明取值和计算规则，区分必填与选填，并用一条完整需求演示从打分到结论的全过程。
要点总览（TL;DR）
- 模板由矩阵主表和评分记录表组成：主表按业务价值、用户价值、战略契合度合成价值分，按研发投入、依赖复杂度合成投入分，再判定象限。
- 价值分默认取三项价值评分的平均值，投入分取两项成本评分的平均值；象限以本批需求的中位值为分界线，紧急度与合规风险只修正结论、不改动原始分数。
- 需求编号、需求名称、业务价值、用户价值、研发投入以及价值分、投入分、象限、优先级结论为必填；战略契合度、依赖复杂度、修正项和处理建议可按团队规模裁剪。
- 填写时先按分值锚点打分，再算分定位象限，最后叠加修正项给出优先级结论与处理建议，评分依据同步写入记录表。
- 矩阵需要定期维护：连续两个周期需求过度集中、业务目标变化或评分分歧明显时调整权重，每个迭代复评待定与暂缓需求，并保留旧版本与历史评分行。
可复制空白需求优先级矩阵模板
模板由两张表组成：矩阵主表承载每条需求的评分与结论，评分记录表留存打分依据，便于复核和追溯。使用时先把主表表头复制到文档或表格工具，再按行填入需求；评分记录表与主表通过需求编号对应。
表一：需求优先级矩阵主表
| 需求编号 | 需求名称 | 提出方 | 业务价值（1–5） | 用户价值（1–5） | 战略契合度（1–5） | 价值分 | 研发投入（1–5） | 依赖复杂度（1–5） | 投入分 | 象限 | 紧急度修正 | 合规风险修正 | 优先级结论 | 处理建议 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
表二：评分记录表
| 需求编号 | 评分人 | 评分日期 | 业务价值依据 | 用户价值依据 | 战略契合依据 | 投入估算依据 | 修正项说明 | 备注 |
|---|---|---|---|---|---|---|---|---|
两张表都采用“一行一条需求”的结构。主表用于快速浏览和排序，记录表用于回答“这个分数是怎么来的”。团队人数较少时，记录表可以只保留评分人、评分日期和一句话依据；需求量大、跨部门评审多时，建议把每项依据写完整。
矩阵字段说明：每个列填什么、怎么算
字段分为四组：标识字段负责定位需求，价值类字段衡量收益，成本类字段衡量付出，修正字段处理时间与风险上的例外。理解每组字段的取值口径，是保证不同评分人结果可比的前提。
| 字段 | 分组 | 含义 | 取值与填写方式 |
|---|---|---|---|
| 需求编号 | 标识 | 需求的唯一标识，用于与需求池、记录表对应 | 沿用团队现有编号规则，如“REQ-001” |
| 需求名称 | 标识 | 一句话概括需求内容 | 动词开头，写清对象，如“支持批量导出订单” |
| 提出方 | 标识 | 需求来源，便于回溯沟通 | 填写部门、客户或角色名称 |
| 业务价值 | 价值 | 需求对收入、成本、效率等业务指标的影响 | 1–5 分，5 分为影响最大 |
| 用户价值 | 价值 | 需求对目标用户完成任务的帮助程度 | 1–5 分，5 分为用户获益最明显 |
| 战略契合度 | 价值 | 需求与当前阶段产品方向和公司目标的匹配程度 | 1–5 分，5 分为高度契合 |
| 价值分 | 价值 | 三项价值评分的合成结果 | 默认取三项平均值，保留一位小数 |
| 研发投入 | 成本 | 完成需求所需的人力与时间规模 | 1–5 分，5 分为投入最大 |
| 依赖复杂度 | 成本 | 需求涉及的外部系统、跨团队协作和前置条件的复杂程度 | 1–5 分，5 分为依赖最多 |
| 投入分 | 成本 | 两项成本评分的合成结果 | 默认取两项平均值，保留一位小数 |
| 象限 | 结论 | 需求在价值—投入平面上的位置 | 按价值分与投入分相对中位值判定，见下文 |
| 紧急度修正 | 修正 | 是否存在明确的时间窗口或外部截止日期 | 填“无”“一般”“紧急”三档 |
| 合规风险修正 | 修正 | 是否涉及法规、合同或安全要求 | 填“无”“关注”“必须处理”三档 |
| 优先级结论 | 结论 | 综合象限与修正项后的最终排序 | 填“高”“中”“低”或“待定” |
| 处理建议 | 结论 | 下一步动作 | 如“本迭代排入”“补充调研后再评”“暂缓观察” |
价值分与投入分的合成规则
默认采用等权平均：价值分 =（业务价值 + 用户价值 + 战略契合度）÷ 3；投入分 =（研发投入 + 依赖复杂度）÷ 2。等权的好处是规则简单、易解释，适合矩阵刚启用的阶段。若团队认为战略契合度更关键，可改为加权求和，但权重需在表头注明并保持整表一致。
象限判定方法
以价值分和投入分各自的中位值为分界线，把需求划入四个象限：
| 象限 | 价值分 | 投入分 | 典型处理 |
|---|---|---|---|
| 优先做 | 高于中位值 | 低于中位值 | 排入近期迭代 |
| 重点评估 | 高于中位值 | 高于中位值 | 拆分需求或分阶段交付 |
| 顺手做 | 低于中位值 | 低于中位值 | 有余量时批量处理 |
| 暂缓 | 低于中位值 | 高于中位值 | 放入需求池观察，定期复评 |
用中位值而非固定分数线，可以让象限随本批需求的实际分布自动调整，避免所有需求都挤在高价值区。
修正字段的作用
紧急度和合规风险不参与价值分与投入分的计算，而是在象限结论上做调整。合规风险为“必须处理”的需求，无论象限如何都应进入处理队列；紧急度为“紧急”且价值分不低于中位值的需求，可上调一档优先级。修正只调整结论，不改动原始分数，保证评分记录可追溯。
必填与选填：哪些字段不能空
必填字段决定矩阵能否完成基本排序，选填字段用于提高判断质量。团队可以先按最低标准跑起来，再逐步补齐。
| 字段 | 必填/选填 | 理由与缺失处理 |
|---|---|---|
| 需求编号 | 必填 | 缺失则无法与记录表和需求池对应，应先补编号再评分 |
| 需求名称 | 必填 | 缺失则评审无法识别对象 |
| 业务价值 | 必填 | 价值分的组成部分，缺失时该需求不参与排序 |
| 用户价值 | 必填 | 同上 |
| 研发投入 | 必填 | 投入分的组成部分，缺失时无法定位象限 |
| 价值分、投入分、象限 | 必填 | 由公式自动得出，不应手工留空 |
| 优先级结论 | 必填 | 矩阵的最终输出，未定时可填“待定”并注明原因 |
| 提出方 | 选填 | 缺失不影响排序，但影响后续沟通效率 |
| 战略契合度 | 选填 | 缺失时价值分按其余两项平均计算，并在记录表注明 |
| 依赖复杂度 | 选填 | 缺失时投入分按研发投入单项计算 |
| 紧急度修正、合规风险修正 | 选填 | 默认视为“无”，有明确依据时再填写 |
| 处理建议 | 选填 | 可在评审会上补充 |
| 评分记录表各列 | 评分人、日期必填，依据列选填 | 依据缺失时至少保留一句话说明 |
不同团队规模的字段裁剪建议
5 人以下的小团队可以只保留编号、名称、业务价值、用户价值、研发投入、象限和结论七列，修正项在评审时口头确认。10 人左右、有固定迭代节奏的团队建议补齐战略契合度和依赖复杂度，让价值分与投入分更稳定。跨部门协作较多、需求来源分散的团队，应完整保留提出方、修正项和评分记录表，否则不同来源的需求难以放在同一口径下比较。
填写示例：一条需求走完整个矩阵
以下示例为演示情景，用于说明字段如何取值和计算，数值不代表任何真实项目的评估结果。
需求背景与原始描述
提出方为运营部门，原始描述是“希望订单列表支持按时间段批量导出，方便每周做对账”。当前运营人员需要逐页复制订单数据，每周约花费半天时间。该需求与当前阶段“提升后台操作效率”的方向一致，不涉及外部系统改造，但导出格式需要与财务系统对齐。
各字段取值与打分理由
| 字段 | 取值 | 理由 |
|---|---|---|
| 需求编号 | REQ-018 | 沿用现有编号 |
| 需求名称 | 订单列表支持按时间段批量导出 | 动词开头，对象明确 |
| 提出方 | 运营部 | 需求来源 |
| 业务价值 | 4 | 每周节省约半天人工，直接降低对账成本 |
| 用户价值 | 4 | 运营人员从重复复制转为一次导出 |
| 战略契合度 | 4 | 符合当前提升后台效率的方向 |
| 研发投入 | 2 | 复用现有查询能力，增加导出接口 |
| 依赖复杂度 | 3 | 导出格式需与财务系统确认字段口径 |
| 紧急度修正 | 一般 | 季度对账前需要，但无硬性截止日 |
| 合规风险修正 | 关注 | 导出数据含客户信息，需确认权限范围 |
计算与象限归属
价值分 =（4 + 4 + 4）÷ 3 = 4.0；投入分 =（2 + 3）÷ 2 = 2.5。假设本批需求的价值分中位值为 3.5、投入分中位值为 3.0，则该需求价值分高于中位值、投入分低于中位值，落入“优先做”象限。
最终结论与处理动作
综合象限结果与修正项，优先级结论定为“高”，处理建议为“本迭代排入，开发前与财务确认导出字段，并限定导出权限”。合规风险为“关注”，因此在处理建议中增加权限确认动作，而不是直接上调优先级。评分记录表同步填写：评分人为产品负责人，评分日期为评审当日，依据列写明“运营每周对账耗时约半天”“复用现有查询能力”等要点。
调整与维护：让矩阵长期可用
矩阵的价值来自持续使用。评分口径、权重和象限阈值都需要随业务变化调整，调整过程本身也要留痕，否则历史结论会失去可比性。
评分权重调整的触发条件
出现以下情况时，建议重新审视权重和分制：连续两个评审周期内，超过六成需求落入同一象限，说明区分度不足；业务目标发生阶段性变化，例如从拉新转向留存，战略契合度的权重需要相应提高；多个团队反馈同一类需求的评分分歧明显，说明评分锚点描述不清，应先补充各分值的判定说明，再考虑调权重。调整应在评审会上确认，并记录生效日期。
定期复评的节奏与参与角色
建议每个迭代规划前复评一次“待定”和“暂缓”象限的需求，每季度对全量需求做一次完整复评。参与角色包括产品负责人、提出方代表和技术负责人：产品负责人维护评分口径，提出方补充价值依据，技术负责人更新投入估算。复评只更新发生变化的字段，并在记录表追加一行，保留上一次评分。
矩阵版本与历史记录留存
每次调整字段、权重或阈值，都应保留旧版本表并标注适用时间段。评分记录表按需求编号累积，不覆盖历史行。这样在回溯“某条需求当时为什么排在后面”时，能同时看到当时的分数、依据和规则版本。
与需求池状态流转的衔接
矩阵结论需要落到需求池的状态上才有执行力。可以约定：优先级结论为“高”的需求进入“已排期”，为“中”的留在“待评估”，为“低”或“暂缓”的进入“观察中”，合规风险为“必须处理”的需求单独标记并进入处理队列。状态变更时同步更新矩阵中的处理建议，避免表格与需求池两套口径。
如果团队使用 ONES 承载需求池，可以把矩阵的评分字段和处理建议对应到工作项字段，让评分结果与需求状态在同一处维护。ONES Wiki 支持页面模板库，可将本文两张表保存为制式化文档模板，一键创建；页面组可关联项目，需求与文档互相对应，文档还支持嵌入任务进度和报表。文档会记录页面版本并支持回滚，便于保留每次复评前后的矩阵版本。评审讨论中的分歧也可以在页面上通过评论留痕，减少评分口径在口头传递中走样。
常见问题
团队对同一条需求的价值打分分歧很大，怎么处理？
分歧通常来自评分锚点不清，而不是评分人判断力不同。可以先回到字段说明，把每个分值对应的典型情形写出来，例如业务价值 5 分对应“直接影响主要收入来源或显著降低成本”，3 分对应“间接改善效率”，让评分人对着同一组描述打分。
如果补充锚点后仍有分歧，建议在评审会上记录两种意见及各自依据，由产品负责人裁定一个取值，并在评分记录表中注明分歧点。下一轮复评时优先复核这类需求，观察结论是否稳定。
需求数量很少时，还需要用中位值划分象限吗？
中位值的作用是让象限随本批需求的实际分布调整，需求数量很少时它的区分度会下降。例如只有五六条需求，中位值可能落在两条相邻分数之间，象限归属对单个分数变化很敏感。
这种情况下可以改用固定分数线，例如价值分 3.5 以上、投入分 3.0 以下为“优先做”，并在表头注明所用口径。等需求积累到一定数量后，再切回中位值方式，切换时保留旧表以便对比。
合规风险为“必须处理”的需求，是否一定排在最前面？
合规风险为“必须处理”的需求应进入处理队列，这是硬性约束，但它与“排在最前面”是两件事。实际排序时还要看处理该需求所需的投入和可用的时间窗口：如果投入很小，通常直接排入近期迭代；如果投入较大，可以拆出满足合规要求的最小范围先行交付，其余部分按常规节奏推进。
无论采用哪种方式，都应在处理建议中写明合规要求对应的具体动作和完成时间，并在矩阵中保留原始分数，避免修正项覆盖评分记录。
矩阵里的优先级结论和需求池里的状态如何保持一致？
常见做法是把结论与状态建立固定映射：结论为“高”进入已排期，“中”留在待评估，“低”或“暂缓”进入观察中，合规风险为“必须处理”的单独标记。映射规则写进团队约定，状态变更时同步更新矩阵中的处理建议。
如果两处分别维护，容易出现表格显示高优先级、需求池里仍停在待评估的情况。可以让矩阵结论成为状态流转的输入条件，并在每次复评后核对一遍两者是否一致。
矩阵运行一段时间后，大部分需求都落在“优先做”象限，说明什么？
这通常说明评分区分度不足，可能的原因有三类：分值锚点过于宽松，评分人倾向于给高分；权重设置让价值分普遍偏高；象限阈值与本批需求的实际分布不匹配。
可以先检查各分值的实际使用分布，如果 4 分和 5 分占了绝大多数，应补充更细的判定描述；再审视权重是否需要调整；最后考虑改用中位值或重新设定分数线。调整后记录生效日期，旧版本表保留，便于对比调整前后的排序变化。
