设计计划实际工时对比表，核心是三件事：先确定对比口径，再固定字段和计算规则，最后把填写、确认和复核串成固定流程。本文按“口径—字段—流程—角色—示例—检查”的顺序，给出一张可直接套用的表格结构，适用于按人力投入差异做过程跟踪的团队。
要点总览（TL;DR）
- 先定口径再建表：按任务明细、按周期汇总最通用，同一张表内不混用按人和按任务两种行单位。
- 字段分三类：工作项、负责人、统计周期、计划工时、实际工时必填；偏差和偏差率用公式计算；数据来源、原因标签、备注用于说明。
- 偏差取实际减计划，正数超支、负数结余；偏差率按偏差除以计划工时计算，计划为零时只填绝对值。
- 流程固定为冻结计划基线、按周期采集实际工时、计算偏差并标注原因、负责人确认、项目经理复核，每步有完成标志。
- 交付前按字段完整性、口径一致性、异常行复核、变更留痕、数据可回溯逐项检查，定稿后归档只读版本。
对比表先定口径：按人、按任务还是按周期
口径决定表格的行是什么、汇总给谁看。同一张表里混用口径，最常见的结果是行数膨胀、合计对不上、偏差无法归因。设计前先回答一个问题：这张表主要用来回答“谁投入多了”“哪项任务超了”还是“这个周期整体偏差多少”。
| 口径 | 行的单位 | 适合回答的问题 | 选择条件 |
|---|---|---|---|
| 按任务 | 一个工作项一行 | 哪项任务超支、偏差集中在哪些类型的工作 | 任务颗粒度稳定、计划工时能落到单项任务 |
| 按人 | 一个人一行（或人×任务一行） | 成员负荷是否均衡、谁的实际投入偏离计划 | 需要做资源调配或负荷分析 |
| 按周期 | 一个统计周期（周或迭代）一行 | 整体偏差趋势、本期与上期比较 | 需要按节奏复盘、向管理层汇报 |
实践中常用组合是“按任务明细、按周期汇总”：明细表以工作项为行，增加统计周期列，汇总时按周期或按人透视。这样一张明细表可以支撑三种视角，前提是每行只归属一个周期、一个负责人，不在一行里塞多个任务。
需要避免的混用包括：同一列既填任务又填人名；汇总行与明细行放在同一张表里参与计算；按周统计的表里出现跨周未拆分的任务。出现这些情况时，先拆行再汇总，不要用合并单元格或手工调整合计来掩盖。
表格字段怎么设：必填列、计算列与说明列
字段按三类组织：必填列保证每行可追溯，计算列由公式生成避免手工误差，说明列承载原因和上下文。以下清单可直接作为建表模板。
| 字段名 | 类型 | 是否必填 | 填写说明 |
|---|---|---|---|
| 工作项编号 | 文本 | 必填 | 与任务系统中的编号一致，作为唯一标识 |
| 工作项名称 | 文本 | 必填 | 简短描述，便于阅读，不替代编号 |
| 负责人 | 文本/人员 | 必填 | 填实际执行人，一人一行；多人协作时拆分或指定主责 |
| 统计周期 | 文本/日期 | 必填 | 统一格式，如“2024-W23”或迭代名称，全表一致 |
| 计划工时 | 数值（小时） | 必填 | 来自冻结后的计划基线，单位统一为小时 |
| 实际工时 | 数值（小时） | 必填 | 来自工时登记记录，按周期汇总后填入 |
| 偏差 | 计算（小时） | 自动 | 实际工时减计划工时，正数为超支，负数为结余 |
| 偏差率 | 计算（百分比） | 自动 | 偏差除以计划工时；计划工时为0时留空，只保留绝对值 |
| 数据来源 | 文本 | 必填 | 注明工时记录出处，如工时日志导出、周报登记 |
| 原因标签 | 枚举 | 偏差超阈值时必填 | 从固定标签中选择，如需求变更、估算偏差、返工、协作等待、资源调配 |
| 备注 | 文本 | 选填 | 补充说明，不替代原因标签 |
计算规则要写进表头说明或单独的规则页：偏差 = 实际工时 − 计划工时；偏差率 = 偏差 ÷ 计划工时 × 100%。偏差率保留一位小数即可，过度精确会让人误以为数据精度很高。计划工时为0的行不计算偏差率，避免除零错误，也避免把“未估算”误读为“无限超支”。
字段命名保持稳定，一旦发布不再随意改名，否则历史数据透视会断裂。原因标签使用下拉选项而非自由文本，保证后续能按标签汇总。备注列允许自由填写，但要求写事实，例如“需求在第二周追加两个页面”，不写“沟通不畅”这类无法核对的判断。
填写与更新流程：从计划基线到偏差确认
表格的价值来自固定节奏，而不是一次性填完。以下流程以“每个统计周期更新一次”为例，周期可以是周，也可以是迭代，团队自行约定后保持一致。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 冻结计划基线 | 已确认的任务清单与估算工时 | 在周期开始前锁定计划工时，记录冻结日期；后续变更单独登记 | 基线版本的计划工时列 | 基线日期已填写，变更记录为空或已登记 |
| 2. 采集实际工时 | 成员工时登记记录 | 按周期导出或汇总每人每任务的工时，核对是否有漏填 | 实际工时列 | 所有在途任务均有实际工时，无空白行 |
| 3. 计算偏差并标注原因 | 计划工时、实际工时 | 用公式生成偏差与偏差率；对超过阈值的行选择原因标签 | 偏差列、偏差率列、原因标签列 | 异常行均有原因标签，无自由文本替代 |
| 4. 负责人确认 | 本行数据 | 执行人核对自己的实际工时与原因说明，修正错填 | 确认后的行数据 | 负责人逐行确认或批量确认完成 |
| 5. 项目经理复核 | 整张周期表 | 检查口径一致性、异常行说明是否充分、计划变更是否留痕 | 可发布的对比表 | 复核意见关闭，表格定稿并归档 |
计划基线的冻结时点建议放在周期开始当天或之前，冻结后计划工时不再直接修改。确需调整时，新增一条变更记录，写明原值、新值、变更原因和变更日期，汇总时以最新基线为准并保留历史。这样做的目的是让“计划变了”和“执行超了”在数据上可区分。
实际工时的采集频率与统计周期一致即可，过密会增加填报负担，过疏会丢失细节。采集后先做一次完整性检查：在途任务是否有实际工时、已关闭任务是否还有新增工时、同一人同一任务是否重复登记。这些检查放在计算偏差之前，能减少后续返工。
当团队在项目管理工具中维护任务和工时，上述流程可以部分由系统承载。例如 ONES 的资源管理支持通过工作数量和工时规模了解成员排期，并支持筛选与分组查看成员在不同项目的投入比重；资源报表可实时反馈项目投入情况，并支持一键导出工时日志。这些能力对应流程中的“采集实际工时”和“按人汇总”环节，计划基线的冻结与变更留痕仍需团队按约定执行，具体操作以实际产品配置为准。
角色分工与各环节交付物
表格能否持续使用，取决于每个环节是否有人负责、有产物可查。角色不必与职位一一对应，小团队可以一人兼多角，但职责要写清楚。
| 角色 | 主要职责 | 提交或确认的产物 |
|---|---|---|
| 任务执行人 | 按周期登记实际工时，核对本人行的数据，对偏差行给出原因标签 | 本人负责行的实际工时与原因说明 |
| 项目负责人 | 冻结计划基线，组织周期更新，处理计划变更登记 | 基线版本、变更记录、周期对比表初稿 |
| 资源或项目管理者 | 复核口径一致性与异常行，汇总跨项目投入，向管理层输出结论 | 复核意见、汇总视图、周期分析结论 |
复核不通过时，退回给对应执行人补充或修正，而不是由复核人直接改数。退回时写明具体问题，例如“该行实际工时低于登记日志”“原因标签与备注矛盾”“计划变更未登记”。修正后重新走确认，复核通过才定稿。这样每行数据都能追溯到填写人和确认人。
跨项目场景下，资源或项目管理者还需要关注成员在不同项目的投入比重。ONES 资源管理支持筛选与分组，帮助掌握成员在不同项目的投入比重，并可实时查看成员每日投入饱和明细，用于识别规划风险。这类视图适合放在复核环节使用，作为判断偏差异常是否与资源冲突有关的参考。
示例：一张按迭代统计的工时对比表
以下为演示数据，展示字段如何填写、偏差如何计算。假设迭代为“迭代 12”，计划工时在迭代开始前冻结，实际工时在迭代结束后汇总。
| 工作项编号 | 工作项名称 | 负责人 | 统计周期 | 计划工时 | 实际工时 | 偏差 | 偏差率 | 原因标签 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| DEV-101 | 登录页改版 | 张明 | 迭代 12 | 16 | 20 | +4 | +25.0% | 需求变更 | 第二周追加验证码适配 |
| DEV-102 | 订单列表导出 | 李华 | 迭代 12 | 12 | 10 | −2 | −16.7% | 复用已有导出组件 | |
| DEV-103 | 支付回调联调 | 王芳 | 迭代 12 | 8 | 14 | +6 | +75.0% | 协作等待 | 依赖方接口延迟两天提供 |
| DEV-104 | 权限配置页 | 张明 | 迭代 12 | 10 | 10 | 0 | 0.0% |
逐列看：偏差由实际减计划得出，DEV-101 为 20−16=+4 小时，偏差率 4÷16=25.0%；DEV-102 为 10−12=−2 小时，偏差率 −16.7%，负号表示结余。DEV-103 偏差率 75%，属于明显异常，原因标签选“协作等待”，备注写清等待对象和时长，便于后续判断是外部依赖问题还是排期问题。
可迁移的填写规律有三条：偏差行必须能对应到一个标签，标签之外的信息放备注；结余行同样保留，不因为“没超”就删行，否则合计失真；同一负责人的多行分别记录，不合并成一行，汇总时再按人透视。示例中的计划工时为整数小时，团队若按 0.5 小时登记，保持全表精度一致即可。
完成检查：表格可用与数据可信的判断标准
表格投入使用前，按以下清单逐项核对。任何一项不通过，先修正再发布，避免带着口径问题进入下一周期。
- 字段完整性：必填列无空白；计算列全部由公式生成，没有手工覆盖的数值。
- 口径一致性：每行只归属一个统计周期和一个负责人；汇总行与明细行分开存放；周期格式全表统一。
- 偏差计算正确：抽查三行，手工复算偏差与偏差率，结果与表格一致；计划工时为0的行未填偏差率。
- 异常行复核：超过团队设定阈值的行均有原因标签和可核对的备注；无标签的异常行为零。
- 计划变更留痕：本期如有计划调整，变更记录包含原值、新值、原因和日期，且汇总采用最新基线。
- 数据来源可查：数据来源列填写具体出处，抽查一行能回溯到原始工时记录。
- 确认与复核记录：负责人确认和项目经理复核均有记录，退回修正的行已闭环。
- 版本约定：表格文件或视图有版本标识和更新日期，历史周期归档不覆盖。
维护上建议固定两件事：每期定稿后归档一份只读版本，下一期在副本上更新；字段和标签的调整集中在下期开始前进行，期中不改结构。做到这两点，跨周期的对比才有可比性，偏差趋势也才值得解读。
常见问题
计划工时在周期中途调整了，对比表怎么处理才不影响偏差判断？
计划工时冻结后不直接改原值，而是新增一条变更记录，写明原值、新值、变更原因和变更日期。汇总时采用最新基线，历史版本保留。这样“计划变了”和“执行超了”在数据上可以区分，偏差率也才有解释力。如果变更频繁到每行都有记录，说明估算或需求管理环节需要单独复盘，而不是在表格里反复改数。
团队工时登记不完整，实际工时偏低，对比表还有意义吗？
有，但结论要限定范围。先做完整性检查：在途任务是否有实际工时、已关闭任务是否还有新增登记、同一人同一任务是否重复。缺失严重的周期，偏差率只能作为方向参考，不宜直接用于考核或资源调配决策。改进顺序是先统一登记节奏和粒度，再谈偏差分析；表格本身可以增加“数据来源”列，让每行能回溯到原始记录。
偏差超过多少才需要填原因标签，阈值怎么定？
阈值由团队按任务颗粒度和估算习惯约定，常见做法是偏差率超过 ±20% 或偏差绝对值超过 4 小时即要求标注，两个条件满足其一即可。阈值写进表头说明，全表统一，不逐行临时调整。阈值定得过低会让标签泛滥、失去汇总价值；定得过高会漏掉值得复盘的行。运行两三个周期后，可以按实际分布再校准一次。
按人统计和按任务统计能不能放在同一张表里？
可以放在同一个文件里，但要分成明细区和汇总区，不放在同一张表参与计算。明细区以工作项为行，每行只归属一个负责人和一个统计周期；汇总区按人或按周期透视生成，由公式引用明细，不手工填写。混在同一区域容易出现合计重复计算、行数对不上。需要同时看两种视角时，用透视或单独视图，比在一张表里塞两套行更可靠。
用项目管理工具记录工时后，对比表还需要单独维护吗？
取决于工具能否稳定导出按任务、按周期的工时数据。如果工时登记和任务计划在同一系统里，实际工时列可以直接从导出数据生成，表格主要承担偏差计算、原因标注和复核记录。以 ONES 为例，资源管理支持通过工作数量和工时规模了解成员排期，支持筛选与分组查看成员在不同项目的投入比重，资源报表可实时反馈项目投入情况并支持一键导出工时日志，这些能力可以承接实际工时的采集与按人汇总环节。计划基线的冻结与变更留痕仍需团队按约定执行，具体操作以实际产品配置为准。
