资源平衡怎么做？项目经理流程优化：资源负载从0到1

资源平衡最容易被误解成“把每个人排满”，但项目真正失控，往往不是因为日历上空白太多，而是关键技能被多个项目同时预订、任务依赖没有留出等待时间、管理者又把预计工时当成确定承诺。我的判断是：资源平衡不是追求每个人每天百分之百利用，而是在交付目标、技能约束和不确定性之间，持续做有依据的取舍。下面以一个中大型产品团队的情景模拟为例，从建立资源负载口径、识别瓶颈到按周调整，拆解项目经理如何把资源管理从“凭感觉救火”推进到“有数据、能复盘、可执行”的阶段。

一、先讲核心结论：平衡不是填满，而是守住交付流

1. 把“资源平衡”定义为一组决策，而不是一张排期表

我在审视项目负载时，会先问三个问题：承诺的工作是否有明确负责人？关键技能是否在需要的时间段可用？计划变动后，团队是否知道要延后什么、由谁拍板？如果这三项没有答案，即使排期表上每小时都被填满，也只能算“看起来很忙”，不能算资源平衡。

更实用的定义是：在约定的时间窗口内，把有限的人力、技能和可用工时分配给有优先级的工作，同时为缺陷、沟通、等待和突发事项留出空间。平衡的目标不是每个人负载一致，而是让最重要的工作可以按顺序通过团队，避免关键岗位成为隐形排队点。

2. 先看团队的流动效率，再看个人利用率

个人利用率容易计算，却很容易诱导错误行为。假设一位测试工程师一天排了八小时任务，表面利用率是百分之百；如果开发任务晚两天交付，这位测试工程师只能等待或临时切换工作，原计划仍然“满载”，但项目交付并没有因此提前。

我更关注工作从“已承诺”到“可交付”的周期、关键岗位的排队时间、临时插单比例和计划变更频率。个人负载是诊断信息，不应该直接变成绩效分数。项目经理的工作不是把人排满，而是让团队少等待、少切换、少返工。

3. 资源负载从零到一，至少要建立四个口径

• 可用容量：某人在某个周期内真正可以用于项目工作的时间，扣除休假、固定会议、值班和必要的支持工作。
• 已承诺负载：已经进入团队承诺、具备负责人和时间窗口的任务，不把愿望清单算进去。
• 技能负载：按技能类别统计需求，例如后端开发、数据分析、测试验证，而非只看总人天。
• 变动负载：临时需求、线上问题、依赖等待和返工造成的额外消耗，单独记录，不混进最初估算。

这四项口径齐备后，项目经理才有条件区分“人手确实不足”“技能不匹配”“计划过度承诺”和“工作被频繁打断”。如果只看总人天，最关键的瓶颈会被平均数掩盖。

二、背景和真实场景：为什么排得越满，项目反而越慢

1. 多项目团队的冲突通常先出现在稀缺技能上

在产品研发组织里，项目名义上由不同负责人管理，实际却共享同一批架构师、测试人员、数据工程师或安全专家。每个项目都可能只需要某位专家“半天”，但六个项目各自预订半天，合起来就超过了专家一周的可用容量。

这类冲突不一定会立刻出现在排期表上。项目经理往往先看到任务状态仍是“进行中”，过一段时间才发现评审排不上、测试积压、方案迟迟不能确认。资源冲突不是平均分配的问题，而是特定技能在特定时间窗口内供需失衡的问题。

2. 资源负载不是静态数字，需求会沿依赖链移动

一个需求从分析、设计、开发、测试到发布，会依次占用不同角色。上游延迟可能让下游人员暂时空闲；一旦上游集中交付，下游又会突然超载。只统计某一周的总人天，很容易把“本周空闲、下周拥堵”误判为供需平衡。

因此我会把资源视图与工作流放在一起看：任务当前处于哪个阶段、下一步需要谁、预计何时进入、前置条件是否满足。若一项任务仍在等待需求确认，就不该仅凭预计日期把测试资源当作已确定占用。

3. 100人以上组织更需要统一视图，但不等于要集中控制一切

当组织扩展到多个团队、多个产品线后，资源信息往往散落在项目计划、个人日历、表格和即时沟通记录里。每个团队都能解释自己的局部安排，却很难快速回答：哪些交付承诺争用了同一位专家？哪些工作可以错峰？哪个项目的延迟会影响最多后续工作？

这类场景可以用 PingCode 作为项目与资源信息的承载示例：把项目、迭代、任务、负责人和时间安排放进同一套可追踪的工作流中，再配合团队容量、任务状态和依赖关系做评审。工具的价值是降低汇总成本、提高变更可见性；它不能替代优先级决策，也不能自动消除组织里的技能瓶颈。

4. 先确定管理粒度：团队周容量通常比个人小时排班更稳

项目早期往往有大量估算不确定性。此时把每个人每天排到小时，制造的精确感远大于信息质量。相对稳妥的起点，是以团队为单位按周管理容量，只有对关键岗位、发布窗口或高度耦合的工作，再细化到个人和天。

粒度应跟着决策需求走：如果团队只需决定本月哪个项目先做，月度人天或周容量足够；如果上线窗口要求某天必须完成联调，则要细到日；如果每天都要变更计划，先解决需求入口和优先级治理，而不是继续把排期切得更碎。

三、常见误区：看起来在管资源，实际上在放大波动

1. 误区一：把百分之百利用率当作理想状态

当团队每天都被安排到满负荷，任何小波动都只能通过加班、延迟或切换任务吸收。需求补充、线上故障、代码评审和跨团队答疑都不是例外事件；如果计划没有容纳它们，所谓满负荷只是把现实工作藏在计划之外。

对于不确定性较高的工作，我会先从较保守的可承诺容量开始，再用连续几个周期的实际完成情况校准。比如团队名义工时为每周四十小时，但固定会议、支持和值班占用后，计划只按每人二十六小时排项目任务。这个数是演示口径，不应直接复制到所有组织。

2. 误区二：只看人头和总人天，不看技能与工作类型

“团队还有五个人”不等于“团队还有五个人可以完成这个任务”。如果工作需要特定的数据库迁移经验，其他岗位的空余工时无法直接补位。把所有人天相加，会让项目表面上不缺资源，真正的瓶颈却始终没有被看见。

资源表至少应能按技能或角色拆分。角色分类不必追求组织架构的完整复刻，而要服务于排期决策：哪些工作必须由某类专家完成，哪些工作可以通过协作、培训或流程调整分担，哪些工作可以延后而不影响关键交付。

3. 误区三：把估算值当成承诺值

估算是对工作规模的判断，承诺是团队愿意在条件明确后负责交付的范围。需求边界不清、外部依赖未确认、验收标准缺失时，即使给出“八人天”的数字，也不意味着已经具备可靠的交付计划。

我会要求任务估算附带条件：范围是否冻结、依赖是否就绪、是否包含评审和返工、是否包括部署验证。条件变化时，不应只要求团队“加快”，而要重新讨论范围、时间或资源的哪一项需要调整。

4. 误区四：把插单当成免费工作

临时需求最常见的隐性成本，不是它本身花了多少小时，而是打断已有工作、重新建立上下文和延后其他承诺。若每次插单都只新增任务、不调整原计划，团队会逐渐形成“所有事情都优先”的状态，最后没人能说清楚真正的优先级。

插单必须带着交换条件进入计划：要么替换掉同等容量的低优先级工作，要么明确延长交付日期，要么批准额外容量并说明风险。没有交换条件的插单，实质上是在把管理决策的代价转嫁给执行团队。

5. 误区五：把资源平衡理解成平均分配工作

不同人的能力、熟悉度、上下文切换成本和工作类型都不相同。把工作平均分给每个人，可能导致关键任务缺少合适负责人，也可能让资深专家被大量低价值沟通占满。公平不等于任务数量相同，合理分配也不等于每个人的负载曲线完全一样。

更好的检查方式是确认负载差异是否有业务原因：某人是否承担关键评审、导师支持或故障值班？某个岗位的工作是否可被拆分？若差异没有明确原因，才考虑重新分配，而不是单纯追求图表上的整齐。

四、专业判断逻辑：先识别瓶颈，再决定调人还是调范围

1. 用“需求、容量、时间、技能、风险”五个维度判断

我会把一次资源评审拆成五个维度。需求回答“要完成什么”；容量回答“有多少可用时间”；时间回答“什么时候需要”；技能回答“由谁或哪类角色完成”；风险回答“估算偏差和外部变化由什么缓冲”。五项都能说明，才算有可决策的资源计划。

如果需求不清，先澄清范围；如果容量不足，谈优先级或补充资源；如果时间冲突，调整顺序或里程碑；如果技能不足，考虑培训、结对或外部支持；如果不确定性太高，则缩小首批承诺或设置验证阶段。资源问题看起来相似，真正的解法可能完全不同。

2. 把负载率作为预警，不作为自动判决

一种常见计算方法是：某角色在某周期的已承诺工时，除以扣除固定占用后的可用工时。它适合用于发现过载趋势，但不宜被解释为“超过百分之百就一定延期”或“低于百分之百就一定有空”。任务并非都能线性拆分，依赖和实际波动会改变结果。

例如，某角色一周可承诺二十六小时，已承诺二十四小时，负载率约为百分之九十二。若任务边界稳定、依赖已就绪，这可能可接受；若该角色还负责线上值班或关键审批，就需要进一步扣除相应占用。数字提供的是提问入口，不是管理结论。

3. 用关键链思维识别真正影响日期的资源

并非所有过载都会影响项目结束时间。一个非关键工作晚一天，可能仍有浮动空间；一个掌握唯一发布权限的岗位晚一天，则可能使后续验证整体顺延。因此，我会把资源负载与关键依赖、里程碑和任务浮动空间一起看。

实际评审时，可先圈出影响交付日期的链路，再检查链路上的角色是否被多个项目同时占用。若资源争用发生在非关键路径，可能通过调整局部顺序解决；若争用发生在关键路径，必须尽早升级为范围、优先级或日期的决策。

4. 预留缓冲要有依据，不能把“多留一点”变成隐形膨胀

缓冲应来自可解释的波动来源，例如团队过去几个周期的临时支持量、依赖方响应时间、需求变更频率或测试返工情况。对有历史数据的团队，可以按工作类型分别估算；对新团队，则先用小批量试运行收集数据，再逐步校准。

我不建议所有任务统一加一个固定比例，因为不同工作的不确定性差异很大。例行维护与探索性技术验证不应使用同一缓冲系数；如果缓冲长期未被使用，也要检查是否过度保守；如果每个周期都被突发事项耗尽，则要追查上游机制，而不是年复一年扩大缓冲。

5. 先判断拥堵发生在哪一层，再采取相应动作

• 个人层：某个成员被多个任务同时占用，通常先做任务限流、明确主次和减少切换。
• 技能层：某类角色持续排队，通常要调整项目顺序、培养备份能力或引入外部支持。
• 流程层：工作在评审、审批或测试环节积压，通常先优化入口质量、批量大小和交接规则。
• 组合层：多个项目争抢同一资源，通常需要产品或项目组合负责人明确优先级，而非让各项目经理私下抢人。

如果没有识别层级就直接“再加几个人”，可能造成更多交接和协调成本；如果瓶颈是审批排队，增加开发人员也不会加快交付。资源平衡首先是定位系统约束，其次才是调整人员数量。

五、具体案例：用一个多团队项目组合演示从盘点到调整

1. 情景设定：三个项目共享一名稀缺角色

以下为情景模拟，数字用于演示推理过程，不代表任何企业的真实经营数据。某产品组织有三个并行项目：项目甲负责核心版本升级，项目乙负责客户交付，项目丙负责数据治理。三项工作都需要同一位数据工程师参与，每周可承诺容量按二十六小时估算。

项目甲预订十二小时，项目乙预订十小时，项目丙预订八小时，合计三十小时，超过可承诺容量四小时。若只看组织总人数，团队可能还有空闲；按技能和周次展开后，数据工程师已经是明确瓶颈。

2. 第一步：区分“已具备条件的工作”和“只是占位的工作”

资源计划里，项目乙的十小时并非全部都应立即占用。客户样本尚未提供，相关数据处理任务暂时无法有效开工。若为了保留资源而把十小时锁死，会造成其他已就绪任务等待；若把它全部释放，又可能低估客户材料到位后的短期需求。

我会把这部分拆成两类：已经具备条件的准备工作进入本周承诺；依赖外部输入的实现工作进入待确认区，并设置重新评估日期。这样既不假装任务已可执行，也不让潜在需求从资源视图中消失。

3. 第二步：把任务分成保留、错峰、降范围三种处置

项目甲影响核心版本窗口，且前置条件已满足，保留十二小时。项目乙先安排四小时做数据结构检查和样本校验，剩余六小时等外部输入确认后再进入排期。项目丙把本周工作从八小时降为四小时，只做需求验证和方案边界确认，其余实现工作顺延。

调整后，本周承诺容量变为十二加四加四，共二十小时，低于二十六小时上限。剩余六小时不自动填入其他新任务，而是作为共享角色的缓冲和临时支持空间。此处的空闲不是浪费，而是对外部输入不确定性的明确承接。

4. 第三步：写清交换条件，避免下周再次“凭记忆抢人”

调整决定需要记录项目优先级、被推迟的任务、触发重新排期的条件和决策人。例如，项目乙客户样本在周三中午前到齐，则周四重新评估是否释放数据工程师；未到齐则不占用已确认的关键迁移时段。项目丙的实现工作只有在需求边界通过评审后才进入下一周承诺。

记录的目的不是增加文书，而是减少重复争论。下周评审时，团队无需重新讨论“为什么上次没做”，而是对照预先约定的条件，决定是否改变安排。

5. 第四步：用实际完成情况校准，而不是追责估算偏差

周末复盘时，记录数据工程师实际投入、完成任务、等待外部输入的时长、临时支持工时，以及因切换产生的损耗。如果实际工作持续超过估算，要判断是任务范围遗漏、估算方法偏差、依赖质量不佳还是临时工作未纳入计划。

若项目乙样本连续两周延迟，问题重点就不再是本周排了几小时，而是外部输入的交付机制是否可靠。若项目丙需求每周变化，则应先限制变更入口或分阶段验证，而不是继续为不稳定范围预留越来越多的资源。

六、从零到一的落地流程：用四周建立可运行的资源管理机制

1. 第一周：统一任务和容量口径

第一周不要急着建设复杂仪表盘，先统一“什么工作要进入资源视图”。项目任务、值班、支持、例行协作和休假是否都记录？工时采用小时、人天还是容量点？已承诺、待确认、候选工作是否区分？这些口径不一致，后续汇总再精美也无法比较。

建议挑选一个项目组或一类稀缺角色试点。先覆盖未来两到四周，而不是试图一次性盘点全年。负载预测越远，需求和人员变动的不确定性越大；短周期数据更适合验证流程是否可用。

2. 第二周：建立按角色和周期的容量视图

把可用容量按周汇总，并区分个人、技能角色和团队。对于频繁支持线上问题的岗位，单独显示支持工作；对于跨项目共享的专家，明确每周可以投入的上限。初期不必追求分钟级准确，重点是让项目负责人看到真实冲突。

可以用简单表格起步，也可以通过项目管理平台汇总任务和负责人。若采用 PingCode 作为管理承载示例，可先梳理项目、迭代、工作项、负责人、状态和时间字段，再检查视图是否能回答“谁在什么周期被哪些已承诺工作占用”。不要因为平台具备更多功能，就一次性启用全部配置。

3. 第三周：举行短时、固定节奏的资源评审

资源评审不应变成逐条汇报任务进度的长会。建议聚焦异常：负载超过团队阈值、关键角色被重复预订、前置依赖未就绪、插单没有替换项、跨项目优先级冲突。没有异常的任务不需要在会上重新讲一遍。

参会人应包括能够做取舍的人，而不仅是提交需求的人。若项目经理发现冲突，却无权决定哪个项目先做，会议再频繁也只是把冲突展示出来。至少要明确升级路径、决策时限和最终拍板角色。

4. 第四周：用结果校准阈值和流程

经过一个周期后，对比计划容量和实际投入，看看偏差主要来自哪里：估算遗漏、支持任务未记录、依赖等待、需求变更，还是切换太频繁。先修正最主要的两项，不要把所有偏差都归因于“团队执行力不足”。

阈值也应逐步校准。某团队的百分之八十五负载可能很稳定，另一团队在百分之七十五时已经频繁延期。业务类型、成熟度、支持责任和技能稀缺程度不同，不存在脱离情境的万能利用率目标。

1. 定义计量对象：以任务、角色、个人或团队中的哪一层为主。
2. 收集两到四周数据：记录承诺量、实际投入、临时工作和等待时间。
3. 识别一个主要瓶颈：不要同时改造所有计划规则。
4. 试行一个调整动作：例如限制在制工作、调整插单规则或培养备份角色。
5. 复盘结果并保留有效规则：将经验写入团队工作约定。

5. 指标要少而能驱动行动

从零到一阶段，我通常建议先用五个指标：按期完成率、计划外工作占比、关键角色负载率、任务等待时间和计划变更频率。每个指标都要对应一个可能动作，例如等待时间上升时检查交接瓶颈，计划外工作增加时检查需求入口，负载率持续超限时重排优先级。

不要一开始就采集大量精细工时数据。数据采集成本过高，员工容易把记录视为额外行政负担，也可能产生虚假的精确。若一个指标无法改变项目决策，先不要采；如果数据口径无法被团队共同解释，也不要用它做横向排名。

七、工具与数据：怎样让资源视图真正支持决策

1. 工具先解决信息断裂，再考虑自动化

资源管理常见的第一道障碍，是任务信息、人员安排和项目优先级分散在不同地方。工具应至少支持清晰的负责人、工作状态、时间周期、依赖关系和项目归属，并能让团队看见更新后的计划。若数据仍需项目经理每周手工从多个表格拼接，视图很快会过期。

以 PingCode 为例，中大型企业或百人以上组织可以先评估其是否能承接已有的项目协作流程，是否能按团队和项目呈现任务状态、负责人及周期信息，以及是否支持权限和变更追踪。实际选型仍应结合部署方式、集成能力、合规要求和团队使用习惯验证，不能把产品功能描述当作落地效果保证。

2. 自动化适合提醒和汇总，不适合替团队决定优先级

当负载超过设定阈值、任务依赖未完成却临近开工、负责人同时被多个关键任务占用时，系统可以触发提醒或生成待评审清单。自动化能够减少漏看和重复汇总，但无法判断客户承诺、法规要求、战略优先级和机会成本之间的权重。

因此，自动化规则应给出“需要谁在什么时候判断什么”，而不是直接把任务从一个人名下搬到另一个人名下。资源调整涉及技能适配、上下文和团队承诺，未经确认的自动重排可能增加返工。

3. 数据治理比图表数量更重要

要把资源视图用于组织决策，至少要约定更新时间、状态含义、估算单位和任务负责人。已取消的任务应及时关闭，待确认工作要与承诺任务区分，已完成任务应保留实际完成信息。否则，过期任务会虚增负载，重复任务会造成错误抢占。

对于跨部门数据，还需要控制可见范围。个人负载数据用于安排工作和识别瓶颈，不应未经解释就用于个人绩效排名。团队若担心数据会被断章取义，往往会减少更新或把任务估得更保守，最终损害资源判断质量。

八、不同情况下的行动建议：先做最能解除瓶颈的一步

1. 小团队、单项目：先减少任务并行

如果团队人数不多、项目依赖相对简单，复杂的资源管理流程可能比问题本身更重。先把每个人同时进行中的任务数量限制下来，明确本周目标和阻塞事项，按周检查工作是否完成。对小团队而言，减少切换往往比把每个人的工时计算得更精细更有效。

当一个人同时负责需求分析、交付协调和支持工作时，不要把所有时间都归入项目任务。把固定职责显性化，才能判断团队究竟缺少容量，还是工作入口太分散。

2. 多项目共享专家：建立技能池和预订规则

若架构、安全、数据或测试专家被多个项目共享，应先定义可预订时间窗口、优先级和变更规则。项目不能只报“需要专家参与”，还应说明需要完成的决策、预计时长、输入材料和最晚时间。准备不充分的评审请求不应占用关键专家的整段时段。

如果某项技能长期只有一名成员具备，除了短期排期，还要制定知识转移、结对和备份培养计划。培养备份会占用当期容量，但它是在降低未来对单点角色的依赖，不应被简单视为低效率工作。

3. 需求经常变化：先管入口和承诺，再调负载表

如果计划每周都因临时优先级变更而重排，问题通常不只是表格更新不及时。需要明确谁有权插入新工作、插单需提供什么信息、哪些工作必须被替换，以及何种情况可以触发紧急通道。

对尚未验证的需求，优先采用短周期探索或小范围验证，而不是把完整实现工作提前压进团队容量。先减少不确定性，再做较大承诺，往往比在不稳定范围上反复调人更可控。

4. 临近上线、时间不可移动：缩范围比假装增加容量可靠

当交付窗口已经固定，关键角色又存在超载，通常需要明确哪些功能是上线必需、哪些可以后续补齐。加班可能短期补回一部分工时，但疲劳、缺陷和交接风险也会增加；临近上线时再引入不熟悉系统的人，短期收益也可能被辅导和返工抵消。

若必须增加资源，应优先补充边界清晰、容易并行的工作，而不是把新人直接放到高度耦合的关键任务上。与此同时，应把上线验证、回滚准备和故障响应算入容量，避免只排开发、不排保障。

5. 组织刚开始建设资源管理：从一个瓶颈角色试点

如果全组织尚未形成统一口径，先选择冲突最明显的角色或项目组试点。例如每周被多个项目预订的测试专家，或经常排队的架构评审角色。先用真实冲突验证数据字段和会议机制，再逐步扩展到其他团队。

试点成功的标准不是图表更完整，而是项目负责人更早发现冲突，管理层能更快做出优先级决策，团队也能减少不必要的等待和反复改计划。

九、不同情况下的取舍：没有一种资源方案适合所有团队

1. 高利用率与高可靠性之间的取舍

提高利用率可能让短期资源看起来更饱和，但也会压缩应对变动的空间。对于工作稳定、需求可预测、交接成本低的团队，可以采用更紧的容量安排；对探索性开发、客户支持密集或外部依赖多的团队，需要更大缓冲。

决策时要比较边际收益与波动代价：多排一个任务能带来多少交付价值？若出现返工或插单，会影响哪些承诺？缓冲不是越多越好，满载也不是越高越好，关键是让风险和收益明确。

2. 专家集中处理与团队分散学习之间的取舍

让专家集中处理关键工作，短期往往更快；让其他成员结对参与，短期会增加沟通和学习成本，但有机会减少长期单点依赖。发布窗口临近时，集中处理可能更合适；项目节奏稳定时，可以安排一定比例的结对和轮岗。

如果组织只奖励短期完成速度，知识转移通常会不断被推迟。项目经理应把培养备份能力看作资源组合的一部分，并说明其预期收益和当期成本，而不是把它藏在“空闲时间”里。

3. 详细工时管理与轻量容量管理之间的取舍

详细到小时的管理适用于计费、受监管项目、严格的排班场景或确实需要精确窗口的任务；它能提供细粒度信息，但录入成本和管理负担也更高。对于多数知识工作团队，以周为周期记录容量和任务承诺通常更容易坚持。

判断是否需要更细粒度，可以看错误成本：如果偏差一小时就会影响设备、安全或客户窗口，需要更精确；如果工作本身高度不确定，精确排到小时只会制造虚假确定性，应优先管理范围和依赖。

4. 内部培养与外部补充之间的取舍

外部补充人员可以较快增加特定能力，但可能涉及招聘、供应商协调、权限开通和知识交接。内部培养起效较慢，却有机会沉淀领域知识、增强团队弹性。若瓶颈是短期、边界明确的专项工作，外部支持可能合适；若瓶颈长期存在且紧贴核心业务，培养内部备份通常更有价值。

不要把“增加人手”当作无需比较的默认答案。应估算新成员真正可以贡献的时间，而不是按入职人数直接增加容量；也要考虑现有团队用于指导和审查的工时。

十、结尾：资源平衡的起点，是让隐性取舍变得可见

资源平衡的独特价值，不是把每个人的日历变得更整齐，而是让组织看清：哪些工作已经承诺，哪些工作还在等待条件，哪类技能正在形成队列，以及每次插单究竟挤掉了什么。只要这些信息仍然隐形，团队就会把计划问题误认为执行问题。

项目经理可以从一个最小动作开始：选定一个共享角色，统计未来两周的可用容量、已承诺工作、待确认依赖和计划外支持；召开一次只讨论冲突与取舍的短会；会后记录被推迟的工作和重新评估条件。连续运行几个周期，再用实际完成、等待和插单数据校准计划。

先建立可信的口径，再暴露真实的瓶颈，最后才决定加人、错峰、减范围或培养备份。这条顺序比追求一张看起来精确的资源表更重要。资源负载从零到一，不是做出完美预测，而是让每一次资源调整都有事实、有负责人，也有明确的代价说明。