评估功能组合合理性，需要把“合理”拆成可复算的指标：功能覆盖度、复用度、组合复杂度和维护成本，在同一功能清单版本与时间窗内计算，再用加权评分或象限图做权衡。本文给出四类指标的定义、取数口径、计算步骤和示例，并说明结论的解读边界，适用于产品负责人复盘“继续扩功能、合并精简还是维持现状”。
要点总览（TL;DR）
- 评估对象是某一版本的功能集合，先冻结功能清单与时间窗，再计算覆盖度、复用度、组合复杂度和维护成本四项指标。
- 覆盖度用已覆盖目标场景数除以场景总数；复用度用被两个及以上功能共用的组件或数据对象数除以总数；复杂度按依赖边数、配置项数、状态组合数分别记录；维护成本按单位功能工时统计。
- 权衡时把覆盖度与组合复杂度放进四象限图，再用加权评分排序，对低覆盖高复杂度的功能回溯原始明细，形成合并、精简、扩展或观察的建议。
- 指标反映现状，覆盖度高不代表组合合理，复用度不宜跨产品比较，复杂度受依赖图质量影响，建议按发布周期复算并保留历史口径。
评估目标：这次复盘要回答什么
功能组合合理性评估的对象是某一版本的产品功能集合，回答的是“这组功能放在一起是否值得”的问题。单个需求的价值评分、优先级排序属于另一类工作，不能替代组合层面的判断：十个单独看都有价值的功能，叠加起来可能带来难以维护的配置体系和相互冲突的交互路径。
本次复盘的典型场景，是产品在扩大功能覆盖与控制组合复杂度之间做取舍。功能越加越多，覆盖的场景变广，但依赖关系、配置项和状态组合随之增长，缺陷定位、客户支持和版本升级的成本也会上升。评估要回答的核心问题是：当前组合带来的覆盖增量，是否值得它引入的复杂度与维护投入。
在开始取数前，先写一份评估目标说明，至少包含三项内容：
- 评估对象：明确功能清单的版本号或冻结日期，例如“V3.2 发布时的全部对外功能”，临时实验功能、内部工具不计入。
- 时间窗：四个指标统一使用同一统计区间，例如最近一个完整季度或最近两个发布周期，避免覆盖度用全年数据、维护成本用单月数据。
- 决策用途：结论要落到三种动作之一——继续扩展功能、合并精简现有功能、维持现状并观察。决策用途决定后续权衡时更看重覆盖度还是复杂度。
目标说明写清楚后，指标才有比较的意义。若评估目的只是向管理层汇报功能数量，四个指标会被简化成功能个数，失去权衡价值。
指标与范围：覆盖度、复用度、复杂度、维护成本怎么定义
四个指标分别刻画组合的不同侧面，需要同时给出公式、分子、分母和单位，保证他人可以按同样口径复算。下表给出建议定义，具体阈值由团队结合业务设定。
| 指标 | 公式 | 分子 | 分母 | 单位 |
|---|---|---|---|---|
| 功能覆盖度 | 已覆盖目标场景数 ÷ 目标场景总数 | 功能组合能够完整支撑的目标用户场景数 | 评估范围内冻结的目标场景清单总数 | 百分比 |
| 复用度 | 被两个及以上功能共用的组件或数据对象数 ÷ 组件或数据对象总数 | 被至少两个功能共同使用的共享组件、数据对象或交互模式数量 | 功能组合涉及的组件、数据对象与交互模式总数 | 百分比 |
| 组合复杂度 | 分别记录依赖边数、可配置项数、状态组合数 | 功能间依赖关系数量；用户可调整的配置项数量；关键对象的状态取值组合数量 | 不设统一分母，按三个口径分别报告 | 个、项、种 |
| 维护成本 | 单位功能维护工时 = 维护总工时 ÷ 功能数 | 统计窗口内缺陷修复、支持工单处理、升级适配投入的工时或人天 | 同一功能清单中的功能数量 | 人天/功能 |
组合复杂度刻意不合成单一数字。依赖边数反映功能之间的耦合，可配置项数反映用户需要理解的选择空间，状态组合数反映测试与支持需要覆盖的分支。三者可能朝不同方向变化：某次改版减少了配置项，却增加了功能间依赖。分开记录，才能在权衡时定位问题出在结构还是配置。
纳入范围需要事先写定：功能清单以哪个版本为准、场景清单何时冻结、统计窗口的起止日期、排除哪些临时实验功能与已下线功能。维护成本的统计还要说明去重规则，例如一个工单涉及多个功能时如何分摊工时。范围一旦确定，本次评估内不再调整，否则分子分母会错位。
数据口径与证据：从哪里取数、如何保证可比
四个指标的数据来源不同，需要分别说明采集方式，并统一到同一功能清单版本上。
- 功能清单与场景清单：功能清单从产品路线图或需求管理系统中按版本导出；场景清单由产品、售前与客户成功共同确认后冻结，每个场景标注被哪些功能覆盖。场景覆盖的判断标准要写清楚，例如“主要路径可完成”算覆盖，“需要人工绕过”不算。
- 依赖关系图：由架构或技术负责人维护，记录功能之间、模块之间的调用与数据依赖。依赖图的完整度直接决定复杂度指标的可信度，取数前应做一次核对。
- 缺陷、工单与工时：缺陷数据从缺陷管理系统按功能标签统计；支持工单从客服系统按功能分类导出；工时从项目管理系统或工时记录中归集。三者都需要去重，同一问题在缺陷与工单中重复出现时只计一次，并在口径说明中注明。
- 定性证据：用户访谈记录、支持团队的高频问题清单、方案评审纪要，用于解释指标异常的原因，不直接进入计算。
可比性处理是这一节的重点。常见问题有三类：分母为零，例如某版本没有新增目标场景，覆盖度无法计算，此时应标注“不适用”而非记为零；功能清单版本不一致，例如覆盖度按旧清单算、维护成本按新清单算，需要统一到同一版本重算；统计窗口错位，例如缺陷数据跨了两个发布周期，应裁剪到统一窗口。处理方式写入口径说明，后续复算时沿用。
功能清单、依赖关系和维护工时的归集如果分散在多个表格与系统中，核对成本会很高。ONES 的项目管理与知识库管理模块可以承载功能清单、场景清单与依赖关系的版本化记录，需求从收集、结构化到开发决策的流程在同一平台留痕，便于按版本导出同一口径的数据；缺陷与工单的工时归集仍需结合团队实际使用的系统。工具承载的是记录与追溯，指标定义和判断标准仍由评估者确定。
计算与评估步骤：从取数到权衡结论
计算流程分为四步，每一步都有明确的产物，便于复核。
第一步，逐项打标。按统一功能清单，为每个功能标注四项信息：所属目标场景、使用的共享组件或数据对象、与其他功能的依赖关系、统计窗口内的维护投入。打标结果形成一张功能明细表，是后续所有计算的基础。
第二步，分别计算四个指标。覆盖度按场景去重统计，一个场景被多个功能覆盖只计一次；复用度按组件或数据对象统计被引用次数；复杂度按三个口径分别汇总；维护成本按功能汇总工时后求单位均值。计算完成后做归一化处理，把各指标映射到 0 到 1 区间，便于加权比较。归一化方法需在报告中注明，例如按历史最大值缩放或按本次评估内的极值缩放。
第三步，做权衡呈现。推荐两种方式结合使用：
- 四象限图：横轴为功能覆盖度，纵轴为组合复杂度，每个功能或功能组作为一个点。高覆盖、低复杂度的区域是组合效率较高的部分；低覆盖、高复杂度的区域是优先复盘对象。
- 加权评分：按决策用途给四个指标分配权重，例如本次复盘以控制复杂度为主，可提高复杂度与维护成本的权重。加权结果用于排序，不替代象限图的结构观察。
第四步，回溯异常值。对落在低覆盖高复杂度区域的功能，回到原始明细逐项检查：是场景清单本身遗漏，还是功能确实只服务少数客户；复杂度来自必要的业务规则，还是历史实现留下的耦合。回溯结论形成调整建议，分为合并、精简、继续扩展、维持观察四类。
权衡矩阵可以用一张表承载：行是功能或功能组，列是四个指标值、加权得分、象限位置和建议动作。矩阵的作用是让每个建议都能追溯到具体数据，而不是凭印象决定砍留。
例子：一次功能组合复盘怎么算
以下为一组演示数据，用于说明公式如何落地，数值为假设，不代表任何真实产品。
假设某版本功能清单共 20 个功能，冻结的目标场景清单共 25 个，其中 18 个场景被至少一个功能完整覆盖。组合涉及共享组件与数据对象共 40 个，其中 16 个被两个及以上功能共用。依赖关系图记录功能间依赖边 34 条，用户可配置项 60 项，关键对象状态组合 12 种。统计窗口为一个季度，缺陷修复、支持工单与升级适配合计投入 240 人天。
| 指标 | 计算 | 结果 |
|---|---|---|
| 功能覆盖度 | 18 ÷ 25 | 72% |
| 复用度 | 16 ÷ 40 | 40% |
| 组合复杂度 | 依赖边 34 条；配置项 60 项；状态组合 12 种 | 分别记录 |
| 维护成本 | 240 人天 ÷ 20 个功能 | 12 人天/功能 |
进一步看功能组层面。假设其中 5 个功能只覆盖 2 个场景，却贡献了 18 条依赖边和 25 个配置项，维护投入合计 70 人天，单位维护成本 14 人天/功能，高于整体均值。这组功能在四象限图中落在低覆盖、高复杂度区域，属于优先复盘对象。
回溯后发现，其中 2 个功能的场景可由另外 3 个功能通过配置组合覆盖，依赖边主要来自重复的数据同步逻辑。据此给出的判断示例是：合并这 2 个功能，复用已有数据对象，预计减少约 8 条依赖边和 10 个配置项；其余 3 个功能维持观察，下一周期复算维护成本是否下降。另一组高覆盖、低复杂度的功能则作为继续扩展的候选，评估新增场景时优先在其上叠加。
这个例子的假设条件包括：场景清单已冻结且覆盖判断标准一致；依赖图经过核对；工时按功能标签归集并已去重。若其中任一条件不成立，计算结果只能作为方向参考，不能直接用于砍留决策。
解读与限制：指标能说明什么、不能说明什么
覆盖度高不等于组合合理。覆盖度只说明场景被支撑的比例，不说明支撑方式是否经济。一个组合可能用大量重复功能覆盖了多数场景，复杂度和维护成本都很高，此时提高覆盖度的正确动作可能是合并而非继续新增。
复用度受架构与业务差异影响明显。面向不同行业、不同部署形态的产品，共享组件的可行范围本就不同，复用度不宜跨产品直接比较，更适合在同一产品的时间序列上观察变化。组合复杂度指标对依赖关系图的质量高度敏感，依赖图不完整时，复杂度会被低估，据此做出的精简判断可能遗漏真实耦合。
维护成本按功能归集时，跨功能的公共投入如何分摊会影响结果，分摊规则需要在口径说明中固定。四个指标反映的是评估窗口内的现状，不能直接证明某个功能导致了收入变化，也不能预测新增功能的未来收益。指标的作用是缩小讨论范围、暴露结构问题，最终判断仍需结合业务证据。
建议每个发布周期或每季度复算一次，保留历史口径与原始明细，观察覆盖度、复用度、复杂度与维护成本的趋势。单次快照容易受版本节奏影响，趋势变化更能说明组合是在变健康还是变臃肿。通用达标线需结合业务实际设定，本文不给出统一阈值。
常见问题
功能清单和场景清单在评估期间发生变更，应该怎么处理？
评估开始前应冻结功能清单版本和场景清单，并在口径说明中写明冻结日期。若评估期间确有功能上线或下线，建议保留原清单完成本轮计算，把变更记入下一轮；若必须纳入，则四个指标全部按新清单重算，不能只更新其中一两个指标，否则分子分母错位，结果不可比。
团队规模小、功能数量不多，也需要做四指标评估吗？
功能数量少时，依赖边数和配置项数本身有限，可以简化计算：覆盖度和维护成本按完整口径统计，复用度与复杂度用清单逐项核对代替精确计数。评估的价值在于形成可追溯的判断依据，而非指标数量。若组合只有十几个功能、维护投入也容易归集，一张功能明细表加一次象限讨论通常就够用。
维护成本中的工时数据不完整，评估还能做吗？
可以先用可获得的证据做方向判断，例如缺陷数量、支持工单频次、升级适配涉及的功能范围，并在报告中标注工时数据缺失的范围。缺失部分不宜按平均值补造，否则单位功能维护成本会失真。下一轮评估前，先把缺陷、工单与工时的归集规则固定下来，再逐步补齐数据。
四个指标算出结果后，如何避免各团队各说各话？
关键是把口径说明和原始明细一起提交评审：公式、分子分母、时间窗、去重规则、归一化方法都写在报告里，每个结论都能追溯到具体功能和数据。评审时先确认口径一致，再讨论权重分配和砍留建议。权重反映本次决策用途，应在评审前确定并记录，避免看到结果后再调整权重。
评估结论建议合并功能，落地时要注意什么？
合并前先确认被合并功能的场景确实可由保留功能通过配置组合覆盖，并核对依赖关系图，避免合并后把耦合转移到别处。合并方案应包含数据迁移、配置兼容和用户通知的安排，合并完成后在下一轮复算中观察依赖边数、配置项数和单位维护成本是否按预期下降。若下降不明显，说明复杂度来源判断有误，需要重新回溯。
