复盘功能扩张与组合收敛时，覆盖度、复用度、组合复杂度和维护成本需要放在同一时间窗、同一统计对象和同一分母口径下核算。四个指标分别回答需求满足、能力共享、配置叠加和长期投入的问题，结论用于判断新增功能是否值得进入组合，以及哪些既有功能应当收敛。功能清单、场景清单与工时记录可以在ONES中承载，便于按同一口径取数。
要点总览（TL;DR）
- 四个指标要放在同一时间窗、同一统计对象和同一分母口径下计算，否则横向比较没有意义。
- 覆盖度按被满足的目标场景数除以场景总数计算，分母是场景清单而非全部请求；复用度按共享场景比例或能力引用次数计算，两种口径不混用。
- 组合复杂度用配置项数、依赖边数、可选组合数等结构性指标衡量，维护成本用单位时间人力投入加缺陷修复工时衡量。
- 权衡时先算基线，再比较新增功能的增量覆盖与增量成本，并用复杂度与成本上限做约束，避免任一指标最大化。
- 高覆盖不等于高价值，高复用可能掩盖耦合，单指标适合描述现状，取舍判断需要四个指标同时在场并标注数据缺口。
权衡要回答什么问题：功能组合的评估目标
复盘的目标是判断下一步继续扩大覆盖，还是收敛组合、降低叠加。这个判断需要同时看四类信息：目标场景中有多少被现有功能满足，同一能力被多少场景共享，配置与依赖叠加到什么程度，维持当前组合需要投入多少人力与缺陷修复工时。四个指标各自回答一个问题，单独看任何一个都容易得出片面结论。
评估结论用于取舍，不用于给团队或个人排名。覆盖度高可能来自大量低频功能堆叠，复用度高可能来自少数能力被过度耦合调用，复杂度低可能只是功能总量少，维护成本低可能只是统计范围窄。把指标用于绩效排名，会诱导团队优化数字而非优化组合。
复盘开始前，建议先列出需要回答的决策问题，作为后续取数和计算的依据：
- 当前组合中，哪些目标场景尚未被满足，缺口集中在哪些能力上；
- 哪些功能只服务单一场景且维护投入持续存在，是否具备收敛条件；
- 新增一个功能预计带来多少增量覆盖，需要增加多少配置、依赖和维护工时；
- 当前组合复杂度是否已接近团队可维护的上限，新增是否应转为替换或合并。
四个指标的定义、公式与统计范围
四个指标需要在同一统计对象上计算，通常以功能或能力为统计单元，以季度或半年为时间窗。统计对象一旦确定，分子分母都从同一份清单取数，跨期比较时保持口径不变。下表给出建议口径，实际使用时可根据团队记录粒度调整，但调整后需在结论中注明。
| 指标 | 建议公式 | 分子 | 分母 | 单位 | 时间窗 |
|---|---|---|---|---|---|
| 功能覆盖度 | 被满足的目标场景数 ÷ 目标场景总数 | 现有功能可完整支撑的目标场景数 | 目标场景清单中的场景总数 | 百分比 | 与场景清单版本一致 |
| 复用度 | 共享同一能力的场景数 ÷ 使用该能力的场景总数 | 通过同一能力实现的场景数 | 使用该能力的场景总数 | 百分比或场景数 | 同一统计周期 |
| 组合复杂度 | 配置项数、依赖边数、可选组合数分别统计 | 按功能模块归集的配置项、依赖关系、可选组合 | 不适用，按绝对值报告 | 个、条 | 版本发布时点 |
| 维护成本 | 单位时间人力投入 + 缺陷修复工时 | 按功能归集的开发维护工时与缺陷修复工时 | 不适用，按绝对值报告 | 人时/月或人日/季度 | 与复盘周期一致 |
覆盖度的分母是目标场景清单，不是全部用户请求或工单数量。场景清单需要事先约定粒度和版本，否则不同人统计出的分母不同，结果无法比较。复用度有两种常见口径：按场景共享比例计算，或按能力被引用次数计算。两种口径回答的问题不同，同一份报告中只选一种，并在表头注明。
组合复杂度建议同时报告配置项数、依赖边数和可选组合数，因为单一数量无法反映耦合程度。一个功能配置项少但依赖多个外部模块，其叠加成本可能高于配置项多但依赖独立的功能。维护成本按功能或模块归集，工时记录需要能对应到具体功能，否则只能报告整体成本，无法参与单个功能的取舍判断。
缺失值处理需要提前约定。场景清单中状态不明的场景不计入分子，但在分母中保留并单独标注；工时记录缺失的功能不估算填补，标注为数据缺口并缩小该功能的结论范围。分母为零时，例如某能力没有使用场景，复用度不计算百分比，直接报告场景数为零并说明原因。
数据从哪里来：口径与证据要求
覆盖度和复用度的分母都依赖两份基础清单：目标场景清单和功能清单。场景清单应包含场景名称、目标用户、触发条件和验收标准；功能清单应包含功能名称、所属模块、上线时间和当前状态。两份清单之间需要建立对应关系，标明每个场景由哪些功能支撑，这份对应关系是覆盖度可复算的前提。
复用度与组合复杂度的证据来自使用日志、配置记录和依赖清单。使用日志需要能按功能或模块粒度导出调用或使用记录；配置记录需要保留配置项名称和所属功能；依赖清单需要标明模块之间的调用或数据依赖方向。三类记录如果粒度不足，只能做整体描述，无法支撑按功能取舍。
维护成本的证据是工时记录和缺陷记录。工时需要按功能或模块归集，缺陷记录需要包含所属功能、修复工时和发现时间。仅有缺陷数量没有修复工时，只能反映问题频次，无法换算为成本。数据来源与用途可对照下表整理：
| 指标 | 主要数据来源 | 证据形式 | 可比性前提 |
|---|---|---|---|
| 功能覆盖度 | 目标场景清单、功能与场景对应关系 | 场景逐条核对记录 | 场景清单版本一致、对应关系完整 |
| 复用度 | 使用日志、能力引用记录 | 按场景统计的使用记录 | 统计粒度和时间窗一致 |
| 组合复杂度 | 配置记录、依赖清单 | 配置项清单、依赖关系表 | 按同一版本或发布时点统计 |
| 维护成本 | 工时记录、缺陷记录 | 按功能归集的工时与修复工时 | 归集口径一致、缺失项已标注 |
口径不一致是复盘中最常见的问题。例如上半年按模块统计工时，下半年按功能统计，两期成本无法直接比较。处理方式是固定统计单元，对历史数据做一次映射转换，并在结论中说明转换方法和影响范围。无法转换的部分标注为不可比，不强行合并。
当功能清单、场景清单和工时记录分散在不同工具中时，取数成本会直接影响复盘频率。ONES可以承载功能清单、场景条目和工时记录，并通过工作项关联把场景与功能对应起来，使覆盖度和维护成本能够按同一统计对象导出。这里的价值在于减少跨工具核对，指标口径仍由团队自行约定。
计算与权衡步骤：从单指标到组合判断
权衡的基本思路是先算单指标建立基线，再对候选新增功能计算增量覆盖与增量成本，最后用复杂度和成本上限做约束判断。单指标用于描述现状，增量比较用于决定是否行动，约束上限用于防止组合无限扩张。
第一步，确定统计对象和时间窗，锁定场景清单与功能清单版本，按上一节的口径计算四个指标的基线值。第二步，对每个候选新增功能，估算它能覆盖的目标场景数，计算增量覆盖度；同时估算新增配置项、依赖边数和预计维护工时，计算增量成本。第三步，比较增量覆盖与增量成本的比例，并与现有功能的平均单位覆盖成本对照。第四步，检查新增后组合复杂度和维护成本是否超过预设上限，超过则考虑合并、替换或暂缓。
约束上限需要团队根据自身维护能力设定，没有通用达标线。可参考的设定方式是：以过去两个周期实际发生的维护工时峰值为参照，设定不超过该峰值的成本上限；以当前依赖边数为参照，设定新增依赖的允许条数。上限一旦设定，在复盘周期内保持一致，避免为某个候选功能临时放宽。
判断规则可以归纳为几条：增量覆盖明显、增量成本低于现有平均单位覆盖成本、且不突破复杂度与成本上限的功能，优先进入组合；增量覆盖有限但成本高的功能，暂缓或寻找复用现有能力的实现方式；新增会显著推高依赖边数或维护工时的功能，即使覆盖度提升，也应先做组合收敛再评估。分母为零或数据不可比时，不计算比例，改为定性说明并标注证据缺口。
一个算例：新增功能该不该进组合
以下为演示情景，数据为假设值，用于说明计算过程，不代表真实业务规模。某产品团队有目标场景40个，现有功能12项，复盘周期为一个季度。现有功能覆盖其中30个场景，季度维护工时为320人时，缺陷修复工时为80人时，配置项合计96项，模块间依赖边28条。
基线计算：覆盖度为30÷40=75%；复用度按场景共享口径统计，12项功能中有5项被3个及以上场景共用，这5项功能涉及的使用场景总数为22个，其中共享场景18个，复用度为18÷22≈81.8%；组合复杂度报告为配置项96项、依赖边28条；维护成本为320+80=400人时/季度。
现在评估一个候选新增功能。该功能预计覆盖3个尚未满足的目标场景，需要新增配置项8项、依赖边3条，预计每季度增加维护工时45人时、缺陷修复工时10人时。增量覆盖为3÷40=7.5%，覆盖度将从75%升至82.5%；增量成本为55人时/季度，维护成本将从400升至455人时/季度，增幅约13.8%；依赖边从28条增至31条。
对照现有平均单位覆盖成本：现有400人时支撑75%覆盖，每百分点覆盖约5.3人时；新增55人时换取7.5个百分点覆盖，每百分点约7.3人时，高于现有平均水平。若团队设定的季度维护成本上限为450人时，新增后455人时已突破上限。结论是该功能覆盖增量明确，但单位成本偏高且突破成本约束，建议先收敛一项低频功能释放工时，或将新功能改为复用现有能力的配置扩展，再重新评估。
敏感性说明：若新增功能的维护工时估算降至35人时，总成本为435人时，未突破上限，单位覆盖成本降至约6人时/百分点，结论会转为可进入组合。估算值对结论影响明显，实际使用时应对工时估算给出区间，并说明区间上下限对应的判断。
如何解读结果与避免误判
高覆盖不等于高价值。覆盖度只说明目标场景被满足的比例，不说明这些场景的使用频次和业务重要性。一个覆盖了多数低频场景的组合，其价值可能低于覆盖少数核心场景的组合。解读时应结合场景权重或使用频次，至少标注覆盖增量集中在哪些场景。
复用度高可能掩盖耦合。同一能力被多个场景共享，既可能是设计良好的抽象，也可能是多个场景被迫依赖同一模块，任何改动都会波及全部使用方。解读复用度时，应同时看依赖边数和变更影响范围，复用度高且依赖集中，往往意味着维护风险而非设计优势。
复杂度和成本需要结合规模看。配置项96项对一个小团队可能已接近上限，对一个大团队可能仍有余量。绝对值只有在与团队维护能力、发布频率和缺陷率对照时才有解释力。跨团队比较复杂度数值，容易得出错误结论。
四个指标都不构成因果保证。覆盖度提升不必然带来业务结果改善，维护成本下降也不必然意味着组合更健康，可能只是统计范围缩小或功能下线。复盘结论应表述为在特定时间窗和统计口径下的组合判断，并附上数据缺口和估算区间。单指标适合描述现状，取舍判断需要四个指标同时在场，并明确约束条件。
常见问题
目标场景清单和功能清单由谁维护，多久更新一次比较合适？
两份清单通常由产品负责人牵头维护，功能负责人补充所属模块与状态，测试或交付角色核对场景与功能的对应关系。更新频率与复盘周期对齐即可，例如按季度复盘就在季度初锁定版本。关键是版本可追溯：每次复盘记录所用的清单版本号，跨期比较时先确认两期清单的粒度和范围是否一致，不一致的部分做映射转换或标注为不可比。
使用日志粒度不够，无法按功能导出复用数据，怎么处理？
先判断能否通过配置记录或能力引用记录间接还原使用场景，例如按模块调用记录加场景对应关系做近似统计。如果仍无法还原，就把复用度降级为定性描述，说明哪些能力被多个场景使用、证据来自哪里，并标注该指标本期不参与比例计算。不要用估算值填补原始记录，也不要把整体使用量当作复用度。缩小结论范围比编造数字更可靠。
团队规模不同，组合复杂度和维护成本的绝对值还能比较吗？
跨团队直接比较绝对值容易得出错误结论。配置项96项对一个小团队可能已接近维护上限，对大团队可能仍有余量。可行的做法是把绝对值换算为与团队维护能力相关的参照，例如人均维护工时、单位发布周期的缺陷修复工时，或与过去两个周期的自身峰值对照。比较的目的是判断当前组合是否接近本团队的上限，而非在团队之间排名。
新增功能的工时估算区间很宽，结论会跟着变，怎么给出稳定判断？
对估算给出上下限，分别计算区间两端对应的增量成本和单位覆盖成本，再看结论是否在区间内保持一致。如果下限未突破成本上限、上限突破，就说明结论对估算敏感，此时应补充证据或先做小范围验证，而不是取中间值直接下结论。算例中维护工时从45人时降到35人时，结论就从暂缓转为可进入组合，这类敏感性需要在复盘中明确写出。
复盘发现某项功能覆盖低、维护成本高，是否应当直接下线？
下线前需要确认三件事：该功能服务的场景是否已被其他能力覆盖，使用方是否还有迁移路径，下线本身需要多少改造与沟通工时。覆盖低且成本高的功能具备收敛条件，但收敛方式可以是合并进其他能力、转为配置扩展或分阶段停用，直接下线只是其中一种。把收敛动作的预期收益与执行成本一起纳入下一轮评估，比单看当期指标更稳妥。
