制定资源工时工具使用规范，先回答三个问题：谁在什么节点填报、填到什么颗粒度、数据由谁核对并用于什么决策。落地时按“界定范围与口径—设计字段—划分角色—规定流程—约定数据使用与例外—试点检查”推进，产出一份规范文档、一张字段定义表和一份发布前检查清单。本文聚焦研发工作投入的记录与分析，通用工资考勤不纳入。
要点总览（TL;DR）
- 规范制定按“界定范围与口径—设计字段—划分角色—规定流程—约定数据使用与例外—试点检查”推进，每一步产出可交付物，避免写成制度宣言。
- 工时颗粒度在按天、按工作项、按天加工作项之间权衡：数据主要用于负荷概览可按天，需要分析需求投入结构则按工作项记录。
- 字段设计遵循最小够用，日期、人员、项目/工作项、工时数、活动类型为必填，备注在超长工时、跨项目支援、返工修复时要求填写。
- 填报人、项目负责人、资源管理者、数据使用方职责分离，审核聚焦工时与工作项状态一致性、单日合计异常和活动类型匹配。
- 发布前用漏填率、退回率、汇总耗时和使用方反馈做一轮试点验证，阻断项缺失时不发布。
规范先定什么：范围、对象与工时口径
规范的第一稿容易写成“加强工时管理、提升数据质量”的制度宣言，执行时却没人知道该填什么。有效的起点是把边界写清楚：这份规范约束哪些团队、哪些项目、哪类工作投入，以及工时记录到什么精度。范围与口径确定后，后面的字段、角色和流程才有共同前提。
适用对象与工作投入范围
适用对象建议按“组织单元＋项目类型＋人员身份”三个维度列清单。例如：研发中心下属产品研发团队、内部交付型项目、正式成员与连续参与两周以上的外部协作人员。清单要写明生效时间，避免历史项目被追溯要求补填。范围说明中同时标注不适用情形，如售前支持、纯行政岗位的日常事务，由对应管理制度处理。
颗粒度与计量单位的选择
工时颗粒度没有统一标准，需要在填报成本和分析价值之间权衡。常见三种选择：
| 颗粒度 | 填报方式 | 适用条件 | 主要代价 |
|---|---|---|---|
| 按天 | 每人每天一条记录，关联项目或工作项 | 团队规模小、项目数量少、主要用于负荷概览 | 难以支撑单工作项的成本与估算校准 |
| 按任务/工作项 | 每完成或推进一个工作项记录一次 | 需要按需求、缺陷、任务分析投入结构 | 工作项拆分过细时填报负担明显上升 |
| 按天＋工作项 | 每天按工作项拆分当日工时，单日合计为一天工时 | 项目复盘和估算校准要求较高，团队有一定填报习惯 | 对工作项命名和拆分规范依赖较强 |
计量单位统一用小时，并规定最小记录单位，例如0.5小时。选择理由要写进规范，便于后续修订时有据可依：如果数据主要用于资源负荷判断，按天颗粒度通常够用；如果要回答“这类需求平均投入多少”，就需要按工作项记录。
计入与不计入的活动
研发工时记录的是工作投入，需要明确哪些活动计入。建议将计入项限定为：需求分析与设计、编码与自测、测试与缺陷修复、技术评审、与项目直接相关的会议和沟通。培训、行政事务、非项目性团建原则上不计入项目工时；如果团队希望了解这些活动占用的时间，可以单设“非项目投入”类别，与项目工时分开统计，避免混入项目成本。
与工资考勤系统的边界
工时工具服务于项目投入分析和资源规划，工资考勤系统服务于出勤与薪酬核算，两者数据口径不同：前者按工作项归集，后者按出勤天数与假勤规则计算。规范中应写明工时数据不作为考勤依据，也不直接进入薪酬计算；如需核对出勤，以考勤系统记录为准。这条边界能减少填报人的顾虑，也避免两个系统之间出现口径冲突。
工时字段与数据口径怎么设计
范围确定后，把规范落到可填写的字段上。字段设计遵循“最小够用”：先保证核心字段定义一致，再按分析需要扩展。字段定义表应包含字段名、定义、取值、是否必填和填写示例五列，作为规范文档的附件发布。
核心字段清单
| 字段 | 定义 | 取值 | 必填 | 示例 |
|---|---|---|---|---|
| 日期 | 工作发生的自然日 | YYYY-MM-DD | 是 | 2025-03-11 |
| 人员 | 实际投入工作的成员 | 系统内成员账号 | 是 | 张明 |
| 项目/工作项 | 工时归属的项目与具体工作项 | 从项目工作项列表选择 | 是 | 订单中心重构 / 接口联调 |
| 工时数 | 当日在该工作项上的投入时长 | 0.5小时的整数倍，单日合计不超过标准工时 | 是 | 3.5 |
| 活动类型 | 投入所属的工作性质分类 | 枚举值，见下节 | 是 | 开发实现 |
| 备注 | 补充说明，便于审核与复盘 | 自由文本，建议不超过100字 | 否 | 联调中发现接口字段缺失，已同步后端 |
活动类型的枚举设计
活动类型决定后续分析维度，枚举值不宜过多。研发团队常用一组：需求分析、方案设计、开发实现、测试验证、缺陷修复、评审与会议、技术支持。每个枚举值配一句定义，说明边界。例如“评审与会议”限定为与项目交付直接相关的评审、站会和跨团队对齐，日常行政会议不计入。枚举值一经发布，在一个统计周期内保持稳定，新增类别需走规范修订流程，避免同一活动在不同月份被归入不同类别。
必填与选填的划分
必填字段过多会降低填报意愿，过少则数据无法使用。建议日期、人员、项目/工作项、工时数、活动类型为必填，备注为选填但在以下情形要求填写：单条工时超过6小时、跨项目支援、返工修复。选填字段的填写要求写清楚触发条件，比笼统写“建议填写”更可执行。
跨团队口径统一的做法
同一活动在不同团队容易产生不同理解，例如“测试验证”在有的团队包含用例编写，有的不包含。统一口径的做法是：为每个活动类型写一句判定规则，并配一个正例和一个反例；在规范发布时组织一次口径说明会，由各团队负责人确认本团队的归类方式；每月汇总时抽查跨团队数据，发现归类分歧在规范修订中补充说明。口径统一靠持续校准，一次发布难以覆盖所有边界情形。
角色分工与交付物：谁填、谁审、谁用
填报、审核、使用三个环节需要各有责任主体，职责分离有助于减少数据失真。角色划分不必与组织职级一一对应，关键是每个角色知道自己的交付物和时间节点。
| 角色 | 主要职责 | 交付物 | 时间节点 |
|---|---|---|---|
| 填报人 | 按实际投入记录工时，关联正确的工作项和活动类型 | 个人工时记录 | 每个工作日结束前或每周固定截止日前 |
| 项目负责人/组长 | 审核本组工时与工作项进度是否匹配，处理退回与补填 | 审核结果与退回说明 | 每周固定审核日，如每周一上午 |
| 资源管理者 | 汇总跨项目投入，识别负荷异常，维护人员与项目归属 | 周度或月度资源投入汇总 | 每周审核完成后两个工作日内 |
| 数据使用方 | 在约定用途内使用数据，反馈口径问题 | 复盘报告、估算校准记录 | 按项目里程碑或月度复盘 |
审核内容与退回处理
审核不是逐条复核数字，而是检查三类问题：工时与工作项状态是否一致，例如工作项已关闭但仍有新增工时；单日合计是否明显超出正常范围；活动类型与工作内容是否匹配。发现问题时退回填报人并写明原因，填报人在两个工作日内修正。同一记录连续两次退回的，由项目负责人与填报人当面确认口径，避免反复往返。
例外与补填路径
漏填、请假、跨项目临时支援都需要例外路径。建议规定：漏填在当周内补填，注明补填原因；超过当周的补填需项目负责人确认；集中补填超过一定条数时，资源管理者记录并在月度汇总中标注。例外路径写清楚审批人和时限，比“特殊情况另行处理”更容易执行。
填报与审核流程怎么走：从记录到汇总
流程设计要让每个关键动作有输入、做法、输出和完成标志。下面按一个周度周期描述端到端流程，团队可按自身节奏调整为双周或月度。
步骤与完成标志
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 填报 | 个人当日参与的工作项、任务进度 | 按工作项记录工时，选择活动类型，必要时填写备注 | 个人工时记录 | 本周全部工作日均有记录，单日合计符合规则 |
| 2. 提交审核 | 个人工时记录 | 在截止时间前提交，确认无遗漏工作项 | 待审核记录 | 系统状态变为待审核 |
| 3. 组长审核 | 待审核记录、工作项进度 | 检查一致性、异常值和活动类型，退回问题记录 | 审核通过或退回说明 | 本组记录全部处理完毕 |
| 4. 汇总 | 审核通过的记录 | 按项目、人员、活动类型汇总，识别负荷异常 | 周度投入汇总 | 汇总表生成并完成异常标注 |
| 5. 冻结 | 周度汇总 | 确认汇总结果，锁定当期数据 | 冻结版本 | 冻结时间点到达且无未处理退回 |
冻结后的修改规则
冻结是为了保证汇总口径稳定。冻结后如需修改，走更正流程：由项目负责人提出，说明修改原因和影响范围，资源管理者确认后修改并保留修改记录。月度复盘使用冻结版本，更正记录单独列出，避免历史数据被静默覆盖。
状态变化与交接节点
一条工时记录通常经历“草稿—待审核—已通过—已冻结”几个状态，退回则回到草稿并附原因。交接节点有两个：填报人提交后责任转移到审核人，审核通过后责任转移到汇总人。每个节点设定时限，超时未处理的记录在汇总时单独列出，作为流程改进的依据。
在工具承载上，如果团队使用 ONES，工时记录可以关联到具体工作项，审核与汇总围绕工作项状态推进。ONES 资源管理支持通过工作数量和工时规模了解成员排期，支持筛选与分组掌握成员在不同项目的投入比重，并可实时查看成员每日投入饱和明细，帮助识别规划风险；资源报表可反馈项目投入情况，工时日志支持导出，便于汇总与复盘使用。具体字段配置和审批流设置需按实际部署版本核验。
数据如何使用：汇总、复盘与例外处理
规范如果只约束填报而不说明数据去向，执行动力难以持续。数据使用规则要写清楚用途、可见范围和异常处理方式，同时明确使用边界。
三类典型用途
资源负荷判断：按周查看成员在各项目的投入比重和每日饱和情况，发现长期超负荷或投入不足时，与项目负责人确认排期调整。项目复盘：在里程碑结束时按活动类型汇总投入结构，分析需求变更、返工和评审占用的比例，形成复盘记录。估算校准：积累同类工作项的实际工时，作为后续类似任务的估算参考，校准时注明样本范围，避免用少量数据外推。
可见范围与使用权限
建议按角色设定可见范围：填报人可查看自己的记录；项目负责人可查看本项目成员记录；资源管理者可查看授权范围内的跨项目汇总；其他人员查看汇总结果需经资源管理者授权。规范中明确工时数据用于资源规划和项目分析，不作为个人绩效评价的直接依据。这条约定能降低虚报和集中补填的动机，但需要管理层在实际使用中遵守，否则规范难以维持。
异常数据的识别与处理
常见异常有三类：漏填，表现为某工作日无记录或单日合计明显偏低；明显偏差，表现为单条工时远超正常范围或活动类型与工作内容不符；集中补填，表现为截止日前大量记录集中提交。处理方式分别是：漏填由填报人当周补填并注明原因；偏差由审核人退回确认；集中补填由资源管理者记录频次，连续出现的在月度复盘中分析原因，判断是流程时点设置不合理还是填报习惯问题。
规范的评审与修订
规范建议每季度评审一次，评审输入包括：退回率、漏填率、汇总耗时、使用方反馈的口径问题。修订采用版本管理，每次修订记录变更内容和生效日期，避免不同团队执行不同版本。遇到组织调整或项目类型变化时，可提前启动专项修订。
示例：一个研发团队的工时规范落地片段
以下示例为演示情景，用于说明规范条款的写法，不代表任何真实团队的做法。示例团队为20人左右的产品研发团队，同时推进两个项目，希望用工时数据支撑资源负荷判断和季度复盘。
示例条款
“本规范适用于产品研发团队全体正式成员及连续参与两周以上的协作人员。工时按天记录并拆分到工作项，计量单位为小时，最小记录单位0.5小时。活动类型包括需求分析、方案设计、开发实现、测试验证、缺陷修复、评审与会议、技术支持七类。培训、行政事务不计入项目工时，如需统计，记入‘非项目投入’类别。工时数据用于资源负荷分析和项目复盘，不作为考勤与薪酬依据。”
一条完整的填报—审核—汇总示例
填报人张明在周三参与了“订单中心重构”项目的接口联调，当天投入3.5小时开发实现、1.5小时缺陷修复，另有2小时参加项目评审会。他在当天记录三条工时，分别关联对应工作项，活动类型选择“开发实现”“缺陷修复”“评审与会议”，备注写明联调中发现的接口字段问题。周四上午组长审核时发现缺陷修复记录关联的工作项已关闭，退回并说明原因；张明确认后改关联到新开的缺陷工作项，重新提交并通过。周一汇总时，资源管理者按项目汇总本周投入，发现张明在两个项目间的投入比重接近饱和，在周报中标注并与项目负责人确认下周排期。
示例的适用边界
该示例的颗粒度和活动类型适合项目数量有限、需要按工作项分析投入的团队。如果团队项目数量多、人员流动频繁，按天记录可能更现实；如果活动类型需要与财务成本科目对应，枚举值需重新设计。角色时间节点也需按团队例会节奏调整，例如审核日可以设在每周站会之后。
完成检查：规范可执行的自检清单
规范发布前逐项检查，确认条款可执行、口径可核对。下表列出检查项、通过标准、所需证据和阻断标记。阻断项缺失时不应发布，其余项可在试点中完善。
| 方面 | 检查项 | 通过标准 | 所需证据 | 阻断项 |
|---|---|---|---|---|
| 范围 | 适用团队、项目类型和人员清单 | 清单具体到组织单元，标注生效时间 | 范围与口径说明 | 是 |
| 范围 | 计入与不计入的活动 | 每类活动有判定规则和示例 | 活动类型定义 | 是 |
| 字段 | 核心字段定义表 | 每个字段有定义、取值、必填规则和示例 | 字段定义表 | 是 |
| 字段 | 活动类型枚举 | 枚举值数量可控，每个值有边界说明 | 枚举值清单 | 是 |
| 角色 | 角色职责与交付物 | 填报、审核、汇总、使用各有责任人和时间节点 | 角色职责对照表 | 是 |
| 流程 | 端到端步骤 | 每步有输入、动作、输出和完成标志 | 流程步骤表 | 是 |
| 流程 | 冻结与更正规则 | 冻结时点明确，更正有审批和记录 | 流程条款 | 否 |
| 数据使用 | 用途与可见范围 | 用途具体，权限按角色划分，明确非绩效依据 | 数据使用规则清单 | 是 |
| 数据使用 | 异常处理 | 漏填、偏差、集中补填各有处理方式和责任人 | 例外处理规则 | 否 |
| 修订 | 评审周期与版本管理 | 评审周期和变更记录方式已约定 | 修订条款 | 否 |
试点验证的方式与观察指标
发布前建议选择一个团队试点一个完整周期，观察四项指标：漏填率，即应填未填记录占比；退回率，即审核退回记录占提交记录的比例；汇总耗时，即从截止到生成汇总所需时间；使用方反馈，即资源管理者和项目负责人对数据可用性的评价。试点结束后根据结果调整颗粒度、截止时点或字段规则，再向其他团队推广。试点中发现的阻断项问题必须修正后才能发布，非阻断项可列入后续修订计划。
常见问题
团队项目数量多、人员流动频繁，工时颗粒度还能按工作项记录吗？
可以，但需要先降低填报负担。项目多、人员流动频繁时，按工作项记录的主要成本来自工作项拆分过细和成员不熟悉归属。可行的做法是限定记录对象：只对正式立项的工作项记录工时，临时事务归入项目下的通用类别；同时把工作项命名和拆分规则写进规范，新成员入职时做一次说明。如果试点一个周期后漏填率仍居高不下，再退回到按天记录，并把按工作项分析的需求改为抽样统计。
工时数据能不能用于个人绩效考核？
规范中建议明确工时数据用于资源规划和项目分析，不作为个人绩效评价的直接依据。工时记录反映的是投入分布，受工作项拆分方式、填报习惯和项目阶段影响，直接与绩效挂钩容易诱发虚报、集中补填或刻意选择易填的工作项。如果管理层确实需要参考投入情况，应结合交付结果、工作项完成质量等多类信息综合判断，并在使用前向团队说明口径。
审核环节发现工时与工作项状态不一致，应该改工时还是改工作项？
先判断哪一边的记录与事实不符。常见情形是工作项已关闭但成员仍在收尾，此时应重新打开工作项或新开收尾工作项，再关联工时；另一种情形是成员误选了已关闭的工作项，此时修正工时归属即可。规范中可以约定一条判定顺序：以实际工作内容为准，工作项状态服务于进度管理，工时归属服务于投入分析，两者不一致时由项目负责人确认后分别修正，并在退回说明中写清原因。
规范发布后，团队执行一段时间出现大面积漏填，怎么调整？
先看漏填集中在哪个环节。如果集中在截止日前，说明填报时点设置与团队工作节奏不匹配，可把截止时点调整到周会之后或改为每日下班前随手记录；如果集中在特定项目或成员，说明工作项归属不清或填报入口不便，需要简化工作项选择方式。调整后观察一个完整周期的漏填率，仍无改善时再考虑降低颗粒度。规范修订走版本管理，记录变更内容和生效日期，避免不同团队执行不同版本。
使用ONES承载工时填报时，规范中的字段和审批规则能直接配置吗？
ONES 资源管理支持通过工作数量和工时规模了解成员排期，支持筛选与分组掌握成员在不同项目的投入比重，可实时查看成员每日投入饱和明细，资源报表反馈项目投入情况，工时日志支持导出。规范中的字段清单、必填规则和审批流设置属于具体配置项，需按团队实际部署的版本核验后再落地，本文不对字段级配置能力作确定描述。
