投入比例实操方法：产品经理提升人力资源计划效率的制度设计方法与模板

投入比例实操方法：产品经理提升人力资源计划效率的制度设计方法与模板

很多产品团队的人力资源计划，表面上有“投入比例”这一列，实际上只是把人名、岗位和百分比填进表格：产品经理 30%、开发工程师 80%、测试工程师 50%。真正执行两周后，比例就失真，开发被临时需求打断，测试集中在发布前加班，产品经理花大量时间协调，却仍然无法回答“这项工作到底占用了多少人力、为什么延期、下个月要不要继续投入”。我在项目复盘中发现，投入比例不是一个填报字段，而是一套连接目标、容量、优先级、预算和责任边界的制度。

本文给出一套可落地的投入比例制度设计方法，重点解决五个问题：投入比例如何定义、如何换算为可用人天、如何处理临时需求、如何让比例与项目结果关联、如何借助项目管理系统形成持续校准。文中的案例数据采用脱敏情景模拟，计算口径和模板来自中大型产品团队的常见管理实践；涉及系统落地时，我会以 PingCode 这类面向 100 人以上组织的项目管理平台为例说明，但不会把工具功能误当成制度本身。

一、先讲核心结论：投入比例不是分配结果，而是资源承诺机制

1. 先确定四个核心判断

我对投入比例的第一个判断是：投入比例必须绑定时间周期、工作对象和交付责任。只说“某开发投入 60%”没有管理意义，因为别人不知道这是本月 60%、某个项目周期 60%，还是在所有工作时间中平均占比 60%。没有时间窗口和对象，比例就无法核算，也无法复盘。

第二个判断是：投入比例不能直接等同于工时比例。一个人名义上投入某项目 50%，并不代表每天有 4 小时可被项目经理自由调度。会议、代码评审、线上故障、客户支持、学习和组织事务都会消耗容量。制度设计时应先扣除不可分配时间，再计算项目可用容量。

第三个判断是：比例的价值不在于预测得多精确，而在于暴露冲突。如果一个人的计划投入合计达到 130%，这并不意味着系统算错了，而是说明组织正在用同一个人承担互相冲突的承诺。比例制度的首要作用，是在项目启动前暴露资源冲突，而不是在月底把超支解释得更漂亮。

第四个判断是：投入比例必须允许偏差，但不能允许无解释偏差。实际投入超过计划 10%并不一定是问题，可能是线上事故或关键客户验收导致的合理变化；但如果每周都超过 20%，且没人说明原因，说明计划基线、需求准入或职责边界已经失效。

2. 一套可执行的投入比例公式

建议将个人月度可分配容量定义为“有效工作日 × 每日标准工时 × 专注系数”，而不是直接用自然月总工时。以一个月 21 个工作日、每日 8 小时、专注系数 0.75 为例，理论工作时长为 168 小时，可用于项目和业务目标的有效容量约为 126 小时。

公式可以写成：

个人有效容量 = 工作日 × 标准日工作时长 × 专注系数 − 已锁定的不可分配时间

项目投入比例 = 项目计划工时 ÷ 个人有效容量

项目计划工时 = 个人有效容量 × 项目投入比例

专注系数不是给员工打折，而是承认真实组织环境中的沟通、评审、上下文切换和突发事务。专注系数可以按岗位和团队成熟度设定：研发团队通常在 0.65，0.80 之间，产品经理可能在 0.55，0.75 之间，承担大量跨部门沟通的项目经理可能更低。

3. 先管“容量”，再管“比例”

如果团队一开始就要求所有人填投入比例，往往会得到一张看似完整、实际无法执行的表。正确顺序应当是：先确认每个人本周期有多少有效容量，再列出必须承担的固定工作，最后把剩余容量分配给项目和产品目标。

1. 确认本周期工作日、休假、培训和长期出差。
2. 扣除固定会议、值班、客户支持、招聘面试和组织职责。
3. 根据历史数据确定专注系数。
4. 计算个人可分配容量。
5. 将容量分配给项目、产品线、技术债和预留缓冲。
6. 检查所有投入比例是否合计超过 100%。

我建议大多数团队至少预留 10%，15%的缓冲容量。缓冲不是浪费，而是用来吸收需求澄清、线上故障、供应商延迟和小型紧急事项。如果团队把 100%的有效容量都提前分配完，任何突发事件都会变成加班或延期。

二、真实场景：为什么投入比例填了，项目仍然不断延期

1. 一个典型的多项目产品团队

我曾经参与过一类非常典型的产品组织：团队规模约 60 人，研发、测试、产品、设计和项目管理人员同时服务三个业务方向。管理层要求每月提交资源计划，表格中也有投入比例，但项目仍然频繁延期。复盘后发现，问题不是缺少表格，而是三种不同的“投入”被混在了一起。

第一种是承诺投入，也就是部门负责人认为某人应该投入多少；第二种是计划投入，也就是项目负责人根据排期安排多少；第三种是实际投入，也就是员工真实花费多少时间。三者没有统一口径，导致管理层看到的是 100%的分配，员工感受到的是 130%的工作量，项目负责人则认为资源始终不够。

例如，一名后端工程师计划投入核心项目 60%、客户定制项目 25%、技术债 15%，合计正好 100%。但实际工作中，他每周还要花 6 小时处理生产问题，参加两个跨部门会议，并承担数据库迁移支持。结果核心项目实际只能获得约 45%的有效投入，却仍然按照 60%的计划计算交付日期。

2. 产品经理最容易忽略的隐形工作

产品经理经常把需求分析、原型设计、评审和验收纳入计划，却漏掉了大量“看不见但必须发生”的工作：用户访谈预约、数据口径确认、法务沟通、运营培训、客服答疑、发布公告、灰度观察和上线后的问题跟踪。

这些工作如果不进入投入计划，就会形成虚假产能。产品经理会觉得自己明明只负责两个项目，为什么每天仍然无法完成关键任务；研发会觉得需求总在变，测试会觉得验收标准不断补充，管理层则把问题归因于执行力不足。

我的经验是，产品经理至少要把投入拆成四类：目标产品工作、跨部门协同工作、运营与客户支持、产品能力建设。只有第一类被看见，计划一定会偏乐观。

3. 临时需求是制度问题，不是个人抗压能力问题

很多组织把临时需求称为“业务灵活性”，但如果临时需求没有准入条件、优先级和资源来源，它就会变成对原计划的无偿侵占。真正成熟的制度不会试图消灭所有临时需求，而是要求每个临时需求回答三个问题：它为什么现在必须做、由谁承担新增投入、原计划中哪项工作需要下调。

如果新增工作没有对应的容量来源，项目负责人就不应只更新截止日期，而应同步更新投入比例、交付范围或风险等级。否则，计划表会继续显示“按期”，实际交付却已经不可控。

三、常见误区：投入比例为什么会失真

1. 误区一：把比例当成“员工努力程度”

投入比例描述的是资源分配，不是绩效评分。一个人投入某项目 80%，并不代表其绩效贡献一定高于投入 40%的人。复杂项目可能需要较少人力但承担更高风险，基础能力建设可能短期没有可见成果，却决定未来交付效率。

如果管理者把比例直接用于评价个人努力程度，员工会倾向于夸大工时、争抢高可见度项目，甚至把低价值会议记录为项目投入。比例制度因此会从资源规划工具退化为形式化汇报工具。

2. 误区二：所有岗位使用同一种投入颗粒度

开发工程师适合按工作包、迭代或模块估算，测试工程师适合按测试阶段和风险类型估算，产品经理则更适合按目标、产品线和关键活动估算。强行让所有岗位按照相同颗粒度填报，会造成两种结果：要么颗粒度过粗，无法用于排期；要么颗粒度过细，填报成本高于管理收益。

3. 误区三：用“人月”替代真正的能力分析

同样是 1 人月，不同人的有效产出差异很大。新成员需要熟悉业务和代码，跨团队协作复杂的项目会产生更多沟通成本，关键岗位的缺席还可能造成等待。人月只能描述投入量，不能自动代表交付能力。

因此，我建议在投入比例之外增加“能力约束”字段，包括领域熟悉度、关键技能、决策权限、替补人员和外部依赖。资源计划不仅要回答“有多少人”，还要回答“这些人能否在这个时间点完成这类工作”。

4. 误区四：月底集中填报实际投入

月底补填的实际投入往往依赖记忆，容易被近期事件覆盖。员工会记得最后一周的加班，却忘记第二周等待数据的时间；项目负责人会记得发布日，却不一定能还原需求反复修改造成的隐性消耗。

实际投入不一定要精确到每 15 分钟，但至少应按周记录主要工作对象和异常原因。对多数知识型团队而言，周度区间记录比月末精确补填更有价值，也更容易坚持。

5. 误区五：看到超配就立即削减资源

如果一个项目长期显示投入比例超过 100%，不一定意味着应该直接砍人。可能是估算偏差、范围扩大、关键依赖迟迟未解决，也可能是项目已经进入高风险阶段，需要短期集中投入。削减资源之前，必须先判断超配的来源。

• 估算偏差：工作量本身被低估，需要校准估算模型。
• 范围扩张：新增需求未走变更流程，需要重新确认目标。
• 等待损耗：资源被阻塞，增加人员未必能解决问题。
• 能力错配：投入的人数足够，但缺少关键技能。
• 优先级冲突：多个项目同时抢占同一关键角色。

四、专业判断逻辑：如何把投入比例设计成一套制度

1. 先定义投入对象，而不是先定义百分比

制度设计的第一步是确定投入比例到底分配给什么对象。对产品经理来说，投入对象可以是产品目标、项目、需求主题、客户交付、运营活动和能力建设。对象过多会增加管理成本，对象过少又无法解释资源去向。

我通常采用三级结构：一级是产品线或业务目标，二级是项目或需求主题，三级是关键活动。月度资源计划使用一级和二级，周度执行只追踪三级中的高风险事项。这样既能支持管理层看资源结构，也不会让执行人员陷入过度填报。

（1）一级对象：回答为什么投入

一级对象应直接连接业务目标，例如提升新客户转化、降低交付成本、改善稳定性或完成合规要求。它不应只是部门名称，也不应只是一个项目代号。

（2）二级对象：回答投入到哪里

二级对象通常是项目、产品模块、版本或需求主题。它需要有明确负责人、起止周期和验收标准，否则投入比例无法与结果关联。

（3）三级对象：回答本周做什么

三级对象包括用户访谈、方案评审、接口开发、回归测试、数据分析等具体活动。只有在项目存在明显风险、依赖或资源冲突时，才需要追踪到这一层。

2. 建立“计划比例，实际比例，产出结果”三联表

单独看计划比例，无法判断计划质量；单独看实际比例，无法判断投入是否合理；单独看产出结果，无法解释资源消耗。三联表把这三个维度放在同一个视图中，才能形成真正的管理闭环。

这张表最重要的不是计算精度，而是帮助团队识别结构性问题。例如，核心版本实际投入增加 6.3 小时并延期，客户项目实际投入减少却按期完成，技术债被临时支持挤压。管理层不能只得出“研发投入不够”的结论，而应进一步处理线上稳定性和需求变更问题。

3. 设置偏差分级，而不是只设一个红线

我建议至少设置三级偏差。绿色区间表示计划与实际差异在可接受范围内；黄色区间要求项目负责人解释原因并提出调整；红色区间则必须触发资源评审或范围重排。

百分比阈值不应机械套用。对于高风险上线项目，10%的波动可能很正常；对于固定流程、工作量稳定的运营任务，10%的波动就值得调查。阈值最终应根据团队历史数据校准，而不是照搬其他公司的制度。

4. 把“决策等待”纳入投入损耗

项目资源计划经常只统计执行工时，却忽略等待产品决策、业务确认、接口权限和环境准备产生的时间损耗。等待不是员工没有工作，而是项目没有形成有效流动。

建议给每个关键任务增加阻塞原因和阻塞时长。若同一项目连续两周出现超过 8 小时的决策等待，就不应继续要求执行人员保持原投入比例，而应由负责人推动决策或调整排期。

在某些团队中，减少一次跨部门决策等待，比增加一名普通执行人员更有效。因为瓶颈可能在决策权，而不是在执行容量。

五、具体案例：一个产品团队如何从“填比例”转向“管容量”

1. 案例背景与初始数据

以下案例是基于真实管理问题整理的脱敏情景模拟。团队为一家中大型企业的软件产品部门，产品、研发、测试、设计和项目管理共 42 人，同时推进平台升级、客户交付、稳定性治理和新业务试点四类工作。团队此前每月填一次资源表，但没有统一的有效容量口径。

初始计划显示，全部人员投入比例合计为 100%，管理层认为资源分配已经平衡。然而，连续三个迭代出现延期，平均延期 6.5 个工作日，需求返工率达到 22%，技术债完成比例只有计划的 38%。

复盘时，我们先没有修改比例，而是重新统计固定事务。结果发现，42 人每月理论容量约为 7,056 小时，扣除会议、支持、值班、培训和休假后，可分配容量约为 5,460 小时，实际计划却仍按 7,056 小时进行。

2. 重新计算后的容量结构

重新计算后，团队发现原本所谓的 100%项目投入，实际只有约 70%的理论工作时间可以进入项目。这个结果并不意味着团队效率低，而是说明以前的计划口径把固定事务和风险缓冲全部隐藏了。

3. 四周试运行后的变化

试运行期间，团队没有要求所有人每天填写工时，而是每周五更新三个字段：本周主要投入对象、实际投入区间、超过计划的原因。产品经理额外记录需求变更、决策等待和客户支持三类事项。

第一个月并没有立刻让所有项目按期完成，但资源冲突提前暴露了。原来同时占用 5 名核心工程师的四个项目，被重新拆成两个主项目、一个维护项目和一个延期项目。延期项目在立项时就完成了对业务方的沟通，而不是在发布日期临近时才被动解释。

试运行四周后，团队观察到以下变化：计划投入与实际投入的平均绝对偏差从 27%下降到 13%，需求返工率从 22%下降到 14%，项目负责人每周用于追问资源状态的时间从约 14 小时下降到 8 小时。技术债完成比例仍然没有大幅提升，但团队已经能清楚看到它被哪些紧急事项挤压。

4. 案例中最重要的管理变化

这个案例最有价值的变化并不是偏差从 27%降到 13%，而是团队开始讨论“为什么偏差发生”。此前大家争论的是谁没有按计划投入，之后讨论变成了需求是否完成评审、客户支持是否有固定容量、哪个项目拥有更高优先级。

这说明投入比例制度的成熟标志，不是表格越来越复杂，而是团队开始用同一套事实讨论取舍。只要不同角色仍然使用不同的容量口径，任何数字都会变成争论材料。

六、模板设计：一张表如何支撑月度规划和周度执行

1. 月度投入比例计划模板

下面这张模板适合产品负责人、项目负责人和部门主管在月度资源会议中使用。建议将比例、工时、结果和风险放在同一张表中，避免只看资源分配、不看交付承诺。

2. 周度投入比例校准模板

周度校准不应重复填写整张月度计划，而应只记录变化。建议保留以下字段：

• 本周实际投入对象：选择项目、产品线或工作主题。
• 实际投入区间：例如 0%，20%、20%，40%、40%，60%。
• 与计划的偏差：低于计划、基本一致、高于计划。
• 偏差原因：需求变更、线上故障、决策等待、人员缺席、估算偏差或其他。
• 下周动作：维持、增加、减少、暂停或转交。
• 是否需要升级：是否需要产品负责人、部门主管或业务负责人决策。

我不建议所有团队一开始就追求精确到小时。对于跨项目协作频繁的组织，先使用区间记录更容易形成稳定习惯。等团队积累 6，8 周数据后，再判断哪些岗位和工作类型值得精细化计时。

3. 变更申请模板

4. 用某项目管理平台承载模板时的字段设计

以 PingCode 这类项目管理平台为例，建议不要只创建一个“投入比例”字段，而是将资源计划拆成项目、工作项、负责人、计划周期、预计工时、实际工时、优先级、阻塞原因和变更状态等字段。这样平台中的任务数据才能与资源视图、迭代计划和交付结果关联。

对于 100 人以上组织，资源计划通常涉及多个部门和项目。此时更重要的是统一字段和权限：员工更新实际工作对象，项目负责人调整计划投入，部门负责人确认容量冲突，产品负责人决定范围和优先级。工具负责记录和计算，制度负责定义谁可以改变什么。

平台落地时，我建议先从一个产品线或一个项目群试点，不要一开始把全公司所有岗位都纳入。先验证四件事：容量公式是否被接受、填报成本是否可控、偏差是否能够触发行动、管理层是否真的使用结果做取舍。

七、工具落地：如何避免资源计划变成另一套低效报表

1. 工具应该解决三类问题

第一类是数据一致性问题。项目名称、人员归属、工作周期和优先级必须使用统一字段，否则不同部门会用不同名称描述同一项工作，无法汇总。

第二类是计算问题。系统应自动计算个人有效容量、项目投入比例、计划工时和实际工时，避免员工重复维护多个表格。

第三类是提醒问题。系统可以在投入比例超过阈值、任务长期阻塞、实际投入连续偏离计划时提醒负责人，但提醒必须连接到明确的处理动作，否则只会产生更多通知。

2. 建议配置的最小数据模型

3. 什么时候不应该上复杂系统

如果团队只有一个项目、人员不会跨项目协作、工作周期短且固定，使用简单表格可能更合适。复杂系统会增加维护成本，甚至让团队把注意力放在字段完整性，而不是资源冲突和交付结果上。

如果组织尚未明确项目优先级，也没有任何人拥有最终取舍权，先上系统通常不会解决问题。系统只能把冲突展示出来，不能替管理层做决定。此时应先建立项目分级、需求准入和变更授权制度。

如果团队对实际投入存在强烈不信任，直接启用精细工时采集容易引发抵触。更稳妥的做法是先从项目级和周度区间开始，证明数据能够帮助团队减少无效协调，再逐步增加颗粒度。

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

1. 单项目团队：先建立最小闭环

单项目团队不需要复杂的跨项目资源矩阵。建议只记录角色、有效容量、任务包、预计工时、实际工时和风险缓冲。重点观察任务是否按阶段流动，以及关键人员是否出现瓶颈。

这类团队最容易犯的错误，是把所有人都安排到 100%项目投入。建议保留 10%左右缓冲，尤其是首次合作、技术方案未知或外部依赖较多的项目。

2. 多项目团队：优先管理关键角色

多项目团队不必一开始追踪所有人员，而应先找到资源冲突最严重的角色，例如架构师、资深后端、数据工程师、测试负责人和核心产品经理。只要这些关键角色的投入计划稳定，项目群的主要风险就能被提前看见。

对于关键角色，建议设置“单周期最多承诺项目数”。例如一个架构师同一周期最多承担两个重点项目，第三个项目必须进入排队或指定替补。这样比单纯把三个项目分别填成 30%、30%、30%更能保护上下文切换成本。

3. 研发与产品长期被临时需求打断：建立服务容量池

如果团队每周都有线上问题、客户支持和紧急需求，建议单独建立服务容量池，不要继续把这些工作藏在各项目比例里。服务容量池可以由固定人员轮值，也可以按团队比例预留。

固定服务容量的优点是项目计划更稳定，缺点是部分周期可能出现容量闲置。按比例预留的优点是灵活，缺点是所有项目都可能被临时事务打断。选择哪一种，取决于故障频率、客户响应要求和团队规模。

4. 交付型组织：把客户差异化需求分层

客户交付团队经常把每个客户都视为最高优先级，导致资源计划失去意义。建议将客户需求分为标准产品能力、可配置能力、一次性交付、定制开发和售后支持五类，并为每类设置不同的投入上限。

5. 处于降本阶段：不要只按比例削减人力

降本时最常见的做法是各部门统一削减 10%人力，但这种做法可能留下关键岗位瓶颈，反而让项目延期和返工增加。更合理的做法是先识别低价值工作、重复协调、等待和范围膨胀，再决定减少项目数量、降低交付范围还是调整人员结构。

如果必须削减资源，我建议按照以下顺序取舍：

1. 先暂停低价值、低紧急度且没有明确结果的工作。
2. 再合并重复建设，统一公共能力和数据口径。
3. 然后降低非关键范围，保留核心用户路径。
4. 最后才调整关键岗位投入，避免把瓶颈人员分散得更严重。

6. 处于高速增长阶段：用投入比例保护长期能力

高速增长团队通常只关注新功能和客户交付，很容易把技术债、自动化测试、数据治理和产品研究全部压缩。短期看交付速度上升，几个月后返工、故障和人员流失会同时增加。

建议至少保留 15%，20%的团队容量用于稳定性、自动化、平台能力和产品研究。具体比例应根据事故率、返工率和未来增长目标调整。这个比例不是固定福利，而是为未来交付能力购买时间。

九、30天落地计划：从一张表开始，而不是从大系统开始

1. 第1周：统一定义和统计口径

第一周只做三件事：定义有效容量、定义投入对象、定义偏差阈值。不要急着让所有人填表，也不要急着配置复杂看板。

• 选择一个产品线或项目群作为试点范围。
• 统计过去一个月的会议、支持、休假和临时事项。
• 确定岗位级专注系数，并说明它只是计划参数，不是绩效评分。
• 确定项目优先级和资源冲突的升级路径。

2. 第2周：建立月度基线

第二周由产品负责人、项目负责人和部门负责人共同完成月度资源计划。每个项目必须填写目标、关键交付、预计投入、资源来源和主要风险。没有明确结果的工作，不应占用正式项目容量。

在这一周不要追求所有数字精确。更重要的是把明显超过 100%的人员和同时被多个项目占用的关键角色找出来。

3. 第3周：开始周度校准

第三周开始，每个人只需要更新实际投入对象、偏差方向和原因。项目负责人负责处理黄色偏差，部门负责人负责处理红色偏差。任何变更都必须说明是增加资源、减少范围、延后时间还是降低质量风险。

如果团队成员反馈填报成本过高，应优先减少字段，而不是要求大家加班完成报表。制度的目标是改善资源决策，不是制造新的行政工作。

4. 第4周：复盘制度，而不是复盘个人

第四周复盘时，应关注四类问题：计划是否过度乐观、临时需求来自哪里、等待是否成为主要损耗、哪些投入没有产生预期结果。

不要把复盘变成员工工时审计。真正需要改进的，可能是需求准入、决策机制、项目数量、系统依赖或管理层的优先级冲突。

5. 30天后应形成的管理资产

• 岗位级有效容量参数。
• 项目和产品线的投入结构。
• 计划投入与实际投入偏差记录。
• 临时需求的准入与替换记录。
• 关键角色的跨项目冲突清单。
• 决策等待、返工和阻塞的主要原因。
• 下一周期需要调整的资源、范围和优先级。

十、最终取舍：投入比例制度到底应该追求什么

1. 追求可解释，不追求绝对精确

知识型工作本身存在不确定性，任何投入比例都不可能精确到真实价值。制度应该帮助团队解释偏差、识别冲突和做出取舍，而不是制造一种“只要数字准确，项目就会按期”的错觉。

2. 追求资源流动，不追求人员满载

人员 100%满载并不代表组织效率最高。满载意味着没有空间处理突发问题，也意味着多个项目会在同一关键节点竞争资源。一个保留缓冲、能够快速响应高价值事项的团队，往往比一个表面上人人满负荷的团队更稳定。

3. 追求责任清晰，不追求流程复杂

投入比例制度必须明确谁填、谁审、谁能改、谁做最终取舍。如果这些责任没有定义，再复杂的系统也只会产生更多数据。工具可以自动计算，却不能替代优先级决策。

4. 追求结果关联，不追求工时漂亮

投入比例最终要回到结果：项目是否按期、范围是否稳定、质量是否达标、用户问题是否解决、产品能力是否积累。如果某项工作投入很高却没有结果，应检查目标是否合理、工作是否被阻塞，或者是否存在重复建设。

5. 给产品经理的最后建议

如果只能做一件事，我建议产品经理先建立“计划比例，实际比例，偏差原因，下周动作”四列周度记录。不要等待完整的资源系统，也不要等待所有部门达成一致。连续记录四到六周后，团队就能看到哪些项目总在超配、哪些角色总在被打断、哪些需求总是绕过正式流程。

如果还能再做一件事，就把临时需求的资源来源写进制度：任何新增事项必须明确由谁承担、替换什么、延期什么，或者增加多少容量。这条规则看似简单，却能把大量隐性加班、无效争论和项目延期提前暴露出来。

投入比例真正的价值，不是把每个人切成几块，而是让组织承认一个事实：人力资源是有限的，所有承诺都必须付出容量代价。产品经理只有把比例、容量、优先级和结果放在同一张决策桌上，才能从“协调资源的人”转变为“设计交付系统的人”。

下一步可以从一个项目群开始，先计算有效容量，再建立月度基线，随后用周度偏差推动调整。等团队能够稳定回答“本周人力去了哪里、为什么变化、下周要牺牲什么”时，投入比例才真正从一张表变成了提升人力资源计划效率的制度。