人力资源计划资源冲突教程：项目成员效率提升，避坑指南

在人力资源计划里，最容易被误判的资源冲突，不是“项目缺人”，而是同一个关键成员被三位负责人同时排进了同一周。计划表上每个项目都有负责人、每个人看起来也都没有闲着；真正执行时，会议、评审、临时支持和返工叠加，计划工时被挤掉，项目却仍按满负荷推进。处理这类问题，重点不是把成员排得更满，而是先识别有效产能，再公开冲突规则，最后用滚动计划验证调整是否真的减少了等待和返工。

一、先讲核心结论：资源冲突不是排班问题，而是优先级与产能问题

1. 不要把“有空”误认为“有产能”

在我做项目资源盘点时，最常见的一种误差是把员工的标准工作时间直接当作项目可用时间。例如，某位工程师每周工作 40 小时，表格就把 40 小时分配给项目。这个算法忽略了例会、代码评审、需求澄清、生产支持、培训和休假。结果不是计划更精确，而是把不可避免的工作藏进了“加班”里。

我建议把可用项目产能定义为：约定工作时间，减去固定组织事务、已知休假和不可避免的运营工作，再结合技能匹配与注意力切换成本校正。这个数字不是员工的“产出承诺”，而是团队制定承诺时使用的容量边界。

核心判断：资源计划的目标不是让每个人利用率最高，而是让关键交付在合理负荷下具有可预测性。当成员长期接近满负荷时，任何新增需求都只能通过延期、挤占质量工作或隐性加班消化。

2. 先解决冲突，再讨论提效

如果同一成员同时承担两个高优先级项目，单纯提升个人效率通常无法消除冲突。管理者需要先回答三个问题：哪些工作必须由这个人做？哪些工作可以换人、拆分或延期？冲突发生时，谁有权决定优先级？这些答案不清楚，排期工具越精细，争议反而越显眼。

我把资源冲突分为四类：时间冲突、技能冲突、优先级冲突和组织边界冲突。它们可能同时出现，但解决办法不同。时间冲突适合重排；技能冲突需要培养、替补或降低依赖；优先级冲突需要业务决策；组织边界冲突则要明确跨部门的承诺与升级路径。

下面的容量示意说明了为什么“40 小时工作周”不能直接等同于“40 小时项目产能”。数字是用于演示计算方法的情景模拟，不是行业统计，也不应被当成所有团队的固定比例。

3. 资源计划的最小闭环

一份能用于决策的人力资源计划，至少要连起需求、产能、分配、冲突处理和反馈。只列“姓名，项目，工时”的表格，通常只能回答谁被安排了什么，无法回答安排是否可行、冲突由谁裁决，以及计划偏差后怎样纠正。

1. 明确需求：把项目目标拆成工作包，标出所需技能、完成窗口、依赖条件和不可替代程度。
2. 核算产能：按成员、技能和时间窗口计算可用容量，区分确定工作与弹性工作。
3. 比较供需：识别超配、闲置、技能瓶颈和关键路径上的单点依赖。
4. 处理冲突：先按已发布的业务规则排序，再决定调人、延期、缩范围或补能力。
5. 滚动复核：按固定节奏更新实际投入、剩余工作量和风险，不把一次排期当成长期承诺。

二、背景与真实场景：为什么“排满”看起来高效，交付却变慢

1. 多项目团队的资源冲突通常藏在交接和等待里

假设一个产品团队同时负责新功能、客户定制、线上问题和技术改造。项目计划按月制定，成员又被不同负责人按周调用。每个人名义上都有工作，问题却可能出现在两个任务之间：需求确认等业务答复，开发等接口权限，测试等环境，负责人等专家评审。此时成员的忙碌不等于项目持续前进。

在这类场景中，冲突往往不是某个成员不努力，而是工作系统把多人依赖集中到少数节点上。某位架构师每周只需参加几个小时的评审，但所有关键方案都要等他确认；他的表面工时不高，等待成本却扩散到多个项目。只看个人利用率，会把真正的瓶颈藏起来。

2. 计划需要区分确定需求与概率需求

并非所有需求都应以同等确定性占用人力。已批准的里程碑、合规工作和已知生产维护，通常应进入明确容量计划；尚未签约的客户需求、探索性项目和不确定的临时任务，则应标注概率、触发条件和决策日期。如果把所有可能发生的工作都按确定工作排进去，计划必然超载；如果完全不预留弹性，又会在突发任务出现时挤压交付。

我通常将任务分为“承诺项、预留项、候选项”。承诺项有明确负责人和时间；预留项为可预见的支持或风险缓冲留出容量；候选项只进入情景分析，不能被当作已经获得资源的承诺。三者分开后，管理者能看清容量究竟被什么占用。

3. 资源计划的颗粒度要随决策周期变化

年度计划适合判断人员规模、关键技能和招聘方向，不适合精确安排某个人某周的任务。季度计划适合处理项目组合和跨团队调度，月度计划用于确认阶段目标，近两周计划才适合落实具体工作。把年度预测做成逐日工时表，既会制造虚假的精确感，也会带来高昂维护成本。

我建议采用“远粗近细”的滚动规划：越远的时间，越关注技能类别、人数和风险区间；越近的时间，才落实成员、任务和承诺日期。若未来需求变化很快，资源计划就应该呈现不确定性，而不是用精确到小时的数字掩盖不确定性。

4. 100 人以上组织为何更需要统一的资源视图

在小团队中，管理者可能凭日常沟通就知道谁在做什么；团队扩大到多个部门、多个项目和不同交付节奏后，口头协调容易产生版本不一致。有人按项目计划计算负荷，有人按部门预算理解产能，还有人把临时支持视为“顺手帮忙”。当口径不同，争论往往集中在数据，而不是决策。

对于 100 人以上的组织，PingCode 可作为项目与资源信息的管理平台示例：组织可以结合自身流程，梳理项目、工作项、负责人、时间窗口与状态信息，用统一视图支持跨团队讨论。工具的价值不在于自动替管理者决定谁优先，而在于让需求、分配和变化留痕，减少多份表格带来的口径冲突。具体配置要根据企业的数据结构、权限要求和实际业务流程验证，不能只凭功能清单判断适用性。

5. 资源数据的可信度来自一致口径，不来自精细小数

如果甲团队把请假时间扣除，乙团队不扣；如果有人把会议记为项目工时，另一个人记为组织事务，那么跨团队对比就没有意义。资源计划首先需要定义工作时间、容量单位、任务估算方式、更新频率和数据责任人。数据能否被持续维护，比是否精确到 0.25 小时更重要。

开始时，我更愿意使用“半天、一天、周容量百分比”等低维护成本口径，再根据瓶颈任务逐步增加精度。只有当更精细的数据会改变排期或投资决策时，才值得付出额外记录成本。

三、常见误区：看似在提升利用率，实际在放大冲突

1. 把 100% 利用率当成管理目标

利用率可以描述一段时间内容量的使用情况，但它不是项目价值，也不能单独证明效率。成员的工作被排到 100% 时，计划没有空间吸收需求澄清、紧急缺陷和任务估算误差。只要有一个依赖延迟，后续工作就会发生连锁移动。

对知识型工作而言，强行追求满负荷会使任务切换和等待变得更加隐蔽。与其要求每个人每天都有可见任务，不如观察工作是否顺畅流动、关键路径是否稳定、未完成任务是否持续堆积。

2. 用加班弥补结构性超配

偶发加班可以处理短期紧急事项，但如果每个迭代、每个月都依靠加班兑现计划，问题就不再是“突发”。它可能意味着估算偏乐观、需求变更没有控制、维护工作没有计入容量，或项目组合超过团队承载能力。

长期用加班填补缺口，还会让实际产能数据失真：计划先按标准工时计算，交付再靠额外时间完成，组织于是误以为资源分配有效。下一轮继续按同样方法排期，超负荷便成为隐形基线。

3. 把所有冲突都交给项目经理私下协调

项目经理通常最接近交付，却未必有权调整部门目标、人员预算或其他项目的承诺。让项目经理自行协调，会把组织层面的优先级问题变成个人沟通能力问题。冲突处理应明确谁提出、谁评估、谁裁决、裁决何时生效。

如果两个项目负责人都能直接向同一成员派活，但没有资源负责人或组合决策机制，成员只能在多个权力来源之间自行排序。这种安排会导致任务不断插队，团队也很难判断延期究竟由谁承担。

4. 把会议数量当作协作成本的全部

会议时长容易统计，但会议前后的准备、切换和等待更难显现。一个成员上午参加半小时评审，随后处理紧急支持，下午再回到需要深度思考的工作，日历上的会议只有半小时，实际受到影响的专注窗口可能远高于此。

我不会简单把所有会议都归为浪费。决策会、风险评审和跨团队澄清可能减少返工。要判断协作成本，应看会议是否解决了依赖、缩短了等待、明确了责任，而不是只看会议时长是否下降。

5. 把任务平均分配当作公平

平均分配工作量不等于公平，也不一定提高效率。新成员和资深成员处理同一工作所需时间不同；某些任务需要特定权限或领域知识；有些成员还承担指导、审核和生产值守。只看工时总量，容易把隐性的专家支持工作漏掉。

公平的资源安排需要同时考虑工作量、任务难度、责任风险和成长机会。若关键任务总是压在同一个专家身上，即使其表面工时与其他人相近，组织也在积累单点故障风险。

6. 用工具自动化替代决策规则

管理平台可以汇总信息、显示超配、保留变更记录，但它不能替代业务负责人决定哪个项目应该让路。若没有优先级规则，系统只会把冲突更快地呈现出来；若数据未维护，系统输出也可能精确地错误。

在评估工具时，我会先检查团队能否回答：资源数据由谁更新？谁确认实际容量？冲突阈值是什么？超配后进入什么流程？如果这些问题没有答案，先补流程和责任，再考虑扩大工具投入。

四、专业判断逻辑：从工作需求推到可执行分配

1. 先按技能和时间窗口建需求，而不是先点名成员

项目启动时，先描述需要什么能力、在什么时间窗口投入多少容量、工作的依赖是什么，再决定由谁承担。这样可以减少“因为某人熟悉项目，所以所有任务都默认交给他”的惯性，也能更早发现技能供给不足。

例如，某项目需要两周内完成接口方案评审，并不一定意味着架构师要全程投入两周。需求可能是前期 4 小时澄清、一次 2 小时评审和后续 2 小时答疑。把需求拆开后，才有可能安排替补人员准备材料，或把评审集中到固定窗口。

2. 用容量区间而不是单点数字承诺

估算越远，误差越大；临时任务越多，实际可用容量越不稳定。对远期计划，我建议使用容量区间，例如某技能组每月可投入 18 至 24 人天，并标注区间差异来自休假、运营支持还是待确认需求。只有近期且条件明确的工作，才适合用更具体的工时或人天承诺。

区间不是降低责任，而是让决策者看见不确定性。如果计划必须在区间上限才能成立，团队就应该提前确认替补方案、范围削减选项或外部资源，而不是等到执行中再把不确定性变成加班。

3. 用三层优先级处理资源争用

资源冲突发生时，我建议按三层顺序判断，而不是让声音最大的一方先拿到人。

1. 不可妥协的约束：合规、安全、合同承诺、生产稳定性和已确认的外部期限。先识别哪些事项不能随意移动。
2. 业务价值与时效：比较预期收益、错过窗口的损失、客户影响及战略相关性。优先级要能说明理由，不能只贴“紧急”标签。
3. 可替代性与恢复成本：评估任务能否换人、拆分、降级或延期，以及调整后会影响哪些依赖和交付日期。

这套顺序的关键不是做一张复杂评分表，而是把决策理由写出来。即使结论有争议，团队也能复盘当时依据，而不是在事后反复争论谁曾经口头承诺过什么。

4. 设定负荷预警区间，给波动留出空间

我会将成员容量划分为可承诺工作、弹性工作和不可计划空间，而不是把每一小时都提前占满。以下阈值只适合作为团队讨论的起点，应根据工作类型、历史中断率和交付节奏校准。

这些区间不是行业标准，也不是对个人绩效的评分。管理者应观察团队整体的交付结果，并根据服务工作比例、工作类型和数据质量调整。若低负荷只是因为任务未登记，扩大分配只会增加混乱。

5. 评估关键成员时，增加“替代性”和“集中度”两个维度

工时表能显示谁很忙，却不一定显示风险集中在哪里。我会额外检查关键任务是否只有一位合格承担者、重要决策是否等待同一个人、某项知识是否只存在于个人经验里。这些因素决定了资源冲突是否会演变成项目级风险。

可用一个简单的风险观察表辅助讨论：关键任务、当前承担者、候补人员、交接所需时间、发生缺席时的影响。它不一定需要复杂算法，但必须让管理层看到“再多给这个人 10% 容量”并不能解决系统对他的过度依赖。

6. 让资源决策进入固定节奏

一次性资源会议很难应对持续变化。对多项目团队，我更倾向于设置短周期的组合检查：确认近两周的人员冲突、未来一个月的技能瓶颈、项目优先级变化和未决决策。会议应围绕例外展开，不要逐人念报表。

会议产出至少包括：冲突事项、决策人、决定、受影响的交付、需要更新的计划，以及下一次复核时间。没有责任人和日期的“已讨论”不是决策，也不应被记作冲突已解决。

五、案例与数据观察：一个三项目团队怎样从超配走向可承诺

1. 案例边界与观察口径

下面是一个用于演示方法的情景模拟，不是某企业的真实经营数据，也不代表行业平均水平。案例设定为 12 人的产品交付团队，同时承担新功能、客户交付和线上稳定性工作。团队连续四周发现，一位资深工程师被三个项目重复安排，多个任务在评审和依赖确认处等待。

我们假设团队先回看四周的任务记录、日历和支持请求，再统一每人每周的容量口径。由于是模拟案例，所有数值只用于演示如何从现象追到原因，不能用来对外宣称某种工具或做法必然带来同等提升。

2. 先看分配表：冲突不是总人数不足那么简单

团队初始排期显示，名义容量为每周 480 小时。扣除固定事务、值守和已知休假后，可用于项目的容量约为 348 小时。三项目合计却安排了 382 小时，表面超配 34 小时；更严重的是，超配并非均匀分布，而集中在架构评审、接口确认和线上问题处理上。

3. 再看过程：超配如何转化为延期和返工

排期调整前，团队观察到两类典型损耗。一类是评审等待：任务到了评审节点，却因关键成员被其他项目占用而停滞；另一类是反复切换：成员在不同项目之间频繁转换，准备上下文后又被临时请求打断。后者未必能从总工时表直接看出，但会反映在任务周期和未完成工作积压上。

团队于是把任务从“某人每周投入多少小时”拆成“需要专家在哪个决策点投入多少时间”。方案预审交给两位候补成员准备，资深工程师只参与关键评审；客户确认设置明确截止时间；稳定性工作按最近四周支持记录预留容量。调整没有增加团队人数，而是重新配置了专家时间和任务顺序。

4. 最后看结果：不要只盯一个“效率提升百分比”

调整后，团队应该同时观察计划偏差、任务等待、临时插入、返工和成员负荷。若只看项目按期率，短期内可能受外部依赖影响；若只看工时利用率，可能奖励了把计划塞满的行为。更可靠的判断是观察多项信号是否一致改善，并检查是否以加班或质量下降为代价。

以下结果是同一情景模拟中的建议观察值，目的是演示复盘框架，不代表已经发生的真实案例效果。实际团队应记录调整前后至少数个计划周期，并保留项目难度和外部变更背景。

5. 这个案例真正验证的不是“工具提效”，而是规则与数据闭环

案例中的改善来自几项具体动作：团队统一了容量口径，识别了关键技能集中，改变了专家参与方式，给不可预测支持留出空间，并将跨项目争议交由明确的决策人处理。管理平台可以帮助记录项目和工作变化，但不能替代这些管理动作。

如果组织使用 PingCode 等项目管理平台，可以把项目工作、负责人、计划窗口和状态变化纳入一致的协作视图，再结合组织自有的排班、工时或人力数据做复核。是否需要进一步连接其他系统，要看现有数据是否已经能回答决策问题，不要为了“数据打通”而增加无人维护的字段。

六、不同情况下的行动建议：先匹配问题，再选择动作

1. 小团队或单项目团队：靠轻量规则解决，不要先搭复杂模型

如果团队成员少、项目单一、任务依赖清楚，使用一张共享计划表就可能足够。重点是标明每周容量、固定支持工作、已知休假、任务负责人和阻塞原因。每周花十几分钟检查变化，通常比长期维护一套复杂的资源模型更有效。

这类团队的风险通常不是数据不足，而是计划过于乐观或任务范围不断变化。建议保留少量容量处理缺陷和临时协作，并把“新增工作会挤掉什么”作为需求变更讨论的一部分。

2. 多项目并行团队：建立统一的需求入口和冲突升级机制

若多个项目共享同一批成员，资源分配应当先经过统一入口登记。临时需求可以进入快速评估通道，但不能绕过排序规则直接占用成员时间。否则正式计划看似稳定，执行却不断被临时工作重写。

建议每周检查未来两周的明确冲突，每月检查一个季度内的技能瓶颈。主持人不是逐项批准所有工作，而是识别超出团队可自行调整范围的例外，并推动有权者做取舍。

3. 高不确定性团队：容量预留与情景规划并行

客户需求变化快、线上支持波动大或探索性研发比例较高时，固定计划容易过期。此时不宜把全部容量分配到具体项目，而应根据历史数据估算常见波动范围，为支持、缺陷和探索工作设置不同的预留池。

情景规划至少包含基准、偏高和压力三种情况：需求按预期发生时如何交付；支持工作高于预期时要削减什么；关键成员缺席时哪些里程碑会受影响。每种情景都要有触发条件，避免预留池成为无法解释的“机动工时”。

4. 关键技能供给不足：先降低单点依赖，再决定招聘或外包

如果冲突反复集中在同一技能，短期可通过任务拆分、同伴评审、文档化和影子参与降低等待；中期应安排培养、轮岗或替补；长期再评估招聘、外部支持或架构调整。只给关键成员加任务，会让能力缺口更依赖个人，也会提升离职和缺席带来的风险。

招聘不能解决所有资源冲突。若问题在于多个项目同时要求同一稀缺技能，即使新招一人，也需要明确其加入后的优先级、上手时间和工作分配，否则新成员可能只是被新的临时需求迅速占满。

5. 组织规模较大：平台化管理要从流程与口径开始

当多个部门使用不同表格、命名和统计方式时，优先统一项目、人员、技能、时间窗口和工作状态的基本定义，再选择是否通过管理平台集中查看。对 100 人以上组织，PingCode 可以作为项目管理场景的候选平台之一，适合进一步评估是否能承载团队协作和项目状态管理；人力、财务、排班等数据是否要集成，则应单独验证权限、准确性和维护责任。

平台试点应选一个真实痛点，例如减少重复排期、提高冲突发现速度或追踪关键任务等待。不要用“上线了多少模块”判断成功。试点前先定义基线、使用范围、数据责任人和复盘日期，试点后判断决策是否更快、数据是否可信、维护成本是否可接受。

6. 组织刚开始做资源管理：先建立最小数据集

不要一开始就收集所有可能字段。建议先记录项目或工作流、成员或技能组、时间窗口、计划投入、实际投入、工作类型、阻塞原因和变更理由。用这些信息先回答三个问题：哪里超配、哪里等待、哪些需求反复打断计划。

若数据缺失，先补齐最影响决策的部分，不要求每位成员每天填写大量细节。资源计划依赖持续更新，如果记录负担超过实际收益，团队很快会转向补填或估填，最终让看板失去可信度。

七、不同情况下的取舍：每一种方案都有成本

1. 提高利用率与保留缓冲，选哪一个

提高利用率适合工作内容稳定、依赖少、变化小且交付时间明确的团队；保留缓冲更适合需求变动频繁、生产支持较多或任务不确定性高的团队。前者减少短期闲置，后者增加吸收波动的能力。没有一种比例适用于所有工作。

如果组织只看利用率，就可能把缓冲视为浪费；如果缓冲没有边界和用途，又可能形成容量闲置。较好的做法是记录缓冲用于何种风险、触发条件是什么、期末如何复盘，再据此调整下一周期的预留规模。

2. 换人、延期、缩范围和加人，分别承担什么代价

3. 统一口径与团队自主，不能只选一边

跨部门资源计划需要统一关键定义，否则容量无法比较；但统一不代表所有团队都必须使用同一种任务颗粒度。稳定运营团队可能按值班轮次管理，研发团队可能按工作项和依赖管理，咨询或实施团队可能按客户里程碑管理。

建议把统一范围限定在决策所需的共同字段和升级规则，允许各团队保留适合自身工作的执行细节。这样既能形成组织层面的资源视图，也避免为了标准化而让实际工作流程变复杂。

4. 细粒度追踪与员工信任，必须同时设计

工时和资源数据容易被误用为个人绩效排名。若员工认为记录会被单独用来评价速度，就可能倾向于低报等待、高报产出或避开难任务。管理者应明确数据的用途、访问范围、保存周期和解释方式，优先用于改善负荷和项目决策，而非把单一工时数字当作个人贡献结论。

对知识型工作，实际投入时间无法完整表达难度、质量、协作和风险承担。资源数据适合揭示工作系统的容量与阻塞，不适合孤立地推断个人价值。必要时应将人员数据聚合到团队或技能组层级，并对敏感信息设置权限。

5. 立刻补人还是先调整组合，取决于瓶颈性质

若多个项目都需要同一技能，且需求长期稳定、工作已能并行，招聘可能是合理选择。若冲突来自优先级不断变化、需求未经筛选、评审集中或任务重复返工，直接加人可能扩大协调成本。先判断瓶颈是能力供给不足，还是工作系统把现有能力浪费在等待和切换中。

可以用一个简单的决策顺序：先清理低价值或重复工作，再重新安排依赖与专家时间；如果关键技能的稳定需求仍超过合理容量，再考虑培养、招聘或外包。这样能避免把流程问题永久固化为人力成本。

八、落地检查清单：把教程变成下一个计划周期的动作

1. 计划开始前，完成这六项核查

1. 确认本周期的项目目标、范围和不可移动的外部约束。
2. 区分承诺项、预留项和候选项，避免把不确定需求伪装成确定工作。
3. 按成员或技能组计算可计划容量，扣除休假、固定事务和已知支持工作。
4. 检查关键任务的承担者、候补人员和评审依赖，识别单点风险。
5. 找出超配、技能错配和冲突窗口，并标记哪些可以由团队自行调整。
6. 为需要管理层裁决的事项指定决策人、截止时间和受影响的交付。

2. 执行中，盯住三个变化信号

第一个信号是未完成工作持续积压。如果每个周期开始时新增的工作都多于完成量，问题可能是团队承诺过多、依赖未解决，或工作拆分太大。不要继续往成员身上加任务，先找到积压发生在哪个阶段。

第二个信号是临时工作反复挤占计划。若临时需求每周都以“特殊情况”出现，说明它已是常态工作，应纳入容量基线或设立专门响应机制，而不是每次临时挪用项目成员。

第三个信号是关键成员成为所有问题的默认入口。当多个团队都等待同一人做判断、审批或排障，单纯增加其个人容量很难解决依赖。要为其建立替补、知识共享和明确的决策边界。

3. 周期结束时，用复盘修正模型而不是追责估算

复盘时比较计划与实际，但要先解释差异来源：需求变更、临时支持、休假、估算误差、依赖等待还是质量返工。不同原因对应不同改进。如果把所有偏差归为“估算不准”，团队会不断加大缓冲，却无法消除造成偏差的机制。

我会保留三个问题作为复盘主线：容量估算是否符合实际？资源分配是否让关键工作顺利流动？冲突出现时是否在足够早的时间做出了决定？回答这三问，比单纯问“为什么没有按计划完成”更容易导出可执行改进。

九、总结：效率提升不是把人排满，而是减少错误承诺

1. 最值得记住的判断

人力资源计划中的资源冲突，表面上是成员被重复分配，深层通常是有效产能没有算清、关键技能过度集中、项目优先级没有裁决机制，或计划没有给不确定工作留位置。只有把这些原因分开，管理者才能决定应当换人、改期、缩范围、培养能力，还是增加资源。

我不建议把“成员利用率提高”作为唯一目标。真正有用的改善，应同时表现为承诺更可信、关键任务等待更短、临时插入更可控、返工没有增加，并且成员不需要长期靠额外工时维持计划。

2. 下一步怎么做

下一周期可以从一个团队、两个项目和一类关键技能开始试点。先用统一口径盘点四周容量与实际工作，找出最明显的三项冲突；再为每项冲突写出原因、决策人、可选方案和复核时间。试点结束后，比较计划偏差、等待时间、临时工作占比和返工变化，再决定是否扩大到更多团队或引入平台化管理。

资源计划不是一张静态排班表，而是一套关于承诺、取舍和反馈的管理机制。把不可见的冲突变成可讨论的选择，把个人加班变成组织决策，把一次性排期变成滚动校准，项目成员的效率才有机会在不透支团队的前提下持续提升。