需求价值缺少数据时，定性评估仍然可以做得可复核。做法是把“我觉得有价值”拆成几个固定的价值维度，为每个维度定义统一的等级锚点，打分时同步记录证据来源和待验证假设，再由多人独立判断、对分歧复核，最后把结论、适用范围和决策人写清楚。这样得到的结论不依赖某个人的直觉，也能在后续数据补充后回看和修正。
要点总览（TL;DR）
- 定性评估的第一步是收窄对象：只判断需求条目本身对用户和业务的价值，功能布局和排期顺序不进入评估范围。
- 把价值拆成用户覆盖与影响程度、问题严重性、战略契合度、时效窗口、替代方案成本五个维度，每个维度配一个可直接回答的判断问题。
- 为每个维度定义三到五级锚点，打分时同步填写证据来源和判断理由，无证据的判断标为假设并按证据强弱降级或转待验证。
- 多人先独立打分再集中复核，同一维度等级相差两级及以上触发复核，复核只围绕证据和假设展开，原始打分保留。
- 取舍结论要写明依据维度、适用范围、有效期和决策人；证据薄弱的高价值需求安排小范围验证或延后决策，并指定负责人和时间点。
定性评估先定清楚评什么、谁来判断
定性评估失效，常见原因不是判断本身主观，而是评估对象没有收窄。有人谈的是功能模块该不该拆，有人谈的是开发任务先做哪个，讨论很快偏离需求价值。开始评估前，先把范围写成一句话：本次评估只判断需求条目本身对用户和业务的价值，功能布局、技术方案和排期顺序不在评估范围内。
评估单元需要提前确定，并在同一批需求中保持一致。可以是一条独立需求，也可以是一组强关联需求（例如同一用户任务下的多个改进点），或者一个需求主题。评估单元过细会让判断碎片化，过粗则容易把不同价值混在一起。建议在评估表首行写明本次采用的单元口径，后续不再临时拆分或合并。
参与角色按输入责任划分，而不是按职级划分：
| 角色 | 在定性判断中的输入责任 |
|---|---|
| 需求提出人 | 说明需求来源、目标用户、触发场景，提供已有的用户反馈、工单、访谈记录等证据 |
| 业务或用户侧代表 | 判断问题严重性和影响范围，确认业务规则、合规要求或客户承诺等约束 |
| 产品负责人 | 判断战略契合度和时效窗口，组织评估、汇总分歧、给出取舍建议 |
| 研发或交付代表 | 提供替代方案成本、实现约束和交付风险方面的事实输入 |
这份范围与分工说明是后续所有打分的共同前提。完成标志是：每个参与角色知道自己要提供哪类证据、对哪些维度给出判断，且评估表上能对应到具体的人。
把价值拆成可讨论的定性维度
维度拆分的目的，是让“这个需求很重要”变成几个可以分别回答的问题。建议按价值来源设置五类维度，每个维度配一个直接可答的判断问题：
| 维度 | 判断问题 | 需要的证据 | 假设标注 |
|---|---|---|---|
| 用户覆盖与影响程度 | 这条需求影响哪类用户、多少人、在什么场景下受影响？ | 用户反馈数量、工单记录、访谈片段、客户名单 | 影响人数为估算时标注估算依据 |
| 问题严重性 | 不解决时用户会中断任务、绕行还是仅感到不便？ | 问题复现记录、用户原话、支持工单等级 | 严重程度来自推断时标注 |
| 战略契合度 | 这条需求支撑当前哪个业务目标或产品方向？ | 目标文档、季度重点、管理层决议 | 目标关联为间接推导时标注 |
| 时效窗口 | 价值是否只在某个时间点前成立，例如合同节点、政策生效日？ | 合同条款、政策文件、客户沟通记录 | 时间点未确认时标注待核实 |
| 替代方案成本 | 不做这个需求，用户或业务是否有可接受的替代做法，代价多大？ | 现有变通流程、人工处理工时记录 | 替代成本为估计时标注 |
维度可以按业务特点调整，例如增加合规风险或品牌影响，但同一批需求必须使用同一套维度和同一套判断问题，否则等级之间无法比较。填写时把事实性证据和主观判断分开：有记录支撑的写入证据栏，靠经验推断的写入假设栏并注明需要什么信息才能验证。完成标志是每个维度都有明确的问题、证据要求和假设栏，且评估表已按此结构建好。
用统一锚点评级并留存证据
锚点的作用是把等级差异说清楚。每个维度定义三到五级，每一级用具体情形描述，避免使用“高、中、低”这类没有内容的词。以问题严重性为例，可以定义为：
| 等级 | 典型表现 |
|---|---|
| 4 | 用户无法完成核心任务，且没有可行替代做法，已有多次同类反馈 |
| 3 | 用户任务明显受阻，需要绕行且绕行成本较高，有可查的反馈记录 |
| 2 | 用户感到不便，存在低成本替代做法，反馈零散 |
| 1 | 体验层面的改进诉求，不影响任务完成 |
打分规则有两条硬要求：一是每个等级必须同时填写证据来源和判断理由；二是没有证据支撑的判断标记为假设，并按证据强弱处理——证据不足时取较低等级，或标注“待验证”而不进入正式排序。这样处理不是否定判断，而是让结论与证据强度匹配。
证据留存建议使用固定字段，便于后续检索和复核：
- 需求编号与评估单元名称
- 维度名称与所评等级
- 证据来源（工单号、访谈日期、文档名称、客户沟通记录等）
- 判断理由，一到两句说明为什么落在这一级
- 判断人与打分日期
- 待验证假设及验证方式
填写示例：需求“批量导入时支持字段映射模板”，问题严重性评为3级，证据来源为三条客户工单和一次实施访谈记录，判断理由为“用户每次导入需手工调整字段，单次约耗时半小时，已有客户提出希望复用模板”，假设栏标注“受影响客户数量尚未统计，需从工单系统按客户去重后确认”。完成标志是一条需求在每个维度上都有等级、证据、判断人和假设标注，缺项视为未完成。
多人独立判断与分歧复核
单人打分容易受最近一次客户沟通或岗位视角影响。降低偏差的有效做法是先独立、后集中：每位参与者在看不到他人结果的情况下完成打分和证据填写，再统一汇总。独立打分阶段不组织讨论，避免先发言者的判断影响其他人。
分歧识别规则需要事先约定。常用规则是：同一维度上最高等级与最低等级相差两级及以上，进入复核；或者某维度被标记为假设但直接影响结论时，也进入复核。复核会议只围绕证据和假设展开，逐条确认证据是否成立、假设是否必要、等级是否需要调整，不重复争论个人偏好。
复核流程可以固定为四步：
- 汇总各人打分，标出触发复核的维度和需求。
- 由证据提供方说明来源和适用范围，其他人补充或质疑。
- 对每个分歧维度形成结论：维持原等级、调整等级或转为待验证。
- 记录调整理由和最终等级，原始打分保留不删除。
结论记录格式建议包含：需求编号、分歧维度、各人原始等级、复核后等级、调整理由、参与人和日期。保留原始打分的价值在于，后续数据补充后可以回看当时的判断依据，判断是证据变化还是理解偏差导致了结论变化。
把定性结论转成需求取舍依据
定性结果用于排序时，不建议把各维度等级简单加总。加总会让一个严重性很高但覆盖很小的需求和一个各方面平平的需求得到相近分数，掩盖关键差异。更合适的做法是先看关键维度组合：例如问题严重性达到最高级且替代方案成本高的需求，优先进入近期范围；战略契合度高但证据薄弱的需求，先安排小范围验证；时效窗口临近的需求单独列出，按时间倒排。
对高价值但证据薄弱的需求，处理方式有两种：一是设计低成本验证，例如定向访谈几位目标用户、做一次可用性测试或小范围灰度，设定验证通过的判断标准；二是延后决策，明确需要补充哪类数据、由谁在什么时间前提供。两种方式都要写入记录，避免需求在“再看看”中失去跟踪。
定性结论需要写明适用范围和有效期。适用范围包括结论针对的用户群体、业务场景和评估时的假设条件；有效期可以按季度或按关键事件设定，例如“数据看板上线后重新评估”。数据补充后，按原维度更新等级并记录变化原因，而不是直接覆盖旧结论。
取舍记录模板建议包含以下字段：
| 字段 | 填写内容 |
|---|---|
| 需求编号与名称 | 与需求条目一致 |
| 取舍结论 | 进入本期、延后、验证后再定、暂不处理 |
| 依据维度 | 列出起决定作用的维度及等级 |
| 待验证项 | 假设内容、验证方式、负责人、时间点 |
| 适用范围与有效期 | 结论成立的条件和回看时间 |
| 决策人与日期 | 对结论负责的人 |
当这些记录需要随需求状态流转时，可以把维度等级、证据来源、假设和复核结论作为需求条目的字段留存，让评估结果和需求本身在一起。ONES 的需求管理支持在需求条目上记录属性、关联文档和变更历史，评审结论与后续状态可以对应起来，便于在数据补充后回看当时的判断依据。是否采用工具承载取决于团队已有的需求管理方式，关键是记录不散落在个人文档里。
示例：一条证据不足的需求如何完成定性评估
以下为演示情景，用于说明流程，不代表真实项目结论。
需求背景：某协作类产品收到反馈，希望“任务详情页支持按自定义字段筛选子任务”。提出人来自两家客户的沟通记录，但没有使用频率数据，也无法确认受影响用户规模。
逐维度评估结果：
| 维度 | 等级 | 证据来源 | 假设标注 |
|---|---|---|---|
| 用户覆盖与影响程度 | 2 | 两家客户沟通记录，未统计其他客户 | 假设：同类需求可能存在于更多客户，需按工单关键词检索确认 |
| 问题严重性 | 3 | 客户描述了每次查找子任务需逐层展开的操作过程 | 无 |
| 战略契合度 | 3 | 与本季度“提升项目执行透明度”的方向相关 | 假设：关联为间接推导，需产品负责人确认 |
| 时效窗口 | 1 | 无合同或政策时间要求 | 无 |
| 替代方案成本 | 3 | 现有做法为导出后手工筛选，客户描述了操作步骤 | 假设：替代耗时未实测 |
初步结论为“问题严重性和替代成本中等偏上，覆盖范围证据不足”。独立打分阶段，业务侧代表对问题严重性给出4级，理由是客户提到该问题影响其月度汇报准备；产品负责人给出2级，认为客户已用导出方式维持运转。两人相差两级，触发复核。
复核会上，业务侧代表提供了客户沟通原文，确认影响集中在汇报准备环节而非日常任务执行；研发代表说明导出方案的实际操作步骤。复核结论为维持3级，调整理由记录为“影响明确但存在可接受替代路径，覆盖范围仍待验证”。
最终取舍结论：延后至下个评估周期，同时安排两项验证——按工单关键词检索同类反馈并去重统计客户数，以及邀请两家客户各做一次操作观察，记录实际耗时。验证负责人为需求提出人，时间点为两周后。结论适用范围为当前版本的任务管理场景，有效期至下次评估；决策人为产品负责人。若验证显示受影响客户超过约定数量，则重新评级并进入候选范围。
完成检查：定性评估是否可复核
评估结束后，用下面这份清单自查。任何一项不满足，都说明结论还不足以支撑取舍：
- 评估范围和评估单元是否在评估前写明，且本批需求口径一致。
- 每条需求在每个维度上是否都有等级、证据来源和判断人。
- 每个等级是否能对应到事先定义的锚点描述，而不是临时解释。
- 所有依赖推断的判断是否标记为假设，并写明了验证方式和负责人。
- 触发复核的分歧是否都有复核记录，原始打分是否保留。
- 取舍结论是否写明依据维度、适用范围、有效期和决策人。
- 证据不足的需求是否给出了验证安排或延后条件，而不是停留在口头讨论。
- 评估记录是否集中存放，后续数据补充时能找到原结论并更新。
这份清单同时可以作为下一次评估的启动检查：如果上一轮的假设已经验证或失效，先更新结论再开始新一批需求的判断，避免旧假设继续影响排序。
常见问题
团队人少、角色不全时，定性评估还能做吗？
可以，但需要合并角色并明确谁补位。例如需求提出人同时承担业务侧代表的证据提供责任，产品负责人同时给出战略契合度判断，研发或交付代表可由最熟悉实现约束的工程师担任。关键不是角色数量，而是每个维度都有人对证据和判断负责。角色合并后，独立打分环节至少保留两人，否则分歧复核失去意义；只有一人可评时，把结论明确标为初步判断，并写明需要谁在什么时间前补充第二意见。
证据只有零散的用户口头反馈，能作为定性评估的依据吗？
可以作为证据，但要标注证据强度。口头反馈应记录来源（哪位用户、什么场景、什么时候）、原话要点和是否可复现，避免只写“有客户反馈”。当证据只有单条口头信息时，对应维度取较低等级或标为待验证，并写明需要补充什么才能升级，例如同类工单数量、访谈记录或操作观察。这样处理让结论与证据强度匹配，后续补充证据后可以按原维度更新等级并记录变化原因。
定性评估多久做一次，已有结论什么时候需要重评？
建议按评估周期和关键事件两种触发方式结合。按周期可以在每季度或每个规划周期开始时回看上一轮结论；按事件则在数据补充、业务目标调整、合同或政策时间点变化、关键假设被验证或推翻时触发重评。重评时保留旧结论和原始打分，按原维度更新等级并写明变化原因，避免直接覆盖。结论本身应写明有效期，例如“数据看板上线后重新评估”，让回看有明确时间点。
定性评估结果和量化数据冲突时以哪个为准？
先判断冲突来源，再决定取舍。常见情况是量化数据覆盖的范围与定性结论的适用范围不一致，例如使用数据只反映存量用户，而定性判断针对新客户场景；也可能是定性判断依赖的假设尚未验证。处理方式是把两者并列写入记录，标明各自覆盖的用户群体、时间范围和证据来源，对冲突维度重新复核。若数据更直接、口径更匹配，以数据为准并更新等级；若数据口径不覆盖结论范围，保留定性结论但标注待验证，并安排补充数据。
评估记录放在个人文档里行不行？
短期可以，长期容易出现记录散落、版本不一致、人员变动后找不到依据的问题。更稳妥的做法是把维度等级、证据来源、假设和复核结论作为需求条目的属性留存，让评估结果和需求本身在一起，状态流转时记录随之保留。ONES 的需求管理支持在需求条目上记录属性、关联文档和变更历史，评审结论与后续状态可以对应起来。是否采用工具承载取决于团队现有方式，判断标准是后续回看时能否快速找到原结论、证据和决策人。
