研发实际投入以哪些数据来源认定

研发实际投入的认定，核心是回答“谁在什么研发任务上投入了多少时间”。可用的数据来源以工时填报记录为主，以任务与工作项状态、人员归属与排班考勤为校验，代码提交、评审测试等记录作辅助参考。本文聚焦人力投入的认定口径与数据加工方法，不展开资金成本偏差和交付达成率评估。

要点总览（TL;DR）

• 研发实际投入以工时填报记录为主数据来源，一条合格记录需包含人员、任务、日期、时长四个字段。
• 任务与工作项状态、迭代排期、人员归属与考勤请假记录用于校验工时是否合理，代码提交与评审测试记录只作旁证。
• 认定流程分五步：按人员—任务—日期归集、按费率折算人力成本、交叉核对、差异处理留痕、形成可下钻的投入台账。
• 排除非投入活动的判断规则有两条：是否直接服务于已立项研发任务、是否有对应工作项可挂靠，行政会议、培训、售前支持、招聘面试、团建应排除。
• 实际投入与计划投入的差值属于人力投入分析；资金成本偏差归项目成本与预算管理，交付达成率归研发计划达成评估，数据可复用但口径不能混用。

研发实际投入的准确定义与认定口径

研发实际投入，指在确定的统计周期内，研发人员实际用于已立项研发任务的时间，以及按约定费率折算出的人力成本。它衡量的是已经发生的人力消耗，数据基础是逐条可追溯的工时记录，而非预算数或估算数。

计量单位通常有三种：人时（1人工作1小时）、人天（1人工作1个标准工作日）、人月（1人工作1个标准工作月）。三者之间按组织约定的标准工时换算，例如1人天按8人时计、1人月按21.75人天计。换算系数一旦确定，应在同一分析周期内保持一致，否则不同月份、不同迭代的数据无法直接相加比较。

统计周期需要事先明确，常见选择有按周、按迭代、按月三种。按周适合节奏快的团队做过程跟踪；按迭代适配合敏捷研发的交付节奏；按月便于与人力成本核算对齐。无论选哪种，都要规定截止时点，例如“每周日24点前完成当周工时填报”，截止后补填的工时计入下一周期并单独标注。

认定口径可以拆成三个要素：谁投入、投入在什么任务上、投入多少。三者缺一不可，缺少人员归属就无法折算成本，缺少任务挂靠就无法判断是否属于研发活动，缺少时长记录就无法计量。

口径要素	要回答的问题	数据要求	常见问题
谁投入	投入人是否为研发人员，归属哪个团队	人员标识、组织归属、岗位或职级	跨团队借调人员归属不清
投入在什么任务上	该时段工作是否服务于已立项研发任务	任务或工作项编号、项目归属	工时不挂任务，只写“日常开发”
投入多少	实际投入的时长是多少	日期、时长、计量单位	按天粗填，无法区分半天投入

认定实际投入的数据来源分层

把可用来源分成主数据、校验数据、辅助数据三层，是为了明确每种记录在认定中的角色：主数据直接构成投入数值，校验数据用来验证主数据是否合理，辅助数据提供旁证但不直接计入。

主来源是工时填报记录。一条合格的工时记录至少包含人员、任务、日期、时长四个字段。它能直接证明“某人在某天为某任务投入了多长时间”，是形成投入台账的唯一直接依据。局限在于依赖填报人的准确性，容易出现集中补填、按整天粗填、任务挂靠随意等问题。

校验来源之一是任务与工作项状态及流转记录。工作项的创建、流转、完成时间，以及迭代或项目排期，可以验证工时是否发生在任务实际存续期间。例如某任务在周三已关闭，却出现周四的工时，就需要核实。局限是状态流转本身也可能滞后，不能反过来否定真实工时。

校验来源之二是人员组织归属、排班与考勤、请假记录。这些记录用于确认人员在岗情况：请假、调休、出差期间填报的研发工时需要重点核对；排班信息可判断某天是否属于工作日。局限是考勤只证明出勤，不证明出勤时间用于研发。

辅助来源包括代码提交、构建与发布记录、评审与测试记录。它们能佐证某段时间确有研发活动发生，适合在抽查或异常核查时使用。局限是这类记录反映产出动作，与投入时长没有稳定换算关系，不能按提交次数折算工时。

层级	数据来源	能证明什么	主要局限
主数据	工时填报记录	人员在具体任务上的实际时长	依赖填报质量，存在补填与粗填
校验数据	任务/工作项状态与流转、迭代排期	工时是否落在任务有效存续期内	状态更新可能滞后于实际工作
校验数据	组织归属、排班、考勤、请假	人员是否在岗、当天是否为工作日	出勤不等于投入研发
辅助数据	代码提交、构建发布、评审测试记录	该时段确有研发活动发生	与时长无稳定换算关系

从原始记录到投入数据的认定流程

分散的原始记录要经过归集、折算、核对、差异处理、留痕五步，才能成为可引用的实际投入数据。每一步都有明确的输入和输出，便于复核。

第一步，按人员—任务—日期归集工时明细。输入是周期内的全部工时填报记录，输出是一张明细表，每行对应一个人在一个任务上一天的有效工时。归集时先剔除明显无效记录，如未挂任务的工时、重复提交的记录。

第二步，按约定费率折算人力成本。输入是明细表和费率表，输出是带成本的投入明细。费率来源需要事先确定，常见做法是按岗位或职级设定标准人天费率，或按项目约定费率。折算规则要保留版本号，费率调整时新规则只适用于调整之后的周期，避免同一分析中前后费率混用。

第三步，与任务状态、考勤记录交叉核对。输入是投入明细、工作项流转记录、考勤与请假数据，输出是核对结果清单。核对重点包括：工时日期是否落在任务存续期内、填报人当天是否在岗、是否存在请假期间的大额工时。核对不通过的不直接删除，转入差异处理。

第四步，处理差异并留痕。输入是核对结果清单，输出是调整记录。差异处理要写明原因、调整前后数值、处理人和处理时间。常见处理方式有：补正任务挂靠、按考勤修正时长、将误挂的非研发活动移出。留痕的意义在于后续审计或口径复盘时能还原每一次改动。

第五步，形成投入台账与汇总视图。输入是调整后的明细，输出是按项目、团队、人员、周期多维汇总的投入台账。台账应保留明细到汇总的对应关系，任一汇总数字都能下钻到原始记录。

在工具承载上，ONES 资源和工时管理解决方案支持查询和导出工时登记日志明细，便于项目经理了解成员工时；并可多维度统计资源投入，查看项目和团队的资源利用率及负荷度。当工时记录与工作项在同一平台流转时，任务状态与工时明细的核对可以在同一套数据中完成，减少跨系统比对的工作量。

哪些活动不应计入研发实际投入

认定实际投入时，排除规则与计入规则同样重要。判断一项活动是否计入，可以问两个问题：它是否直接服务于已立项的研发任务？它是否有对应的工作项可以挂靠？两个问题都答“是”，才计入研发投入。

应排除的活动类型包括：

• 行政会议与内部管理事务，如部门例会、绩效沟通；
• 培训与学习活动，包括内部分享和外部课程；
• 售前支持与客户现场支持，如方案讲解、客户答疑；
• 招聘面试与候选人沟通；
• 团建、文体活动及其他非工作事务。

边界活动需要按项目口径判断。技术预研若已单独立项并有明确工作项，可作为研发投入统计；若属于个人自发探索、无立项无工作项，则不计入。缺陷修复通常属于研发活动，但客户定制化补丁、历史版本维护是否计入，取决于项目范围如何界定。返工与返修要区分原因：因需求变更导致的重做，若在原任务范围内继续投入，可计入；因质量问题产生的额外修复，建议单独标记，便于后续分析。环境维护与工具搭建，若服务于项目交付且有工作项，可计入。

误计入的典型表现有三种：一是把整天工时笼统填在“日常开发”这类虚拟任务上，无法判断活动性质；二是把会议、培训时间混入任务工时；三是把跨项目的支持时间全部记在主项目上。纠正方式是要求工时必须挂靠具体工作项，对虚拟任务设置填报限制，并在周期核对时抽查任务与工时内容是否匹配。

与计划投入、成本偏差等相关概念的区别

实际投入、计划投入、资金成本偏差、交付达成率经常出现在同一份研发分析报告中，但它们的对象和口径不同，混用会导致结论失真。

计划投入是事前确定的预算工时或排期工时，回答“打算投入多少”；实际投入是事后归集的真实工时，回答“实际投入了多少”。两者的差值构成投入偏差，属于人力投入分析范畴。

资金成本偏差关注的是预算金额与实际支出的差异，涉及采购、外包、云资源等费用科目，归项目成本与预算管理。实际投入折算出的人力成本可以作为资金分析的输入之一，但资金偏差本身不由工时数据单独认定。

交付达成率与可预测性关注的是计划交付内容与实际交付内容的匹配程度，归研发计划达成评估。它使用任务完成状态和交付结果数据，与实际投入共享同一批工作项记录，但计算口径不同。

概念	分析对象	核心口径	归属主题
实际投入	已发生的人力时间与成本	工时记录归集与折算	计划与实际投入分析
计划投入	预算或排期确定的人力	估算工时、排期工时	计划与实际投入分析
资金成本偏差	预算金额与实际支出	费用科目核算	项目成本与预算管理
交付达成率	计划交付与实际交付	工作项完成情况统计	研发计划达成与可预测性

同一批数据可以在不同分析中复用：工时明细既支撑实际投入统计，也可作为资源利用率分析的输入；工作项状态既用于交付达成率，也用于校验工时合理性。复用的前提是各自按自己的口径取数，不把一种口径的结论直接搬到另一种分析中。

一个具体例子与常见误解

假设某团队一个两周迭代内有5名研发人员，迭代计划投入为200人时。周期结束后导出工时明细共记录230人时，其中包含：行政例会12人时、内部技术分享8人时、客户现场支持10人时、挂靠在“日常开发”虚拟任务上的工时15人时。核对发现一名成员在请假当天填报了4人时，另有一笔工时挂在已关闭任务上计3人时。

认定过程如下：先剔除行政会议、技术分享、客户支持共30人时；对虚拟任务上的15人时，要求填报人补充具体工作项后重新归类，其中12人时能对应到已立项任务，3人时无法对应予以剔除；请假当天的4人时按考勤修正为0；已关闭任务上的3人时经核实属于任务关闭后补做的收尾工作，补建工作项后保留。最终实际投入为230−30−3−4=193人时，与计划200人时相比偏差7人时。整个过程每一步调整都有记录，可回溯到原始填报。

常见误解需要逐一纠正：

• 把打卡时长直接当研发投入。打卡只证明出勤，出勤时间中包含会议、沟通、休息等，必须经过工时填报和活动性质判断才能转为研发投入。
• 把代码提交量当作投入量。提交次数受提交习惯、代码拆分粒度影响，与投入时长没有稳定关系，只能作为活动发生的旁证。
• 把所有缺陷修复都算作额外投入。缺陷修复若在项目范围内且有计划工作项，属于正常研发投入；只有超出原计划的额外修复才需要单独标记分析。
• 口径中途变更导致前后不可比。费率、换算系数、排除清单一旦调整，应保留版本并注明生效周期，跨周期对比时说明口径差异，避免直接相减得出错误结论。

常见问题

工时填报粒度按天还是按任务，会影响实际投入的认定结果吗？

会影响。按天粗填只能得到某人某天在岗投入的总时长，无法区分同一天在多个任务之间的分配，遇到跨项目支持时容易把时间全部记在主项目上。按任务填报能保留“人员—任务—日期—时长”的对应关系，后续与工作项状态核对时也有据可查。

如果团队习惯按天填报，可以要求每条记录必须挂靠具体工作项，并对“日常开发”这类虚拟任务设置填报限制，减少无法判断活动性质的记录。

请假、出差或调休期间出现的工时记录应该怎么处理？

这类记录不直接删除，先转入差异处理。核对时以考勤和请假记录为准，请假当天的工时按实际情况修正，出差期间如确有研发工作发生，需补充说明并保留对应工作项。每一次调整都要写明原因、调整前后数值、处理人和处理时间，便于后续复盘。

技术预研、缺陷修复这类边界活动，计入与不计入的界线在哪里？

界线是两条：是否直接服务于已立项的研发任务，是否有对应工作项可以挂靠。技术预研已单独立项并有明确工作项，可作为研发投入统计；个人自发探索、无立项无工作项的不计入。缺陷修复在项目范围内且有计划工作项，属于正常研发投入；超出原计划的额外修复建议单独标记，便于后续分析，但不改变其研发活动的性质。

费率或换算系数中途调整后，前后周期的投入数据还能直接比较吗？

不能直接相减比较。费率、人天与人时换算系数、排除清单一旦调整，应保留规则版本并注明生效周期，新规则只适用于调整之后的周期。跨周期对比时说明口径差异，或按同一版本规则重新折算后再比较，避免得出错误结论。

工时记录与工作项在同一平台流转，对认定实际投入有什么实际帮助？

主要减少跨系统比对的工作量。工时明细与工作项状态在同一套数据中，核对工时是否落在任务存续期内可以直接关联查询，不必先导出再人工匹配。ONES 资源和工时管理解决方案支持查询和导出工时登记日志明细，并可多维度统计资源投入，查看项目和团队的资源利用率及负荷度，适合把归集、核对与汇总放在同一处完成。