提升项目效率的秘诀：如何利用项目工时表实现精准管理？

提升项目效率的秘诀：如何利用项目工时表实现精准管理？

项目延期后，管理者最常问的一句话是：“这项工作为什么花了这么久？”但如果工时表只记录“张三今天工作了8小时”，这个问题仍然没有答案。真正有价值的项目工时表，必须把项目、任务、人员、计划工时、实际工时、产出和异常原因关联起来，让团队不仅知道时间花在哪里，还能判断为什么超时、哪些投入值得保留，以及下一次如何把计划做得更准。

我在项目管理实践中反复看到一个现象：很多团队并不是没有填工时，而是填完之后没有形成管理动作。表格越填越复杂，项目经理却仍然依靠会议追进度、依靠经验估算资源，最后工时管理就变成了另一种形式的考勤。本文将从表格设计、填报规则、偏差分析到工具选型，拆解如何把项目工时表从“记录工具”变成真正的项目管理仪表盘。

一、先讲核心结论：工时表不是为了统计谁最忙

1. 工时表的核心价值是解释偏差

项目进度表可以告诉我们任务是否完成，甘特图可以显示任务处于哪个阶段，但它们通常无法解释任务为什么延期。工时表补充的是“实际投入”这一层信息：某项任务原计划需要多少时间，实际花费了多少时间，超出的部分用于什么工作，以及这些投入是否带来了相应产出。

因此，我对工时表的判断标准不是“记录得是否详细”，而是它能否回答以下四个问题：

• 哪个项目或任务正在消耗超出预期的资源？
• 超出的工时是需求变更、返工、等待，还是估算失真？
• 哪些人员存在长期超负荷或频繁被临时任务打断的情况？
• 下一次遇到类似项目时，计划工时应该如何调整？

如果一张表回答不了这些问题，即使每天都有人填报，也很难称为精准管理。它最多是一份时间流水账。

2. 管理者应该关注“时间结构”，而不是总时长

同样是一个项目投入100小时，可能有完全不同的管理含义。80小时用于有效交付、10小时用于必要沟通、10小时用于返工，说明项目过程相对健康；如果只有55小时产生有效产出，30小时用于等待和协调，15小时用于返工，那么项目真正的问题并不是“大家工作不够努力”，而是流程和协作存在损耗。

所以，工时表至少要区分有效产出工时、沟通协调工时、等待阻塞工时、返工修改工时和计划外工时。这样做的目的不是给每一分钟贴标签，而是避免把所有时间简单相加后得出错误结论。

3. 工时数据不能直接等同于个人绩效

实际工时高于计划工时，并不自动意味着执行效率低。复杂任务、紧急需求、跨团队沟通和前置条件缺失，都可能导致投入增加。相反，工时较低也不一定代表效率高，可能是记录不完整、任务被转移给其他人，或者交付质量不足导致问题被推迟到后续阶段。

我更建议把工时数据用于三类管理动作：修正估算、优化流程和调整资源。除非已经建立了稳定的任务分类、质量标准和历史基线，否则不建议用单一工时指标给员工排名或进行惩罚性考核。

二、为什么很多团队填了工时，项目效率仍然没有提升

1. 只记录“今天做了什么”，没有记录“属于哪个任务”

“处理客户需求”“跟进开发”“参加项目会议”是常见填报内容，但这些描述无法支持后续分析。管理者不知道这段时间属于哪个项目、哪个里程碑，也不知道工作最后是否形成了可验收成果。

更好的填报方式是把工作绑定到具体任务。例如，“完成支付接口异常处理”“整理客户确认版需求清单”“修复移动端登录页面兼容性问题”，这些任务不仅可以关联负责人和截止时间，还可以与交付物、缺陷单或评审记录建立对应关系。

2. 只有实际工时，没有计划工时

单独记录实际工时，只能说明团队花了多少时间，无法说明投入是否合理。计划工时是比较基准，哪怕初始估算并不准确，也能帮助团队在项目结束后发现估算偏差。

不过，计划工时不能被理解为绝对标准。新类型任务、探索性工作和技术预研都存在较大不确定性。对于这类任务，我通常建议记录一个区间，例如“预计8至12小时”，而不是强行写成一个看似精确的数字。

3. 把工时表做成了第二张考勤表

考勤关注的是人在不在岗，工时管理关注的是项目投入如何分布。两者的统计目的不同。如果工时表要求员工把每天8小时全部填满，却不允许记录等待、支持、沟通和临时任务，最终得到的数据一定会失真。

有些团队为了让数据看起来完整，会把无法归属的时间全部填到“其他工作”。短期看起来填报率很高，长期却会形成一个无法分析的黑洞。我的建议是保留“计划外工作”和“待归属工时”两个字段，但要求项目负责人在周会前完成归类。

4. 只有填报要求，没有审核和复盘

工时表最常见的失败原因，是管理者要求大家每天填，却没有说明这些数据会如何被使用。如果填报结果不影响排期、不影响资源分配，也不参与项目复盘，成员很快会把它当作行政负担。

一套有效机制至少要包含三个固定动作：成员及时填报，负责人周期性审核，项目结束后沉淀历史数据。缺少任何一个环节，工时数据都很难转化为管理价值。

三、一张可用的项目工时表应该记录什么

1. 先设置不可缺少的基础字段

基础字段的作用是让每条记录能够被准确归属。对于大多数项目团队，以下字段已经足够构成第一版工时表：

这里有一个容易被忽略的原则：项目名称和任务名称必须分开。如果把“客户门户改版，登录模块兼容性修复”全部塞进一个文本框，后续按项目汇总可以做到，但按任务类型、阶段和负责人分析就会非常困难。

2. 再根据管理目的增加分析字段

基础字段解决“记录什么”的问题，分析字段解决“为什么记录”的问题。不同团队不必一次性加入全部字段，应根据管理目的逐步扩展。

如果团队刚开始做工时管理，我不会建议一上来就设计二三十个字段。字段越多，成员填写越慢，错误率越高。比较稳妥的做法是先运行两到四周，观察项目负责人实际需要哪些分析，再增加字段。

3. 让每一条工时记录都能对应一个结果

工时记录不一定都要绑定文件，但应该尽量说明产出或状态。例如设计工作可以关联原型链接，开发工作可以关联代码提交或任务卡片，客户沟通可以关联会议纪要，测试工作可以关联缺陷记录。

这样做的好处是，管理者可以把“投入”与“成果”放在一起判断。尤其当实际工时明显超过计划工时时，交付物和变更记录能够帮助团队区分合理投入与过程损耗。

四、项目工时表怎么设计才不会变成填表负担

1. 先拆任务，再记录工时

任务拆分是工时管理的前置条件。一个任务如果同时包含需求沟通、方案设计、开发、测试和上线，就算记录了40小时，也无法判断是哪一个环节超出了预期。

我的经验是，任务至少要满足三个条件：有明确负责人，有可识别的完成标准，有相对独立的交付结果。对软件研发，可以拆到功能点或缺陷；对设计项目，可以拆到页面、方案版本或交付批次；对咨询项目，可以拆到访谈、分析、报告和汇报阶段。

2. 统一工时口径

在正式启用工时表前，必须先回答几个看似琐碎的问题：会议算不算工时？等待客户反馈算不算工时？临时支持其他项目如何归属？午休是否排除？返工是否另行记录？最小填报单位是15分钟、30分钟还是1小时？

如果这些问题没有统一答案，同一张表里的数据就不能直接比较。有人把会议计入项目，有人把会议填入部门管理；有人把等待时间记在任务上，有人完全不记录。最后，所谓“效率差异”可能只是统计口径差异。

3. 选择与项目节奏匹配的填报频率

• 日填报：适合短周期、任务切换频繁、并行项目较多的团队。
• 周填报：适合周期较长、工作内容相对稳定、成员不希望频繁打断工作的团队。
• 节点填报：适合工程、咨询和阶段性交付项目，在里程碑完成时记录阶段性投入。

日填报通常更准确，但也更容易造成抵触；周填报成本低，却更依赖成员记忆。我通常建议变化快的研发和交付团队采用“每天记录、每周审核”，而不是每周结束时集中补录。

4. 设置异常校验，而不是只追求填报率

工时表可以设置几条简单规则：单日总工时超过12小时自动提醒；任务已关闭但仍出现新增工时时需要审核；计划外工时必须填写原因；单条工时超过8小时需要确认是否存在漏拆任务。

这些规则不应该用来制造处罚，而是帮助项目经理及时发现数据问题。尤其是“单日总工时100%填满”并不是高质量填报的证明，真正需要关注的是记录是否可追溯、任务是否真实完成以及异常是否有解释。

五、如何用工时数据计算项目效率

1. 先计算工时偏差

最基础的指标是工时偏差：

工时偏差 = 实际工时 − 计划工时

例如某任务计划工时为20小时，实际投入26小时，工时偏差就是6小时。这个数字可以帮助项目经理快速识别超支任务，但它本身还不能说明问题原因。

2. 再计算工时偏差率

为了比较不同规模的任务，可以使用工时偏差率：

工时偏差率 =（实际工时 − 计划工时）÷ 计划工时 × 100%

如果计划工时为20小时，实际工时为26小时，偏差率就是30%。如果另一个任务计划工时为4小时，实际工时为6小时，偏差率为50%，但它对项目总投入的影响可能小于前一个任务。因此，偏差率和偏差小时数应当同时查看。

3. 用剩余工时判断任务是否正在失控

只看已经发生的工时，容易等到任务结束后才发现问题。更实用的做法是记录剩余工时，并计算预计总投入：

预计总投入 = 已发生实际工时 + 剩余工时

如果一项任务计划工时为30小时，当前已经投入24小时，但负责人判断还需要10小时，那么预计总投入为34小时，预计偏差率已经达到13.3%。项目经理可以在任务结束前采取动作，而不是等到延期后再复盘。

4. 把工时与有效产出结合起来

对可量化的工作，可以计算单位产出工时：

单位产出工时 = 实际工时 ÷ 有效完成量

例如，一个团队用40小时完成10个经过验收的有效功能点，单位产出工时为4小时/功能点。但这个指标必须建立在产出定义清晰的前提下，不能简单用任务数量代替有效产出，否则成员可能倾向于拆分大量低价值任务来制造“完成量”。

对于研究、创意、战略咨询等工作，产出往往不能被一个数字完整表达。这类项目应当同时观察交付质量、客户反馈、评审通过率和返工工时，避免用单位产出工时进行机械排名。

5. 不要忽视返工、等待和沟通工时

在实际复盘中，返工工时往往比总工时更能揭示流程问题。需求反复确认、设计多轮修改、测试阶段集中暴露缺陷，都会让团队在不知不觉中增加投入。

六、一个完整的项目工时表分析案例

1. 案例背景：总工时没有失控，关键任务却已经预警

下面使用一组情景模拟数据，模拟一个中型企业进行客户门户改版的项目。项目包含需求访谈、原型设计、开发实施和测试修复四类任务。项目总计划工时为74小时，团队在执行过程中发现部分任务已经超时，但整体项目仍然处于可交付范围内。

如果只看开发实施任务，团队甚至可以得出“开发效率不错”的结论；如果只看测试修复，又可能直接把超时归因于测试人员。但把四类任务放在一起看，会发现真正的问题可能在需求和原型阶段：前期范围扩大、评审反复，最终以缺陷和修复的形式在测试阶段集中体现。

2. 专业判断：不能把测试超时直接归咎于测试人员

测试修复任务的实际工时为27小时，比计划多出11小时。第一步应该检查缺陷数量、缺陷严重程度、缺陷来源和修复次数，而不是先比较测试人员的工作时长。

如果多数缺陷来自需求变更和原型修改，那么测试阶段的超时是前置决策的结果。如果缺陷主要来自新增技术方案，说明技术风险评估不足。如果只是测试人员重复验证同一问题，则应改进缺陷流转和环境管理。

这也是工时表与考勤表最大的区别：它不是为了寻找一个“超时责任人”，而是为了找到超时在流程中的传播路径。

3. 复盘结论：下一次应该改变什么

• 需求访谈阶段增加变更确认节点，新增业务场景必须明确是否进入本期范围。
• 原型评审前先确认关键页面和验收标准，减少在开发后期反复修改。
• 测试阶段保留风险缓冲，不再用历史平均工时直接覆盖高变更项目。
• 开发任务继续复用已有组件，但要在计划中单独记录组件适配和兼容性成本。
• 将“返工工时”和“新增需求工时”分开记录，避免两类原因混在一起。

七、如何建立从填报到复盘的工时管理闭环

1. 项目启动时建立工时基准

项目启动阶段不要只录入任务名称和截止时间，还应为主要任务设置计划工时、负责人、验收标准和依赖关系。对于不确定性较高的任务，可以使用区间估算，并记录估算依据。

例如，“完成数据接口开发”不应只写“预计20小时”，还应说明该估算基于几个接口、是否已有数据字典、是否需要联调以及是否包含异常处理。估算依据越清晰，后续偏差分析越有价值。

2. 执行过程中及时填报

最理想的记录时间，是工作完成后不久，而不是项目结束时凭记忆补录。集中补录会产生两个问题：一是时间被平均分配到多个任务，二是成员容易遗漏等待、沟通和临时支持。

为了降低负担，可以采用以下规则：

1. 单条记录尽量对应一个任务，不使用大段模糊描述。
2. 每天只要求记录发生变化的任务，不要求重复填写完全相同的内容。
3. 对会议、等待和返工使用固定工作类型，减少自由文本。
4. 允许移动端或在线表格快速填报，避免必须打开复杂系统。
5. 当天未填报时自动提醒，但不要把提醒设计成惩罚通知。

3. 每周只分析三类异常

项目周会上不建议把所有工时记录逐条念一遍。我通常会先筛选三类数据：超出计划的任务、明显增加的返工工时、持续出现的计划外工时。

每一类异常都应该对应一个动作。例如，任务超时需要判断是否调整截止时间；返工增加需要安排质量评审；计划外工时增加需要重新确认项目范围和资源容量。没有动作的报表，只会让成员进一步怀疑填报的意义。

4. 项目结束后建立历史基线

历史工时数据的价值，往往在下一个项目中才真正体现。团队可以按项目类型、任务类型、人员角色和复杂度建立基线。例如，普通营销页面设计的历史中位数是12小时，高度定制页面的历史中位数是24小时，那么下一次估算就不应再使用一个笼统的16小时。

我更推荐使用中位数和区间，而不是只使用平均值。少数极端项目会显著拉高平均数，中位数更能反映典型任务的投入水平；而上下四分位区间则能提醒项目经理保留合理的风险缓冲。

八、PingCode等项目管理工具如何帮助中大型团队落地

1. 什么时候值得从Excel升级

Excel适合项目数量少、人员规模小、任务关系简单的团队。只要项目经理能够通过筛选、透视表和简单公式完成汇总，暂时没有必要为了“数字化”而增加系统成本。

但当组织出现以下情况时，继续依赖Excel通常会产生明显摩擦：

• 一个成员同时参与多个项目，工时需要按任务自动归集。
• 项目数量较多，负责人需要查看跨项目资源占用。
• 任务状态、工时、缺陷和交付物分散在不同表格中。
• 项目经理每周要花数小时合并版本、核对重复记录。
• 企业对权限、审计、私有化部署或数据安全有明确要求。

对于100人以上、项目并行度较高的中大型组织，PingCode这类项目管理平台可以把任务、负责人、进度、工时和项目报表放在同一套管理链路中。它更适合解决“多人协作、跨项目统计和过程追踪”的问题，而不是简单替代一张Excel表。

2. 选择工具时，不要只看有没有工时字段

很多平台都可以添加“实际工时”字段，但这不代表它适合项目工时管理。真正需要检查的是工时能否与任务关联，计划工时和剩余工时能否同时维护，是否支持按项目、人员、部门和时间范围汇总，以及异常数据能否被提醒。

如果组织已有较复杂的研发管理流程，还需要关注历史数据迁移和系统集成。PingCode支持Jira平滑迁移，对于正在进行国产化替代、又不希望重新建立全部项目数据的团队，迁移能力会直接影响切换成本。

对于对数据边界要求较高的企业，私有化部署也是重要考察项。它可以让企业根据自身的基础设施、权限体系和安全要求安排部署方式。不过，私有化部署并不意味着实施可以省略，项目编码、角色权限、字段口径和报表规则仍然需要提前设计。

3. 工具落地的正确顺序

1. 先定义口径：明确什么算项目工时，什么算部门支持，返工和等待如何记录。
2. 再统一任务结构：规定项目、阶段、任务和子任务的层级关系。
3. 再配置字段：优先保留项目、任务、负责人、计划工时、实际工时和异常原因。
4. 再设置报表：先做项目偏差、人员负荷和计划外工时三类基础报表。
5. 最后推广：选择一个项目试运行，确认填报成本和数据质量后再扩大范围。

我不建议企业在系统上线第一天就要求所有部门填报几十个字段。工具的作用是降低管理成本，而不是把原本模糊的流程包装成更复杂的线上流程。

4. Excel、在线表格和项目管理平台的取舍

九、不同项目类型下，工时表应该怎样调整

1. 软件研发项目：重点记录任务、缺陷和返工

研发团队的工时记录通常需要关联需求、开发任务、测试任务和缺陷。仅记录“开发8小时”价值不高，最好进一步说明对应的功能点、技术债、缺陷修复或代码重构。

研发项目尤其要区分“新功能开发”和“缺陷修复”。如果二者混在一起，管理者会误以为开发速度下降，实际可能是版本质量问题增加了修复投入。

2. 设计和内容项目：重点记录版本和修改轮次

设计、文案和内容项目的工时偏差，常常来自修改次数而不是制作速度。因此，工时表应增加交付版本、评审轮次、客户反馈次数和返工标记。

如果同一页面经历三轮以上重大修改，项目经理应该回到需求确认和评审机制上找原因，而不是要求设计人员压缩制作时间。

3. 咨询和专业服务项目：重点记录客户、阶段和可计费性

咨询项目通常同时包含客户会议、资料分析、报告撰写、内部讨论和售后支持。工时表需要区分可计费工时、不可计费工时和内部支持工时，否则报价、预算和项目利润分析都会出现偏差。

对于客户现场工作，还应记录服务对象、工作地点和交付成果。这样才能判断某类客户需求是否长期消耗额外资源，并为下一次报价提供依据。

4. 工程和施工项目：重点记录班组、工序和现场因素

工程项目的工时不能简单按照个人每天工作几小时来统计，还需要关联工序、班组、施工区域、设备和天气等现场因素。等待材料、等待验收和设备故障都可能影响实际工时。

这类项目更适合按阶段或关键节点填报，而不是要求所有人员频繁填写复杂表单。管理重点是识别工序衔接和现场依赖造成的损耗。

十、项目工时管理中的六个常见误区

1. 只记录总时长，不记录工作内容

“今天投入8小时”无法支持任务复盘。至少要记录项目、任务和工作类型，必要时增加交付物链接或异常原因。

2. 把工时少直接理解为效率高

工时少可能意味着任务简单、经验复用，也可能意味着工作没有记录完整。必须结合完成质量、验收结果和返工情况判断。

3. 把超时直接归因于个人能力

超时可能是任务拆分不合理、需求边界不清、依赖未完成或评审反复造成的。没有原因分类之前，不宜把偏差率直接用于个人评价。

4. 只看项目总工时，不看计划外投入

项目总工时没有明显超支，并不代表管理健康。如果大量临时需求被成员分散吸收，项目可能只是把范围失控隐藏在正常工时中。

5. 让所有人一次性填写过多字段

字段越多并不代表数据越精准。填报时间过长会降低及时性，也会增加选择错误。应先使用核心字段，再根据复盘需要增加字段。

6. 只做统计，不做行动

工时表必须服务于排期、资源、预算、报价或复盘中的至少一个决策。如果数据没有触发任何变化，它就很难长期获得团队配合。

十一、不同情况下的行动建议与管理取舍

1. 团队人数少、项目简单：先用轻量表格

如果团队只有几个人，同时运行的项目不超过三个，建议先用Excel或在线表格建立统一模板。重点不是购买工具，而是把项目、任务、计划工时、实际工时、工作类型和异常原因这几个字段跑通。

这类团队的取舍是：牺牲部分自动化，换取低成本和快速试错。只要能够坚持连续记录两到四周，并在周会上复盘超时任务，就已经能发现不少问题。

2. 项目数量增加、人工汇总变慢：升级在线协作方式

当项目经理每周需要花数小时合并多个表格，或者成员分散在不同地点时，在线表格会比本地Excel更适合。重点检查权限、历史修改记录、筛选汇总和提醒能力。

这类方案的短板是，任务关联和流程自动化可能不够强。若团队已经出现大量跨项目资源冲突，继续靠多个在线表格拼接，可能只是延缓系统化管理的时间。

3. 中大型组织、多项目并行：优先考虑平台化管理

对于100人以上的组织，工时表往往不再是单个项目经理的个人工具，而是涉及研发、产品、测试、交付、财务和管理层的共同数据。此时需要统一项目编码、任务层级、权限规则和报表口径。

PingCode这类项目管理平台适合将工时与任务、迭代、缺陷和项目进度关联起来，也更适合查看跨项目资源分布。对需要私有化部署、关注数据安全，或者希望从Jira平滑迁移的企业，迁移能力和部署模式应纳入选型评估。

但平台化的代价是实施和治理。企业必须投入时间清理历史项目、定义角色权限、培训成员并建立数据审核机制。工具功能越强，越不能忽略基础管理设计。

4. 项目处于探索阶段：不要过早追求精确到分钟

预研、创新和战略项目的不确定性较高，过度强调精确工时可能让成员为了填表而填表。此时可以用半天或小时作为最小单位，重点记录阶段、假设、实验结果和阻塞原因。

这类项目更适合关注投入上限和阶段性产出，而不是用偏差率评价个人。项目经理应该先判断“是否值得继续投入”，再讨论如何提高单位工时产出。

5. 项目即将延期：先处理风险，不要先完善表格

项目已经出现延期迹象时，最优先的动作不是增加字段，而是找出影响最晚交付节点的任务。查看剩余工时、任务依赖、负责人负荷和计划外工作，判断是缩小范围、增加资源、调整顺序还是重新确认交付时间。

工时表的作用是帮助快速定位问题，而不是在风险已经发生时继续扩大行政流程。

十二、落地项目工时表的30天行动方案

1. 第1周：统一口径和字段

• 确定哪些时间计入项目工时。
• 确定会议、等待、返工和计划外工作的分类方式。
• 建立项目、任务、负责人、计划工时和实际工时字段。
• 选择一个真实项目作为试点。

第一周不要追求复杂报表，只要保证每条记录能准确找到项目和任务。字段口径统一，比表格外观精美更重要。

2. 第2周：开始日常填报

• 成员在工作完成后及时记录。
• 项目负责人每天或隔天检查明显异常。
• 对“其他工作”和“计划外工作”进行二次归类。
• 记录任务的剩余工时和预计完成时间。

这一阶段最容易出现的问题是成员忘记填报。可以通过提醒降低遗漏，但不要把未填报直接定义为绩效问题，否则成员可能优先追求形式完整，而不是数据真实。

3. 第3周：识别偏差和损耗

• 计算计划工时与实际工时的偏差。
• 筛选偏差率超过20%的任务。
• 统计返工、等待和计划外工时占比。
• 检查是否有成员同时承担过多项目。

20%可以作为初始观察阈值，但不应被当作绝对标准。对于计划工时很小的任务，1小时偏差可能导致偏差率很高；对于复杂任务，较大的绝对偏差反而更值得关注。

4. 第4周：形成管理动作

• 选择三项最主要的超时原因。
• 为每项原因指定负责人和改进动作。
• 更新同类任务的估算区间。
• 决定是否需要升级到在线表格或项目管理平台。

30天结束时，团队不一定会得到完美的效率模型，但应该能够回答：哪些任务最容易超时，超时主要由什么造成，哪些字段真正有用，以及下一次项目计划应该如何调整。

十三、结语：真正精准的不是表格，而是管理判断

项目工时表本身不会自动提升效率。它真正能做的，是把过去依靠感觉判断的项目问题，转化为可以追踪、比较和复盘的数据。

一张有价值的工时表，至少要完成三次连接：把时间连接到任务，把任务连接到产出，把偏差连接到管理动作。只有这样，管理者才不会停留在“谁投入了多少小时”，而是能够进一步判断“哪些投入产生了结果，哪些时间被流程浪费，下一次应该怎样重新安排”。

如果团队准备开始实施，可以先做三件事：建立包含项目、任务、计划工时、实际工时和异常原因的基础表；连续记录两到四周；在周会上只分析超时、返工和计划外工时三类问题。等数据口径稳定后，再考虑自动化汇总、权限管理和平台化升级。

我的最终建议是：不要先追求一张功能齐全的工时表，而要先建立一个能够产生行动的最小闭环。当团队开始依据工时数据调整排期、澄清需求、减少返工并修正下一次估算时，工时表才真正从“填表任务”变成了提升项目效率的管理基础设施。