研发实际投入统计口径要解决的是“计划投入和实际投入能不能对得上”的问题。基本口径可以定为：可归属到研发工作项、由研发角色在统计周期内真实发生的人力工时。数据以任务或工时系统中已提交的工时记录为主，考勤、排期和迭代记录用于校验；计入范围限定在需求分析、设计、编码、测试、缺陷修复、技术评审等直接研发活动，会议、培训、行政、售前支持和运维值守按规则单列或剔除。口径确定后，统计对象、时间窗、工时单位、折算方式和缺失值处理都要固定下来，发布前再做抽样复核。
要点总览（TL;DR）
- 研发实际投入的基本口径是：可归属到研发工作项、由研发角色在统计周期内真实发生的人力工时，资金偏差和交付达成率不在这个口径内。
- 数据以任务或工时系统中已提交的工时记录为主，考勤、排期和迭代记录用于校验；每条记录至少要有人员、工作项、日期、工时数和活动类型五个字段。
- 需求分析、设计、编码、测试、缺陷修复、技术评审计入主口径；会议、培训、行政、售前支持、运维值守单列或剔除，并在口径文档中逐项写明。
- 计算按“实际投入=Σ有效工时（按活动类型过滤后）”执行，人天折算需固定每日标准工时，分母为零或样本不足时单独标注。
- 发布前抽样复核不少于10%的工时记录并覆盖所有团队，口径变更时保留可比性处理记录。
评估目标：实际投入口径要回答什么问题
这套口径首先服务于计划与实际的对比：某个项目、团队或迭代在统计周期内计划投入多少人天，实际发生了多少人天，差异集中在哪些活动类型上。其次是资源投入结构复盘：人力主要落在新功能开发、缺陷修复还是技术评审，哪些环节占用了超出预期的工时。口径稳定后，这些对比才能跨周期进行，管理者看到的是趋势而不是某一次统计的偶然结果。
需要明确的是，本文讨论的是人力工时口径。项目资金偏差、预算执行率、交付达成率和需求吞吐量属于另外的度量体系，不在实际投入口径内计算。把资金数据和工时数据混在同一张表里做“总投入”对比，容易让读者误以为两者可以直接相加，实际口径应当分开定义、分开呈现。
口径可比对有三个基本要求：统计对象固定（按人、按团队还是按工作项归集）、时间窗固定（自然月、迭代周期还是项目阶段）、单位固定（人时或人天，以及每日标准工时）。三项中任何一项在两次统计之间发生变化，结果就不宜直接比较，需要在报告中注明。
指标与范围：哪些活动算研发投入
计入范围应围绕直接推进研发交付的活动展开。需求分析与澄清、方案设计、编码实现、测试执行、缺陷修复、技术评审、代码审查、必要的联调与环境适配，这些活动产出的结果直接进入研发工作项，属于实际投入。判断一条工时是否计入，可以问两个问题：它是否挂在一个研发工作项上；它是否由承担研发职责的角色完成。两个条件同时满足，才进入主口径。
会议、培训、行政事务、售前支持、运维值守、招聘面试等活动，建议单列而不是直接混入。单列的价值在于保留信息：团队确实花了时间，但这些时间不构成对研发工作项的投入。如果组织希望观察“研发人员总负荷”，可以把单列项作为附加视图；如果只做计划与实际对比，则从主口径中剔除。无论选择哪种处理，都要在口径文档中逐项写明，避免不同项目各自解释。
| 活动类型 | 处理方式 | 说明 |
|---|---|---|
| 需求分析、方案设计 | 计入 | 需关联到具体需求或设计工作项 |
| 编码、单元测试、联调 | 计入 | 按开发任务归集 |
| 测试执行、缺陷修复 | 计入 | 缺陷修复需关联缺陷工作项 |
| 技术评审、代码审查 | 计入 | 作为独立活动类型记录，便于分析评审占比 |
| 会议、培训 | 单列 | 保留记录，不进入主口径 |
| 行政事务、招聘面试 | 单列或剔除 | 按组织管理需要选择 |
| 售前支持、运维值守 | 单列 | 与研发交付无直接工作项归属关系 |
统计对象建议至少保留三个维度：人员、团队、项目或工作项。人员维度用于核对填报完整性，团队维度用于资源结构分析，项目或工作项维度用于计划与实际对比。角色范围要写清楚，例如是否包含测试工程师、产品经理、技术经理的投入；如果包含，需在活动分类中为他们的工作找到对应类型，避免出现“角色在范围内但活动无处归类”的情况。时间窗通常取自然月或迭代周期，工时单位统一为人时，展示时再折算为人天。
数据口径与证据：工时从哪来、怎么校验
主数据源应选择任务或工时系统中已提交的工时记录。相比事后回忆或表格汇总，系统记录带有时间戳、人员、工作项和活动类型，可追溯性更强。每条记录至少需要五个字段：人员标识、关联工作项、发生日期、工时数、活动类型。缺少活动类型的记录无法参与计入过滤，应退回补充或按预设规则归入“未分类”并单独统计。
辅助校验源包括考勤数据、排期计划和迭代记录。考勤用于核对统计周期内可工作天数与工时总量是否匹配；排期和迭代记录用于核对某条工时是否落在对应工作项的计划区间内。校验的目的在于发现异常，例如同一人同一天工时明显超过合理上限、工时集中填在周期最后一天、工作项已关闭后仍有大量工时登记。发现异常时按预设规则处理：先退回确认，确认后保留并标注，无法确认的进入缺失值清单，不直接按零计入。
缺失值处理要在口径中提前约定。常见做法是：未提交工时的记录不计入实际投入，但在报告中披露缺失人数和缺失比例；缺失比例超过约定阈值时，该周期结果标注为“不完整”，不参与跨周期趋势判断。异常值的处理同理，保留原始记录、标注处理方式，保证任何人按同一规则都能复算出相同结果。
在工具承载层面，ONES 资源和工时管理解决方案支持多维度统计资源投入，便于按项目和成员查看投入情况；支持查询和导出工时登记日志明细，项目经理可以据此核对成员工时记录；同时支持查看项目和团队的资源利用率及负荷度并统计项目工时。这些能力对应的是工时记录的归集、查询与导出环节，活动类型的划分和计入规则仍需在口径文档中定义清楚，再落到具体字段和统计视图中。
计算与评估步骤：从原始记录到实际投入
计算从原始工时记录开始，按以下步骤执行，每一步都留下可核对的中间结果。
- 导出统计周期内的全部工时记录，保留人员、工作项、日期、工时数、活动类型、提交状态字段。
- 过滤提交状态，只保留已提交记录；草稿或撤回记录不进入计算，单独计数备查。
- 按活动类型归类，将记录标记为“计入”“单列”“剔除”三类，归类规则来自第二节的对照表。
- 核对工作项归属，剔除无法关联到研发工作项的记录，或将其转入单列类别。
- 对计入记录求和，得到实际投入工时。
- 按固定标准工时折算人天，并汇总到人员、团队、项目三个维度。
汇总公式为：实际投入 = Σ有效工时（按活动类型过滤后）。人天折算公式为：人天 = 人时 ÷ 每日标准工时。每日标准工时需要在口径中固定，例如按 8 小时计，全组织统一使用同一数值，不因团队或个人调整。折算只改变展示单位，不改变原始工时记录。
分母处理需要单独说明。做人均投入或投入占比分析时，分母可能是统计人数、计划工时或总工时。分母为零的情形包括：统计周期内团队无在岗人员、计划工时未录入、某活动类型无任何记录。此时结果不应显示为 0%，而应标注“无有效分母”并跳过该计算。样本不足时，例如某团队只有一人填报，人均值参考意义有限，应在报告中注明样本量，避免读者把个别数据当作团队整体水平。
发布前抽样复核建议覆盖不少于 10% 的工时记录，且覆盖所有团队。复核内容包括：记录是否关联正确工作项、活动类型是否与工作内容一致、工时数与考勤和排期是否大体吻合。通过标准可设为抽样记录中错误记录占比低于约定阈值；超过阈值则退回修正后重新统计，而不是带着已知偏差发布结果。
例子：一个迭代周期的实际投入计算
以下为演示情景，数据为设定值，用于说明口径如何落地。某 6 人研发小组，迭代周期两周，每日标准工时按 8 小时计。周期内工时系统共导出 240 条记录，合计 960 人时。按活动类型分布如下：需求分析与设计 120 人时，编码与联调 380 人时，测试执行 160 人时，缺陷修复 100 人时，技术评审 60 人时，会议与培训 90 人时，售前支持 50 人时。
| 活动类型 | 工时（人时） | 处理 | 计入实际投入 |
|---|---|---|---|
| 需求分析与设计 | 120 | 计入 | 120 |
| 编码与联调 | 380 | 计入 | 380 |
| 测试执行 | 160 | 计入 | 160 |
| 缺陷修复 | 100 | 计入 | 100 |
| 技术评审 | 60 | 计入 | 60 |
| 会议与培训 | 90 | 单列 | 0 |
| 售前支持 | 50 | 单列 | 0 |
| 合计 | 960 | — | 820 |
按口径过滤后，实际投入为 820 人时，折算 102.5 人天。若直接使用全部 960 人时，会多计 140 人时，折算多出 17.5 人天，相当于把会议、培训和售前支持算成了研发交付投入。这个差异在计划与实际对比中会直接表现为“实际超出计划”，但超出的部分并不来自研发活动本身。
常见误算点有三个：一是把已关闭工作项上的后续工时继续计入，导致同一工作项投入被重复统计；二是把跨周期填写的工时全部记在填写日期，而不是按实际发生日期归属；三是把单列活动直接删除，导致总负荷视图缺失。前两个问题影响计入准确性，第三个问题影响解读完整性。示例中 820 人时是主口径结果，960 人时可以作为总负荷参考值，两者并列呈现比只保留一个数字更有解释力。
解读与限制：口径的边界与误用风险
跨团队或跨项目比较前，先确认三件事：活动分类规则一致、每日标准工时一致、统计时间窗一致。三个条件中有一个不同，比较结果就可能来自口径差异而非真实投入差异。例如一个团队把技术评审计入研发投入，另一个团队将其归入单列，两个团队的“实际投入”就不在同一基准上。比较时应同时展示计入项构成，帮助读者判断差异来源。
工时填报质量直接决定结果可信度。集中补填、按经验估算、活动类型随手选择，都会让统计结果偏离实际。口径能规定规则和校验方式，但无法替代日常填报习惯。建议把工时提交纳入迭代收尾动作，在迭代结束前完成核对，减少事后补填带来的偏差。
实际投入是投入侧的度量，反映的是人力去了哪里，不能单独代表产出、质量或绩效。投入高可能意味着任务复杂，也可能意味着返工多或估算偏差大；投入低同样有多种解释。把实际投入与计划投入、交付结果、缺陷数据结合看，才能形成有意义的判断。用单指标做团队排名或绩效评价，容易诱导填报行为变形，反而破坏数据质量。
口径变更时要保留可比性处理记录。例如调整了活动分类或标准工时，应在变更说明中写明生效周期，并对变更前后的统计结果做衔接说明，必要时按新规则重算历史数据的一个对照周期。这样跨周期趋势才不会在变更点出现无法解释的跳变。
常见问题
工时记录缺少活动类型字段时，还能按这套口径统计吗？
可以统计，但需要先补一个处理规则。缺少活动类型的记录无法参与计入过滤，建议在口径中约定：这类记录退回补充；确实无法补充的，归入“未分类”单独统计，并在报告中披露未分类工时占比。未分类占比过高时，该周期的实际投入结果应标注为不完整，不直接用于跨周期趋势判断。
研发人员参与售前支持或线上运维，这部分时间要不要算进实际投入？
按本文口径，售前支持和运维值守属于单列活动，不进入研发实际投入主口径。原因是这些时间没有归属到研发交付工作项上，计入后会让计划与实际对比失真。如果组织需要观察研发人员的总负荷，可以把单列项作为附加视图与主口径并列呈现，两个数字分开解释，避免混为一个“总投入”。
团队刚开始推行工时填报，数据质量不高，口径还能用吗？
可以使用，但要把数据质量作为结果的一部分披露。建议先做两件事：一是把工时提交纳入迭代收尾动作，在迭代结束前完成核对，减少集中补填；二是在报告中注明缺失人数、缺失比例和抽样复核的错误占比。缺失比例超过约定阈值时，该周期结果标注为不完整。口径本身能规定规则和校验方式，填报习惯仍需在日常流程中逐步建立。
调整了活动分类或每日标准工时，历史数据还能直接比较吗？
不宜直接比较。口径变更后应在变更说明中写清生效周期，并对变更前后的结果做衔接说明；必要时按新规则重算一个对照周期的历史数据，让趋势线在变更点有可解释的过渡。跨团队比较同样要先确认活动分类、标准工时和统计时间窗三项一致，否则差异可能来自口径而不是真实投入。
实际投入数据能不能直接用于团队绩效评价？
不建议单独使用。实际投入反映的是人力去了哪里，投入高可能是任务复杂，也可能是返工多或估算偏差大，投入低同样有多种解释。把实际投入与计划投入、交付结果、缺陷数据结合看，才能形成有意义的判断。用单指标做团队排名，容易诱导填报行为变形，反而破坏后续数据的可信度。
