角色最佳实践：PMO资源管理最佳实践，常见问题

PMO资源管理最常见的失控，并不是“人不够”，而是同一个人被三个项目同时按满负荷排期，直到关键节点前才发现冲突。资源表看起来有名字、有工时、有开始日期，却回答不了三个更重要的问题：谁有能力做这件事、此时是否真的有空、如果优先级改变，哪些承诺必须随之调整。我的判断是，PMO资源管理的核心不是把人员塞进计划，而是建立一套能持续暴露供需矛盾、支持取舍、记录决策后果的机制。

一、先讲核心结论：资源管理不是排满日历

1. PMO要管理的是供需匹配，不是人员占用率

资源管理常被简化成“谁有空就分给谁”。这套逻辑只在任务简单、人员可替代、项目优先级稳定时勉强有效。一旦工作依赖特定技能、跨部门决策或稀缺专家，空闲时间并不等于可用产能：某位架构师本周看似还有两天，但若这两天被拆成六个零散时段，他可能无法完成任何需要连续专注的设计工作。

我更倾向于把资源管理定义为：在明确能力、可用时间、工作依赖和优先级的前提下，持续决定“由谁在何时以什么容量承担什么工作”，并在条件变化时及时重排。分配不是一次性动作，资源承诺也不是永久有效的事实。

2. 资源表之外，还要看决策链是否闭合

一张表能显示谁被安排了多少工时，却不一定能显示这项安排由谁批准、基于什么优先级、依赖什么前提、冲突发生后由谁裁决。若这些信息缺失，PMO看到的只是结果，不是能被纠正的管理过程。

我在评估资源机制时，通常会追问四件事：需求是否有责任人；产能是否经过团队负责人确认；冲突是否有明确决策者；变更是否会同步更新交付承诺。四项中任何一项不成立，资源台账都可能只是“看起来很细”的登记册。

3. 先统一口径，再追求精细化

不同团队经常把“可用”理解成不同概念：有人按合同工时计算，有人扣除例会和支持任务，有人把休假排除了，有人则默认这些事项会挤占项目时间。若没有共同口径，利用率看似可比较，实际是在比较不同算法。

建议先明确统计周期、可分配工时、非项目工作、技能标签、需求粒度和更新时间，再决定要不要做更复杂的预测。错误口径下的精确数字，比粗略但诚实的区间更容易误导决策。

二、背景和真实场景：为什么资源计划经常在执行中失真

1. 项目计划是需求视图，团队排期才是供给视图

项目经理通常从交付倒推任务：某功能需要设计、开发、测试；部门负责人则从团队现有工作出发，看到缺陷处理、线上支持、技术债和人员休假。两边都可能合理，但如果只有项目计划，没有团队供给视图，计划就容易默认每个人都能全职投入。

冲突往往不是突然发生，而是被不同系统分散记录。项目计划里写着某位专家要参加方案评审；支持群里又约了紧急排查；部门负责人手上还有一个监管要求。PMO若没有统一的需求入口和冲突处理规则，通常只能等延期之后再追问原因。

2. 资源冲突有三种，解决方式并不相同

• 时间冲突：同一个人被安排在重叠周期工作。通常要通过调整顺序、缩小并行数或重新分配来处理。
• 能力冲突：有空的人不具备所需技能，或经验层级不足。单纯增加人数不一定有帮助，可能需要培训、专家复核或降低范围。
• 优先级冲突：多个项目都声称“最高优先级”，而决策层没有说明放弃什么。此时PMO应推动业务决策，而不是要求员工自行加班解决。

三类冲突常常叠加。例如，项目A需要资深安全工程师两周，项目B需要同一位工程师每天参加评审，项目C则因监管节点被临时提升优先级。这不是排班技巧能独立解决的问题，而是业务承诺、技能供给和优先级治理共同造成的结果。

3. 多项目组织里的“忙”并不等于有效产出

当一个人同时服务多个项目，表面利用率可能很高，实际却被频繁切换、等待决策和临时支持侵蚀。把工作切成更小的时间片，未必能提高吞吐量；对需要连续思考的工作，反而可能让任务在不同项目之间反复启动。

因此，资源视图至少要区分“计划容量”和“连续专注容量”。前者适合做总量判断，后者有助于识别复杂工作是否被过度切碎。对于专家评审、架构设计、故障分析等任务，连续时间块通常比总工时更有解释力。

4. 需求越晚进入资源视图，临时协调成本越高

资源请求通常从“需要一个人”开始，但有效需求应描述工作结果、所需能力、投入窗口、预计负荷、依赖条件和不确定性。只提供人数和日期，资源负责人无法判断请求是否合理，也无法比较两个项目的真实紧急程度。

我的建议是把资源需求分成三种状态：已确认需求、待验证需求和情景需求。已确认需求进入基线；待验证需求先安排评估时间；情景需求用于预测可能的峰值，但不应被当成正式承诺。这样既能预警，也不至于把每个早期猜测都变成占用。

三、常见误区：看起来精细，实际上不能支持决策

1. 误区一：把利用率越高视为管理越好

高利用率容易成为管理层的直观目标，但单独追求这个数字会诱发虚假排满：预留工时被消灭，学习和改进工作被挤压，临时支持没有位置，计划外事件只能靠加班吸收。利用率高也可能意味着缺少缓冲，而不是执行更优秀。

我会把利用率作为诊断信号，而不是绩效目标。连续多个周期接近满载时，应进一步看延期、返工、跨项目切换、加班和缺陷趋势；如果这些指标同步恶化，说明系统缓冲不足。若高利用率只出现在短期冲刺，且交付稳定、团队可恢复，则解释又不同。

2. 误区二：将工时均分给每个项目

把一个人平均分给四个项目，看起来公平，也便于做表；但公平分配不等于最优交付。项目阶段、关键路径、技能匹配和切换成本都不同。某项目临近发布时需要集中测试，另一个项目还在需求探索阶段，两者不应机械地各占四分之一。

建议按交付窗口和工作类型分配连续容量，而不是只按项目数量均摊。需要高专注的任务尽量集中安排；必须跨项目支持的角色，明确固定时段或服务等级，减少每天临时切换。

3. 误区三：把需求人数相加，当作资源缺口

四个项目都写“需要一名数据分析师”，并不必然意味着缺四个人。需求可能发生在不同月份，也可能只需要阶段性评审；反过来，四个项目各写半个人，也不意味着一个人可以无损地承担，因为工作窗口可能重叠、技能方向可能不同。

资源缺口要按时间、能力和负荷分解。至少应回答：缺口发生在哪个周期；需要什么层级的技能；工作是否能拆分；有没有依赖同一关键专家；是否可以通过调整范围或交付顺序化解。

4. 误区四：把专职与兼职简化成两种身份

“专职”不代表整周可用，“兼职”也不代表资源随叫随到。专职人员仍要承担沟通、评审、支持和管理工作；兼职专家还可能需要较长的上下文切换时间。若只登记比例，不登记工作窗口和服务边界，数字会产生错误安全感。

对于兼职资源，我更关注约定的可响应窗口、连续工作块、任务交接要求和替补机制。对于专职资源，则关注未登记工作、跨团队职责和计划外支持。身份标签可以保留，但不应替代容量建模。

5. 误区五：把预估工时当成事实

项目早期估算本身带有不确定性。若PMO把“预计需要两周”直接录成精确的八十小时，再拿它与实际工时比较，就会把估算偏差、范围变化和执行效率混在一起。精确到小时的表格，不会自动让不确定性消失。

更稳妥的做法是记录区间、置信度和估算依据。成熟项目可以细化到工作包；探索性工作保留范围并按阶段复估。重要的是保留“为什么变了”，而不是要求每次更新都让数字看起来更确定。

6. 误区六：把资源冲突交给个人协调

当两位项目经理都向同一个工程师要时间，要求工程师自己决定先做哪件事，等于让执行者承担组织级优先级决策。员工可以提供工作量和风险信息，但不应背负决定哪个业务承诺被牺牲的责任。

PMO应设计升级路径：团队负责人确认容量，项目负责人说明交付影响，业务或组合层负责人做优先级裁决，PMO记录选择及其后果。没有决策权的协调者可以暴露冲突，但不能靠反复开会替代真正的裁决。

四、专业判断逻辑：从需求、能力、容量到决策

1. 先问工作是什么，再问需要谁

“需要一个高级工程师”是人员请求，不是完整需求。PMO应追问任务要交付什么、依赖哪些能力、需要多长连续时间、是否必须由资深人员全程承担，以及什么条件变化会让需求失效。

把请求从“人头”转成“工作包”，可以发现很多并非必须由稀缺专家执行的事项。例如，专家可能只需做方案审查和关键节点把关，资料整理、测试执行和常规分析可以由其他角色承担。这样不是降低质量，而是把稀缺能力用在最难替代的环节。

2. 用三层容量视图避免虚假的精度

我建议将容量分为组织容量、团队容量和个人窗口。组织容量用于判断总体供需；团队容量用于发现技能池和交付依赖；个人窗口用于安排近期任务。越靠近执行，颗粒度可以越细；越靠近远期预测，越应该使用区间而不是具体到日的排期。

• 组织层：按月或季度看关键技能供需、项目组合峰值和人员缺口。
• 团队层：按迭代或阶段看可投入容量、支持工作、休假和交付责任。
• 个人层：只对近期、已确认的工作窗口做具体安排，避免长期精确排到每一天。

具体时间尺度应由业务节奏决定，而不是照搬固定模板。产品团队可能按迭代管理近端容量，工程建设项目可能按里程碑管理阶段资源，长期研发组合则需要季度级情景预测。

3. 按能力稀缺度与替代难度定优先级

资源请求排序不能只看项目级别。两个项目都很重要时，关键问题是哪个需求更难替代、哪个延迟会引发更大的连锁影响、哪个窗口具有不可逆性。需要稀缺专家的任务，不一定自动优先，但应尽早暴露其约束。

判断时，我会结合业务价值、法定或客户承诺、关键路径影响、技能稀缺性、需求置信度和可延后成本。可将这些维度分开评分，但评分只能帮助比较，不能假装把价值判断变成完全客观的数学问题。

4. 将不确定性显式化，而非强行压成一个数字

远期需求可采用低、中、高三种情景：低情景假设范围收敛且无额外支持；中情景代表当前最可能情况；高情景代表风险触发后可能出现的峰值。这种方式能让管理层看见“最可能需要多少”和“最坏情况下会缺多少”并非同一个答案。

资源计划还应记录关键假设，例如供应商按期交付、法规评审不追加轮次、关键岗位人员未发生变动。若假设变化，计划就应进入复核，而不是等到工时超支后才追责。

5. 冲突处理要包含代价，不只给出新排期

当稀缺资源冲突时，常见建议是“把项目B往后挪两周”。但排期变化的真正成本可能包括客户窗口错过、其他团队等待、合同节点变化或技术风险累积。只给新日期而不展示代价，管理层就无法做知情选择。

我建议每个冲突决策至少记录：冲突双方、所需能力、当前承诺、可选方案、每种方案的影响、最终决策人、决定日期和复核触发条件。决策记录不必写成冗长纪要，关键是未来能够解释“当时为什么这样取舍”。

6. 把变更治理纳入资源管理闭环

资源计划不是批准一次就不再变化。新增需求、范围调整、故障事件、人员离职、休假变化和供应商延误，都可能改变供需关系。若团队只更新任务，却不更新容量和承诺，资源视图很快就会失去可信度。

应约定什么变化必须触发复核。例如，关键技能缺口持续超过一个周期、关键节点预计偏差超过约定阈值、个人负荷连续高于可持续范围，或新增任务挤占已批准工作的容量。阈值由组织结合历史数据设定，不宜直接套用统一数字。

五、案例与数据观察：用一个示意情境看清资源冲突

1. 情境说明：四个项目争用同一类稀缺能力

下面的案例是基于常见多项目协作模式构造的情景模拟，不代表某家企业的实际统计。某中大型组织同时推进平台升级、客户交付、合规改造和内部效率项目。四项工作都需要资深数据工程能力，但需求在不同阶段集中，且同一位专家还承担线上支持。

最初的资源表将这位专家的容量按项目拆分，合计达到每周四十小时。项目负责人都认为分配已获确认，但部门负责人并未确认支持任务和评审占用。两周后，线上问题增加，合规项目临时加了数据核验，平台升级的设计评审因此延迟。

2. 诊断过程：先拆需求，再识别真正的瓶颈

我会先把四项项目的请求从“各要一位专家”拆成工作包。平台升级需要架构方案评审与关键数据链路验证；客户交付需要短期排障支持；合规项目需要数据口径确认和审计证据；内部效率项目的早期分析则可以由中级工程师完成，专家做一次阶段评审即可。

拆分后，冲突不再是“谁抢到专家”，而是三个不同问题：哪些工作必须由专家亲自完成；哪些可以由团队成员完成、专家复核；哪些工作可以调整顺序。这样的分类让管理层可以讨论交付风险，而不是只讨论个人是否忙不过来。

3. 方案比较：增加人力不是唯一选项

4. 情景推演：把选择的代价摆在同一张桌面上

在这个模拟案例中，团队将专家的一部分常规执行工作交给中级工程师，保留专家用于方案审查、复杂问题处理和关键节点决策；同时把客户支持改为固定响应窗口，并由轮值人员处理常规问题。合规工作被确认为优先窗口，内部效率项目的部分分析任务顺延。

这一方案不保证所有项目都按原日期完成。它的价值在于把取舍显性化：关键合规节点获得保障；平台项目的评审仍需调序；内部项目接受范围或日期调整；专家的工作负荷不再靠隐性加班填补。PMO需要记录的不是“安排成功”，而是每个承诺改变了什么。

5. 观察指标：不要只用“是否按时”评价方案

资源调整后的评估应覆盖结果、过程和风险。结果层看关键里程碑、范围变化和延期；过程层看需求变更响应时间、资源冲突解决周期、计划与实际偏差；风险层看加班、返工、单点依赖和计划外支持占比。

如果交付日期保持不变，但返工和加班显著上升，不能简单判定资源方案有效。反之，若部分日期调整，却降低了关键人员的过载并减少了重复切换，组织可能获得更稳定的持续交付能力。判断改善要看系统成本，不要只看局部日期。

六、落地方法：从一张可用的资源台账开始

1. 定义最小字段，避免先做一张没人维护的大表

资源台账的第一版不需要覆盖所有可能字段，但必须能支持实际决策。字段太少，无法解释冲突；字段太多，维护负担会迅速超过收益。建议先确保需求、能力、时间窗口、负荷、责任人和决策状态完整。

• 需求信息：项目或产品、工作包、预期结果、所需角色与技能。
• 时间信息：开始窗口、结束窗口、关键节点、是否需要连续工作块。
• 容量信息：预计投入区间、团队可用容量、已知支持与非项目任务。
• 风险信息：需求置信度、依赖、替代人员、假设条件和风险触发点。
• 治理信息：需求提出人、容量确认人、冲突裁决人、最近更新时间。

如果组织使用某项目管理平台或内部资源管理系统，字段设计也应围绕这些业务问题展开。工具可以帮助统一状态、保留变更历史和汇总视图，但不能替管理层决定优先级。系统上线前，先验证流程里谁输入、谁确认、谁消费信息，通常比先讨论仪表盘颜色更重要。

2. 建立分层节奏：近端排期，远端预测

资源会议不应每周重复盘点所有人的全部工作。近端需要解决具体冲突，远端则需要识别技能缺口和组合峰值。把两类问题混在同一场会议里，容易让会谈在细节排班中耗尽，却没有时间讨论未来的能力建设。

3. 会议前先异步准备，会议只处理需要决策的事项

资源会议的价值不在于把表格念一遍，而在于解决无法通过异步更新解决的冲突。会前由需求负责人更新工作包和预估；团队负责人确认容量与限制；PMO整理需要裁决的事项，并标注每个方案的交付影响。

会上只讨论优先级不清、关键技能冲突、重要承诺变更和需要跨部门协调的事项。单纯的信息同步可以通过共享视图完成。会议结束后，更新决策记录和受影响的项目计划，并明确哪些事项仍待验证。

4. 先用数据找模式，不要过早给个人贴标签

某人连续超负荷，未必是个人规划能力差；也可能是项目组合过多、职责边界不清或单点技能依赖。某团队利用率低，也不一定意味着效率低；可能是项目需求尚未成熟，或容量被预留给不可预测的支持工作。

分析应先看系统模式：哪些技能反复成为瓶颈；哪些项目总在临近节点抢人；计划外工作集中在哪些团队；需求变化后多久才更新承诺。找到模式之后，再决定要改变组织设计、项目组合、工作流程还是个体发展计划。

5. 设定数据质量规则，让台账保持可信

资源数据的主要风险不是缺少字段，而是更新过期。建议为关键字段设置更新时间和责任人，并把“未确认”作为明确状态，而不是留空让读者自行猜测。需求负责人对需求准确性负责，团队负责人确认容量，PMO负责汇总、检查口径和推动冲突处理。

对敏感人事信息应遵循必要、最小化原则。资源规划通常需要能力、可用窗口和工作负荷，不必收集与决策无关的个人隐私。个人负荷趋势的用途是识别系统风险，不应将粗略估算直接用作个人绩效结论。

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

1. 项目少、团队小：先把冲突说清楚

小团队不必一开始建立复杂的能力模型或多层审批。可以用一页共享视图记录近期工作、关键能力、支持事项和冲突责任人。管理重点是避免同一成员被多个负责人重复承诺，并保留足够的临时处理空间。

取舍在于精度与维护成本：若人数少、工作高度透明，手工台账可能比复杂系统更有效；但当人员跨项目、需求变动频繁，或同一技能被多个业务单元依赖时，简单表格就容易出现版本不一致和责任缺位。

2. 项目组合复杂、组织规模较大：分清需求治理与人员排班

中大型组织通常同时存在项目、产品、运营支持和专项任务。PMO应负责组合层供需与冲突治理，团队负责人负责可用容量和技能现实，项目负责人负责工作包和交付影响。角色边界不清时，资源会议很容易变成所有人都在更新数据，却没人有权做选择。

如果使用系统化工具，应关注跨项目汇总、权限与数据边界、历史变更、工作与资源关联、报表口径和集成成本。工具评价不能只看功能清单，还要测试它能否让不同角色按职责完成更新，并让决策所需信息在同一流程中闭合。

3. 需求高度不确定：用容量预留和阶段复核

探索性研发、市场试验和早期产品规划不适合把未来数月精确排到个人。可先按能力池预留区间容量，再在关键假设验证后逐步细化。每次阶段评审都重新检查需求范围、依赖、可替代性和下一阶段工作量。

这样做的代价是远期计划不够“整齐”，但能减少虚假承诺。对管理层而言，明确一个区间及其前提，通常比承诺一个精确数字、数周后再解释变化更有决策价值。

4. 项目受外部硬期限约束：优先保护关键路径，但公开代价

监管期限、客户上线窗口或供应链交付可能具有不可移动性。此时可以集中稀缺资源保护关键路径，但要同步评估其他项目的影响，明确是否缩减范围、转移任务、采用临时支持或调整后续承诺。

取舍不是“硬期限项目永远优先”，而是确认该期限是否真实不可移动，以及错过的后果是否大于其他项目被延后的代价。如果决策层选择集中资源，就应正式接受被挤出工作产生的风险，而不是把损失悄悄转嫁给执行团队。

5. 关键专家成为单点：先减少依赖，再决定补人

对于架构、安全、数据治理或特定设备等稀缺技能，先盘点任务中哪些环节必须由专家完成，哪些可以通过标准、模板、配对和复核下放。建立替补能力需要时间，因此短期排期和长期培养应并行推进。

招聘并非总是最快解法。新成员需要学习业务和系统，外部人员需要权限、背景和交接；如果问题来自知识集中和工作方式不透明，补人可能只是增加更多协调成本。若缺口持续存在、需求稳定且能够形成可复用工作量，再考虑新增编制或外部合作会更合理。

6. 资源数据可信度低：先治理输入，暂缓复杂预测

当需求经常不更新、工时口径不一致、团队容量缺少确认时，先不要建设看似精密的预测模型。优先建立统一定义、责任人、更新时间、变更记录和基础校验规则。对不确定信息标记状态，比强行补齐数字更诚实。

当连续几个周期的数据质量稳定后，再逐步分析预测偏差、技能瓶颈和计划外工作模式。否则模型学到的可能是填表习惯，而不是组织真实的资源规律。

八、常见问题：PMO资源管理的实践答疑

1. PMO是否应该直接决定人员分配

不一定。PMO通常更适合负责资源视图、组合冲突、规则设计和升级机制；团队负责人掌握实际容量与技能；业务负责人或组合治理层负责优先级取舍。若PMO没有授权，却被要求单独决定所有人力分配，最后往往会变成替各方传话，无法真正消除冲突。

组织可以授权PMO在明确边界内做常规协调，例如处理已批准优先级下的排期调整；涉及业务目标、客户承诺或重大范围变化时，应由相应责任人裁决。

2. 应该按工时还是按人数管理

两者都需要，但回答的问题不同。人数适合做编制和能力池的粗略视图；工时或容量适合安排近期工作；复杂工作还需要看连续时间、技能层级和依赖。只看人数会忽略可用比例，只看工时则可能掩盖人员技能不匹配。

组织应从实际决策出发选择颗粒度：若要判断未来季度是否需要补充某类能力，可按人数和技能池估算；若要安排下个迭代的工作，则需要更细的容量和时间窗口。

3. 资源预测应该提前多久

没有适用于所有组织的统一周期。预测窗口应覆盖组织做出招聘、培养、供应商采购或项目排序所需的准备时间。短期排期要足够具体，远期预测则应保持情景化，并随着需求成熟逐步更新。

判断预测窗口是否合适，可以看组织是否有时间采取行动。如果缺口出现时已经来不及招聘或调整项目顺序，预测太晚；如果远期数字频繁变化且没有可执行用途，预测可能过细或时间跨度过长。

4. 怎样判断一个人是否真的过载

不要仅凭登记工时超过某个比例判断。结合连续高负荷周期、加班、任务切换、交付偏差、返工、缺陷、请假恢复情况和本人反馈一起看。任何单一信号都可能误判，尤其是早期估算和计划外工作记录不完整时。

过载识别的目的应是调整工作系统，而不是给个人贴上“效率低”或“抗压差”的标签。必要时应检查项目并行数、优先级冲突、支持轮值、任务拆分和管理跨度。

5. 资源管理系统能否自动解决资源冲突

系统可以减少重复登记、汇总供需、显示冲突、追踪决策和保留历史，但无法替代业务取舍。若组织没有清晰的优先级规则、容量确认责任和冲突升级路径，自动化只会更快地展示矛盾，不会自动解决矛盾。

评估系统时，应先用真实流程验证：需求从哪里进入、谁确认、如何处理变更、冲突如何升级、决策如何回写，以及数据如何与现有工作系统衔接。功能丰富不等于治理成熟，流程可执行比界面更关键。

6. 如何避免资源台账变成“没人维护的表”

每项关键数据都要有责任人和更新触发点；输入应尽量接近工作发生的位置；管理会议要真正使用这些数据做决策；过期信息应被标记，而不是默默保留。若更新数据没有任何后续用途，团队自然会把它视为额外负担。

还可以定期删除不再支持决策的字段。台账的质量不取决于列数，而取决于信息是否能帮助判断需求、容量、风险和责任。

7. 个人资源数据可以用于绩效评价吗

应谨慎。资源数据多是计划估算和协作记录，可能受到任务复杂度、支持工作、依赖等待和需求变化影响。直接用利用率或估算偏差评价个人，容易诱发虚报工时、拒绝支持任务和回避不确定工作。

如果组织需要绩效信息，应使用与岗位目标相匹配、经过解释和校验的证据，并结合质量、协作、学习和实际贡献。资源视图的首要用途是改善供需和降低交付风险，而不是把粗略计划数值变成个人排名。

九、结尾：把资源冲突变成可治理的选择

PMO资源管理真正的成熟，不是每个人的日历都被填满，也不是每个项目都拿到自己想要的人数，而是组织能够在冲突出现时看清事实、找到有权决策的人，并明确接受每种选择的代价。

我最看重的判断标准是：资源计划能否让“需求、能力、时间、假设、优先级和承诺”彼此关联。当专家无法兼顾多个项目时，组织能不能决定先做什么、延后什么、转交什么；当假设改变时，相关计划能不能同步调整；当关键岗位只有一个人时，是否有人在降低单点依赖。

下一步不必先买工具或重做所有流程。先选一个项目组合，统一可用容量口径；把近期冲突拆成时间、能力和优先级三类；给每项关键需求补齐工作结果、窗口和置信度；再建立由谁确认、由谁裁决、由谁回写的闭环。跑完几个周期后，用延期、计划外工作、冲突解决时间和关键岗位负荷验证机制是否有效。

资源管理的目标不是证明团队“已经很忙”，而是让有限能力被投向最值得做、最需要现在做、且组织愿意承担其代价的工作。