周报工时最佳实践：项目负责人工时表实操方法，常见问题

周报工时最佳实践：项目负责人工时表实操方法，常见问题

项目周报里的工时总数看起来准确，不代表项目进度就真实：如果一名成员把同一段工作时间填进两个项目，团队本周的投入会被高估；如果大家把会议、返工和等待都漏掉，项目又会显得比实际更高效。我建议项目负责人把周报工时表当成一张“投入解释表”，而不只是每周收集一次数字。它要能回答：时间花在哪里、为什么偏离计划、下一周需要调整什么。

一、先讲核心结论：工时表要能支持决策，而不只是完成填报

1. 一张有用的工时表，至少回答四个问题

我判断一份周报工时是否有管理价值，通常不先看它有多少列，而是看负责人能不能用它回答四个问题：本周投入了多少、投入分布在哪些工作、计划与实际差异在哪里、差异会不会影响交付。如果只能回答“每个人填了多少小时”，它更像考勤汇总，不足以支持项目管理。

这四个问题分别对应总量、结构、偏差和行动。比如“前端本周投入了 36 小时”是总量；“其中 12 小时用于需求变更后的返工”是结构；“原计划 4 小时，实际用了 12 小时”是偏差；“下周冻结接口范围并安排一次联调”才是行动。

核心原则是：工时数据必须能追溯到任务，也必须能回到管理动作。只统计总工时，容易把问题藏在平均值里；只要求写详细描述，又会把填表变成文书负担。实操中应把任务归属、工时口径、差异说明和后续动作放在同一条管理链路中。

2. 先统一口径，再讨论效率

项目负责人在比较计划工时和实际工时之前，必须先确认两边口径一致。计划工时可能是个人可用工作时间，也可能只是任务预计投入；实际工时可能包含会议、沟通和返工，也可能只记录直接产出。口径不同，差异值就没有解释力。

我建议至少明确三件事：哪些工作需要记录、按什么粒度记录、记录到什么时间范围。举例来说，如果团队约定只记录项目任务，就不能拿项目工时直接除以员工一周全部工作时间，得出“利用率”；如果团队约定将项目会议计入投入，就不能把会议时间从某个人的实际工时中剔除后再比较。

3. 周报不应该变成个人绩效排名表

工时能够说明某段时间资源投入在哪里，却不能单独说明一个人的贡献高低。复杂任务、排障工作、跨团队协调和新人上手，都会让相同交付结果对应不同投入。把周工时从高到低排序并直接解释为效率排名，既容易误判，也会诱发拆分任务、填报凑数等行为。

我更愿意把工时数据用于项目层面的判断：是否有任务持续超支、是否存在关键人过载、是否有大量时间被等待或返工吞掉、是否需要调整范围或资源。个人层面的沟通可以用具体任务和阻塞事实展开，而不把小时数当成表现结论。

二、背景和真实场景：为什么周报工时容易失真

1. 周报是回忆记录，越晚填写越容易漏项

工时表常常在周五下午集中补填。到了这个时间，成员要回忆五天里做过的任务、临时沟通、线上排障和等待情况。越是碎片化工作，越容易被压缩成“开发 8 小时”或“处理需求 6 小时”这样的笼统描述。

这并不一定是成员不认真，而是人的记忆更容易保留完整事件，难以准确还原短时切换。当天处理了三次各 20 分钟的线上问题，到了周末，往往只记得其中一次。因而我通常建议日常轻量记录、每周集中核对，而不是把记录和核对都堆到周末。

2. 项目工作并不等于连续执行任务

项目人员的时间常被切成几类：直接完成任务、参加评审和沟通、等待外部输入、处理线上问题、修复返工，以及协助其他成员。若表格只设置“开发、测试、设计”等岗位类别，团队可能知道是谁填了时间，却不知道工时为何消耗。

尤其在多项目并行的团队里，临时支持和跨项目协作很容易造成归属模糊。某位工程师半天处理线上故障，另一半时间又参与新项目联调。如果只允许选一个项目填报，数据会出现归属偏差；如果随意拆分，负责人又难以判断真实投入。解决方法不是增加无数细项，而是规定一个简单、稳定的归属规则。

3. 负责人关注的是偏差原因，不是漂亮的周报

我见过一种常见情况：计划工时和实际工时几乎完全一致，但周报仍然无法帮助项目决策。原因是成员为了让数据“好看”，把实际投入写成接近计划的数字；又或者实际确实超出计划，却没有说明任务为什么变难、是否发生需求变化、是否重复返工。

因此，周报工时表不宜以“越接近计划越好”作为唯一目标。偏差可能来自估算不准、范围变化、外部依赖或质量问题，性质不同，处理方式也不同。项目负责人真正要做的是识别偏差类型，再决定是调整资源、修正估算、控制范围，还是解决依赖。

4. 大型组织需要关注协作成本和口径治理

当团队规模超过百人，项目往往跨部门、跨职能甚至跨业务单元。此时，工时表的难点不只在填报，还在分类口径是否一致、谁负责审核、哪些信息需要共享，以及项目投入如何与计划、风险和交付记录关联。规模越大，单靠负责人逐条追问越难持续。

例如，中大型企业采用 PingCode 等项目管理平台时，可以把工时记录与任务、迭代或项目关联，以减少事后整理和重复录入。具体能否满足要求，仍需结合权限、流程配置、统计口径和现有系统集成情况评估；工具能承载流程，但不能替团队决定什么叫“有效工时”。

三、常见误区：看起来规范，实际会误导判断

1. 误区：工时填得越细，数据越准确

要求每 15 分钟填一次，看起来颗粒度很高，实际可能增加记录成本，并让成员把更多精力用在解释时间上。对于频繁切换的知识工作，时间被切得过细后，填报本身就会引入误差；成员也可能把沟通、思考和上下文切换硬塞进某个任务，制造虚假的精确感。

我更建议根据管理目的决定粒度。普通团队可以按任务和半天或小时级别记录；涉及成本核算、合同交付或客户服务时，再细化到项目阶段或服务事项。粒度要细到能识别管理问题，但不能细到让填报成本超过数据价值。

2. 误区：所有人每周都应填满固定小时数

固定小时数适合用来核对工作容量或发现明显缺失，不适合直接当作每个项目的目标工时。员工一周内可能有法定假期、培训、病假、值班或非项目工作。若要求每人填满同一数字，团队可能把不可用时间也分摊到项目中，导致项目成本和实际投入都失真。

建议先定义可用工作时间，再区分项目投入、非项目工作和缺勤时间。对于工时差异，应先确认成员本周实际可用容量，再判断投入是否异常，而不是拿一个固定分母套所有人。

3. 误区：计划与实际差 10%，就说明估算失败

单周任务的实际工时偏差会受到任务复杂度、依赖响应和突发事件影响。对于探索性工作，早期估算本来就存在较大不确定性；对成熟、重复的操作任务，持续出现同方向偏差才更值得追查。统一用一个比例线判定所有任务，容易把合理不确定性误判成执行问题。

我会先观察偏差是否重复出现，再看它集中在哪类任务、哪一环节、是否由同一个外部因素造成。与其争论“超了 10% 算不算问题”，不如问：超时是否改变交付日期、是否消耗关键资源、是否使剩余工作量判断失真。

4. 误区：会议时间不是产出，所以不该计入

会议不一定产生可交付成果，但它确实消耗项目容量。完全不记录会议，项目可能低估协作成本；把所有会议都计入项目，又可能掩盖会议过多或议题低效。更合适的做法是根据会议目的分类，例如需求评审、技术决策、跨团队协调、例行管理，并视管理需要汇总。

如果项目会议占比持续上升，重点不是要求成员把它藏进“任务开发”，而是检查会议是否必要、参与人是否过多、是否重复讨论以及决策有没有沉淀。记录会议不是为了证明开过会，而是为了识别协作投入是否值得。

5. 误区：低工时代表高效率，高工时代表高贡献

工时少可能意味着任务简单、复用充分，也可能意味着记录漏报或工作被转移给别人；工时多可能是复杂攻坚，也可能是返工、等待和低效沟通。没有任务难度、交付质量和工作背景，单看时长很容易得出相反结论。

如果团队确实需要分析效率，应把工时与交付结果结合，例如完成的工作范围、缺陷情况、返工原因、承诺时间兑现情况。对不同类型任务，也要避免简单横向比较。修复一个线上高风险故障，不能直接和完成一个常规配置任务按小时比较。

6. 误区：工时偏差越小，项目控制越好

偏差小可能代表估算和执行较稳定，也可能代表团队为了迎合计划而调整填报。项目管理需要的是可信偏差，而不是零偏差。若每个任务都恰好等于计划，负责人更应检查数据是否来自真实记录、任务是否被拆分得过细，以及团队是否敢于报告风险。

更可靠的观察方式是关注偏差分布和解释质量。偏差虽大但原因清晰、影响可控，通常比偏差很小但没有真实依据更有管理价值。

四、专业判断逻辑：从填报规则到负责人审阅

1. 先定义工时范围和排除项

一份工时表开始设计之前，先用一句话说明它的用途。例如：“本表用于了解项目投入、发现计划偏差和调整资源，不用于单独评价个人绩效。”这个声明可以减少成员把数据理解为考核排名，也能帮助负责人拒绝与目的无关的字段。

随后明确记录范围。一个可执行的口径通常包括：实际用于项目任务的时间、项目相关会议和协作、返工与缺陷处理；是否记录培训、行政事务、支持其他项目、值班和休假，则要根据报表用途另行规定。口径不必追求覆盖所有组织活动，但必须让使用者知道哪些时间不在表内。

2. 用任务分类解释投入，而不是只按岗位汇总

按岗位统计能回答“开发投入多少、测试投入多少”，但难以说明工时为何增长。我建议采用两层分类：第一层是项目任务或工作包，第二层是投入性质。投入性质可以包括计划执行、需求变更、返工缺陷、等待依赖、会议协作和线上支持。

分类不要一开始就做得太复杂。若成员要在几十个类别里选择，填报体验会迅速变差。初期可以从 5 至 7 个常用类别开始，每月检查一次“其他”占比。如果“其他”长期超过总工时的 10%，再分析是否需要拆分类别；若多数类别几乎没人使用，就应考虑合并。

3. 用有意义的粒度减少伪精确

周报记录粒度要与任务组织方式一致。任务通常以小时或天为单位安排，就按小时或半天记录；如果服务请求要求追踪单次处理成本，才需要按事件记录。关键是记录者能够稳定执行，审阅者也能解释数字。

例如，一个人上午完成代码修改，下午参加评审并处理故障，可以分成几个相关记录；但不必把每次短暂沟通都拆成独立条目。对于不足 15 分钟的零散事项，可按团队约定合并到“协作沟通”或所属任务，并在备注中注明性质。做法要一致，才有跨周比较价值。

4. 让偏差说明有固定结构

偏差说明不必写成长篇报告，但至少要包含原因、影响和动作。一个简短模板可以是：“原因：接口文档晚两天确认；影响：联调任务增加约 6 小时，测试窗口压缩；动作：周二前确认字段，必要时调整发布范围。”这比“任务复杂，工时超出”更有用。

对负责人而言，偏差原因可以归入几种可行动类型：估算偏差、范围变更、质量返工、外部依赖、资源切换和突发事件。分类的目的不是给偏差贴标签，而是避免把不同问题归为“执行效率低”，从而采取错误的管理动作。

5. 审阅采用分层规则，不要逐条追问所有记录

每周审核全部记录会让负责人陷入低价值工作。更有效的方法是先检查完整性，再看异常信号，最后抽查高风险任务。完整性可以关注漏报、重复、超出可用时间等明显问题；异常信号可以包括计划偏差、返工占比、单人过载和关键任务投入突然下降。

我建议把审核动作分成三层。第一层自动或快速检查格式和空缺；第二层由负责人查看偏差明显、影响关键路径或连续多周异常的任务；第三层再针对原因不明的记录和关键项目抽样核实。这样既能降低审核成本，也不至于把所有成员的每条时间记录都变成审批。

6. 用趋势而不是单周数字判断问题

一周的数据适合发现突发异常，不适合轻易下长期结论。项目负责人可以观察 4 至 6 周的滚动趋势：计划工时是否持续低估、返工投入是否反复升高、会议占比是否增加、关键角色是否一直超载。趋势能够区分一次性事件与系统性问题。

如果项目刚启动，前几周本来就可能出现估算校准和技术探索；如果项目进入收尾，测试、缺陷修复和发布准备的投入结构也会变化。因此，趋势比较要结合项目阶段，不能把不同阶段的工时结构当作同一种状态直接对比。

五、具体实操案例：从一周填报到一次管理调整

1. 案例背景：计划总量正常，关键任务却被挤压

下面用一个情景模拟说明表格如何支持决策。某产品团队有 8 名成员，项目进入一次迭代收尾阶段，本周计划项目投入 320 小时。周五汇总后，实际记录仍是 320 小时，看起来总量完全符合计划，但按任务性质拆开后，团队发现有 46 小时用于返工和线上问题，计划中原本只预留 20 小时。

与此同时，需求评审和跨团队沟通占用了 38 小时，比预估多 10 小时。总工时没有超支，并不代表项目没有风险：原本留给功能验收和自动化补测的时间，被返工和协作逐步挤占。若只看汇总总数，负责人很可能会误以为进度稳定。

2. 周报工时表怎样组织字段

对这个团队来说，表格需要能连接任务、投入时长、工作类型和偏差原因。若采用电子表格，建议一行对应一个任务在一个工作日或一个时间段内的投入，而不是一行写下一整周的笼统总数。这样在汇总时可以按成员、任务和投入性质透视，也保留必要的追溯信息。

3. 示例数据：总量相同，投入结构揭示了风险

下面的数字为该情景模拟中的周工时数据，用来说明分析方法，不代表行业基线。重点不是比较某个比例“正常不正常”，而是把计划与实际放在同一口径下，找到发生变化的工作类型。

从表格可见，功能开发和测试合计少了 28 小时，而返工与线上问题多了 26 小时，协作又多了 10 小时。若只看项目总工时，变化完全被抵消；按性质拆分后，负责人才能看出交付时间正在被返工和协调蚕食。

4. 负责人如何从数据定位原因

第一步不是立刻要求成员加班，而是抽查 46 小时返工与线上问题的构成。负责人可以检查是否同一个缺陷反复修复、需求是否在任务开始后发生变更、测试环境是否不稳定，以及问题是否集中在某个接口或模块。不同原因对应的动作完全不同。

第二步是确认 38 小时协作投入是否产生了决策。如果大量会议没有结论，应该收敛参会范围、会前明确议题；如果协作时间上升是因为外部团队没有及时提供接口信息，则要设定依赖负责人和确认时间，而不是简单要求本团队减少会议。

第三步是评估剩余交付范围。若验收和自动化补测已经受到挤压，项目负责人要在质量、范围和日期之间作出明确取舍，而不是要求所有工作“照常完成”。例如先保护关键路径测试，将低优先级功能放入下一迭代，并在周报中记录决策依据。

5. 下一周的行动如何落到表里

案例中的团队可以在下一周采取三项动作：冻结关键接口字段至指定日期；针对高频缺陷模块安排一次短时联合排查；将低优先级功能调整出本次交付范围。每项动作都要有负责人、完成时间和验证方式，否则只是周报里的建议，不构成管理闭环。

复盘时，负责人还要回看这些动作是否降低了返工和等待，而不是只检查周报是否填写完整。若返工投入仍然偏高，就需要进一步分析质量控制或需求管理；若下降明显，则可以把这次处理方式沉淀为团队规则。

六、不同情况下的行动建议：按团队成熟度和项目特点调整

1. 小团队或单一项目：先使用轻量表格

人数较少、项目数量有限时，先用共享表格就可以开始。字段控制在日期、成员、任务、工时、投入性质和异常说明几个核心项，负责人每周固定时间检查漏填与关键偏差。不要一开始就建复杂审批流或要求每条记录附证明材料。

小团队最重要的是形成稳定习惯：工作发生时顺手记，周末前核对，负责人用工时结构做一次短复盘。如果成员能够保持一致口径，表格后续再升级也不会丢失基础数据。

2. 多项目并行：先解决项目归属和共享资源问题

成员同时参与多个项目时，最常见的问题是工时被重复计算、共享支持没有明确归属，以及项目负责人各自要求不同格式。此时应统一项目编码、任务归属原则和非项目时间的记录方式，并明确谁有权审核跨项目投入。

对于临时支持，可以约定按实际服务对象记录，或统一记入共享支持池后再按规则分摊。两种方式都可以，但不能让每位成员自行选择。若工时用于项目成本核算，分摊规则要由财务与业务共同确认，避免管理报表和财务口径相互冲突。

3. 探索性或研发型项目：以区间和阶段判断替代精确承诺

探索性任务在早期通常缺少完整信息，要求每项工作都给出精确工时会制造不可靠的承诺。负责人可以记录投入区间、假设条件和阶段成果，再通过短周期评审决定是否继续投入。重点是看每一阶段是否减少了关键不确定性，而不是追求每小时都能预先估准。

这类项目更适合将验证活动、原型开发、技术调研和正式实现区分开。若验证没有得到预期结果，投入并不一定是浪费；关键是该投入是否及时揭示风险、是否影响后续投资决策。

4. 固定合同或客户结算项目：严格区分内部管理口径与计费口径

对外结算的项目，工时记录可能涉及合同、审计或客户验收，因此需要明确可计费活动、内部管理活动、休息和等待时间如何处理。内部周报中的实际投入不一定等于客户可计费工时，两者应分开标注，不能为了结算把管理数据改写成符合合同的数字。

建议保留任务、时间、负责人和审批痕迹，并把合同约定的计费规则单独维护。涉及客户和财务的数据，权限控制、修改记录与保留周期也要纳入流程设计。

5. 多职能、大规模组织：优先统一定义和治理责任

在多部门组织中，统一字段只是第一步，还要规定数据定义、报表责任人、异常处理时限和跨项目争议的升级路径。不同部门对“项目工时”“支持工时”“返工”的理解可能不同，如果只上线工具而没有共同口径，报表很快会变成看似统一、实际不可比较的数据集。

可以先选取一个业务单元或一个项目群试行，观察填报耗时、数据完整率、分类分布和审阅发现的问题，再决定是否推广。若组织已有项目管理平台，可以评估任务关联、权限设置、报表导出和历史追溯能力；工具选型应服从流程需求，不要先买系统再反向寻找使用理由。

七、工时表的取舍：哪些该记录，哪些不值得追

1. 精度与填报成本之间的取舍

更细的记录能提高追溯能力，却会增加填写和审核负担。项目负责人应比较每增加一个字段能带来的决策价值。如果字段无法改变资源安排、范围判断或风险处理，就不值得强制每个人每周填写。

一个实用办法是先试运行两到四周，统计成员每周填报时间，并观察字段缺失率和“其他”使用率。若某项信息几乎没人使用，或填写后从未进入项目复盘，可以考虑删除；若某项异常反复出现、且确实影响决策，再保留并细化。

2. 统一标准与项目个性之间的取舍

所有团队使用完全相同的分类，便于横向汇总，却可能不适合不同类型项目。所有项目各自定义，又会导致跨项目比较失效。较稳妥的做法是设置一组组织通用的基础类别，再允许项目增加少量本地类别，并要求本地类别能够映射到通用口径。

例如，通用类别可以包含计划执行、返工、协作和外部等待；研发、实施或运营团队可增加领域特有的子类别。负责人需要控制自定义类别数量，避免一个项目一套语言，最后只能看项目内部数据，无法形成组织级判断。

3. 透明度与隐私边界之间的取舍

工时记录越详细，越容易暴露个人工作节奏、处理事项甚至客户信息。项目管理需要透明，但不意味着所有成员都应查看所有个人记录。可以按角色设置访问范围：项目成员查看与自身协作有关的信息，负责人查看项目投入，组织层面使用汇总数据分析资源趋势。

如果工时用于绩效或薪酬相关决策，组织应明确告知使用目的、访问权限和保留期限，并让员工知道数据如何解释。把管理数据暗中改作其他用途，容易破坏填报信任，最终损害数据质量。

4. 自动化与人工判断之间的取舍

自动汇总、异常提醒和任务关联能够减少重复劳动，但系统无法独立理解为什么某项工作超支，也不能替负责人决定是否调整范围。自动化适合做重复校验和信号筛选；原因解释、优先级取舍和跨团队协调仍需要人作判断。

如果使用项目管理工具或项目管理平台，应重点确认数据能否与任务关联、历史修改是否可追溯、报表口径是否可解释、权限是否符合组织要求。工具功能多不等于管理成熟，能稳定减少重复录入并支持复盘，通常比拥有大量无人使用的字段更有价值。

5. 记录完整性与信任之间的取舍

缺少记录会让数据失去代表性，但用惩罚机制逼迫成员“填满数字”，可能导致虚报和防御性填写。负责人应区分偶发漏报、流程设计不合理和故意造假。对于前两者，优先修正提醒机制、字段设计或工作节奏；对于反复违反明确规则的情况，再按组织制度处理。

让成员相信工时用于识别阻塞和改善估算，而不是单纯寻找谁“用时太长”，往往比增加审批层级更能提高记录质量。信任不是放弃管理，而是让规则透明、使用范围明确、质疑有回应。

八、常见问题：项目负责人实际会问到的工时问题

1. 周报工时应该每天填，还是周末统一补？

我建议平时轻量记录，周末集中核对。每天记录的目的不是增加打卡次数，而是减少对碎片工作的回忆误差；周末核对则用于修正归属、补齐偏差原因和检查总量。若团队确实无法每日维护，可至少在每天结束时用简短方式记下当天主要任务和大致投入。

2. 工时记录是否必须与任务系统绑定？

不一定，但任务数量多、跨项目协作频繁或需要追溯交付成本时，任务关联通常更有价值。小团队用表格也可以，但应保持任务名称和项目归属稳定。若工时记录和任务记录长期分离，负责人会花大量时间对照、合并和纠错。

3. 成员没有填满计划工时，该怎么办？

先检查其实际可用时间，以及是否存在非项目工作、休假、等待依赖或记录遗漏。没有填满计划工时不一定意味着人没有工作，也可能意味着计划容量与实际工作结构不匹配。确认口径后，再决定是调整计划、补充记录还是改变资源安排。

4. 计划工时和实际工时差多少才需要复盘？

没有适用于所有团队的固定百分比。可以先按项目风险设预警规则，例如关键路径任务偏差达到某个比例，或同类任务连续数周出现同方向偏差时触发复盘。具体阈值应通过历史数据校准，并结合任务类型、影响范围和剩余交付时间判断。

5. 会议时间要不要记进项目工时？

如果会议服务于项目，且项目负责人需要了解协作成本，通常应记录或至少按类别汇总。若会议是组织级管理、培训或行政活动，则应依据统一口径另行归类。关键是团队前后一致，不要为了让某个项目报表更好看而改变口径。

6. 返工工时是否应该单独统计？

只要团队需要识别质量成本或计划偏差，返工就值得单独统计。可以先使用较粗的分类，再对高频原因做复盘，例如需求理解不一致、设计缺陷、测试遗漏或外部变更。单独统计不是为了责备某个岗位，而是找出能减少重复工作的流程改进点。

7. 工时数据能不能用于绩效评价？

不建议把工时总量直接作为个人绩效结论。若组织需要参考工时数据，应结合任务难度、交付质量、角色职责、协作贡献和资源条件，并提前说明使用规则。工时更适合提供背景和容量信息，不能单独替代绩效评价所需的多维证据。

8. 用电子表格还是项目管理平台更合适？

如果团队人数少、项目简单、需要的统计有限，结构清晰的电子表格足以启动。若项目多、任务关联复杂、权限要求较高或需要持续汇总历史趋势，再评估项目管理平台是否能降低重复录入和审核成本。选型时应拿真实场景验证，不只看演示功能。

九、总结：把工时记录从“追数字”改成“解释变化”

1. 项目负责人下一步可以怎么做

如果团队当前没有稳定的周报工时流程，我建议不要先追求一张完美模板。先用一周时间统一工时口径，再试运行少量字段；第二周观察成员填报成本和漏记情况；第三周检查数据能否解释计划偏差；之后再根据实际管理问题增加分类或自动化能力。

一个可执行的起步动作是：选一个正在推进的项目，记录计划工时、实际工时、任务归属和投入性质；周末只挑出影响交付的三类异常，逐项写清原因、影响与下一步动作。连续运行四周后，检查是否出现稳定趋势，再决定是否推广到更多项目。

2. 最重要的判断标准

周报工时表的质量，不在于填报数字有多整齐，而在于它能否让团队更早看见资源被什么事情消耗、交付风险从哪里产生，以及接下来该改变什么。精确到小数点的记录，如果无法促成任何行动，不如一份口径一致、原因清楚、能支持取舍的简洁周报。

对项目负责人来说，下一步不是要求成员把每一分钟都解释清楚，而是挑一个真实项目，用统一口径记录四周；每周复盘投入结构、关键偏差和后续动作；最后根据数据决定是修正计划、控制范围、减少返工，还是调整资源。工时表的终点不是汇总，而是更好的项目决策。