面向多个产品形态做功能规划时，常见难点是同一项能力在不同形态里叫法不同、边界模糊，讨论时容易各说各话。本文给出一套可执行的方法：先把功能拆到统一粒度，再按共性程度分成共享、可配置、差异化三层，最后依据使用频率、流程依赖和竞争区隔确定基础、可选与差异化功能的组合。功能清单和组合策略通常需要在工作项与文档中承载、评审和跟踪，ONES 可作为这类协作的承载工具之一。
要点总览（TL;DR）
- 先把各产品形态的功能拆到统一粒度，按“角色+动作+业务对象+结果”描述，并标注适用形态与用户任务，否则共性判断会因条目粗细不一而失真。
- 用两个轴判断共性：用户任务是否一致、实现逻辑是否一致。任务与实现都一致归共享能力，任务一致但实现差异大归可配置能力，只在特定形态成立归差异化功能。
- 基础功能按“高频、跨形态必需、缺失则核心流程中断”入选；可选功能按“形态相关、可配置开关”入选；差异化功能按“构成竞争区隔且成本可控”入选。
- 三类功能争资源时，先保各形态核心流程完整，再保共享与可配置能力的复用成本可控，最后投入差异化卖点，裁决依据要随结论记录。
- 划分结果提交评审前逐项核对粒度一致性、分层完整性、基础功能覆盖、可选与差异化边界、形态负责人确认五项。
先统一功能描述粒度：共性判断的前提
共性判断失真的主要原因，往往不是判断标准本身，而是功能条目的粗细不一致。一个形态把“订单管理”作为一个条目，另一个形态把“创建订单、修改订单、取消订单”拆成三条，两者无法直接比较。划分工作的第一步，是把所有形态的功能拉到同一描述粒度。
统一写成“角色+动作+业务对象+结果”
每个功能条目按固定格式描述：谁（角色）对什么（业务对象）执行什么动作，产生什么结果。例如“销售人员在订单详情页修改收货地址，订单物流信息同步更新”。这个格式同时约束了主语、对象和结果，避免出现“支持订单管理”这类无法判断边界的表述。描述中涉及的业务对象应使用统一名称，同一对象在不同形态中的别名在清单中合并标注。
把打包模块拆到可独立判断的最小功能点
以“能否单独决定它在某个形态中保留或去掉”为拆分标准。一个模块如果内部各功能点的适用形态不同，就应拆开。拆分不必细到按钮级，但每个功能点应当能独立回答三个问题：它服务哪个用户任务、它出现在哪些形态、去掉它是否影响核心流程。拆分过细会增加维护成本，可以按“一次用户操作闭环”作为下限。
标注适用形态与用户任务
在清单中为每个功能点增加两列：适用形态（可多选）和所属用户任务。用户任务用动宾结构描述，如“完成下单”“核对账单”“配置权限”。这两列是后续共性判断的直接输入，也便于发现同一用户任务在不同形态中被重复实现的情况。
输出可比较的功能清单
完成后的清单建议包含以下字段，作为后续分层和组合决策的工作底稿：
| 字段 | 说明 | 示例 |
|---|---|---|
| 功能编号 | 唯一标识，便于引用和追踪 | F-012 |
| 角色 | 执行该功能的用户角色 | 销售人员 |
| 动作 | 对业务对象执行的操作 | 修改 |
| 业务对象 | 操作指向的对象，名称统一 | 订单收货地址 |
| 结果 | 操作完成后的可观察状态 | 物流信息同步更新 |
| 用户任务 | 该功能支撑的任务 | 完成下单后的信息修正 |
| 适用形态 | 该功能出现的产品形态 | Web 端、移动端 |
清单完成后先做一次自查：同一用户任务下的功能点是否粒度接近，是否存在只写模块名未拆开的条目。粒度统一之后，共性判断才有可靠基础。
按共性程度分层：共享、可配置与差异化
分层回答的是“这项功能在多个形态之间属于哪一类关系”，判断依据是两个轴：用户任务是否一致，实现逻辑是否一致。两个轴组合后，功能自然落入三层。
两个判断轴与三层划分标准
| 用户任务 | 实现逻辑 | 分层结果 | 处理方式 |
|---|---|---|---|
| 一致 | 一致 | 共享能力 | 统一实现，各形态直接复用 |
| 一致 | 差异大 | 可配置能力 | 统一功能语义，允许形态侧不同实现或配置项 |
| 仅特定形态成立 | — | 差异化功能 | 保留在特定形态，明确边界与归属 |
共享能力的典型特征是：去掉形态差异后，用户要完成的事和系统内部的处理路径基本相同。可配置能力的典型特征是：用户目标相同，但受终端能力、使用场景或合规要求影响，交互方式或数据处理方式需要不同。差异化功能则只在某个形态中才有意义，例如依赖特定硬件或特定渠道的能力。
共性高但实现差异大的功能如何处理
这类功能最容易在规划中引发争议：业务上认为应该统一，技术上认为合并成本过高。处理原则是统一功能语义、分离实现路径。在清单中保留同一个功能定义和用户任务描述，标注各形态的实现差异、复用成本和维护责任方。是否合并实现，作为技术决策单独评估，不改变它在组合中的分层归属。这样既避免因实现差异把一个业务上共性的能力误判为差异化功能，也避免强行合并带来长期维护负担。
分层结果回填清单
在功能清单中增加“分层归属”和“判断依据”两列。判断依据写明两个轴的结论，例如“任务一致、实现一致，归共享”或“任务一致、移动端受离线限制，归可配置”。依据写清楚，后续评审时可以直接核对，减少反复讨论。分层完成后，按三层汇总功能点数量，作为组合策略的输入。
确定基础、可选与差异化功能的组合策略
分层描述的是功能之间的关系，组合策略要回答的是：在每个产品形态中，哪些功能必须默认提供，哪些按配置启用，哪些作为形态特色保留。三类功能的入选条件不同，需要分别设定。
三类功能的入选条件
| 类别 | 入选条件 | 组合中的位置 |
|---|---|---|
| 基础功能 | 使用频率高、跨形态必需、缺失会导致核心流程中断 | 所有形态默认提供，不设开关 |
| 可选功能 | 与形态或客户场景相关、可通过配置开关启用 | 按形态或租户配置，默认状态需明确 |
| 差异化功能 | 只在特定形态成立，构成竞争区隔，且建设与维护成本可控 | 限定形态提供，明确归属与投入边界 |
基础功能的判断可以用一个测试：假设某个形态缺少这项功能，用户能否完成该形态承诺的核心任务。不能完成，就应进入基础功能；能通过其他方式绕行，则考虑放入可选功能。可选功能必须明确默认状态和开关粒度，否则会在实际交付中退化为“每个客户都不一样”的定制。差异化功能需要同时满足区隔价值和成本可控，只有卖点但维护成本持续攀升的功能，应重新评估是否保留。
取舍冲突的裁决顺序
三类功能争夺同一份研发资源时，按以下顺序裁决：先保证各形态核心流程的完整性，再保证共享与可配置能力的复用成本可控，最后才投入差异化卖点。裁决结论要记录依据，例如“该功能在移动端缺失会导致下单流程中断，因此从可选提升为基础”。只记录结果不记录依据，下一轮规划时同样的争议会再次出现。
组合策略的输出形式
输出一张按形态展开的组合策略表，每行一个功能点，列包括：分层归属、组合类别、适用形态、默认状态、配置方式、负责团队。这张表同时是研发排期和版本规划的直接输入。功能清单与组合策略表需要在评审中流转并保留版本，使用 ONES 的工作项承载功能条目、用文档承载分层表与组合策略表，可以把评审意见、确认状态和后续变更记录在同一处，便于各形态负责人对照确认。
角色分工与各环节交付物
划分工作涉及多个角色，职责不清时容易出现清单由一方编写、差异由另一方口头补充的情况。建议按下表明确输入、输出和交接点。
| 角色 | 主要职责 | 输入 | 输出 |
|---|---|---|---|
| 产品规划角色 | 组织功能盘点，统一描述粒度，完成分层 | 各形态现有功能、用户任务清单 | 统一粒度的功能清单、三层分层表 |
| 各产品形态负责人 | 确认功能在本形态的适用性、差异与优先级 | 功能清单、分层表草案 | 形态侧确认意见与差异说明 |
| 研发与架构角色 | 评估实现共性、复用成本与技术约束 | 分层表、差异说明 | 实现方式建议、复用成本评估 |
| 评审环节 | 集中裁决冲突，形成确认结论 | 清单、分层表、组合策略表 | 各形态负责人确认的组合策略表 |
交接点有两个：功能清单与分层表草案提交形态负责人确认，以及组合策略表提交评审。评审的完成标志是所有形态负责人对基础功能覆盖和可选、差异化功能边界签字确认，而不是会议结束。研发与架构角色的评估应在分层草案阶段介入，避免组合策略确定后才发现实现成本不可接受。
示例：两个产品形态下的功能组合划分
以下为演示情景，用于说明划分过程，不代表任何真实产品的结论。某团队同时运营 Web 管理端和移动巡检端，共享的用户任务包括“接收工单”“处理工单”“上报处理结果”。
逐条判断共性并分层
把两个形态的功能拆到统一粒度后，得到若干功能点，节选如下：
| 功能点 | 适用形态 | 用户任务 | 分层判断 |
|---|---|---|---|
| 巡检员接收指派工单，工单状态变为处理中 | Web、移动 | 接收工单 | 任务一致、实现一致，共享 |
| 巡检员填写处理结果并提交，工单进入待审核 | Web、移动 | 上报处理结果 | 任务一致，移动端需离线暂存，可配置 |
| 巡检员拍摄现场照片并关联工单 | 移动 | 上报处理结果 | 依赖移动端摄像头，差异化 |
| 主管批量改派工单，工单责任人变更 | Web | 调度工单 | 仅管理端成立，差异化 |
组合结果与边界争议处理
组合结果是：接收工单作为基础功能，两个形态默认提供；填写并提交处理结果作为可选功能，移动端开启离线暂存配置，Web 端直接提交；拍照关联和批量改派作为差异化功能，分别限定在移动端和 Web 端。争议出现在“填写处理结果”上：移动端负责人认为离线能力是移动场景的必备条件，应作为基础功能。处理方式是回到入选条件核对——缺少离线暂存时，巡检员仍可在有网络时完成上报，核心流程不中断，因此归为可选功能，但默认开启。争议结论和依据一并记录在组合策略表中。
完成检查：组合划分是否可交付
划分结果提交评审前，逐项核对以下检查项，全部通过才视为可执行。
| 检查项 | 通过标准 |
|---|---|
| 功能清单粒度一致 | 每个条目均按“角色+动作+业务对象+结果”描述，不存在未拆开的模块名条目 |
| 分层归属完整 | 每个功能点均归入共享、可配置、差异化三层之一，并写明判断依据 |
| 基础功能覆盖核心流程 | 逐个形态核对，缺少任一基础功能都会导致该形态核心流程中断 |
| 可选与差异化功能边界清晰 | 可选功能有默认状态和开关粒度，差异化功能有适用形态和归属团队 |
| 形态负责人确认 | 各形态负责人对组合策略表签字确认，争议结论及依据已记录 |
检查中发现的问题按类型回到对应环节修正：粒度问题回到功能清单，归属问题回到分层表，取舍问题回到组合策略表。修正后重新核对，确认版本一致再进入排期。
常见问题
功能清单已经按模块列好了，还需要拆到多细才能做共性判断？
拆分标准是“能否单独决定它在某个形态中保留或去掉”。如果同一个模块里有的功能点只出现在移动端、有的两个形态都有，就应拆开，否则共性判断会把不同适用范围的条目混在一起。下限可以按“一次用户操作闭环”把握，不必细到按钮级，过细会增加清单维护成本。拆完后用同一用户任务下的条目粒度是否接近做一次自查。
两个形态的用户目标相同，但实现方式差别很大，应该合并还是分开？
建议统一功能语义、分离实现路径。在清单中保留同一个功能定义和用户任务描述，把它归为可配置能力，同时标注各形态的实现差异、复用成本和维护责任方。是否合并实现属于技术决策，单独评估，不改变它在组合中的分层归属。这样既不会把业务上共性的能力误判为差异化功能，也避免强行合并带来长期维护负担。
可选功能的开关由谁决定，默认状态怎么定？
可选功能的默认状态应由各形态负责人结合该形态的核心任务确定，并在组合策略表中写明。判断依据是：关闭该功能后，该形态承诺的核心任务是否仍能完成。能完成，默认关闭或按客户场景开启；不能完成，说明它更接近基础功能，应重新核对入选条件。开关粒度也要写清楚，是按形态、按租户还是按角色配置，避免交付时退化成逐客户定制。
划分过程中形态负责人和研发意见不一致，按什么顺序裁决？
先回到入选条件核对事实，再按资源投入顺序裁决：优先保证各形态核心流程的完整性，其次保证共享与可配置能力的复用成本可控，最后才投入差异化卖点。裁决结论要连同依据一起记录，例如某项功能从可选提升为基础，是因为缺失会导致该形态下单流程中断。只留结论不留依据，下一轮规划时同样的争议会再次出现。
功能组合划分完成后，怎么和后续的版本排期衔接？
组合策略表本身就是排期的输入。表中每行包含分层归属、组合类别、适用形态、默认状态、配置方式和负责团队，研发可以据此拆分工作项并安排版本。建议把功能条目放在工作项中跟踪状态，把分层表和组合策略表放在文档中保留版本与评审记录，使评审意见、确认状态和后续变更可以对照查询。具体承载方式可按团队现有工具习惯选择。
