识别功能堆砌，需要把使用率、维护成本和复杂度放在同一份功能清单、同一时间窗里计算，先筛出低使用、高维护、高复杂度的候选功能，再结合业务价值与合规要求做取舍。阈值不宜照搬外部标准，更稳妥的做法是用自身历史分位数设预警线，并定期复盘调整。
要点总览（TL;DR）
- 识别功能堆砌要把使用率、维护成本和复杂度放在同一份功能清单、同一时间窗上计算，先筛出低使用、高维护、高复杂度的候选功能，再结合业务价值与合规要求做取舍。
- 使用率需写清分母：触达率=触达用户数÷目标用户数，活跃用户占比=活跃用户数÷目标用户数，调用次数要注明统计周期与去重规则；维护成本按年度人天、缺陷处理量和变更次数折算。
- 复杂度用配置项数量、开关数、跨模块依赖数和页面或代码分支数衡量，口径要结合产品形态选择，配置密集型与平台型产品侧重点不同。
- 阈值不设通用达标线，用自身历史分位数设预警线，例如使用率低于P25、维护成本高于P75、复杂度高于P75，三项中两项触发即进入候选清单，每季度复盘调整。
- 分位数只反映功能在自身产品中的相对位置，低使用率可能来自入口深或宣传不足，维护成本高可能来自技术债，单指标不能作为删除依据。
评估目标：判断哪些功能属于堆砌
这项评估要回答的问题是：在当前产品中，哪些单个功能或功能组合占用了持续投入，却只服务很少的用户，或者给系统带来不成比例的维护负担。评估对象是功能清单上的每一项已上线功能，以及由若干功能共同形成的组合，例如同一业务场景下的一组配置项和页面入口。
判断方向可以归纳为三类信号的叠加：使用侧长期偏低，维护侧持续消耗人力与缺陷处理资源，结构侧带来大量配置、开关和跨模块依赖。三类信号同时出现的功能，更接近“堆砌”的典型形态；只出现一类信号的功能，需要先排查其他解释。
需要明确的是，评估结论的用途是支撑取舍讨论，为产品规划提供候选清单和证据，不直接等同于删除决定。一个功能进入候选清单，意味着它需要被重新审视：是否可以简化、合并、下线，或者保留但降低维护投入。最终决策还要考虑用户承诺、合同约定、合规要求和迁移成本。
指标与范围：三类指标怎么选、统计哪些功能
指标设计的关键是每个指标都有明确的公式、分母、单位 and 统计时间窗，否则不同功能之间无法比较。下面三类指标分别对应使用、维护和结构三个维度。
功能清单的纳入范围
先建立一份统一的功能清单，作为所有指标的统计底表。清单中建议标注功能状态：已全量上线、灰度中、内部工具或运营后台功能。已上线功能进入常规评估；灰度功能单独统计，避免用不完整周期的数据下结论；内部工具功能如果服务对象是员工而非外部用户，应使用内部用户数作为分母，不与面向客户的功能混排。
合规必需功能和安全功能需要在清单中单独标注，例如满足监管要求的数据留存、审计日志、权限控制等。这类功能即使使用率低，也不进入常规堆砌候选判定，其存续依据是合规义务而非使用频次。
三类指标的定义
| 指标类别 | 指标名 | 公式 | 单位 | 分母说明 | 时间窗 |
|---|---|---|---|---|---|
| 使用率 | 触达率 | 统计期内触达该功能的用户数 ÷ 目标用户数 | 百分比 | 目标用户指该功能设计服务的人群，如某角色或某套餐用户 | 近90天 |
| 使用率 | 活跃用户占比 | 统计期内使用该功能至少一次的用户数 ÷ 目标用户数 | 百分比 | 同上，需去重 | 近90天 |
| 使用率 | 调用次数 | 统计期内功能调用总次数 ÷ 活跃用户数 | 次/人 | 活跃用户数，需说明是否去重及统计周期 | 近90天 |
| 维护成本 | 人力投入 | 统计期内该功能相关研发、测试、运维人天合计 | 人天/年 | 按功能归集的工时记录 | 近12个月 |
| 维护成本 | 缺陷处理量 | 统计期内该功能相关缺陷单数量及处理工时 | 个、人天 | 缺陷系统按功能标签归集 | 近12个月 |
| 维护成本 | 变更次数 | 统计期内该功能相关需求变更与发布次数 | 次 | 变更记录按功能关联 | 近12个月 |
| 复杂度 | 配置项数量 | 该功能暴露给用户或运营的配置项总数 | 个 | 以产品配置文档为准 | 当前版本 |
| 复杂度 | 开关数 | 该功能涉及的功能开关、灰度开关数量 | 个 | 配置管理平台 | 当前版本 |
| 复杂度 | 跨模块依赖数 | 该功能直接依赖的其他模块或服务数量 | 个 | 架构文档或代码仓库依赖关系 | 当前版本 |
| 复杂度 | 分支数 | 该功能相关的页面分支或代码分支数量 | 个 | 代码仓库或页面配置统计 | 当前版本 |
使用率的分母必须写清楚。以“目标用户数”为分母，能反映功能在其设计服务人群中的渗透程度；如果以全量用户为分母，低频角色功能会被系统性低估。调用次数适合观察使用深度，但要注明是否去重、统计周期多长，避免把批量任务产生的调用误读为用户活跃。
维护成本建议按年度口径折算，便于和规划周期对齐。人力投入按功能归集工时，缺陷处理量同时记录数量和工时，变更次数反映功能的波动程度。复杂度指标需要结合产品形态选择：配置密集型产品重点看配置项和开关，平台型产品重点看跨模块依赖，前端页面多的产品可补充页面分支数。
数据口径与证据：取数来源和可比性处理
三类指标来自不同系统，直接放在一起比较容易失真。取数时要固定来源、统一时间窗，并对版本变更做分段处理。
使用率数据通常来自埋点、服务端日志和账号活跃记录。埋点适合统计页面和按钮级触达，日志适合统计接口调用，账号活跃记录用于确定分母中的目标用户。三者口径不同，同一功能应尽量使用同一来源，跨来源时需说明差异。
维护成本数据来自工时记录、缺陷系统和变更记录。工时按功能标签归集时，要约定拆分规则，例如一个需求涉及多个功能时按预估比例分摊。缺陷单需要功能字段，缺失时可用模块路径映射。变更次数从发布记录或需求管理系统提取。
复杂度数据来自配置管理平台、代码仓库和产品配置文档。配置项和开关数量以当前版本为准，跨模块依赖以架构文档或依赖分析结果为准，分支数从代码仓库统计。复杂度是时点值，使用率 and 维护成本是区间值，解读时要注明这一差异。
可比性处理有几条规则：时间窗统一为近90天（使用率）和近12个月（维护成本），复杂度取当前版本；统计期内发生重大版本重构的功能，按变更前后分段统计，不把重构前的数据混入；缺失值标记为“数据不足”，不按零处理；分母为零的功能（如目标用户群尚不存在）不参与分位数计算，单独列入待确认清单；灰度期数据单独统计，达到全量后再纳入常规评估。
计算与评估步骤：从原始数据到堆砌候选清单
下面五步可以把原始数据转化为可讨论的候选清单，每一步都保留可复算的记录。
- 汇总原始值。按功能清单逐项填入三类指标的原始值，注明数据来源、时间窗和分母。输出一张功能指标底表，每个功能一行。
- 标准化处理。三类指标量纲不同，可分别转换为分位数排名，或做极值归一化。分位数方法的优点是直接反映该功能在自身产品中的相对位置，不受绝对数值大小影响。
- 设定预警阈值。用自身历史数据的分位数设线，例如使用率低于P25视为偏低，维护成本高于P75视为偏高，复杂度高于P75视为偏高。分位数基于过去若干周期的功能指标分布计算，样本量过少时可放宽到P20/P80，并在记录中注明。
- 组合判定。三项中两项触发预警，即进入堆砌候选清单。也可以按业务需要设置更严格的规则，例如使用率偏低且维护成本偏高优先，复杂度作为辅助信号。
- 人工复核。候选清单逐项复核，确认是否存在入口深、宣传不足、目标用户群变化等可解释原因，并结合用户价值、合同承诺和合规要求给出处理建议：简化、合并、下线观察或保留。
阈值需要定期调整。建议每季度复盘一次，检查候选清单的命中情况 and 实际处理结果，避免阈值长期固化导致清单失真。产品形态发生较大变化时，例如从工具型转向平台型，复杂度口径和阈值应同步重设。
在功能清单、使用数据和评审记录的管理上，ONES 的工作项与文档能力可以承载这条流程：功能清单作为工作项台账维护，使用率与维护成本数据以文档或表格形式关联到对应功能，候选清单和复核结论通过评审流程留痕，便于下一季度对比调整。具体字段和流程可按团队现有管理方式配置。
例子：一个功能的三项指标计算与判定
以下示例为演示用途，数字为假设值，不代表行业基准。
假设某协作产品有一个“自定义报表导出”功能，目标用户是管理员角色，共2000人。近90天数据显示，触达该功能的用户为300人，其中至少使用一次的有180人，调用总次数为900次。使用率计算：触达率 = 300 ÷ 2000 = 15%；活跃用户占比 = 180 ÷ 2000 = 9%；人均调用次数 = 900 ÷ 180 = 5次/人。
维护成本按近12个月统计：研发与测试工时合计60人天，运维支持10人天，人力投入共70人天/年；相关缺陷单24个，处理工时合计18人天；需求变更与发布共9次。复杂度方面，该功能暴露配置项14个，功能开关3个，直接依赖报表引擎、权限模块和存储服务共3个模块，页面分支6个。
假设该产品当期功能指标分布为：使用率P25对应12%，维护成本P75对应50人天/年，复杂度P75对应配置项10个。该功能使用率9%低于P25，维护成本70人天高于P75，配置项14个高于P75，三项全部触发预警，按组合规则进入堆砌候选清单。
复核阶段需要确认：该功能是否只服务少数大客户而有合同约定；低使用率是否因为入口藏在三级菜单；维护成本高是否主要来自历史技术债。如果确认无合同约束、入口可优化且技术债可清理，处理建议可以是先优化入口观察一个周期，再决定是否下线；如果存在合同承诺，则保留但控制变更频率。
解读与限制：阈值不是达标线，指标不等于因果
分位数阈值反映的是功能在自身产品中的相对位置，不是行业通用标准。一个功能使用率低于P25，只说明它在本产品内相对偏低，不能直接推断它没有价值。跨产品、跨业务线比较分位数没有意义，因为分母人群和功能定位不同。
低使用率有多种可能原因。入口层级深、功能命名不清晰、缺少引导和宣传，都会压低触达率。评估时应先排除可发现性问题，例如检查入口点击路径长度、搜索命中情况和帮助文档覆盖，再判断是否属于真实需求不足。
维护成本高也可能与功能本身无关。历史技术债、架构耦合、测试覆盖不足都会推高工时和缺陷量。这类情况下，处理方向可能是重构或解耦，而非直接下线功能。解读维护成本时，应区分“功能带来的必要成本”和“实现方式带来的额外成本”。
复杂度阈值需要结合产品形态调整。配置密集型产品的配置项天然较多，平台型产品的跨模块依赖难以避免，用同一套绝对值横向比较会失真。复杂度更适合作为辅助信号，与使用率和维护成本组合使用。
单指标不能作为删除依据。使用率低但承担合规义务的功能、维护成本高但服务核心付费客户的功能，都需要人工复核后单独判断。评估结果应作为取舍讨论的输入，配合用户访谈、合同梳理和迁移成本评估，形成可执行的处理方案。
常见问题
功能使用率的分母到底该用全量用户还是目标用户？
建议用目标用户数作分母，也就是该功能设计服务的人群，例如某角色或某套餐用户。用全量用户作分母，低频角色功能会被系统性低估，容易把“只服务少数角色但确实必要”的功能误判为堆砌。
如果同一功能服务多类人群，可以按角色分别计算再合并观察。分母口径一旦确定，应在整个评估周期内保持一致，跨周期比较时注明分母是否变化。
维护成本里的工时怎么归集到单个功能？
工时归集依赖功能标签。可以在工时记录或需求管理系统中为每条记录关联功能字段，一个需求涉及多个功能时按预估比例分摊，并记录分摊规则。
缺陷单如果缺少功能字段，可以用模块路径映射到功能。归集规则不必追求绝对精确，关键是同一套规则在多个周期内保持一致，让功能之间的相对高低可比。
历史数据不足、算不出分位数怎么办？
样本量过少时，可以先把分位数放宽到P20/P80，并在评估记录中注明这一调整；同时用绝对值做辅助判断，例如使用率低于10%、维护成本超过团队年度投入的一定比例时先列入观察。
更根本的做法是先把指标底表建起来，积累两到三个周期的数据后再切换到分位数方法。在数据积累期，候选清单的结论应更依赖人工复核，不急于据此做下线决定。
合规必需功能使用率很低，也要进入候选清单吗？
不建议。合规必需功能和安全功能应在功能清单中单独标注，例如满足监管要求的数据留存、审计日志、权限控制等，其存续依据是合规义务而非使用频次，不进入常规堆砌候选判定。
这类功能仍可以评估实现方式是否过重，例如能否用更少的配置项或更低的维护投入满足同样要求，但判断维度是合规成本，不是使用率高低。
阈值定好之后多久调整一次比较合适？
建议每季度复盘一次，检查候选清单的命中情况和实际处理结果：被标记的功能有多少最终确认需要简化或下线，有多少属于误判。误判集中出现时，说明阈值或指标口径需要修正。
产品形态发生较大变化时，例如从工具型转向平台型，复杂度口径和阈值应同步重设，不必等到季度节点。
