功能取舍标准解决的是产品功能布局层面的判断问题：面对一批候选功能，团队需要一套统一规则决定哪些做、哪些缓、哪些不做、哪些换一种做法。本文给出一张可直接套用的判定规则表、一套分步操作流程、角色分工对照表，以及一个演示情景和运行检查清单，帮助团队把取舍从个人拍板变成可追溯的常规动作。
要点总览（TL;DR）
- 功能取舍标准由三部分组成：五个判断维度与阈值、四种结论类型（做、缓、不做、换做法）、固定角色与评审节奏。
- 落地按五步推进：明确本期目标、建立候选清单、逐项判定记录依据、评审确认分歧、归档并安排回看。
- 产品负责人对结论负责，业务、研发、设计分别提供价值证据、成本风险与体验影响评估，记录人负责归档。
- 判断标准是否运行，看规则覆盖度、结论依据、评审记录和暂缓项回看是否落实；结论靠拍板、记录缺失是主要失效信号。
- 单需求的价值评分与优先级排序属于需求管理，功能取舍结论为“做”之后才进入该流程。
功能取舍标准由哪些判断规则组成
一套可用的功能取舍标准，核心是一张判定规则表：每个候选功能按同一组维度评估，每个维度有明确的判定口径和阈值，评估结果映射到固定的结论类型。规则表的价值在于让不同人面对同一功能时得出可比较的判断，而不是各说各话。
建议覆盖五个维度。维度数量可以按团队情况增减，但一旦确定，就应在同一评审周期内保持稳定，否则横向比较失去意义。
| 维度 | 判定口径 | 阈值示例 | 结论映射 |
|---|---|---|---|
| 战略契合 | 该功能支撑本期目标的程度，以及是否服务于当前产品阶段的主线 | 直接支撑本期目标记“高”；仅间接相关记“中”；与本期目标无关记“低” | 低契合通常进入“不做”或“缓”，除非有强制外部约束 |
| 用户价值覆盖 | 受影响用户的比例、使用频次，以及问题对用户任务的阻断程度 | 覆盖核心用户群且高频使用记“高”；覆盖边缘场景或低频记“低” | 高价值覆盖支撑“做”；低覆盖需结合成本判断是否“缓” |
| 成本与复杂度 | 研发工作量、对现有架构的改动面、上线后的维护负担 | 可在本期资源内完成且不引入新维护面记“可控”；超出本期资源或显著增加长期维护记“高” | 成本高而价值中等时，优先考虑“换做法”缩小范围 |
| 依赖与风险 | 是否依赖未就绪的外部条件、是否存在合规或数据风险、失败后的影响面 | 依赖已就绪且风险可接受记“低风险”；依赖未定或风险影响核心流程记“高风险” | 高风险且无法缓解时“缓”或“不做” |
| 可逆性 | 上线后撤回或调整的代价，是否影响已有用户数据与习惯 | 可快速下线或灰度调整记“可逆”；涉及数据迁移或用户习惯改变记“不可逆” | 不可逆且证据不足时倾向“缓”，先小范围验证 |
评估结果统一归入四种结论。“做”表示本期纳入计划并分配资源；“缓”表示认可价值但本期不做，需记录触发条件，例如依赖就绪或用户量达到某水平后重新评估；“不做”表示明确放弃，并写明理由，避免反复讨论；“换做法”表示目标保留但调整实现方式，例如缩小功能范围、先用轻量方案替代完整实现。四种结论必须落到具体表述，避免“再看看”“先放着”这类含糊状态。
需要区分的是，这套标准处理的是功能布局层面的取舍，回答“这个功能要不要进入产品”。单个需求的价值评分、优先级排序、排期方法属于需求管理范畴，本文不展开。两者衔接的方式是：功能取舍结论为“做”之后，具体需求再进入需求管理流程排序。
按什么步骤建立并运行这套标准
规则表只有进入固定流程才会产生作用。以下五步构成一个可循环运行的周期，每一步都明确输入、动作、输出和完成标志。
第一步：明确产品阶段与本期目标
输入是产品当前阶段判断和本期业务目标；动作是把目标写成可判断的表述，例如“本期聚焦新用户首次使用路径的完成率”，而不是“提升用户体验”；输出是一份本期目标说明，作为所有取舍的基准；完成标志是团队对本期目标没有歧义，且能据此判断某功能是否相关。
第二步：建立候选功能清单与统一信息字段
输入是各来源收集到的功能想法，包括用户反馈、销售诉求、内部规划；动作是把它们合并为一张清单，每个功能填写统一字段：功能描述、提出来源、目标用户、预期解决的问题、初步成本量级；输出是一张字段完整的候选清单；完成标志是清单中每个条目信息足以支撑规则表评估，缺失字段已补齐或标注待补。
第三步：按规则表逐项判定并记录依据
输入是候选清单和判定规则表；动作是逐项按五个维度评估，每个维度写下判断依据而非只写结论，例如“用户价值覆盖：高，依据是近三个月该场景反馈占全部反馈的较大比例”；输出是每个功能的判定记录，包含各维度结论、综合结论和依据；完成标志是所有候选功能都有结论，且每个结论都能追溯到具体依据。
第四步：评审会上的分歧处理与结论确认
输入是判定记录；动作是召开固定节奏的评审会，对结论一致的功能快速确认，对存在分歧的功能逐条核对依据，分歧集中在证据不足时，结论倾向“缓”并约定补充证据的时间；输出是评审确认后的最终结论清单；完成标志是每个功能有唯一结论，分歧项有明确处理方式和责任人。
第五步：结论归档与下期回看
输入是最终结论清单；动作是把结论、依据、评审记录归档到统一位置，并为“缓”和“不做”的功能标注回看时间或触发条件；输出是可检索的取舍记录；完成标志是下期评审开始前，团队能调出上期结论并逐条核对哪些条件已变化。
在结论记录与回看环节，取舍结论需要和依据、责任人、回看条件放在一起管理。ONES 的工作项与文档能力可以承载这一动作：每个候选功能作为一条工作项记录结论状态，判定依据和评审记录沉淀在关联文档中，暂缓项设置回看时间，下期评审时按状态筛选即可核对。这样取舍过程留下的是一条可追溯的记录链，而不是散落在会议纪要里的口头结论。
谁来做判断：角色分工与交付物
标准停留在文档层面的常见原因是角色不清：谁维护规则、谁提供证据、谁做最终结论没有约定。下表给出一种可参考的分工，团队可按规模调整，但每类职责都应有明确承担人。
| 角色 | 在取舍中的职责 | 交付物 |
|---|---|---|
| 产品负责人 | 维护判定规则表与阈值口径，主持评审，对最终结论负责 | 规则表、评审结论清单 |
| 业务/用户代表 | 提供用户价值与场景证据，说明功能对应的真实使用场景和影响范围 | 用户证据说明、场景描述 |
| 研发负责人 | 提供成本量级、技术复杂度、依赖条件与实现风险评估 | 成本与风险判断记录 |
| 设计负责人 | 评估方案表达难度、对现有体验一致性的影响，以及“换做法”时的替代方案可行性 | 体验影响评估、替代方案说明 |
| 评审记录人 | 记录评审过程、分歧点与最终结论，负责归档和回看提醒 | 评审记录、归档条目 |
分工的关键约束是：提供证据的角色不单独决定结论，做结论的角色不能跳过证据。产品负责人拥有最终结论权，但结论必须建立在其他角色提交的依据之上，否则规则表就退化为形式。
一个完整示例：三个候选功能的取舍过程
以下为演示情景，用于说明规则如何落到结论，数据为示意，不代表真实项目。
背景设定：某协作类产品处于成长期，本期目标写为“提升新用户首次完成核心任务的比率”。候选清单包含三个功能：A 是新手引导流程改版，B 是面向企业客户的多级审批配置，C 是数据导出格式扩展。
逐项判定过程：A 在战略契合上为高，直接服务本期目标；用户价值覆盖为高，影响全部新用户；成本可控；无外部依赖；可逆性较好，可灰度上线。综合结论为“做”。B 的战略契合为中，服务的是另一类客户诉求，与本期目标间接相关；用户价值覆盖集中在少数企业客户；成本高且涉及权限模型改动；可逆性差。综合结论为“缓”，回看条件设定为企业客户签约数量达到约定规模。C 的战略契合为低；用户价值覆盖为低频场景；成本中等；结论为“不做”，理由记录为与本期目标无关且可由现有导出方式部分满足。
分歧处理：评审中研发负责人认为 A 的改版成本被低估，与产品负责人的判断不一致。处理方式是回到依据：研发补充了具体改动面说明，产品负责人据此把 A 的范围缩小为“仅改版首次进入路径”，结论从“做”调整为“换做法”，目标保留、实现范围收窄。这一调整被写入记录，而不是留作会后口头约定。
结论落地：三个功能的结论、依据、责任人和回看条件写入统一记录，A 进入本期计划，B 和 C 标注回看时间。下期评审开始时，团队先核对 B 的回看条件是否已满足，再决定是否重新评估。
标准跑起来后的完成检查
判断这套标准是否真正运行，可以按以下清单逐项核对，每项都给出可观察的通过标准。
| 检查项 | 通过标准 |
|---|---|
| 规则表覆盖度 | 本期全部候选功能都按同一张规则表评估，没有绕过规则直接进入计划的条目 |
| 口径一致性 | 同一维度在不同功能上的判定口径一致，阈值没有随结论需要临时调整 |
| 结论依据记录 | 每个结论都能找到对应的依据说明，包括“不做”和“缓”的功能 |
| 评审节奏与记录 | 评审按约定周期发生，每次都有记录，记录中包含分歧点与处理结果 |
| 回看安排 | “缓”和“不做”的功能都有回看时间或触发条件，且在下期评审中被实际核对 |
同时留意几类失效信号：结论主要靠职位高低拍板，依据记录形同虚设；评审记录缺失，下期无法核对上期结论；规则表长期不更新，阈值与实际资源状况脱节；所有功能都得出“缓”，说明标准被用来回避决策。出现这些信号时，优先修复的是记录与回看环节，因为取舍标准的可信度来自结论可追溯、可复核。
常见问题
团队规模小、没有专职设计或业务代表，角色分工怎么简化？
可以合并角色，但不能合并职责。例如产品负责人同时承担业务/用户代表的证据收集工作，研发负责人兼顾技术风险评估，设计评估由实际负责界面实现的人承担。关键约束保持不变：做结论的人要看到成本和价值两方面的依据，记录与归档有明确承担人。角色合并后建议在规则表旁注明每类职责的实际承担人，避免评审时出现无人提供依据的情况。
“缓”和“不做”的功能，回看条件应该怎么设才不至于永远搁置？
回看条件要写成可观察的事实，而不是时间点加一句“到时候再看”。常见写法有两类：一类是外部条件，例如依赖的系统上线、目标客户签约数量达到约定规模；另一类是内部条件，例如相关场景的反馈量增长到需要单独处理的水平。每个暂缓项至少绑定一个条件，并指定核对人。下期评审开始时先逐条核对条件是否满足，未满足的继续保留并更新说明，满足的重新进入判定流程。
评审会上产品和研发对成本判断不一致，按什么规则收口？
分歧回到依据层面处理，而不是靠职位高低裁决。做法是让提出异议的一方补充具体说明，例如研发列出改动涉及的模块、需要调整的接口和预估工作量，产品据此判断是否调整功能范围。若补充证据后仍无法达成一致，且该功能可逆性较好，可以先按缩小范围的方式推进并约定验证节点；若不可逆且证据不足，结论倾向“缓”。无论哪种结果，分歧点和处理方式都要写入评审记录。
规则表用了一段时间后阈值明显不合实际，能中途改吗？
可以调整，但要按周期改，不在单个功能的评审中临时改。建议在每个评审周期结束时集中回看规则表：哪些维度的阈值与实际资源状况脱节，哪些维度反复出现判断困难。调整后从下一周期开始统一适用，并在规则表上记录修改时间和原因。同一周期内保持口径稳定，是为了让不同功能的结论可以横向比较；如果某个功能确实情况特殊，应在记录中说明例外理由，而不是修改规则本身。
功能取舍结论和后续的需求排期怎么衔接？
两者是前后衔接的两道判断。功能取舍回答“这个功能要不要进入产品”，结论为“做”或“换做法”的功能才进入需求管理环节，再由需求管理流程做价值评分和优先级排序。衔接时建议保留取舍阶段的依据记录，需求排序时可以引用，避免重复论证。结论为“缓”的功能不进入排期，但保留回看条件；结论为“不做”的功能写明理由后关闭，后续若有人再次提出，先查记录再决定是否重新评估。
