工时表模板的核心字段可以归纳为“日期+人员+项目/任务+工时数+工作说明”，再加填报人、审核人、审核状态三个控制字段，就能覆盖投入记录与审核闭环。本文提供可直接复制的空白明细表和周汇总表、逐字段填写口径、必填与选填划分、一份完整的一周填写示例，以及团队变化后调整模板的方法。工时成本计量与考勤工资计算不在本文范围内。
要点总览（TL;DR）
- 工时表模板以“日期+填报人+项目+任务/工作项+工时数+工作说明”为核心字段，配合审核人、审核状态、提交时间三个控制字段，即可覆盖投入记录与审核闭环。
- 必填字段建议为日期、填报人、项目、工时数、工作说明和审核状态；任务/工作项、审核人、提交时间可按团队管理要求转为必填。
- 填写示例覆盖跨项目分行记录、审核退回后修改重提两种情形，周汇总表只统计“已通过”记录。
- 模板调整应有触发条件和版本记录，从表格迁移到系统填报时按字段一一对应，并保留一段双轨核对期。
可复制空白工时表模板
下面两张表可以直接复制到 Excel、飞书表格、腾讯文档或钉钉文档中使用。明细表按“一人一天一条工作记录”组织，周汇总表按“一人一周一行”汇总，两张表的字段名称与后文说明完全一致，复制后不需要再改表头。
表一：工时明细表（空白）
| 日期 | 填报人 | 项目 | 任务/工作项 | 工时数（小时） | 工作说明 | 审核人 | 审核状态 | 提交时间 |
|---|---|---|---|---|---|---|---|---|
表二：周汇总表（空白）
| 周次 | 填报人 | 项目 | 本周工时合计（小时） | 涉及任务数 | 审核状态 | 审核人 |
|---|---|---|---|---|---|---|
使用方式：明细表逐条记录每天的实际投入，周汇总表用求和公式从明细表取数，不手工二次录入。周汇总表的“项目”列按项目分行，一个人一周跨两个项目就占两行，这样汇总结果与明细能逐项对上。
工时表字段说明：每个字段填什么、怎么填
字段设计围绕两个目的：一是让每条记录能还原“谁在什么时间为哪个项目做了什么、花了多久”，二是让审核人能在不追问的情况下判断这条记录是否合理。下表逐字段说明含义与填写口径。
| 字段 | 含义 | 填写口径与常见写法 |
|---|---|---|
| 日期 | 该条工时实际发生的自然日 | 统一格式如 2025-03-10；补填时仍写实际发生日，不写补填当天 |
| 填报人 | 实际投入工时的人 | 写姓名或工号，全表统一一种写法；代填时仍写实际执行人 |
| 项目 | 工时归属的项目 | 使用项目正式名称或项目编号，避免简称混用；非项目工作可填“内部事务”“运维支持”等固定类别 |
| 任务/工作项 | 项目内具体的工作条目 | 与任务管理系统中的名称保持一致；没有任务编号时写清具体事项，如“登录页接口联调” |
| 工时数（小时） | 该条记录投入的时长 | 统一以小时为单位，最小粒度建议 0.5 小时，全天合计不超过 8 小时（或团队约定的标准工时） |
| 工作说明 | 这段时间做了什么、到什么程度 | 写到能判断产出或进展的颗粒度，如“完成登录接口联调并修复 2 个字段校验问题”，避免只写“开发”“沟通” |
| 审核人 | 负责确认这条工时的人 | 一般为项目经理或任务负责人；同一项目固定同一审核人，避免多头审核 |
| 审核状态 | 记录当前所处的审核环节 | 统一使用“待提交 / 待审核 / 已通过 / 已退回”四种状态，不自行增加同义状态 |
| 提交时间 | 填报人完成提交的时间 | 精确到日期即可；退回后重新提交时更新为最新提交时间，便于判断是否超期 |
工时数的计量单位与最小粒度需要在模板启用前一次性约定。常见做法是以小时为单位、以 0.5 小时为最小粒度，原因是半天以内的投入差异对项目判断影响有限，粒度过细反而增加填报负担。团队若按人天结算外包，也可以改用 0.5 天为粒度，但同一张表内只保留一种单位，不混用小时和天。
工作说明的颗粒度可以用一个简单标准检验：审核人读完这条说明，能否判断这项工作是否按计划推进、是否需要介入。写“需求评审”只能看出动作，写“完成订单模块需求评审，输出 6 条待确认问题并同步给产品”就能支撑判断。说明控制在 30 字左右即可，不需要写成日报。
哪些字段必填、哪些可以选填
必填字段的作用是保证记录可追溯、可审核；选填字段的作用是补充信息，不填也不影响审核闭环。把两者分开，可以避免模板一开始就过重，导致填报人敷衍填写。
| 字段 | 建议属性 | 理由与适用场景 |
|---|---|---|
| 日期 | 必填 | 没有日期无法判断工时归属周期，也无法核对是否漏填 |
| 填报人 | 必填 | 审核与汇总都以此字段为索引 |
| 项目 | 必填 | 项目是投入统计的基本维度；纯内部事务填固定类别 |
| 工时数 | 必填 | 模板的核心数据，缺失则记录无意义 |
| 工作说明 | 必填 | 审核人判断合理性的主要依据，建议保留为必填 |
| 审核状态 | 必填 | 控制字段，决定记录是否进入汇总 |
| 任务/工作项 | 选填（可转必填） | 团队已有任务管理系统、需要按任务核算投入时转为必填；仅按项目统计时可选填 |
| 审核人 | 选填（可转必填） | 项目固定单一审核人时可由模板预设默认值；多人轮值审核时需逐条填写 |
| 提交时间 | 选填（可转必填） | 需要考核填报及时性、或按截止时间催办时转为必填 |
判断某个选填字段是否转为必填，可以看两个条件：这个字段是否会被用于汇总或对外汇报；缺失它是否会导致审核人必须回头追问。两个条件满足其一，就值得转为必填。团队规模在十人以内、项目数量少时，保留“项目+工时数+工作说明”即可运转；人数增加、跨项目投入变多后，任务/工作项和提交时间通常会先转为必填，因为此时按任务核对投入和按周催报都成为常态。
填写示例：一份完整的一周工时表
以下为演示数据，用于说明字段如何协同，不代表任何真实客户记录。示例中的填报人“李明”是后端开发，本周同时投入“订单系统重构”和“客户门户改版”两个项目，其中周三的一条记录曾被退回。
| 日期 | 填报人 | 项目 | 任务/工作项 | 工时数（小时） | 工作说明 | 审核人 | 审核状态 | 提交时间 |
|---|---|---|---|---|---|---|---|---|
| 2025-03-10 | 李明 | 订单系统重构 | 订单查询接口改造 | 6 | 完成查询接口拆分，补充分页参数校验，自测通过 | 王芳 | 已通过 | 2025-03-10 |
| 2025-03-10 | 李明 | 客户门户改版 | 门户登录联调 | 2 | 与前端联调登录接口，修复 2 个字段校验问题 | 张涛 | 已通过 | 2025-03-10 |
| 2025-03-11 | 李明 | 订单系统重构 | 订单查询接口改造 | 7 | 完成接口性能优化，压测响应时间从 800ms 降至 300ms | 王芳 | 已通过 | 2025-03-11 |
| 2025-03-12 | 李明 | 订单系统重构 | 订单状态机梳理 | 4 | 梳理订单状态流转，输出状态机文档初稿 | 王芳 | 已退回 | 2025-03-12 |
| 2025-03-12 | 李明 | 客户门户改版 | 门户登录联调 | 3 | 补充登录失败提示文案，与产品确认交互细节 | 张涛 | 已通过 | 2025-03-12 |
| 2025-03-13 | 李明 | 订单系统重构 | 订单状态机梳理 | 5 | 补充状态机文档中的异常分支，完成评审并记录 3 条修改意见 | 王芳 | 已通过 | 2025-03-13 |
| 2025-03-14 | 李明 | 订单系统重构 | 订单查询接口改造 | 6 | 按评审意见调整接口返回结构，更新接口文档 | 王芳 | 已通过 | 2025-03-14 |
逐项说明几个关键点。跨项目分摊通过分行实现：3 月 10 日李明在两个项目各有一条记录，合计 8 小时，两个项目分别由王芳和张涛审核，互不影响。审核退回发生在 3 月 12 日的第一条记录，退回原因通常是工作说明不足以判断进展；修改后该条记录在 3 月 13 日重新提交，工作说明补充了异常分支和评审结果，状态变为“已通过”，提交时间同步更新为 2025-03-13。原 3 月 12 日的记录保留在表中，便于追溯退回历史。
对应的周汇总表如下，按项目分行，数据由明细表求和得到：
| 周次 | 填报人 | 项目 | 本周工时合计（小时） | 涉及任务数 | 审核状态 | 审核人 |
|---|---|---|---|---|---|---|
| 2025 年第 11 周 | 李明 | 订单系统重构 | 28 | 3 | 已通过 | 王芳 |
| 2025 年第 11 周 | 李明 | 客户门户改版 | 5 | 1 | 已通过 | 张涛 |
汇总时只统计“已通过”的记录，处于“待审核”或“已退回”的工时不进入合计，避免审核未完成的数据提前进入项目统计。这条规则建议写进模板说明，而不是靠汇总人自行判断。
模板的调整与维护方法
模板不是一次定稿就长期不变。团队项目数量、人员规模、审核要求变化后，字段需要跟着调整，但每次调整都应有触发条件和记录，避免不同版本的表单同时在团队里流转。
常见增删字段及触发条件
| 调整动作 | 触发条件 | 处理建议 |
|---|---|---|
| 新增“任务/工作项”为必填 | 需要按任务核算投入，或任务系统已全面使用 | 先并行运行两周，确认任务名称口径统一后再转必填 |
| 新增“工时类别”字段 | 需要区分需求、缺陷、支持等投入类型 | 类别控制在 5 个以内，避免填报人反复纠结归类 |
| 新增“成本中心”字段 | 涉及跨部门结算或外包结算 | 属于成本核算范畴，建议单独建表，不混入基础工时表 |
| 删除“提交时间” | 不考核填报及时性，且无催报需求 | 删除前确认历史数据已归档 |
| 拆分“工作说明”为“工作内容+产出” | 审核人普遍反馈说明过于笼统 | 拆分后需同步更新填写示例，否则填报人仍按旧习惯填写 |
模板版本与变更记录
每次调整字段都应在表格底部或单独的说明页记录版本号、变更内容、生效日期和调整原因。版本号建议用“v1.0、v1.1”这类简单编号，字段增删升小版本，结构大改升大版本。变更生效后，旧版本表格只保留只读归档，不再接受新填报，防止同一周出现两种口径的数据。
从表格工时表过渡到系统填报
当团队人数增加、项目并行变多，表格在汇总、退回通知和权限控制上的成本会明显上升。此时可以把表格字段对应到系统记录中：日期对应工时登记日期，填报人对应成员，项目与任务/工作项对应系统中的项目和工作项，工时数对应登记时长，工作说明对应备注，审核人与审核状态对应审批环节。ONES 资源和工时管理解决方案支持查询和导出工时登记日志明细，项目经理可以据此了解成员工时，并查看项目和团队的资源利用率与负荷度；跨项目投入较多时，也可以借助其跨项目资源规划视图查看成员在各项目上的分布。迁移时建议先保留一个月的表格与系统双轨记录，核对两边汇总结果一致后再停用表格。
维护责任人与复核节奏
模板维护建议指定一个明确责任人，通常由项目管理办公室或项目管理部门成员担任，负责接收字段调整需求、发布新版本和更新填写示例。复核节奏可以按季度进行一次：检查退回率是否异常升高、是否存在大量记录集中在周末补填、汇总表与明细表是否对得上。退回率持续偏高往往说明工作说明的填写要求不够清楚，此时优先修订示例，而不是增加字段。
常见问题
工时数的最小粒度应该定多少？团队里有人按小时填、有人按天填怎么办？
最小粒度没有统一标准，由团队在启用模板前约定并写入模板说明。常见做法是以小时为单位、以 0.5 小时为最小粒度，适合大多数研发与项目团队；按人天结算外包的团队可以改用 0.5 天为粒度。关键是同一张表内只保留一种单位，不混用小时和天。如果已经出现混填，建议在模板中增加“单位”列或统一换算规则，并在下一次填报周期开始前通知全员，避免汇总时反复换算。
审核人退回一条工时记录后，填报人应该修改原记录还是新增一条？
建议修改原记录并重新提交，同时更新提交时间，保留退回状态的历史痕迹。这样同一条工作投入只有一条有效记录，汇总时不会重复计算。如果团队使用的表格工具不支持状态历史，可以在工作说明中注明“原记录于某日退回，本次修改内容为……”，便于事后追溯。新增一条记录的做法容易导致同一笔投入出现两条数据，汇总时需要人工去重，不建议采用。
团队从表格工时表迁移到系统填报时，最容易被忽略的字段对应关系是什么？
容易被忽略的是“审核状态”和“提交时间”这两个控制字段。表格里它们只是列，迁移到系统后对应的是审批环节和流程时间戳，需要确认系统里的状态名称与表格中的“待提交 / 待审核 / 已通过 / 已退回”能一一对应，否则历史数据导入后无法按状态筛选。另一个容易忽略的是“任务/工作项”与系统中工作项的关联方式：表格里是自由文本，系统里通常需要选择已有工作项，迁移前应先统一任务名称口径。ONES 资源和工时管理解决方案支持查询和导出工时登记日志明细，迁移时可用来核对两边汇总结果。
周汇总表只统计“已通过”的工时，那“待审核”的工时在项目周报里怎么处理？
建议在周报中把“已通过工时”和“待审核工时”分列展示，而不是合并成一个数字。已通过工时用于正式的项目投入统计和对外汇报；待审核工时单独列出，提示这部分数据尚未完成审核，后续可能调整。这样既不会让未审核数据提前进入正式统计，也能让项目经理看到本周实际投入的全貌。如果团队审核周期较长，可以在周报中注明待审核工时的预计确认时间，避免读者误读。
模板维护责任人应该由谁担任？多久复核一次比较合适？
维护责任人通常由项目管理办公室或项目管理部门成员担任，负责接收字段调整需求、发布新版本和更新填写示例。复核节奏可以按季度进行一次，重点检查退回率是否异常升高、是否存在大量记录集中在周末补填、汇总表与明细表是否对得上。退回率持续偏高往往说明工作说明的填写要求不够清楚，此时优先修订示例和填写说明，而不是增加字段。团队规模较小、项目数量稳定时，也可以按半年复核一次。
