面向多个产品形态规划功能时，功能共性与差异的边界往往在讨论中变得模糊：同一个功能，有人认为是各形态都该有的底座，有人认为它只服务于某一类客户。本文给出一套可执行的划分方法：先把功能拆成可比较的功能项，再用共性—差异矩阵判断归属，最后形成基础、可选、差异化三类功能的组合配置表，并配套角色分工与维护规则。
要点总览（TL;DR）
- 划分功能组合的核心动作有三个：把功能拆成以用户任务为单位的可比较功能项，用共性—差异矩阵判断归属，再形成基础、可选、差异化三类功能的组合配置表。
- 共性判断看两点：用户任务是否相同、跨形态行为是否一致；差异分为参数差异、流程差异和能力有无差异，分别对应配置化、分支开关和独立实现。
- 基础功能统一实现维护，可选功能写清启用条件与配置边界，差异化功能绑定形态定位并控制复用范围，避免反向污染基础层。
- 边界不清的功能项先标记待定，用真实客户场景或试点形态验证后再归类，分类结果需在版本规划前、新增形态时和定制需求集中出现时持续校准。
先建立可比较的功能项清单
划分功能组合的第一步，是把“功能”从模糊的产品语言转成可比较的条目。如果清单里写的是“报表模块”“权限体系”这类模块名，不同产品形态之间就无法对齐，因为同一模块在不同形态下承担的任务可能完全不同。可比较的单位是用户可感知的任务，例如“按客户维度导出月度用量报表”“为外部协作方分配只读权限”，这类描述能直接回答“这个任务在几个形态里存在、行为是否一致”。
每个功能项需要记录固定字段，保证后续判断有据可依。建议的最小字段集如下：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 功能项名称 | 以用户任务命名，动词开头，可独立验收 | 按客户维度导出月度用量报表 |
| 所属用户任务 | 该功能服务的上层任务或业务目标 | 月度对账与用量结算 |
| 使用场景 | 谁在什么情况下使用，触发条件是什么 | 财务人员每月初核对上月的资源用量 |
| 涉及产品形态 | 列出该功能出现或需要出现的形态 | 标准版、行业版 |
| 当前实现方式 | 已实现、部分实现、未实现；实现是共用还是各形态独立 | 标准版已实现，行业版独立实现，逻辑不一致 |
收集来源要覆盖四类输入：现有各形态的版本功能、客户反馈中反复出现的诉求、销售在合同中作出的承诺、竞品观察中发现的形态差异。前两类决定清单的完整性，销售承诺决定哪些功能项带有交付约束，竞品观察帮助识别哪些差异是形态定位的一部分。收集完成后按用户任务归并，同一任务在不同形态下的多条记录合并为一个功能项，形态差异写入“涉及产品形态”和“当前实现方式”字段。
填写规则上有两点需要统一：一是功能项粒度控制在“一个用户任务、一次可验收的操作结果”，过粗无法判断共性，过细会淹没判断重点；二是“当前实现方式”必须如实记录各形态是共用代码还是各自实现，这一列直接决定后续复用成本。清单本身需要版本化管理，功能项的新增、合并和废弃都留痕，便于回溯某次划分的依据。这类清单和判定记录通常以工作项加文档的形式承载，ONES 的项目工作项与知识库可以承担功能项登记、字段维护和变更留痕的管理动作，具体字段与权限按团队现有流程配置。
用共性—差异矩阵判断功能归属
功能项清单准备好后，逐项回答两个问题：该功能服务的用户任务在各形态中是否相同；该功能在各形态中的行为是否一致。两个问题都答“是”，说明它是跨形态的共同底座；任一为“否”，就要进一步判断差异属于哪一类。
差异分三种类型，处理方式不同：
- 参数差异：任务和行为一致，只是取值不同，例如报表的默认时间范围、字段数量上限。这类差异适合配置化，同一实现加不同参数即可。
- 流程差异：任务一致，但操作步骤或审批环节不同，例如行业版需要多一级合规审核。这类差异适合在同一实现中做分支或开关，需要明确分支条件。
- 能力有无差异：某形态需要一项其他形态完全不具备的能力，例如行业版独有的设备对接。这类差异通常需要独立实现，并绑定该形态的定位。
矩阵的落位规则可以归纳为下表：
| 判断结果 | 归入类别 | 典型特征 |
|---|---|---|
| 用户任务相同，跨形态行为一致 | 基础功能 | 各形态必需，统一实现、统一维护 |
| 任务相同但存在参数或流程差异，或仅部分形态需要 | 可选功能 | 共性中等，按形态、客户类型或部署方式启用 |
| 差异显著，且该能力承载某一形态的定位 | 差异化功能 | 服务特定形态的目标用户，复用范围受控 |
边界不清是常态，处理方式是先标记“待定”，不急于在会上拍板。待定项要写明争议点：是任务判断有分歧，还是行为一致性缺乏证据。随后用真实场景验证，例如选取两到三个典型客户的使用路径走一遍，或在一个试点形态中先按某一类实现，观察是否出现返工。验证结论回填到功能项记录中，待定状态随之关闭。强行在规划阶段对所有功能项一次性定性，往往导致后续频繁返工。
确定基础、可选与差异化功能的组合策略
分类结果要转化为配置策略，才能指导各形态的版本规划。三类功能的配置方式不同：
基础功能统一实现、统一维护，作为各形态的共同底座。判断一个功能是否进入基础层，除了共性高，还要确认它的行为一致性有明确约束：一旦某形态提出特殊要求，应优先评估能否用参数或配置满足，避免基础层被个别形态的需求拉出分支。
可选功能需要写清启用条件，条件维度通常包括产品形态、客户类型、部署方式。每个可选功能要明确开关位置和配置边界：哪些参数可调、调整范围是什么、关闭后系统行为如何。启用条件写得含糊，交付时就容易变成“看情况”，既增加实施成本，也让版本规划失去依据。
差异化功能绑定具体形态的定位，复用范围要主动控制。这类功能的价值在于支撑形态之间的区分，因此宁可单独维护，也不为了短期复用把它下沉到基础层。反向污染是常见风险：一个差异化功能被多处引用后，基础层的改动会牵动它，最终两边都难以演进。
组合策略的取舍本质是复用收益与形态定位价值的权衡。复用收益高、且不影响任何形态定位的功能尽量下沉；承载定位价值的功能即使实现成本较高，也保持独立。配置结果落到组合配置表中：
| 功能项 | 类别 | 适用形态 | 启用条件 | 维护责任 |
|---|---|---|---|---|
| 按客户维度导出月度用量报表 | 基础功能 | 全部形态 | 无，默认开启 | 平台组 |
| 多级合规审核流程 | 可选功能 | 行业版、私有化部署 | 客户类型为受监管行业时启用 | 行业版产品组 |
| 设备协议对接 | 差异化功能 | 行业版 | 仅行业版提供 | 行业版产品组 |
角色分工与交付物
划分工作涉及产品定位、功能判定和技术可行性三类判断，需要明确谁对哪一步负责，避免清单由单一角色闭门完成。
| 角色 | 职责 | 主要产出 |
|---|---|---|
| 产品负责人 | 定义各产品形态的定位与差异化方向，裁定差异化功能的取舍 | 形态定位说明、差异化方向清单 |
| 产品经理 | 维护功能项清单，完成共性—差异判定，填写组合配置表 | 功能项清单、共性—差异矩阵、组合配置表 |
| 研发负责人 | 确认共性功能的技术复用可行性，评估参数化、分支与独立实现的成本 | 复用可行性意见、实现方式建议 |
四类交付物贯穿整个过程：功能项清单是输入，共性—差异矩阵是判定过程，组合配置表是结论，变更记录是维护依据。变更记录不必复杂，但要能回答三个问题：哪个功能项改了类别、触发原因是什么、谁批准的。这四份材料建议放在同一处管理，评审时同步查阅，避免矩阵与配置表版本不一致。ONES 的知识库可用于存放功能项清单与判定依据，工作项可用于跟踪待定项的验证进度和跨类迁移的审批，使分类结论与执行状态保持对应。
示例：两个产品形态下的功能组合划分
以下为演示情景，用于说明方法，不对应真实客户案例。设定两个产品形态：标准版面向中小团队，强调开箱即用；行业版面向受监管行业客户，强调合规留痕与设备接入。
选取四个功能项逐项判断：
- “按客户维度导出月度用量报表”：两个形态的用户任务相同，均为对账结算，行为一致，归入基础功能。
- “多级合规审核流程”：任务在标准版中不存在，行业版需要两级审核，属于流程差异，归入可选功能，启用条件为受监管行业客户。
- “设备协议对接”：仅行业版需要，且是行业版区别于标准版的核心卖点，属于能力有无差异，归入差异化功能。
- “报表字段自定义”：两个形态都需要，但行业版要求字段数量更多、支持审计字段，属于参数差异，归入可选功能，以配置项形式提供，启用条件为行业版或客户提出申请。
其中“报表字段自定义”最初存在争议：有观点认为行业版的审计字段属于差异化能力。判定过程是回到用户任务——两个形态的用户都在做同一件事，即调整报表展示内容，差异只在字段范围和取值，行为逻辑一致，因此按参数差异处理，通过配置满足，不单独实现。这一判定记录在功能项备注中，写明验证依据是行业版两个试点客户的实际使用路径。
组合配置表片段如下：
| 功能项 | 类别 | 适用形态 | 启用条件 | 维护责任 |
|---|---|---|---|---|
| 按客户维度导出月度用量报表 | 基础功能 | 标准版、行业版 | 默认开启 | 平台组 |
| 多级合规审核流程 | 可选功能 | 行业版 | 客户类型为受监管行业 | 行业版产品组 |
| 报表字段自定义 | 可选功能 | 标准版、行业版 | 行业版默认开放审计字段，标准版按申请开启 | 平台组 |
| 设备协议对接 | 差异化功能 | 行业版 | 仅行业版提供 | 行业版产品组 |
完成检查与持续校准
划分结果在进入版本规划前应通过一轮检查，检查项可直接对照下表执行：
- 每个功能项是否都有明确归属，待定项是否都写明了争议点和验证计划；
- 可选功能的启用条件是否可执行，能否由实施或配置人员直接判断，而非依赖口头解释；
- 差异化功能是否都绑定了具体形态的定位说明，是否存在被多处引用而可能污染基础层的情况；
- 组合配置表中的维护责任是否落到具体团队，是否存在无人认领的功能项；
- 功能项清单、矩阵、配置表三者的版本是否一致。
分类不是一次成型的结论，需要在几个固定时点重新校准：版本规划前复核待定项和新增功能项；新增产品形态时整体重跑一遍矩阵，因为新形态可能改变原有共性判断；客户定制需求集中出现时，检查这些需求是否指向某个可选功能的启用条件过窄，或某个差异化功能的边界需要调整。
功能跨类迁移要有触发条件和审批方式。常见触发条件包括：某可选功能在多数形态中被启用，具备下沉为基础的复用收益；某基础功能因形态定位变化需要分化；某差异化功能失去定位支撑。迁移由产品经理提出，产品负责人批准，涉及技术复用判断时需研发负责人确认，迁移原因和影响范围写入变更记录。保留每次判定的依据，后续复盘时才能区分“当时判断有误”和“业务条件已变化”，为下一轮规划提供参照。
常见问题
功能项拆到多细才合适？拆得太细会不会让清单难以维护？
粒度标准是“一个用户任务、一次可验收的操作结果”，例如“按客户维度导出月度用量报表”就比“报表模块”更适合作为功能项。拆得过粗，不同形态之间无法对齐；拆得过细，判断重点会被淹没。实际操作中可以先用粗粒度列一遍，再把跨形态行为可能不一致的条目拆开，其余保持合并。清单维护成本主要来自字段填写，建议只保留用户任务、使用场景、涉及形态、当前实现方式等必要字段，随判定推进再补充备注。
某个功能在多数形态中都需要，但其中一个形态要求特殊流程，应该归为基础功能还是可选功能？
先判断特殊流程属于哪类差异。如果用户任务相同、只是多一个审批环节或步骤分支，属于流程差异，可以保留在基础功能中，通过开关或分支条件实现，同时把该形态的启用条件写清楚。如果特殊流程改变了任务本身，或需要独立的能力实现，则应归入可选功能或差异化功能。判断依据是行为一致性是否有明确约束，而不是需要该功能的形态数量多少。
待定的功能项一直验证不出结论，会阻塞版本规划吗？
待定项不应无限期挂起。建议给每个待定项设定验证期限和验证方式，例如选取两到三个典型客户走一遍使用路径，或在一个试点形态中先按某一类实现并观察返工情况。如果到期仍无结论，可以由产品负责人按形态定位价值做临时裁定，并在变更记录中注明这是临时结论、后续需复核。这样版本规划可以继续推进，同时保留修正空间。
功能从可选类迁移到基础类，需要走什么流程？
常见触发条件是某可选功能在多数形态中被启用，下沉为基础层能带来明显复用收益。迁移由产品经理提出，说明触发原因、影响范围和涉及的形态；产品负责人批准方向；涉及技术复用判断时由研发负责人确认实现成本。迁移结论和依据写入变更记录，并同步更新组合配置表中的类别、适用形态和维护责任，避免矩阵与配置表版本不一致。
两个产品形态的用户任务看起来相似，但使用场景差别很大，还能算共性功能吗？
需要回到两个判断维度分别看：用户任务是否相同、跨形态行为是否一致。使用场景差别大，往往意味着触发条件、操作角色或数据范围不同，这时要检查这些差别是否会导致行为不一致。如果行为逻辑一致、只是参数取值不同，仍可按共性功能处理并配置化；如果场景差异导致流程或能力要求不同，就应归入可选功能或差异化功能。场景差异本身不是分类依据，它影响的是对行为一致性的判断。
