功能取舍标准是一套事先约定的判断规则，用来回答“这个功能现在做不做”。它由四部分构成：产品边界与阶段目标、判断维度、决策规则、评审机制。缺少任何一部分，取舍就容易变成临场争论。本文按制定顺序展开，每一步给出可交付的产物，并说明取舍结论与评审记录如何在协作工具中留痕，供团队参照执行。
要点总览（TL;DR）
- 功能取舍标准由四部分构成：产品边界与阶段目标、判断维度、决策规则、评审机制，缺一项取舍就容易变成临场争论。
- 判断维度控制在四到六个，每个维度配一个可回答的判断问题和判断口径，判断结果写成结论加依据，不只给分数。
- 决策规则把结论分为必做、可做、暂缓、不做四类，先执行一票否决，再对通过否决的候选做加权比较，冲突时按固定裁决顺序处理。
- 评审机制要落到人、材料、节奏和记录上：产品负责人裁决，业务、研发、设计各出对应维度的判断，结论记录分类、理由、决策人和日期。
- 标准落地后按清单自查，并在阶段目标调整、规则冲突反复出现、暂缓项集中到期等情况下校准，注明版本与生效时间。
先定取舍的前提：产品边界与目标
取舍标准要能落地，前提是团队对“我们做什么产品、现阶段要达成什么”有共同答案。这两项输入不清晰，后面的维度打分就会各说各话：有人按长期愿景判断，有人按本季度指标判断，结论自然冲突。制定标准的第一步，是把边界和目标写成一份简短说明，作为所有功能判断的基准。
产品定位与“不做什么”的边界
产品定位说明目标用户、核心场景和主要价值主张；“不做什么”的边界则明确排除的方向，例如不进入某类客户、不承担某类定制、不覆盖某段流程。边界写得越具体，判断时越容易识别“这个功能虽然有人提，但超出我们的范围”。边界可以按用户类型、业务场景、交付形态三个角度各写几条，并注明例外由谁批准。
阶段性目标与衡量方向
阶段目标决定当前取舍的倾斜方向。处于验证期时，取舍偏向能快速验证核心假设的功能；处于增长期时，偏向能提升转化与留存的功能；处于成熟期时，偏向稳定性、效率与成本控制。每个阶段选两到三个衡量方向即可，例如激活率、关键任务完成率、支持工单量，并写明统计口径。目标不宜过多，否则每个功能都能找到支持自己的指标。
边界与目标如何转化为取舍依据
把边界和目标转成判断依据，做法是各写一句可引用的判断语。边界转化为排除条件，例如“面向非目标行业客户的定制功能，默认不做”；目标转化为优先条件，例如“本阶段优先支持新用户完成首次核心任务的功能”。这些句子进入下一节的判断维度，成为具体打分和分类时的参照。完成标志是：团队能拿着这份说明，对任意一个候选功能说出它落在边界内还是边界外、与当前目标是否一致。
取舍标准的核心判断维度
判断维度回答“看什么”。维度不宜多，四到六个足够覆盖大多数功能决策；每个维度要配一个可回答的判断问题和判断口径，避免停留在“重要”“有价值”这类无法比较的描述。下表给出一组可直接套用的维度，团队可按业务特点增删。
| 维度 | 判断问题 | 判断口径 |
|---|---|---|
| 战略契合度 | 这个功能是否服务于当前阶段目标，是否落在产品边界内？ | 对照边界与阶段目标说明，判定为直接支撑、间接支撑、无关、越界四档 |
| 用户价值与影响范围 | 解决的是哪类用户的什么问题，影响多少用户、多高的使用频次？ | 写明目标用户群、问题严重程度、覆盖用户量级与使用频次，区分核心用户与边缘用户 |
| 实现成本与维护负担 | 需要多少研发、设计、测试投入，上线后是否带来持续维护成本？ | 按人力投入量级和是否引入新的长期维护面（如新模块、新集成、新数据链路）评估 |
| 风险与依赖、时机 | 是否存在技术、合规或外部依赖风险，现在是不是合适的时点？ | 列出关键依赖方与前置条件，判断依赖是否已就绪，错过时点是否有代价 |
四个维度中，战略契合度与用户价值回答“值不值得做”，成本与风险回答“现在能不能做”。两组问题分开判断，可以避免用“成本高”直接否掉一个战略上必须做的功能，也避免用“价值大”掩盖明显的依赖风险。每个维度的判断结果要写成简短结论加依据，而不是只给一个分数，方便评审时复核。
把维度变成可执行的决策规则
维度只说明看什么，决策规则说明看完之后怎么下结论。规则的作用是让不同的人按同一套逻辑得出相近的结论，减少“我觉得可以做”式的争论。规则要写成条目，每条包含触发条件和对应结论。
四类结论的判定条件
把取舍结论分为必做、可做、暂缓、不做四类，并为每类写明判定条件：
- 必做：直接支撑当前阶段目标，或属于合规、安全、核心链路可用性的硬性要求，且不存在未解决的关键依赖。
- 可做：与目标一致、用户价值明确，成本在团队可承受范围内，可排入近期计划但让位于必做项。
- 暂缓：方向正确但时机未到，例如依赖的能力尚未就绪、当前阶段资源不足，需写明重新评估的触发条件。
- 不做：超出产品边界，或与阶段目标无关且用户价值有限，或成本与风险明显超过可承受范围。不做也要记录理由，避免同一提议反复被提出。
一票否决与加权判断的适用情形
一票否决适用于存在硬性约束的维度：越出产品边界、触碰合规红线、引入无法接受的安全风险，任一条成立即可直接判定不做，不再进入加权比较。加权判断适用于多个功能竞争同一批资源的情形，按维度重要性分配权重后比较总分，权重由产品负责人根据阶段目标确定并公开。两类机制并存时，先执行否决条件，再对通过否决的候选做加权比较。
规则冲突时的裁决顺序
规则之间出现冲突时，按固定顺序裁决：先看边界与合规，再看阶段目标契合度，再看用户价值与影响范围，最后看成本与风险。顺序靠前的条件优先，靠后的维度只在前面条件相当的情况下起作用。裁决顺序要写进规则清单，并在评审中一致执行；如果某次评审需要突破顺序，须记录理由和批准人，作为后续校准规则的输入。
评审机制与角色分工
标准要落到具体的人、时点和材料上，否则规则只停留在文档里。评审机制需要回答三个问题：谁参与、拿什么材料、在什么节奏下做出决定并留下记录。
各角色职责
| 角色 | 主要职责 | 在取舍中的输出 |
|---|---|---|
| 产品负责人 | 维护边界与阶段目标说明，主持评审，确定维度权重，做最终裁决 | 取舍结论与裁决理由 |
| 业务/运营 | 提供用户反馈、市场与客户需求信息，判断影响范围 | 用户价值与影响范围的判断依据 |
| 研发负责人 | 评估实现成本、技术风险与依赖就绪情况 | 成本与风险维度的评估结论 |
| 设计 | 评估交互与体验影响，识别与现有功能的一致性冲突 | 体验层面的判断意见 |
评审输入材料与会议节奏
每次评审的输入材料应包含：候选功能说明（背景、目标用户、预期效果）、按四个维度填写的判断表、相关数据或用户反馈、依赖项状态。材料在会前发出，让参与者在会前完成各自维度的判断。会议节奏按规划周期设定，例如每个规划周期一次功能取舍评审，临时插入的重大需求走简化评审。会议只处理结论未定的分歧，已按规则明确判定的条目直接确认，不逐条重议。
决策记录与结论留痕
每条取舍结论都要记录：功能名称、四维判断结果、最终分类、裁决理由、决策人和日期；暂缓项还要记录重新评估的触发条件。记录集中存放并可按功能检索，让后续规划、复盘和新人接手时能查到“当时为什么这么定”。在协作工具中，可以把候选功能建成工作项，将判断表与结论写入工作项字段或关联文档，评审结论同步到规划视图，使取舍记录与后续排期保持在同一处可追溯。ONES 在 IPD 场景中提供了阶段评审与决策机制的相关支持，可作为评审结论留痕与阶段决策的参考；具体配置方式以团队实际使用的产品能力为准。
示例：一次功能取舍的完整判断
以下为演示情景，用于说明标准如何落地，不代表真实项目。
候选功能背景
某协作类产品处于增长期，阶段目标为提升新用户首次核心任务的完成率。业务团队提出：为新手用户增加一个引导式任务面板，自动推荐下一步操作。同期还有两个候选：为老用户增加批量导出功能、接入一个新的第三方登录方式。
按维度逐项判断
| 候选功能 | 战略契合 | 用户价值与影响范围 | 成本与维护负担 | 风险与依赖、时机 | 结论 |
|---|---|---|---|---|---|
| 引导式任务面板 | 直接支撑首次任务完成率目标 | 覆盖全部新用户，频次高 | 中等，需新增引导状态管理 | 依赖埋点数据就绪，已具备 | 必做 |
| 批量导出 | 与当前目标间接相关 | 覆盖少量重度用户，频次中 | 较低 | 无关键依赖 | 可做，排在必做项之后 |
| 第三方登录接入 | 与当前目标无关 | 影响部分新用户注册环节 | 中等，引入长期维护面 | 依赖外部服务稳定性，尚未评估 | 暂缓，待依赖评估完成且阶段目标调整后重议 |
记录与后续动作
评审后，三条结论分别记录：引导式任务面板进入本期计划，明确负责人和验收口径；批量导出进入候选池并标注排序；第三方登录记录暂缓理由与重新评估条件。引导面板上线后按阶段目标跟踪首次任务完成率变化，作为下一轮校准判断口径的依据。整个过程体现了标准的作用：结论有依据、有分类、有记录，后续可查、可复盘。
标准落地后的检查与校准
标准制定完成不等于可以长期使用。需要定期检查它是否仍可判断、可记录、可追溯，并根据阶段变化调整。以下清单可用于首次落地后的自查和周期性复核。
完成检查清单
- 产品边界与阶段目标说明是否成文，团队成员能否据此判断功能是否越界、是否契合目标。
- 每个判断维度是否配有明确的判断问题和口径，判断结果是否要求写明依据而非只给分数。
- 四类结论的判定条件是否写清，一票否决的适用条件是否明确列出。
- 规则冲突时的裁决顺序是否成文，突破顺序的情形是否要求记录理由和批准人。
- 角色职责是否落实到人，评审输入材料是否在会前发出。
- 每条取舍结论是否有分类、理由、决策人和日期，暂缓项是否写明重新评估条件。
- 历史结论能否按功能检索，规划排期能否与取舍记录对应。
- 最近若干次评审是否按规则执行，是否存在未记录的口头决定。
定期校准的触发条件
出现以下情况时，应重新审视标准：阶段目标发生调整，原有优先条件失效；连续多次评审出现同类规则冲突，说明裁决顺序需要补充；暂缓项集中到期，需要重新评估其依赖与时机；用户结构或业务方向发生明显变化，边界说明需要更新；评审记录显示大量结论缺少依据，说明维度口径不够可判断。校准的产物是更新后的边界目标说明、维度表或规则清单，并注明版本与生效时间，让团队知道按哪一版标准判断。
常见问题
团队规模较小、没有独立评审会，取舍标准还需要写这么完整吗？
可以简化，但四部分不能省。小团队可以把评审并入常规的规划会，角色由一人兼多个，判断维度保留战略契合、用户价值、成本与风险三项即可。关键是结论仍要记录分类、理由和日期，暂缓项写明重新评估条件。标准的作用是让判断可复核，会议形式可以随团队规模调整。
一票否决用多了会不会让标准变成少数人拍板？
一票否决只应绑定硬性约束，例如越出产品边界、触碰合规红线、引入无法接受的安全风险，这些条件要事先写清并公开。除此之外的候选一律进入加权比较，不能临时扩大否决范围。如果评审中频繁动用否决，说明边界说明或规则清单需要补充，应把新出现的否决情形写进规则并注明批准人，而不是每次靠临场判断。
暂缓的功能过一段时间又有人提，怎么处理？
先查历史记录。暂缓项应写明重新评估的触发条件，例如依赖能力就绪、阶段目标调整。触发条件满足时重新进入评审，按当时的边界与目标重新判断；条件未满足则直接引用原结论，不重复讨论。同一功能反复被提出且理由相近，可以考虑把它作为校准规则的输入，检查是边界说明不够清楚，还是判断口径遗漏了这类需求。
取舍结论和后续排期怎么保持对应，避免记录归记录、排期归排期？
把候选功能建成工作项，判断表、结论分类、裁决理由和决策日期写入工作项字段或关联文档，评审通过后直接进入规划视图排期，让记录与排期指向同一条目。这样复盘时可以从排期反查当时的判断依据，也能发现未记录就进入计划的功能。ONES 在 IPD 场景中提供了阶段评审与决策机制的相关支持，可作为评审结论留痕与阶段决策的参考，具体配置以团队实际使用的产品能力为准。
阶段目标调整后，旧标准要全部重写吗？
通常只需更新受影响的部分。阶段目标变化主要影响优先条件和维度权重，边界说明、四类结论的判定条件、裁决顺序往往仍然适用。校准后注明版本与生效时间，并说明哪些条目发生变化，让团队知道按哪一版判断。已经做出的历史结论保留原记录，不追溯改写，便于后续复盘对照。
