工时审核管理指南：项目负责人如何做好工时管理，入门指南全流程

工时表里每个人都填满了 8 小时，不代表项目真的按计划推进。项目负责人最容易在月末遇到这样的反差：工时看起来完整，关键任务却延期；成员说每天都很忙，负责人却说不清时间究竟花在需求变更、返工还是等待审批上。工时审核管理的核心不是盯住每个人填了几小时，而是让时间记录成为项目判断的可靠证据：能解释偏差、支持调整，并且不把团队变成“为了填表而工作”。

一、先讲核心结论：审核的是项目事实，不是个人态度

1. 工时管理的目标不是把每一分钟管起来

我做工时管理设计时，首先会问：这组数据最终要帮助谁做什么决定？如果答案只是“月底要交表”，团队很快就会把填报当成行政任务。记录可能按时提交，却无法用于判断项目是否超支、需求是否失控，或团队是否被大量临时工作打断。

有效的工时管理至少要支持四类判断：项目还需要投入多少时间、预算是否存在超支风险、工作量是否在团队间失衡、实际时间与计划差异的原因是什么。记录粒度、审核频率和审批人，都应从这四类判断反推，而不是从表单字段数量反推。

我的判断原则是：工时记录精确到足以支持决策即可，不必精确到制造虚假的确定性。对于知识工作，成员通常很难准确回忆每个任务用了多少分钟。要求按 15 分钟逐项追溯，看似细致，实际往往会提高填报负担并降低可信度。

2. 把审核拆成三层，避免负责人变成逐行校对员

我建议把审核分成完整性、合理性和经营解释三层。完整性检查“该填的有没有填”；合理性检查“时间是否符合任务与日历事实”；经营解释则判断“这些时间意味着什么”。三层解决的问题不同，不能只靠一个审批按钮代替。

• 完整性：成员是否在规定周期内提交，任务、日期、投入时长、工作说明是否齐全。
• 合理性：是否存在重复记录、非工作日异常填报、超出日常容量的投入，或记录与任务状态明显矛盾。
• 经营解释：实际投入偏离计划的原因是否明确，是否需要调整范围、排期、资源或质量策略。

负责人不应把所有记录都当成待查案件。对信息完整、任务状态一致、偏差处于正常范围的记录，可以批量确认；把人工精力留给异常、重复出现的偏差和高风险项目。审核效率不是少看几行，而是把注意力集中到能改变决策的异常上。

3. 先定口径，再选工具

我见过团队先买系统、再讨论“什么算工时”，最后不得不在字段、报表和审批流程上反复返工。工具能帮助收集、提醒、汇总和追溯，却不能替组织决定哪些投入算项目成本、会议时间归哪个任务、跨项目支持由谁承担。

因此，建议先写一页工时口径：记录对象是什么、按什么周期填、哪些时间纳入项目、哪些情况需要说明、谁负责审核、超出什么范围要升级处理。口径统一后，再评估是否用表格、项目管理工具或企业级平台落地。

二、理解真实场景：为什么工时表看着齐，项目还是失控

1. 工时记录发生在工作之后，天然带有回忆误差

大部分团队不是实时计时，而是在每天结束或周末集中补录。成员需要回忆自己做过什么、切换了几次任务、临时帮谁排查了问题。工作越碎片化，回忆越不准确。于是，一天里真正发生的 1 小时排障、30 分钟协作和数次短会，可能被粗略归进一个任务，甚至被忘掉。

回忆误差不是品格问题，而是记录机制与工作方式之间的摩擦。若一个人每天切换十几次任务，却要求周五准确还原每项投入，数据就会呈现一种“看起来整齐、实际上偏粗”的特征。管理者应先降低记录的回忆成本，例如鼓励当天记录、提供清楚的任务分类、避免过细的项目树。

2. 多项目共享资源，让“忙碌”与“产出”错位

在中大型组织里，设计、测试、架构、安全和数据团队常被多个项目共同使用。项目负责人只看到本项目的计划投入，成员却同时承担线上支持、跨团队评审、内部治理和临时需求。如果这些投入没有明确归属，项目账面上就会低估资源占用，其他团队也会觉得成员“明明有空”。

我会要求组织区分至少三类时间：项目交付、运维或支持、组织性工作。分类不宜无限扩张，通常先把最影响资源判断的类别拆出来。细分项太多，会让成员花时间选择标签；类别太少，则无法解释共享资源被什么工作占用。

3. 任务变更和返工会让计划基线失去意义

如果需求范围不断变化，却仍然拿最初估算与实际工时作比较，偏差会被错误地归因于执行效率。项目负责人应该保留计划基线，同时记录批准过的范围或估算变更。这样才能区分“团队做得比预计慢”和“工作内容已经不是原来的工作”。

当实际投入增加时，我通常先检查变更记录、缺陷返工、等待外部依赖和跨团队协作，再讨论个人效率。没有范围背景的工时差异，只是一个数字；有了事件时间线，才可能成为管理证据。

4. 案例：月末发现超支，根因不在成员“填得不认真”

以下是用于说明审核方法的匿名情景案例，不代表某个企业的真实经营数据。一个约 120 人的产品与研发组织，多个项目共用测试和平台工程资源。项目负责人每月收到工时汇总，发现核心功能项目比计划多出约 18% 的投入，但各成员记录都接近标准工作日，看不出明显异常。

进一步把工时按任务类型拆分后，发现三类投入被混在一起：需求变更后的补充开发、上线前的集中缺陷修复，以及平台团队对其他项目的临时支持。成员不是没有填报，而是任务归属和工作类别不清。负责人据此调整了项目口径，并把临时支持单独标注，下一周期才看清本项目交付投入与共享支持成本的差异。

这组情景数据真正说明的不是“换一种表格就能提升效率”，而是记录口径改善以后，管理者能更快看见投入去了哪里。若没有类别定义、变更记录和项目归属规则，任何工具都只能更快地汇总不清楚的数据。

三、常见误区：看起来严格，实际降低数据质量

1. 把“每天填满标准工时”当作数据质量标准

每天都出现固定时长，容易让报表显得完整，却可能掩盖病假、培训、公共假期、支持工作和实际休息。标准工作日是容量规划参考，不是要求每个人把所有时间都归入项目的配额。

我建议把“未分配时间”作为需要解释的信号，而非自动判错。它可能来自记录遗漏，也可能反映组织性工作或人员休假。关键在于设定清晰类别和审核规则，避免把不确定时间硬塞进一个看似合理的任务。

2. 逐分钟审核，把负责人时间耗在低价值确认上

若负责人每天检查每条记录是否精确到小时，团队会把审核视为信任缺失，负责人也会失去安排资源和排除风险的时间。工时审核不等于考勤核验，更不是对每个人工作态度的评分。

更有效的做法是设定例外规则：例如日投入明显超过团队正常容量、连续多日没有任务归属、同一任务多次出现异常偏差、已关闭任务仍持续录入等。规则只是筛选信号，不能直接当作违规结论。

3. 用工时直接给个人生产率排名

工时长短不能直接代表产出效率。复杂任务可能投入更多时间但价值更高；熟悉业务的人处理常规工作可能很快；缺陷修复投入增加，也可能是前期质量风险暴露。把工时简单换算成个人排名，会促使成员回避困难任务，甚至把协作和维护工作藏起来。

如果组织确实要做能力或产能分析，应结合交付成果、任务复杂度、质量、依赖和工作类型，且优先用于团队级趋势观察。工时适合解释资源消耗，不适合单独裁定个人价值。

4. 频繁修改记录，却不保留修改原因

审核者发现不合理记录后，若直接替成员改数字，最后报表可能更整齐，但数据责任和事实依据都会变模糊。更稳妥的方式是退回并说明问题，让记录者修订；如需代改，应保留原值、修改人、时间和原因。

对于预算核算、客户结算或合规要求较高的场景，修改留痕尤其重要。否则，组织很难判断差异是正常修正、口径调整，还是流程缺陷。

5. 把填报频率和记录粒度混为一谈

每日填报不代表每项工作都要拆到极细。团队可以每日或每周记录，同时按半天、小时或任务阶段汇总。记录频率解决“多久回忆一次”，粒度解决“细到什么程度”，两者应分别设计。

四、专业判断逻辑：一条工时记录怎样才算“值得审核”

1. 先检查记录是否可以追溯

一条可用记录至少需要回答四件事：谁投入、在哪一天投入、投入到什么工作、用什么口径记录。若涉及项目成本，还要明确项目或成本归属；若记录偏差明显，应附上简短解释。字段越多不一定越好，缺少关键字段才会让数据无法解释。

我会优先检查任务关联是否稳定。如果一个任务名称过于宽泛，例如“研发工作”或“日常支持”，即使时长准确，也无法支持排期复盘。若任务拆分过细，成员又会花大量时间维护任务结构。实践中，任务粒度应能够对应一个可识别的交付或工作阶段。

2. 再判断时长与计划之间的关系

实际投入超过计划，不应自动等同于执行失败。先确认计划是否经过估算、工作范围是否变化、任务是否被阻塞、是否发生返工，再判断偏差性质。建议组织设定自己的关注阈值，例如单项任务偏差达到一定比例或绝对时长后需要说明，但阈值应结合任务规模制定。

小任务用百分比阈值容易误报。例如计划 2 小时、实际 3 小时，偏差 50%，但绝对差异只有 1 小时；大型任务则可能百分比不高，却造成数十人时的额外投入。因此，比例与绝对值应同时看，不能只看一个数字。

3. 把偏差分类，而不是只问“为什么超了”

我常用五类偏差帮助复盘：范围变化、估算偏差、依赖等待、质量返工、外部支持。每类对应不同的行动。如果是范围变化，需要重新确认基线；如果是估算偏差，需要修正未来估算；如果是等待依赖，需要调整协作机制；如果是返工，需要检查质量门槛；如果是外部支持，需要重新分配容量。

• 范围变化：新增需求、验收标准变化、临时插单。
• 估算偏差：复杂度判断不足、未知风险没有预留。
• 依赖等待：外部团队、环境、审批或数据准备未按时到位。
• 质量返工：缺陷修复、测试失败、设计与实现反复调整。
• 外部支持：线上问题、跨项目协助、紧急维护。

4. 用“事实、解释、行动”完成审核闭环

审核记录不应止于“通过”或“退回”。我建议负责人用三句话完成关键偏差的处理：事实是什么、原因是什么、下一步做什么。比如：“本任务实际投入比基线多 12 小时；其中 8 小时用于新增验收规则，4 小时用于修复接口兼容问题；新增需求已确认，排期向后调整两天。”这样的记录比单写“超时，注意”更有复用价值。

如果偏差不需要调整项目决策，也应说明为什么无需行动。持续积累后，团队可以看出哪些工作类型经常低估，哪些依赖最容易拖延，哪些需求入口造成范围波动。

五、落地全流程：从口径定义到月度复盘

1. 第一步：明确用途和数据边界

在启动填报前，先明确组织要解决的是项目成本核算、资源规划、客户结算，还是交付复盘。一个流程可能同时服务多个目的，但各目的对精度和证据要求不同。内部项目复盘可以使用小时级估算；合同结算可能需要更严格的确认、留痕和争议处理机制。

同时写清楚记录边界：会议是否计入项目、培训如何归类、跨项目协作如何分摊、病假和公共假期如何处理、线上支持算哪个项目。不要让成员自行猜测，尤其不要在月底才临时更改口径。

2. 第二步：选定记录粒度和周期

记录粒度应与决策精度匹配。如果项目每周只做一次资源调整，按小时或半天归集通常已经足够；如果工作与外部结算、合同证据相关，可能需要更细的任务和时间说明。粒度越细，数据维护成本越高，应确认额外精度能够带来相应的决策价值。

记录周期同样要考虑回忆误差和团队节奏。每日记录通常更接近实际发生情况；每周汇总的管理负担较轻，但更依赖成员的记忆与习惯。对频繁切换工作的团队，可以要求工作日简短更新，而不是要求每次任务切换都启动计时器。

3. 第三步：设计最少但足够的字段

一个基础记录通常包括成员、日期、项目或成本对象、任务、投入时长和简短说明。若组织需要追踪偏差，再增加工作类别、是否计划内、偏差原因等字段。字段设计要避免重复提问，例如任务类别和偏差原因若都要求填写“工作说明”，成员可能只会复制同一句话。

我倾向于用“必填字段少、异常说明有条件触发”的方式。正常记录只需快速提交；当投入超过阈值、任务状态异常或涉及客户结算时，再要求提供更具体的说明。

4. 第四步：明确成员、负责人和运营角色的职责

成员对记录真实性与及时性负责，项目负责人对任务关联、偏差解释和后续行动负责，项目运营或行政角色负责流程口径、提醒和报表维护。管理层则负责决定资源冲突、预算变更和项目优先级。职责不清时，工时审核会退化成“所有人都看过，但没人负责行动”。

5. 第五步：设置提交提醒与异常校验

提醒最好靠近记录发生时间，而不是等到月底一次性催办。可以设置提交截止时间、未提交提醒和负责人待审提示。校验规则则重点关注空任务、重复记录、超容量投入、非工作日记录、已关闭任务继续录入等情形。

自动规则不能替代判断。例如非工作日填报可能是线上事故支持，也可能是时区或日历设置问题；系统应提示负责人核对，而不是直接拒绝记录。合理的自动化是减少重复核对，不是把复杂事实压成一个机械结论。

6. 第六步：审核异常，保留责任链

发现异常时，先区分信息缺失与事实偏差。信息缺失可以退回补齐；事实偏差应要求说明是否存在变更、返工或支持投入。对于需要代为修改的情况，保留原始记录、修改理由与操作时间，避免审核过程改变了数据，却没有留下可追溯线索。

建议用风险优先级排序：影响客户结算或预算的记录优先复核；重复出现的偏差优先复盘；对项目结果影响很小的单次异常可抽样处理。所有异常都追问，会让流程变重；完全不追问，则会让数据失去管理价值。

7. 第七步：把审核结果用于滚动预测

项目负责人审核后，应把实际投入与剩余工作放在一起看。已经消耗的时间说明过去发生了什么，剩余工作估算才决定项目未来是否会超期。单看“已投入工时”容易把管理注意力锁在历史记录上。

每周或每个迭代结束时，建议重新估计剩余工作，并与团队可用容量比较。若计划剩余工作明显高于可用容量，尽早讨论范围、人员、依赖或质量策略；不要等到累计工时超预算才宣布风险。

8. 第八步：月度复盘，修订估算和规则

月度复盘不应只问谁超时，还应问哪些任务类型经常估算不足、哪些变更来源重复出现、哪些团队承担大量未计划支持、哪些流程字段没人使用。规则需要根据观察结果调整，但不宜每月频繁改口径，否则不同周期的数据就失去可比性。

修订口径时，应记录版本、生效日期和影响范围。对于重要报表，需保留旧口径与新口径的映射关系，避免把分类变化误读为工作量突然增加或减少。

六、具体案例与数据观察：如何从偏差识别到项目动作

1. 情景案例：迭代投入超出计划，先排查工作结构

下面仍为情景模拟。某产品团队计划在一个迭代内完成一组功能，计划投入 240 小时，实际记录达到 286 小时，多出 46 小时。若负责人只看到总数，很容易将其判断为估算不准或执行偏慢；把记录按工作类别拆开后，才发现差异分布在多个原因中。

这时，我不会立即让团队“下个迭代加快 19%”。首先确认 34 小时变更是否已批准；再看 42 小时返工是否来自同一质量问题；最后明确 22 小时支持和等待是否可由流程调整减少。超出的 46 小时并非一个单一原因，行动也不应该只有一个。

2. 把成本、交付和质量放到同一张复盘桌上

如果团队只追求减少工时，可能通过减少测试、推迟维护或把工作转移到下个周期制造“效率提升”。我建议工时偏差与交付完成度、缺陷趋势、范围变化一起看。时间投入减少但缺陷激增，不一定是改善；投入上升但关键风险消除，也不必自动判定失败。

复盘时可以使用三组问题：投入发生在哪里、结果是否符合预期、下一周期如何减少重复损耗。对团队来说，工时数据的价值在于发现系统问题，而不是证明某个人“忙得不够”。

3. 让工时解释转化为下一周期的可验证动作

每次复盘最好只选少量、可验证的动作。例如需求变更较多，就规定新增范围必须确认影响；返工集中在验收理解，就在开发前增加验收示例；共享支持占用高，就为支持工作设置轮值或容量预留。

动作要能在下一周期观察效果，而不只是写进会议纪要。可以追踪变更导致的额外投入、重复缺陷返工小时、未计划支持占比或负责人审核耗时。这样才能验证工时管理是否真的改善项目，而不是只增加报表。

七、工具与流程取舍：什么时候用表格，什么时候上平台

1. 小团队可以从轻流程开始

如果团队规模较小、项目数量有限、协作边界简单，结构清楚的表格可能足够。重点是统一字段、设定截止时间、保留修改记录，并有人定期检查异常。此时不必为了“看起来数字化”引入复杂审批。

当成员需要重复填写项目、任务和时间，且每月都要手工合并多张表，表格成本开始显现。尤其是多人共享资源、项目跨部门、需要按权限查看成本时，手工维护容易出现版本冲突和数据口径不一致。

2. 多项目和中大型组织需要关注数据关系

对于 100 人以上、多团队并行交付的组织，问题通常不只是有没有工时字段，而是工时能否与项目、任务、迭代、资源计划和权限关联。工具选择应检查能否统一身份与组织架构、支持跨项目汇总、保留审计轨迹、处理异常提醒，并让数据进入资源和项目复盘流程。

例如，PingCode 可作为企业项目协作场景中的一种评估对象。评估时不要只看演示页面是否有填报入口，而要验证：能否按组织现有项目结构记录投入、能否控制不同角色的查看权限、能否将异常交给负责人处理、能否导出或汇总管理层所需的口径。产品能力、合同范围和具体配置可能随版本及部署方式变化，应以实际演示和采购条款为准。

3. 选型时先做真实流程试跑

我不建议只用供应商提供的标准演示流程做判断。应拿团队真实任务、跨项目支持、休假、变更和返工场景试跑一轮，观察成员填报需要几步、负责人处理异常需要多久、报表能否回答预算和资源问题。

• 用一组真实项目任务测试任务关联和分类逻辑。
• 模拟成员同时承担两个项目和一项临时支持，检查归属是否清楚。
• 模拟工时修改、退回和补录，确认是否保留操作轨迹。
• 让负责人生成实际需要的项目、团队和周期报表。
• 评估权限、数据导出、部署方式、集成维护成本及供应商支持边界。

4. 计算总成本，不只比较软件报价

工具成本还包括流程配置、数据迁移、培训、管理员维护、系统集成和成员填报时间。一个报价较低的平台，如果需要大量人工整理数据，未必比报价更高但能减少重复维护的方案划算。反过来，功能丰富的系统也可能因字段和审批过重而降低使用率。

简化的评估方式是先设定基线：当前每月花多少时间追表、核对、合并报表和追问异常；试点后再记录相同口径下的处理时间、数据完整度和决策使用情况。不要只比较“上线后节省了多少分钟”，还要看数据是否真正被用于排期、资源和风险管理。

八、不同情况下的行动建议与取舍

1. 团队刚开始做工时管理：先求口径一致

如果团队从未系统记录过投入，不要一开始就追求复杂成本模型。先选一个真实项目做 4 至 6 周试点，记录项目、任务、日期、时长和少量偏差原因。每周检查成员是否理解口径、负责人是否能看懂报表，再决定增加哪些字段。

这阶段可以接受一定程度的分类粗糙，但不能接受各人各填一套定义。先让数据可比较，再逐步提高精细度。若试点期间发现成员频繁询问同一口径问题，优先修改说明和示例，不要先责怪执行不认真。

2. 项目已频繁超预算：把范围与返工分开

如果工时持续超出计划，先检查范围变更、缺陷返工和未计划支持是否混在一起。设置变更记录和偏差分类，确保计划基线可追溯。接下来用每周滚动预测判断剩余工作是否超出团队容量，并及时提出范围、资源或排期方案。

这一场景下，不建议以“减少填报粒度”作为第一反应。真正需要的是更清楚地解释投入构成。如果异常原因明确，团队反而可以减少不必要的过程监控。

3. 人员同时支持多个项目：先解决归属和容量争议

共享人员团队要先明确优先级规则和支持工作归属。每个人的计划容量应考虑会议、维护、休假和组织性工作，不能把名义上的工作日全部分配给项目任务。项目负责人还要定期与资源负责人校准，不要等工时数据证明人力已被超额使用才处理冲突。

如果项目之间争抢资源，工时记录能提供事实，但不能代替优先级决策。管理层仍需决定哪个项目优先、哪些工作可以延后，以及共享团队是否需要建立稳定的支持容量。

4. 涉及客户结算或审计：提高证据要求

外部结算、合同计费或审计场景，应提前确认合同口径、审批责任、记录保留周期和争议处理方式。成员需要清楚哪些工作可计费、哪些属于内部投入；修改记录应保留原值和原因，审批人也要有明确授权。

这时可以接受更细的记录和更严格的审批，但必须为相应的行政成本预留时间。不要一边要求完整证据，一边假设成员和负责人可以无成本地完成全部记录与审核。

5. 团队抵触填报：先查流程摩擦，不要先加处罚

成员抵触常见原因包括任务列表难找、同类工作分类混乱、填报频率不合适、记录用途不透明，以及数据被误用于个人绩效排名。负责人应先做小范围访谈：最难填的字段是什么、哪些数据没人使用、成员担心记录会被如何解释。

如果组织无法说明为什么需要这些数据，就应减少采集范围。若数据用于资源规划，应公开说明组织会如何使用、哪些用途不会采用。透明度往往比增加催办次数更能改善长期配合。

6. 负责人审核积压：把审批改成分级处理

当负责人每天面对大量待审记录，可以把低风险记录改为规则校验加抽样复核，把高风险记录交由人工确认。还可以将审核频率从逐日调整为每周，但要评估回忆误差和项目决策时效。

要避免一种看似有效的做法：把所有审批权下放，却不给下级培训和升级条件。分级审核需要明确什么情况下可通过、什么情况下应退回、什么情况下必须升级到项目负责人或财务角色。

九、项目负责人可直接采用的审核清单

1. 每周审核前：先看数据是否能被解释

• 记录是否在规定周期内提交，缺失项是否有人跟进。
• 任务是否关联到正确项目和工作对象，是否存在过度宽泛的任务。
• 超出计划或容量的投入是否有说明，比例和绝对工时是否同时检查。
• 是否存在重复记录、关闭任务继续录入或非工作日异常记录。
• 项目范围是否发生变化，基线是否需要更新或保留变更说明。
• 共享支持、运维和组织工作是否被误归入交付任务。

2. 每周审核后：留下决策，不只留下审批状态

负责人可以把每周复核结果归为三类：无需行动、需要成员补充事实、需要项目调整。无需行动也要有判断依据；补充事实要指出缺少什么；需要调整则要明确责任人和完成时间。

若一个团队连续多个周期都出现相同类型的异常，问题大概率不在提醒频率，而在流程设计、任务结构、估算方式或资源分配。此时应改规则或工作机制，不要无限增加催办。

3. 每月复盘：看趋势，不只看单点

月度复盘至少要看项目计划与实际投入差异、未计划工作占比、返工投入、共享支持投入、提交及时性和异常处理耗时。所有指标都应明确统计周期与分母，例如“异常率”是异常记录数除以全部记录数，还是异常投入小时除以总投入小时，两者含义完全不同。

指标数量不宜过多。若报表有几十个数字，却没有对应的行动人和决策路径，管理层很难持续使用。选择少量能改变资源或交付决策的指标，通常比追求报表全面更有效。

4. 每季度复核：确认规则没有变成负担

至少每季度问一次：哪些字段从未进入分析，哪些审批只是形式确认，哪些分类导致成员困惑，哪些项目仍然无法解释成本。对没人使用且不承担合规责任的字段，可以考虑删除；对频繁触发但没有行动价值的规则，应重新调整阈值。

记录制度的成熟，不是字段越来越多，而是同样的管理问题能够用更少的追问、更清晰的证据和更快的行动解决。

十、结语：工时管理的成熟度，体现在少问“谁没填”，多问“下一步改什么”

项目负责人做好工时审核，关键不是让所有数字看起来整齐，而是建立一条可信的解释链：投入对应什么工作，偏差从哪里来，它对项目有什么影响，组织接下来采取什么行动。没有解释的数字只能用于汇总；能够连接范围、质量、资源和交付的记录，才真正进入管理。

下一步可以从一个正在进行的项目开始：写清工时用途与归属口径，选定最少必要字段，连续运行一个短周期，再复盘异常是否转化成了决策。若团队尚小，先用轻流程验证；若多个项目共享资源、需要权限和审计，再评估平台化支持。先把问题定义清楚，再决定记录多细、审核多严、工具多复杂。

真正有效的工时管理，不是证明每个人每天有多忙，而是让项目负责人更早发现计划正在失真，并有证据决定该调整范围、资源、排期还是工作方式。