需求价值评估表把需求编号、目标用户、业务价值、影响范围、实现成本、风险与依赖等字段放在同一张表里，让不同评估人按统一口径填写和打分，再据此排出优先级。本文提供一张可直接复制的空白表、逐字段说明、必填与选填对照、一条完整填写示例，以及模板长期使用中的调整与维护方法。评估对象是需求，不涉及任务排期和功能规划取舍。
要点总览（TL;DR）
- 空白评估表包含需求编号、目标用户、业务价值、影响范围、实现成本、风险与依赖、价值分、性价比、优先级等16个字段，可直接复制到文档或表格工具中使用。
- 事实字段先填、判断字段后打分：业务价值、影响范围、实现成本按1–5分打分，价值分示例口径为业务价值×0.6＋影响范围×0.4，性价比为价值分÷成本分。
- 需求编号、需求名称、目标用户、业务价值、影响范围、实现成本、价值分、成本分、性价比、优先级、评估人、评估日期、风险与依赖为必填；提出人、状态、备注可按团队规模裁剪。
- 优先级以性价比排序为基础，风险与依赖为“高”的需求先解决依赖再排期，调整理由写入备注，保证结果可复盘。
- 模板需按季度复核字段、调整权重前做新旧排序对比、保留版本号与变更记录，并每月清理超期未评估记录。
可复制空白需求价值评估表
下表可直接复制到文档或表格工具中使用。表头固定，每行填写一条需求；评估人按字段顺序先填事实、再打分，最后计算价值分与优先级。表格末尾附一行填写提示，复制时一并保留，方便新成员快速上手。
| 需求编号 | 需求名称 | 提出人/来源 | 目标用户 | 业务价值 | 影响范围 | 实现成本 | 风险与依赖 | 价值分 | 成本分 | 性价比 | 优先级 | 评估人 | 评估日期 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
填写提示：先填需求编号到风险与依赖的事实字段，再按团队约定口径给业务价值、影响范围、实现成本打分，算出价值分、成本分与性价比，最后判定优先级并签署评估人。空白行可按需增删，字段顺序建议保持不变。
如果团队已经在 ONES 中管理需求，可以把这张表作为评估口径，在 ONES Wiki 中用页面模板库创建制式化文档模板，让每次评估从同一张表开始；评估结论再与需求对象关联，避免表格散落在个人电脑里。ONES Wiki 支持页面组关联项目、需求与文档互相对应，评估记录可以跟随需求一起留存。
每个字段填什么：字段说明与取值口径
字段分为两类：事实字段记录客观信息，判断字段承载评估结论。事实字段由提出人或需求负责人填写，判断字段由评估人按统一口径打分。两类字段混填是评估失真的常见原因，建议在表头用颜色或分组区分。
| 字段 | 类型 | 含义 | 取值口径 | 常见填写错误 |
|---|---|---|---|---|
| 需求编号 | 事实 | 需求的唯一标识 | 沿用需求池或项目中的编号，不另行编造 | 同一需求出现两个编号，导致重复评估 |
| 需求名称 | 事实 | 一句话概括需求 | 动宾结构，控制在20字以内 | 写成方案描述或技术实现细节 |
| 提出人/来源 | 事实 | 需求从哪里来 | 填写具体人名、客户或渠道 | 只写“客户反馈”，无法追溯 |
| 目标用户 | 事实 | 需求服务的用户群体 | 写明角色或用户分层，如“新注册用户” | 写“所有用户”，范围过宽失去区分度 |
| 业务价值 | 判断 | 需求带来的业务收益 | 按1–5分打分，5分为直接支撑核心业务目标 | 凭印象给满分，缺少打分理由 |
| 影响范围 | 判断 | 受影响的用户量或业务环节 | 按1–5分打分，5分为覆盖主要用户群或多个环节 | 把影响范围与业务价值混为一谈 |
| 实现成本 | 判断 | 研发、设计、测试的投入量级 | 按1–5分打分，5分为投入最大 | 只估研发工时，漏掉设计与测试 |
| 风险与依赖 | 事实+判断 | 技术风险、外部依赖、合规约束 | 列出具体依赖项，并标注高/中/低 | 写“有一定风险”，无法据此决策 |
| 价值分 | 计算 | 业务价值与影响范围的综合分 | 示例口径：业务价值×0.6＋影响范围×0.4 | 直接抄业务价值分，忽略影响范围 |
| 成本分 | 计算 | 实现成本的量化分 | 直接取实现成本分，或按团队口径折算 | 与价值分使用不同量纲，无法比较 |
| 性价比 | 计算 | 单位成本带来的价值 | 价值分÷成本分，保留一位小数 | 成本分为0时未做处理 |
| 优先级 | 判断 | 需求的排序结论 | 按性价比排序，结合风险与依赖人工调整 | 只按提出人职级排序 |
| 评估人 | 事实 | 对本次评估负责的人 | 填写参与评估的主要责任人 | 空白或只写部门名 |
| 评估日期 | 事实 | 评估完成时间 | 统一格式，如2025-06-01 | 格式混用，无法按时间筛选 |
| 状态 | 事实 | 评估进展 | 待评估/已评估/已排期/已关闭 | 长期停留在“待评估” |
| 备注 | 选填 | 补充说明 | 记录打分理由或争议点 | 把完整讨论过程写进备注 |
价值分与优先级的计算方式需要在模板说明中固定下来。上表给出的权重是示例口径，团队可以根据业务阶段调整，例如早期产品更看重影响范围，成熟产品更看重业务价值。优先级不只看性价比：风险与依赖为“高”的需求，即使性价比靠前，也应先解决依赖再排期。评估人需要在备注中写明调整理由，保证排序结果可复盘。
必填与选填：哪些字段不能空
必填字段缺失会让评估结论失去依据，这类记录应退回补充，不进入排序。选填字段用于补充信息，团队可按规模裁剪。
| 字段 | 必填/选填 | 缺失时的处理 |
|---|---|---|
| 需求编号 | 必填 | 退回提出人补充，无法关联需求池 |
| 需求名称 | 必填 | 退回补充，名称不清无法评审 |
| 目标用户 | 必填 | 退回补充，缺少用户对象无法判断价值 |
| 业务价值 | 必填 | 评估人补打分并写明理由 |
| 影响范围 | 必填 | 评估人补打分 |
| 实现成本 | 必填 | 由研发负责人补充估算 |
| 价值分、成本分、性价比 | 必填（计算得出） | 检查公式是否被覆盖，重新计算 |
| 优先级 | 必填 | 评估会当场判定，不允许留空 |
| 评估人、评估日期 | 必填 | 补签，否则评估记录无效 |
| 风险与依赖 | 必填（可写“无”） | 明确写“无”，避免默认未考虑 |
| 提出人/来源 | 选填 | 可合并进备注 |
| 状态 | 选填 | 小团队可省略，用表格分组代替 |
| 备注 | 选填 | 无补充内容可留空 |
团队规模影响裁剪方式。5人以下的小团队可以省略提出人、状态两列，把评估会与需求评审合并进行，减少重复填写；10人以上的团队建议保留全部字段，并增加“评估轮次”列，区分初评与复评。跨部门协作的团队应保留风险与依赖字段，因为外部依赖往往是排序调整的主要依据。裁剪的原则是：影响排序判断的字段保留，只影响记录完整性的字段可以合并。
填写示例：一条需求从空表到排序结果
以下为演示情景，用于说明填写方式，不代表真实项目数据。背景：某协作工具团队收到一条需求，希望新注册用户在首次登录时看到引导任务清单，减少因不熟悉功能而流失的情况。
| 字段 | 填写内容 |
|---|---|
| 需求编号 | REQ-2025-0187 |
| 需求名称 | 新用户首次登录展示引导任务清单 |
| 提出人/来源 | 客户成功团队，来自三家试用客户的访谈反馈 |
| 目标用户 | 注册7天内、尚未完成核心操作的新用户 |
| 业务价值 | 4分。引导完成率提升可直接影响试用转化，属于增长目标下的支撑需求 |
| 影响范围 | 4分。覆盖全部新注册用户，涉及注册后首页与消息通知两个环节 |
| 实现成本 | 3分。需要前端新增引导组件、后端记录完成状态，测试覆盖多端 |
| 风险与依赖 | 中。依赖用户行为埋点数据，埋点方案需与数据团队确认 |
| 价值分 | 4×0.6＋4×0.4＝4.0 |
| 成本分 | 3 |
| 性价比 | 4.0÷3≈1.3 |
| 优先级 | 高。性价比在同期候选中靠前，依赖项可在两周内确认 |
| 评估人 | 产品负责人（评估会三人共同确认） |
| 评估日期 | 2025-06-01 |
| 状态 | 已评估 |
| 备注 | 若埋点依赖延期，优先级下调至中，先做静态引导版本 |
这条示例与字段说明保持一致：业务价值与影响范围分别打分，价值分按示例权重计算，性价比保留一位小数，优先级在计算结果基础上结合依赖确认时间做了说明。备注写明了条件变化时的调整方式，便于下次复盘时判断当时的排序是否合理。把同类需求按性价比从高到低排列，再对风险与依赖为“高”的条目单独标注，就得到一份可讨论的优先级清单。
评估结果需要进入评审和后续跟踪。在 ONES 中，可以把评估表作为 Wiki 页面模板固定下来，评估记录与需求文档互相对应；ONES Wiki 记录所有页面版本并支持回滚，权重口径调整后旧记录仍可追溯。ONES Assistant 可以基于项目、工作项和 Wiki 页面等上下文回答问题，帮助评估人快速找到历史评估依据，减少重复补充背景。
模板的调整与维护方法
模板用一段时间后会出现字段冗余、口径漂移和记录堆积三类问题。维护的目标是让字段继续服务于排序判断，让评分口径在团队内保持一致，让历史记录可查可清理。
字段增删原则。新增字段前先回答：这个字段是否会影响排序结论或评审决策。会影响的字段加入必填区；只用于记录的字段放入备注或单独附表。删除字段时保留至少一个评估周期的历史数据，确认无人引用后再移除。字段名称和顺序尽量稳定，改名时同步更新填写说明。
评分权重调整方法。权重调整应基于复盘数据，而非临时感觉。可以按季度统计：按当前权重排出的优先级，与实际排期结果偏差较大的需求有多少，偏差集中在业务价值还是影响范围。调整后先在少量需求上试算，对比新旧排序差异，再正式启用。每次调整都要在模板说明中记录生效日期和调整理由。
版本与变更记录。模板本身应有版本号，例如 v1.0、v1.1，并在表格顶部或说明页记录变更内容、变更人和生效时间。ONES Wiki 的页面版本记录可以承担这一职责，文档实时同步并保留历史版本，需要时回滚到旧版对照。权限方面，可为评估人配置编辑权限、为提出人配置只读权限，减少误改。
定期复盘与清理机制。建议每月检查一次状态停留在“待评估”超过两周的需求，退回或关闭；每季度清理已关闭且无后续引用价值的记录，归档到历史页面。复盘会上抽取若干条已排期需求，核对当时的评分与实际结果是否吻合，把结论写回模板说明，形成下一轮调整依据。
- 每季度复核一次字段清单，删除连续两个周期无人填写的字段
- 权重调整前做新旧排序对比，保留对比记录
- 模板版本号与生效日期写入表头
- 每月清理超期未评估记录，每季度归档已关闭需求
- 复盘结论回写模板说明，作为下次调整依据
维护动作本身也需要有人负责。可以由产品负责人或需求管理岗担任模板维护人，评估人负责按口径填写，提出人负责补充事实字段。职责明确后，模板才能在团队人员变动时继续使用，评估记录也才能成为可追溯的决策依据。
常见问题
评估表里的价值分和优先级，应该由一个人定还是集体定？
建议由评估小组共同确认，评估人字段填写主要责任人。业务价值与影响范围涉及对用户和业务目标的判断，单人打分容易受岗位视角影响；实现成本应由研发负责人提供估算，避免产品单方面压低或抬高成本分。评估会上逐条确认打分理由，把争议点写入备注，比事后追认更省时间。
小团队可以把评估会与需求评审合并，由产品、研发、业务各出一人参与，仍然保留评估人签署环节。
同一个需求在不同季度评估，分数变了怎么办？
分数变化本身是正常现象，关键是保留两次评估记录并说明变化原因。可以在备注中写明“因用户量增长，影响范围由3分调整为4分”这类具体依据，而不是直接覆盖旧分数。模板维护人按季度核对分数波动较大的需求，判断是市场变化、口径调整还是当初打分偏差。
如果变化来自权重口径调整，应在模板说明中记录生效日期，旧记录按当时口径解读，避免用新口径反推历史排序。
需求数量多、评估人力有限时，能不能只给部分需求打分？
可以分层处理。先按来源和目标用户做初筛，明显重复、超出当前产品范围或缺少目标用户的需求直接退回，不进入打分环节；进入候选池的需求再按完整字段评估。这样能保证参与排序的每条需求都有完整依据，同时减少评估工作量。
初筛标准应写入模板说明并保持稳定，避免变成按提出人职级或主观印象筛选。初筛退回的需求保留记录，便于后续复盘时判断筛选是否合理。
评估表放在文档里和放在需求管理工具里，怎么选？
评估频率低、参与人少的团队，用文档表格即可满足需求，复制模板、填写、存档都比较直接。评估频繁、需求与项目进度需要联动的团队，更适合把评估表做成固定模板放在知识库中，并与需求对象关联，让评估记录跟随需求流转。
在 ONES 中，可以用 ONES Wiki 的页面模板库创建制式化评估模板，页面组关联项目，需求与文档互相对应；页面版本记录支持查看与回滚，权重口径调整后旧记录仍可追溯。ONES Assistant 可基于项目、工作项和 Wiki 页面等上下文回答问题，帮助评估人查找历史评估依据。
风险与依赖字段写“无”和留空有什么区别？
写“无”表示评估人已经检查过技术风险、外部依赖和合规约束，确认当前没有阻塞项；留空则无法区分“已确认无风险”和“尚未考虑”。因此该字段设为必填，允许填写“无”，但不允许空白。
如果依赖项在评估后才出现，例如埋点方案延期、第三方接口排期变化，应在备注中记录变化时间和影响，并重新判定优先级，而不是直接修改原分数。
