维护投入占比的统计口径，核心是固定四件事：维护类工作的判定边界、工时来源与填报粒度、分母包含的工作类型、统计周期与缺失工时处理。公式本身简单——统计周期内维护类工时除以同期全部研发工时再乘100%，难点在于分子分母是否同源、边界是否稳定。本文只讨论投入端的统计方法，不涉及产出价值比较，也不用于个人绩效排名。
要点总览（TL;DR）
- 维护投入占比=统计周期内维护类工时÷同期全部研发工时×100%，结果保留一位小数，分子分母必须同源。
- 口径要固定四件事：维护类工作的判定边界、工时来源与填报粒度、分母包含的工作类型、统计周期与缺失工时处理。
- 维护判定建议按工作项类型、工作来源、是否改变产品能力三条组合判断，争议项逐条成文并记录版本。
- 占比高低不含好坏判断，需拆到故障处理、技术债偿还、兼容性适配等子项，并结合多期趋势解读。
- 口径变更会让前后期不可比，跨期比较前先核对口径版本，变更首期同时给出新旧口径结果。
这个指标要回答什么问题
维护投入占比是一个投入结构指标，用来观察维护类工作占用了多少研发资源。它回答的是“资源花在哪里、维护负担有多重”，而不是“团队做得好不好”。把用途先说清楚，后面的口径设计才不会跑偏。
典型使用场景有三类。第一，资源规划：在下一季度排期前，判断有多少人力会被维护工作占用，剩余多少可用于新功能。第二，维护负担评估：观察某产品线或某系统的维护投入是否持续上升，为架构改造、技术债治理提供讨论依据。第三，版本规划前的投入预估：参考历史占比，为版本周期预留维护缓冲。
需要明确的使用边界同样重要。这个指标不用于个人绩效排名，工时多不等于贡献大；也不直接等同于产出价值，维护投入高可能说明系统稳定、用户满意，也可能说明缺陷频发、架构老化，单看比例无法区分。指标的价值在于引发资源分配的讨论，而不是给出结论。
维护与研发的边界怎么划
分子范围是口径争议最集中的地方。建议先列候选清单，再对争议项逐条定规则，最后成文归档。维护类工作的常见候选范围包括：缺陷修复、线上故障处理、例行巡检与运维支持、兼容性适配（如依赖升级、浏览器或系统版本适配）、技术债偿还（重构、补测试、清理告警）。
争议项需要单独处理。紧急需求、客户定制开发、大规模重构、新功能附带的小修，这几类最容易在归类时产生分歧。一个可操作的判定规则是三条组合判断：
| 判断维度 | 计入维护的典型情形 | 不计入维护的典型情形 |
|---|---|---|
| 工作项类型 | 缺陷、故障、巡检任务、技术债任务 | 需求、用户故事、新功能任务 |
| 工作来源 | 线上问题、监控告警、既有功能适配 | 产品规划、客户新签需求 |
| 是否改变产品能力 | 恢复原有能力、保持可用性 | 新增用户可见能力 |
三条同时满足时计入维护最稳妥；只满足一两条的，按团队事先约定的优先级判定，例如“改变产品能力”优先于“工作项类型”。紧急需求若只是修复线上问题，按缺陷计入；若包含新能力交付，拆分为两个工作项分别归类。客户定制若属于既有产品的配置化交付，可计入维护支持；若形成新产品能力，计入研发。重构按目的区分：为偿还技术债、不改变外部行为的计入维护；为支撑新功能而做的架构调整，随新功能计入研发。
边界清单要成文，与口径说明放在一起维护，每次调整记录版本和生效日期。清单越具体，跨团队归类的一致性越高。
工时数据从哪里取、按什么粒度记
分子分母必须同源，否则比例失真。工时数据通常来自三个位置：工时填报系统、工作项上的工时字段、迭代或项目统计的导出报表。选定一个主数据源后，分子分母都从同一处取数，避免一边用填报数据、一边用估算数据。
填报粒度建议按人按天、挂在工作项上，最小记录单位为0.5小时或1小时，并在口径中写明舍入规则（如四舍五入到0.5小时）。粒度太粗会让归类误差放大，太细则增加填报负担。一人同时参与多个工作项时，按实际投入分摊，分摊依据写进口径，例如按当天主要工作项记全额、次要工作项记剩余工时。
跨团队协作工时要明确归属：由实际投入人填报在自己所属团队，统计时按工作项归属汇总，避免同一份工时被两个团队重复计算。缺失工时的处理也要事先约定：允许在统计周期结束后一个固定窗口内补填，逾期未填的按该人该周期日均工时估算并标记为估算值；估算占比超过一定阈值（如10%）时，该周期数据标注为不完整，不参与跨期比较。非研发人员参与维护支持的工时，若计入分母，需在口径中单列，保持各期一致。
在工具层面，ONES 支持在工作项上记录工时、按工作项类型和来源归类，并导出统计结果，适合把上述填报规则固化到流程里：工作项创建时选定类型与来源，工时随任务推进填报，统计时按同一套字段汇总分子分母。规则落在字段和流程上，比事后人工归类更稳定。
占比怎么算：公式、分母与时间窗
计算公式为：维护投入占比 = 维护类工时 ÷ 同期全部研发工时 × 100%，结果以百分比表示，保留一位小数。分子是S2判定清单内所有工作项的工时之和，分母是同一时间窗内全部研发工作类型的工时之和。
| 参数 | 定义 | 注意事项 |
|---|---|---|
| 分子 | 维护类工作项工时合计 | 按判定清单归类，含估算补填工时并标记 |
| 分母 | 同期全部研发工时 | 需列明包含的工作类型，如需求、设计、开发、测试、维护、项目管理 |
| 时间窗 | 按月、按季度或按版本周期 | 写明起止日期；跨期任务按实际填报日期切分，或按里程碑完成日归入一期 |
| 单位 | 百分比，保留一位小数 | 中间计算保留两位小数，最终结果再舍入 |
| 异常处理 | 分母为零或样本过小 | 分母为零时显示“不适用”；样本低于约定阈值（如总工时不足200小时）时标注“样本不足”，仅供参考 |
分母包含哪些工作类型，必须在口径中逐项列明。常见做法是包含需求分析、设计、开发、测试、维护、项目管理与会议等全部研发相关工时；是否包含培训、招聘、行政事务，各团队可自行约定，但一旦确定就保持稳定。时间窗建议与团队规划节奏对齐，按月统计适合观察趋势，按季度统计适合资源规划，按版本周期统计适合版本复盘。跨期任务要么按每日填报切分到各期，要么约定按完成日归入一期，两种方式选一种并写清楚。
一个可复算的例子
以下为演示情景，数字为构造值。某团队2025年第二季度（4月1日至6月30日）共8人，全部工时从同一工时系统按工作项导出，总工时合计9600小时。
归类过程：缺陷修复类工作项合计1720小时；线上故障处理合计380小时；例行巡检与运维支持合计460小时；兼容性适配合计240小时；技术债偿还合计520小时。以上五项按判定清单计入维护，分子合计3320小时。争议项处理：一个客户定制工作项共160小时，其中120小时为既有功能配置交付、40小时新增了报表能力，拆分为两个工作项后，120小时计入维护支持，40小时计入研发需求。另有一名成员在6月末有16小时未及时填报，在补填窗口内补齐，按实际值计入。
计算：维护投入占比 = 3320 ÷ 9600 × 100% ≈ 34.6%。若把客户定制的120小时也计入维护，分子为3440小时，占比约35.8%；两种结果差异来自边界判定，说明争议项必须事先定规则，否则同一份数据会算出不同结果。该季度总工时充足，不触发样本不足标注；估算补填工时占比约0.2%，数据完整性可接受。
结果怎么读，口径有哪些限制
占比高低本身不含好坏判断。34.6%的维护投入，可能对应一个稳定运行、用户量大的成熟产品，也可能对应一个缺陷频发、架构老化的系统，需要结合维护对象、缺陷来源和版本节奏一起看。如果维护工时主要集中在故障处理，说明稳定性是主要矛盾；如果集中在技术债偿还，说明团队在做长期投入；如果集中在兼容性适配，可能与外部依赖变化有关。把占比拆到这几类子项，解读才有信息量。
口径变化会导致结果不可比。调整判定清单、更换工时来源、改变分母范围或时间窗，都会让前后两期数字失去可比性。跨期比较前先核对口径版本，口径变更时在新版本生效的第一个周期同时给出新旧口径的结果，作为过渡说明。
工时填报质量直接影响结果。填报滞后、集中补填、按估算而非实际记录，都会让分子分母同时失真；小样本下波动更明显，一个月的异常故障就可能把占比推高几个百分点，建议结合多期趋势而非单期数字判断。最后，这个指标只反映投入结构，不能作为团队绩效或产出价值的全部证据，使用时与缺陷率、交付周期、可用性等指标配合，结论才站得住。
常见问题
维护投入占比和缺陷率、交付周期这些指标怎么配合使用？
维护投入占比只反映投入结构，说明资源花在哪里，无法说明做得好不好。建议与三类指标配合：缺陷率或线上故障数，判断维护投入是否对应质量问题；交付周期或需求吞吐，判断新功能投入是否被维护挤压；可用性或故障恢复时间，判断维护工作的实际效果。
配合使用时保持同一时间窗和同一团队范围，避免一个指标按月、另一个按季度，导致结论对不上。
团队中途调整了维护判定清单，历史数据还能直接比较吗？
不能直接比较。判定清单变化会改变分子范围，前后两期的占比失去可比性。处理方式有两种：一是按新口径回溯重算历史周期，前提是原始工作项类型和来源字段保留完整；二是保留旧口径结果，在新口径生效的第一个周期同时给出新旧两套数字，并注明差异来源。
无论选哪种，都要在口径说明里记录变更内容、生效日期和影响范围，后续跨期比较以同一口径版本为准。
工时填报不全时，是补填还是直接剔除缺失数据？
建议先约定补填窗口，例如统计周期结束后五个工作日内允许补填，补填工时按实际值计入并保留记录。超过窗口仍未填报的，可按该成员该周期日均工时估算，并标记为估算值。
估算占比超过约定阈值（如10%）时，该周期数据标注为不完整，只用于内部参考，不参与跨期比较和对外汇报。直接剔除缺失工时会让分母偏小、占比虚高，通常不作为首选。
按版本周期统计和按月统计，结果差异大吗？
差异可能明显。版本周期长短不一，若某版本集中安排技术债偿还，该版本占比会偏高；按月统计则把这类集中投入摊平到各月，趋势更平滑。
选择哪种时间窗取决于用途：观察长期趋势用按月或按季度，版本复盘用按版本周期。两种口径可以并存，但各自独立成系列，不混在同一张趋势图里比较。跨期任务要写明按每日填报切分还是按完成日归入一期。
非研发人员参与维护支持，工时要不要计入分母？
可以计入，但必须在口径中单列并保持各期一致。常见做法是把运维、技术支持等角色的维护支持工时计入分子，同时把其全部工作工时计入分母，保证分子分母覆盖同一批人。
如果只把支持工时计入分子、分母仍只统计研发人员工时，占比会被系统性高估。是否纳入取决于评估目标：关注研发资源占用时以研发人员为主，关注整体维护负担时可扩大到支持角色，两种范围分别命名、分别统计。
