项目优先级清单用于在多个候选项目之间做取舍：每个项目占一行，记录战略贡献、价值与投入、风险与依赖、资源占用和决策结论，再用统一口径排出先后。本文提供可直接复制的空白表格、逐字段取值说明、必填与选填划分、一行完整填写示例，以及评审周期内的调整维护规则，示例中的分值与权重可按组织实际口径替换。
要点总览（TL;DR）
- 项目优先级清单按“基本信息—评估评分—决策结论”三段组织，每个候选项目一行，用统一评分口径排出先后。
- 决定排序的必填字段是项目名称、负责人、所属组合、战略贡献、业务价值、投入规模，以及加权总分、优先级排序和决策结论。
- 评分统一用1–5分并对投入、风险、依赖、资源占用做正向化处理，加权总分按评审组事先确定的权重计算，同一批次内权重保持不变。
- 清单需要按评审周期维护：新项目进入、范围或预算变化、关键依赖延期时更新，每轮评审后保存快照并记录变更。
- 单个需求在项目内部的排序交给需求优先级方法，组合层面的资源重新分配属于组合动态调整，清单只提供取舍依据。
可复制空白模板：项目优先级清单表
下表按“基本信息—评估评分—决策结论”三段组织。使用时整表复制到文档或表格工具，每个候选项目新增一行；评分列先按统一刻度打分，再由加权公式汇总，最后填写结论与排期。空白行保留三行，便于直接开始填写。
| 一、项目基本信息 | ||||||
|---|---|---|---|---|---|---|
| 项目名称 | 项目编号 | 负责人 | 所属组合/业务线 | 提出日期 | 评审批次 | 当前状态 |
| 二、评估评分（1–5 分，5 为最优） | ||||||||
|---|---|---|---|---|---|---|---|---|
| 战略贡献 | 业务价值 | 投入规模 | 风险程度 | 依赖复杂度 | 资源占用 | 加权总分 | 评分人 | 评分日期 |
| 三、决策结论 | ||||||
|---|---|---|---|---|---|---|
| 优先级排序 | 决策结论 | 计划启动时间 | 目标完成时间 | 决策人 | 决策日期 | 备注 |
三段拆开是为了让不同角色分工填写：项目负责人填基本信息与自评，评审组填评分，决策人填结论与排期。若在表格工具中使用，建议三段放在同一工作表，用列宽和底色区分，避免拆成多个文件后版本对不上。
字段说明：每个列填什么、怎么取值
字段口径不一致是清单失效最常见的原因：同一个“业务价值”，有人填收入增量，有人填用户满意度，排序结果就失去可比性。下表给出每个字段的含义与取值方式，填表前应先由评审组确认一遍。
| 字段 | 含义 | 取值方式 |
|---|---|---|
| 项目名称 | 可识别的项目简称 | 文本，与立项材料保持一致 |
| 项目编号 | 组织内唯一标识 | 文本，沿用现有编号规则 |
| 负责人 | 对项目结果负责的人 | 姓名，一人 |
| 所属组合/业务线 | 项目归属的管理单元 | 从组织既有的组合或业务线清单中选择 |
| 提出日期 | 进入候选池的时间 | 日期 |
| 评审批次 | 参与哪一轮评审 | 如“2025-Q2 第一次评审” |
| 当前状态 | 项目在流程中的位置 | 候选、评审中、已排期、进行中、暂缓、关闭 |
| 战略贡献 | 与年度重点方向、关键目标的契合程度 | 1–5 分，5 表示直接支撑核心目标 |
| 业务价值 | 收入、成本、体验或合规方面的预期收益 | 1–5 分，按组织约定的收益区间映射 |
| 投入规模 | 所需人力、时间与资金的综合量级 | 1–5 分，5 表示投入最小（正向化处理） |
| 风险程度 | 技术、市场、合规等不确定性 | 1–5 分，5 表示风险最低 |
| 依赖复杂度 | 对外部团队、系统或前置项目的依赖 | 1–5 分，5 表示依赖最少 |
| 资源占用 | 对关键稀缺资源（如核心研发、预算）的占用 | 1–5 分，5 表示占用最少 |
| 加权总分 | 各评分项按权重汇总的结果 | 公式计算，保留一位小数 |
| 评分人/评分日期 | 评分责任与时间 | 姓名与日期，便于追溯 |
| 优先级排序 | 本批次内的名次 | 整数，同分时并列并注明 |
| 决策结论 | 对项目的处置意见 | 优先启动、排入计划、暂缓、不立项 |
| 计划启动/目标完成 | 排期区间 | 日期，暂缓项目可留空 |
| 决策人/决策日期 | 结论的责任人与时间 | 姓名与日期 |
| 备注 | 补充说明 | 文本，如暂缓原因、附加条件 |
评分刻度建议统一为 1–5 分，并对“投入规模、风险程度、依赖复杂度、资源占用”做正向化处理，即分值越高代表越有利，这样加权时所有列方向一致，不必在公式里做减法。权重由评审组在每轮评审前确定，例如战略贡献 30%、业务价值 30%、投入规模 15%、风险程度 10%、依赖复杂度 10%、资源占用 5%，加权总分 = Σ（单项得分 × 权重）。权重一经确定，同一批次内不得单独调整，否则排序不可比。
必填与选填：哪些字段决定排序，哪些用于补充
决定排序结论的是评分项与决策项，基础信息中只有少数几列必须齐全。把字段分成必填与选填，可以让初筛阶段填得轻，正式评审再补齐，减少填表阻力。
| 字段类别 | 字段 | 缺失后果 |
|---|---|---|
| 必填 | 项目名称、负责人、所属组合/业务线 | 无法识别项目归属，评审时无法分派责任 |
| 必填 | 战略贡献、业务价值、投入规模 | 加权总分无法计算，排序缺少核心依据 |
| 必填 | 加权总分、优先级排序、决策结论 | 清单退化为信息登记表，无法支撑取舍 |
| 选填 | 项目编号、提出日期、评审批次 | 不影响排序，但影响追溯与批次管理 |
| 选填 | 风险程度、依赖复杂度、资源占用 | 初筛可暂缺；正式评审建议补齐，否则排序偏乐观 |
| 选填 | 计划启动/目标完成时间、决策人、决策日期、备注 | 暂缓或不立项项目可留空；已排期项目应填写 |
初筛阶段的目的是快速淘汰明显不合适的候选，此时只需项目名称、负责人、所属组合、战略贡献与业务价值五项，加上一句初步判断即可。进入正式评审后，补齐全部评分项、加权总分与决策字段，并由评审组复核评分口径。若组织项目数量较多，也可以把风险与依赖两项放到正式评审再评，但需要在规则中写明，避免不同批次口径不一致。
填写示例：一个完整项目行怎么填
以下为演示情景，项目名称与分值均为虚构，用于说明填写方式与计算过程，实际使用时替换为真实数据。
背景与约束：某业务线提出“客户自助报表”项目，目标是减少客服重复取数工单，预计投入两名研发约一个季度，依赖数据平台已上线的指标接口。本批次权重为战略贡献 30%、业务价值 30%、投入规模 15%、风险程度 10%、依赖复杂度 10%、资源占用 5%。
| 字段 | 填写内容 |
|---|---|
| 项目名称 | 客户自助报表 |
| 项目编号 | PRJ-2025-018 |
| 负责人 | 张明 |
| 所属组合/业务线 | 客户服务 |
| 提出日期 | 2025-04-08 |
| 评审批次 | 2025-Q2 第一次评审 |
| 当前状态 | 评审中 |
| 战略贡献 | 4 分（支撑“降低服务成本”年度目标） |
| 业务价值 | 4 分（预计减少约三成重复取数工单） |
| 投入规模 | 3 分（两人一个季度，属中等投入） |
| 风险程度 | 4 分（技术方案成熟，主要风险在推广使用） |
| 依赖复杂度 | 3 分（依赖数据平台指标接口按期交付） |
| 资源占用 | 3 分（占用两名后端研发） |
| 加权总分 | 3.7 分 |
| 评分人/评分日期 | 评审组 / 2025-04-15 |
| 优先级排序 | 第 2 位 |
| 决策结论 | 排入计划 |
| 计划启动/目标完成 | 2025-05-06 / 2025-08-15 |
| 决策人/决策日期 | 李华 / 2025-04-18 |
| 备注 | 需数据平台确认接口排期后启动 |
计算过程：4×30% + 4×30% + 3×15% + 4×10% + 3×10% + 3×5% = 1.2 + 1.2 + 0.45 + 0.4 + 0.3 + 0.15 = 3.7 分。同批次中另一项目加权总分为 3.9 分，故本项目排第 2 位。可以看到，战略贡献与业务价值两项合计占 60%，对结果影响最大；投入与资源两项用于在价值接近时区分先后。示例中每个评分都附了一句依据，这是保证不同评分人理解一致的关键动作。
调整与维护方法：让清单在评审周期内持续可用
清单填完只是开始。项目组合会随市场、资源和交付情况变化，若清单长期不更新，排序会与实际脱节。维护的重点是明确“什么时候改、改什么、怎么留痕”。
更新触发条件建议写入规则：新项目进入候选池、项目范围或预算发生明显变化、关键依赖延期、季度评审启动、重大风险出现。触发后由负责人更新对应行，评审组复核评分，决策人确认结论变化。日常小调整可只改状态与备注，涉及评分或结论的变更应走一次简短复核。
字段增删与权重调整需要克制。建议每个评审周期开始前集中确认一次字段与权重，周期内保持不变；确需调整时，在变更记录中写明原因，并对已评分项目重新计算，避免新旧口径混排。字段增删优先考虑是否影响排序，只影响描述的信息放入备注列。
历史版本留存方面，每轮评审结束后保存一份快照，并维护一张变更记录表：
| 变更日期 | 变更对象 | 变更内容 | 变更原因 | 影响范围 | 确认人 |
|---|---|---|---|---|---|
需要区分边界：本清单处理的是项目之间的取舍，单个需求在项目内部的先后顺序应交给需求优先级方法处理；组合层面的资源重新分配属于组合动态调整的执行过程，清单只提供决策依据，不替代资源调度。把这两类工作混在同一张表里，会让评分口径变得难以解释。
清单落地时，承载方式会影响维护成本。若清单以文档形式存在，可借助 ONES Wiki 的页面模板库一键创建制式化文档，让每轮评审使用同一结构；成员可在线添加注释与评论，对评分依据进行反馈；页面版本会被记录并支持查看与回滚，便于保留每轮评审快照。页面组可关联项目，使清单条目与项目工作保持对应，文档中也可嵌入任务进度与报表，方便评审时对照实际进展。具体采用哪种承载方式，取决于团队已有的协作习惯与评审频率。
常见问题
项目数量不多，还需要做加权评分吗？
项目少时可以先简化，但建议保留评分方向的一致性。若候选项目在10个以内，可只对战略贡献、业务价值、投入规模三项打分并直接排序，风险与依赖作为讨论时的补充信息。项目数量增加或跨业务线比较时，再引入完整权重，避免不同批次口径不一致。
同一批次里两个项目加权总分相同，怎么处理？
同分时先看权重最高的评分项，例如战略贡献与业务价值，比较单项得分；仍相同则参考风险程度与依赖复杂度，优先选择不确定性更低的项目。排序栏可并列注明“并列第2”，并在备注中写明取舍理由，便于后续追溯。
评分人给出的分数差异很大，如何校准？
校准的关键是让每个分值附一句依据。评审前用一两个已完成项目做锚点，说明各分值对应的典型情形；评审中由评审组对分歧较大的项目逐项讨论，记录调整原因。评分人、评分日期和依据说明都保留在清单中，下一轮可对照历史口径。
清单用文档维护还是用管理工具维护？
取决于评审频率和参与人数。评审频率低、参与人少的团队，用文档承载即可，结构统一、便于传阅。评审频繁、需要与项目进展对照时，可考虑用支持页面模板与版本记录的工具承载。例如 ONES Wiki 支持通过模板库一键创建制式化文档，页面版本会被记录并支持查看与回滚，页面组可关联项目，文档中也可嵌入任务进度与报表，便于评审时对照实际进展。具体选择仍以团队已有协作习惯为准。
暂缓的项目要不要继续留在清单里？
建议保留，并把当前状态标为“暂缓”，在备注中写明暂缓原因和重新评估的条件，例如依赖接口交付或预算释放。这样下一轮评审可以直接复用已有评分，只需复核变化的部分；直接删除会让历史判断丢失，后续重复讨论。
