资源管理资源池全流程：PMO制度设计与一文讲清

资源管理资源池最常见的失败，不是“人不够”，而是同一个人被三个项目同时当成可用资源：项目经理按计划排了他，部门主管按职能工作安排了他，临时需求又把他拉去救火。到月底，工时表看起来完整，交付却延期，团队还说不清究竟是谁做了取舍。资源池的价值，不在于把员工名单放进一张表，而在于建立一套可追溯的决策机制：谁能申请、谁有权承诺、资源冲突如何裁决、需求变化后如何重新分配。

一、先讲核心结论：资源池不是人力清单，而是供需治理机制

1. 资源池要解决的是承诺冲突，而不是“看见人员”

我设计资源管理制度时，通常先问一个问题：组织是否能在项目启动前回答“这项工作需要什么能力、什么时间投入、由谁批准、与现有承诺冲突时如何处理”？如果不能，建立一张更漂亮的人员表格也不会改变结果。

真正有效的资源池至少包含四类信息：资源能力与可投入时间、项目需求与优先级、分配与审批规则、实际投入与偏差反馈。四者缺一不可。只有人员信息没有需求管理，资源池是名册；只有需求没有可用能力，资源池是愿望清单；只有分配没有反馈，资源池会不断重复错误。

我的核心判断是：资源池不是一个静态库存，而是一套“需求进入，能力匹配，承诺批准，执行监控，释放复盘”的闭环。制度要让资源决定有依据、有责任人、有变更记录，而不是让PMO替所有项目经理做排班。

2. 先区分“资源可见”与“资源可承诺”

某位工程师本月有十个工作日没有登记任务，不代表他有十天可供新项目使用。假期、值班、技术债、团队例会、跨项目支持和不可预见工作，都可能占用这段时间。因此，资源池中的“空闲”必须有口径，不能把日历空白直接等同于可承诺产能。

我建议把资源状态至少拆为四种：已承诺、待确认、可分配、不可用。已承诺代表有批准的工作；待确认代表需求或时间尚未核实；可分配代表在预留缓冲后仍能接受任务；不可用则包括休假、关键值班、培训或其他明确限制。状态改变需要有来源和更新时间。

例如，团队名义上每月有20个工作日。扣除例会、支持任务和常规维护后，可规划产能可能只有14至16天。若PMO仍按20天配置项目，计划表会显得充足，实际交付却会持续透支。这不是个人效率不足，而是产能口径错误。

3. 资源池的首要产出是可执行的分配决策

一个资源池是否有用，可以用三个问题检验：项目启动前是否能找到合适能力；冲突发生时是否能在规定时间内得到裁决；分配后是否能看到承诺与实际投入的差异。若这三项都没有改善，系统里有多少人、多少标签、多少仪表盘都不是关键成果。

因此，PMO不应把目标设为“收集到所有人的工时”，而应设为“提升关键资源分配的可预测性”。工时采集只是证据之一，不是管理目的。对于低风险、标准化的任务，粗粒度估算足够；对于稀缺专家、关键路径和跨部门资源，才需要更细的投入与变更记录。

二、背景与真实场景：资源为什么总在最后一刻短缺

1. 需求入口多，承诺出口少

中大型组织通常同时存在产品路线图、客户交付、内部系统建设、合规整改和运维支持。需求可能从业务部门、销售团队、管理层、研发团队各自进入，却没有统一的优先级和资源承诺入口。每条线都认为自己的事项“已经排进计划”，最后却发现同一位架构师、测试负责人或数据专家被重复安排。

这类冲突的根因不是大家不会填表，而是不同需求拥有不同的承诺权。若部门主管可以口头调人、项目经理可以自行锁定资源、业务负责人又能临时插入事项，正式计划就会被非正式承诺不断覆盖。PMO需要做的不是再加一张表，而是明确什么动作才构成组织承诺。

2. 资源瓶颈往往集中在少数能力，而不是总人数不足

团队总人数看起来够用，并不意味着关键能力够用。一个项目可能需要十名开发人员，却只有一名熟悉核心系统的架构师；另一个项目可能有充足测试人员，却缺少能设计自动化框架的人。按部门人数汇总，会掩盖能力结构上的短缺。

我更倾向于把资源盘点从“有多少人”改为“哪些能力在什么时间段是瓶颈”。能力名称不能无限细分，否则匹配成本过高；也不能只写“研发”“运营”这类过宽标签。实务上可以采用三层分类：专业领域、技能方向、熟练度或授权级别，再为稀缺能力设置明确的替代规则。

3. 计划产能与实际产能之间必须留出缓冲

资源计划不是把每个人的日历填满。若团队每周都按100%排满，任何临时故障、需求澄清、返工或客户反馈都会转化为延期。缓冲比例没有适用于所有组织的单一答案，关键在于识别工作波动性：稳定、可重复的团队可以采用较高的计划负荷；探索性研发、客户交付和高支持负荷团队则需要更多机动空间。

以下示意用于解释产能折减，不代表行业统计。假设一名全职员工每月有20个工作日，日常会议与支持约占3天，休假及不可用时间折算1天，组织希望保留2天应急空间，那么可承诺产能约为14天，而不是20天。若再承担两个项目各10天的承诺，冲突在计划阶段就已出现。

4. 资源池要同时照顾项目交付与职能发展

如果制度只按项目需求分配资源，关键岗位会长期被最紧急的项目占用，培训、技术治理和知识传承就会不断延期。反过来，如果部门只按职能发展保留人员，项目又会因为关键能力不足而拖延。资源管理制度必须把业务交付、运营保障、技术治理和能力建设放在同一张决策桌上。

这并不意味着所有工作都要折算成同一单位后机械比较。合规事项可能有截止日期，运维任务可能涉及服务等级，产品探索可能具有不确定收益。PMO需要把约束和收益显式表达，供有权决策的人取舍，而不是假装所有需求都能用一个“优先级分数”完全排序。

三、常见误区：为什么资源池越建越复杂，冲突却没有减少

1. 把资源池做成通讯录或技能标签库

人员姓名、部门、技能、职级、所在城市等信息有价值，但它们只是资源描述，不是分配机制。若没有可用时间、项目需求、决策权限和更新责任，标签越多，查询越复杂，管理者仍然会回到私聊和会议中找人。

我的做法是先限定最小数据集，再根据决策需要扩充。初始阶段通常只需知道：能力类别、所属团队、可投入时间区间、当前承诺、不可用约束、资源负责人和数据更新时间。每增加一个字段，都要能回答“它将改变哪一种分配决策”。

2. 把100%利用率当成效率目标

利用率高不等于产出高。团队可能在等待审批、频繁切换任务、返工和救火中保持“忙碌”，但交付周期反而更长。资源池若只奖励高利用率，管理者会倾向于把每个空档都塞进任务，最终增加并行工作量和协调成本。

应当区分资源利用率、交付完成率、周期时间和变更频率。对于依赖协作的知识工作，过高的并行负荷会让等待时间上升。PMO最好观察一段时间内的趋势，而不是把单月利用率作为部门绩效的唯一依据。

3. 用工时填报替代资源治理

工时记录可以帮助解释投入与偏差，却不能自动回答该不该启动项目、谁应该承担任务、哪个项目该让路。过度追求精确到小时的填报，会把管理成本转嫁给执行团队，也可能诱发“填得准确但决策无用”的数据形式主义。

对大多数计划管理场景，周或迭代级投入记录可能足以识别偏差；只有成本结算、合同计费、法规审计等明确场景，才需要更细颗粒度。记录精度应匹配决策精度：若决策单位是团队周产能，就不必采集每个人每天每小时的所有活动。

4. 认为工具上线后，资源问题自然会消失

管理软件能降低信息汇总、状态更新和冲突识别的成本，但不能替代组织授权。若项目优先级没有统一口径，工具只会更快地显示出冲突；若部门负责人仍可绕过流程承诺资源，系统计划很快就会失真。

以PingCode这类面向中大型企业及100人以上组织的项目管理平台为例，可以把项目计划、工作项、团队容量和进展信息放到相对一致的工作环境中，减少多表维护。不过，平台能否发挥作用，取决于组织是否先定义需求入口、审批责任和状态口径。采购工具之前，我会先确认流程是否能够用一张纸讲清楚。

5. 把所有资源冲突都交给PMO处理

PMO负责制定规则、维护组合视图、推动冲突升级和记录决策，不应成为每个资源请求的最终批准者。项目优先级、业务收益和部门能力建设通常需要业务负责人、项目组合委员会或职能负责人共同承担责任。

若所有冲突都由PMO拍板，PMO既缺少业务授权，也容易成为瓶颈。更稳妥的设计是把决策分层：团队内部的短期调整由团队负责人处理；跨项目的关键资源冲突由组合层裁决；涉及战略、预算或重大客户承诺的冲突则升级到有相应授权的管理层。

四、专业判断逻辑：PMO如何设计资源池制度

1. 先划清资源池边界

不是所有工作都必须纳入同一个池。稳定的运维团队可能按服务容量管理，临时项目团队可能按阶段性需求管理，专家资源可能按预约和审批管理。若把所有人、所有活动都混成一个池，流程会过度复杂；若切分过细，又无法看到跨项目竞争。

我建议从三类资源开始：稀缺专家、跨项目共享岗位、项目关键路径岗位。普通、稳定且由单一团队独立交付的工作，可以先由团队内部管理。待组织能够稳定维护数据，再逐步扩大覆盖范围。

资源池边界应明确资源所有权与分配权。职能部门通常负责人员能力、培养和日常管理；项目组合或业务负责人负责项目优先级；项目经理负责需求澄清和交付安排；PMO负责规则、视图、节奏与决策记录。职责可以因组织调整，但不能让“谁都能承诺、没人负责冲突”成为默认状态。

2. 建立统一的资源需求单

资源申请不能只写“需要一个高级工程师两个月”。至少要说明任务结果、所需能力、投入区间、持续时间、开始与结束条件、优先级依据、可替代方案，以及若不能满足会造成什么影响。需求越具体，匹配越有效，也越容易评估是否可以拆分、延期或外包。

对能力描述，我建议用“任务类型＋能力层级＋必要性”表达。例如，不写“需要数据人员”，而写“需要具备客户数据治理经验的分析师，在方案评审和上线验证两个阶段各投入约一周；一般报表开发可由团队成员承担”。这能避免把高阶专家长期锁定在低复杂度工作上。

3. 统一容量口径，避免虚假的精确

资源池容量可以按人天、团队周或百分比表示，关键是组织内一致。早期不必追求精确到小时，可以先以周为单位记录计划负荷；当项目成本核算或合同要求确实需要更细数据时，再细化到日或小时。

容量口径要同时规定有效工作日、常规支持占比、假期处理方式和应急预留。对高不确定工作，可以用区间而非单点承诺，例如“每周约2至3天”，并标明复核日期。单点数字看起来精确，却可能把尚未验证的估算包装成承诺。

4. 设计分层优先级，不要迷信一个分数

我通常把优先级拆成硬约束与可比较因素。法律或合规截止日期、已签约交付、生产安全等可能是硬约束；战略贡献、用户影响、收益潜力、风险降低和机会成本则是比较因素。先识别哪些事项不能简单让位，再对其余事项进行权衡。

可以使用评分表辅助讨论，但必须展示评分依据和不确定性。若每个项目的业务收益都被评为最高，评分工具就失去了区分能力。遇到争议时，管理层应决定的是“本次选择牺牲什么”，而不是要求PMO把分数调到看起来没有冲突。

以下为可用于讨论的示意权重，不是通用标准。组织可以按战略阶段调整，但调整必须记录原因，避免每个项目临时修改规则以争取资源。

5. 规定分配、变更和释放的授权

制度要写明哪些动作可以直接批准，哪些必须升级。团队内部不影响其他项目的短期调度，可以由团队负责人处理；占用稀缺专家、改变已承诺里程碑或跨项目挪用资源，则应由相应的项目组合决策者批准。

资源变更必须记录原因、影响对象、批准人、生效时间和回滚条件。尤其要避免“资源已经口头挪走，但原项目计划仍显示未变”的双重事实。资源池的可信度来自变更可追溯，而不是审批数量多。

6. 建立稳定的管理节奏

资源池不应只在项目启动时更新。建议采用两种节奏：短周期滚动检查，处理未来数周的容量和变更；较长周期组合审视，处理季度或阶段级优先级和能力缺口。频率要与业务变化速度匹配，过低会错过冲突，过高则让团队陷入反复排计划。

会议前应由项目经理更新需求、负责人确认可用性，PMO整理冲突清单。会议只讨论例外、取舍和待决事项，不逐项朗读所有资源状态。若大多数会议时间都花在核对表格，说明数据责任或工具整合还没有做好。

资源治理的决策链可以概括为：需求提交、完整性检查、容量匹配、优先级裁决、承诺登记、执行复核。每个节点都要有输入、责任人和输出，不必把流程设计成层层审批。

7. 让数据定义为决策服务

建议先确定少量核心指标：关键资源冲突数、需求响应时间、已承诺与实际投入偏差、计划变更次数、项目因资源原因延期的比例、资源释放及时率。每个指标都要附上口径、统计周期、数据来源和责任人。没有口径的数字无法比较，容易被误用。

资源利用率可以作为观察指标，但不宜直接变成单一考核目标。若利用率上升同时交付周期拉长、返工增加或延期上升，说明团队可能只是更忙，并没有更有效。管理者应该寻找指标之间的因果线索，而非对一个数字做奖惩。

五、落地案例与数据观察：先治理瓶颈，再谈全面透明

1. 一个跨部门团队的情景复盘

以下案例为依据常见组织问题构造的匿名情景模拟，不代表特定客户的真实统计。某企业有约160名项目、产品、研发和测试人员，多个业务团队共享少数架构、数据与安全专家。项目分别维护自己的排期表，团队主管掌握人员可用性，PMO每月汇总一次组合状态。

复盘发现，项目计划中出现了重复承诺；关键专家经常在临近评审时被临时借调；业务提出的紧急事项没有统一说明对原计划的影响。管理层最初希望“统一收集所有人的工时”，但进一步梳理后，真正的首要问题是需求口径不一致和跨项目承诺缺少决策出口。

团队先对架构、数据、安全三类稀缺能力建立资源池试点，不要求所有岗位同步填报。项目经理提交需求时必须说明阶段、投入区间和可替代方案；职能负责人每周确认未来六周的可用性；组合负责人每两周处理一次跨项目冲突。PMO只维护冲突台账和决策记录，不代替业务负责人决定项目优先级。

2. 试点前后应该比较什么

试点结果不能只看“资源表填报率”。更有意义的观察包括：重复承诺是否下降、冲突从提出到决策的时间是否缩短、资源是否更早释放、项目变更是否留下原因、因资源问题延期的事项是否减少。下表是情景模拟数据，用于说明评估方法，不是行业基准或外部调查结果。

3. 结果改善不等于流程已经成熟

试点数据即使改善，也要检查是否存在转移成本。例如，冲突数下降可能是项目经理不再提交需求；资源原因延期下降可能是延期原因被重新分类；信息完整率上升也可能只是大家学会填写字段，但需求估算仍不可靠。

因此，我会同时抽查原始项目记录、变更单和实际投入，并访谈项目经理与职能负责人。定量数据回答“发生了什么”，访谈和样本核查帮助解释“为什么发生”。如果数据口径在试点中途改变，应把变更写入复盘，不将前后数字直接当成严格因果证明。

4. 资源池试点的分阶段路线

第一阶段先选瓶颈能力，而非全员推广。挑选重复冲突较多、业务影响可见、负责人愿意参与的两至四类岗位，明确容量口径和决策权。试点周期要覆盖至少一个完整的计划、执行与复盘循环，才能观察资源释放和变更处理。

第二阶段把资源需求、项目优先级与进展变化关联起来。项目范围或里程碑变化时，必须重新核对资源承诺。资源池不能只在需求进入时更新，计划变动之后仍沿用旧容量，会让系统保持“看似准确”的历史信息。

第三阶段才考虑扩展到更多团队、增加自动化提醒和组合分析。扩展前应确认数据维护成本是否可接受，职能负责人是否能按节奏确认容量，决策者是否实际使用冲突视图。若答案是否定的，先修复责任和流程，不要急于增加字段与仪表盘。

六、工具与数据：怎样让平台支撑制度而不是替代制度

1. 先定义最小可用数据模型

工具选型前，我会先画出资源池需要管理的实体关系：人员或能力单元、项目与工作项、需求申请、投入承诺、日历可用性、变更记录和实际投入。每项信息都应有明确维护人和更新时间，否则数据会在项目数量增加后迅速过期。

最小字段可以包括资源标识、能力分类、所属团队、可投入时间段、现有承诺、需求优先级、申请状态、审批记录、预计释放日期和实际偏差。个人敏感信息应遵循最小必要原则，只收集完成资源决策所需的信息，控制查看权限与留存范围。

2. 工具能力应与管理问题一一对应

某项目管理平台可以帮助团队集中维护项目、任务、负责人、时间计划和进展状态；如果支持容量视图、跨项目查询、权限控制、变更记录和数据导出，也能减少手工合并计划表的负担。选型评估时应拿真实场景验证，而不是只看功能清单或演示环境中的标准流程。

以PingCode为例，如果组织已经用平台管理项目工作项和团队进展，可以进一步评估其是否适合承载资源需求、项目计划与团队容量信息的协同。验证重点不是“有没有资源管理模块”这一个问题，而是能否按组织权限维护数据、识别跨项目冲突、追踪承诺变更，并把需求状态与交付工作关联起来。具体能力和配置应以实际版本、部署方式及组织方案核实为准。

3. 用试验任务验证真实工作流

我建议选取一个真实的跨团队项目，走完从需求提交到资源释放的全流程。让项目经理提交申请，让职能负责人确认容量，让决策者处理一次冲突，再由执行团队更新进展。观察是否需要在平台外重复维护、字段是否过多、权限是否阻塞、报表能否直接用于会议。

验证时至少检查四类问题：数据能否在一个位置维护；不同角色看到的信息是否合适；变更后计划是否同步；管理者能否在数分钟内找到待决事项。如果任何一步仍必须复制到多个表格，应该先查清是平台能力缺口还是流程设计不一致。

4. 选择系统时比较总成本，而不是只比较许可价格

资源池的工具成本包括许可或订阅、实施配置、数据迁移、培训、管理员维护、集成开发和日常填报时间。对100人以上的组织，维护成本可能随着团队、角色和流程差异增长。过度定制会抬高升级与运维负担，因此应优先验证标准配置能否覆盖核心流程。

若组织目前只有少量团队、需求稳定、冲突少，电子表格或轻量看板可能足够；若组织跨部门协作多、项目组合复杂、审计要求较强，集中平台更有价值。工具并非越复杂越好，关键是它能否减少决策等待和重复维护，且不把数据录入工作转嫁给一线。

七、不同情况下的行动建议：从问题类型反推治理动作

1. 如果冲突集中在少数专家

先建立稀缺能力清单，限定在真正无法快速替代的岗位，不要把所有岗位都标记为关键资源。对每种能力记录当前承诺、未来可用区间、替代人选和培养计划。短期通过组合层裁决分配，长期通过知识转移、轮岗和备份人选降低单点依赖。

不要只问“谁还能借给项目”，还要问“为什么每项任务都必须找同一个人”。若专家被大量低复杂度任务占用，应该重新分工、建立标准或培养替代能力。增加资源池透明度能暴露瓶颈，却不能凭空创造能力。

2. 如果项目需求变化频繁

采用滚动容量而非一次性年度排期。把近端工作安排到较细颗粒度，把远期需求保留为区间和假设，并设置复核日期。对范围变化建立影响评估：新增工作占用谁的时间、原有里程碑是否变化、需要谁批准。

需求频繁变化时，过细的长期资源计划会制造虚假确定性。较合理的做法是保护近期承诺，远期使用能力池和情景计划；当需求进入明确窗口，再将资源转为正式承诺。这样既保留调整空间，也不会把资源长期“占住不用”。

3. 如果组织刚开始做资源管理

先选一条业务线或几类共享资源做小范围试点，使用最少字段和简单审批。第一轮只验证三件事：需求是否能说清、冲突是否能裁决、承诺是否能更新。不要一开始就建设覆盖全公司的精细工时体系，也不要把平台配置、绩效考核和组织调整同时推进。

试点结束后，评估维护负担。如果每周需要多个管理员花大量时间修正数据，而管理者却不据此作决定，说明流程设计过重。应先删字段、调整节奏或明确责任，再决定是否扩展。

4. 如果项目组合已经成熟、审计要求较高

把资源申请、批准、调整和释放纳入可追溯的治理记录。定义记录保留期、审批权限、数据访问范围和例外处理。对重大项目与关键资源建立正式基线，所有影响承诺的变更均记录原因、批准人和生效时间。

成熟组织也不应把每个小任务都升级为组合审批。制度可以采用分级门槛，例如按资源稀缺程度、投入规模、项目影响和跨部门范围判断是否升级。门槛要便于执行，并定期复核是否造成不必要的等待。

5. 如果团队抵触填报

先检查他们是否看得到回报。若填报后仍要在会议中重新解释、仍需另填多个表格、数据只用于追责而不用于解冲突，抵触是合理的。减少重复录入、让资源负责人及时更新结果，并把计划变化的原因公开，通常比要求“提高填报意识”有效。

同时要区分合理透明与微观监控。资源管理关注的是团队承诺、能力供给和交付风险，不应把每个人每分钟的活动都变成审查对象。对于知识工作，精确追踪并不自动带来更好的管理，反而可能损害信任和协作。

八、不同情况下的取舍：没有一种制度能同时优化所有目标

1. 透明度与维护成本之间的取舍

更细的数据能帮助识别个人层面的冲突，也会增加填写、校验和维护成本。若组织当前只需要判断团队是否有足够容量，按团队或能力单元汇总可能已经够用；只有在稀缺专家、成本核算或明确合规场景中，才值得深入到个人级甚至日级数据。

我的建议是从决策所需的最低粒度开始。数据粒度应能够支持批准或拒绝需求，而不是为了追求“看起来全面”。当管理者无法解释某个字段会改变什么决策，就不应把它列为必填。

2. 效率与公平感之间的取舍

把资源优先给高收益项目，可能让基础能力建设和低可见度的维护工作持续被挤压；平均分配资源看似公平，却可能让所有项目都进展缓慢。应明确组织当前优先优化的是战略收益、客户承诺、风险降低还是能力建设，并为非项目工作留出明确份额。

公平不是每个项目都拿到一样多的人天，而是决策规则透明、例外有解释、被延后的团队知道原因。资源池不能消除竞争，只能让竞争从私下关系转为有依据的组织决策。

3. 利用率与韧性之间的取舍

把产能安排得越满，短期看起来越有效率，但组织应对突发事项和探索性工作的能力会下降。保留缓冲意味着某些周期里看起来没有全部利用，但这部分余量可能减少故障响应时间、计划返工和跨项目中断。

缓冲不是固定比例的浪费额度。应根据工作波动、支持责任和历史偏差调整：需求稳定、工作可预测的团队可以减少缓冲；运维占比高、依赖外部审批或需求变化频繁的团队应保留更大机动空间。调整依据应来自自身数据，而非照搬其他组织的数字。

4. 集中统筹与团队自治之间的取舍

完全集中分配可以减少跨项目争抢，却会让决策离现场更远；完全自治能提升团队响应速度，却可能产生重复承诺和部门墙。适合多数组织的折中方式是：团队内资源由团队负责人调度，跨团队稀缺能力由组合层统筹，战略级冲突由高层决策。

授权边界应与可逆性匹配。短期、低风险、可快速撤回的调整可以下放；影响关键里程碑、客户承诺或长期能力结构的决策应升级。这样既不让PMO成为审批中心，也不让重要资源配置变成无记录的口头交易。

九、结尾：把资源池从“看人”变成“做选择”

1. 最值得记住的判断

资源管理资源池真正的价值，不是把所有人的时间都填满，而是让组织在资源有限时更早看见冲突、更清楚地表达取舍，并让承诺与实际投入可以复核。它最终管理的不是人员名单，而是组织对项目、能力和风险的优先级选择。

如果制度只能告诉你“谁很忙”，却不能回答“哪项工作先做、谁批准、另一项工作因此延后什么、变更后如何恢复容量”，它还不是完整的资源管理机制。反过来，即便起步阶段只有少数关键资源、一套轻量流程，只要决策责任清楚、数据可信、冲突有出口，也已经具备扩展基础。

2. 下一步先做三件事

第一，列出过去一个季度反复发生资源冲突的岗位或能力，控制在少数关键项，不要从全员盘点开始。第二，为这些能力统一需求单和可用产能口径，明确项目经理、职能负责人、PMO和组合决策者各自的责任。第三，选择一个真实项目组合跑完需求、分配、变更和释放流程，用本组织的数据复盘响应时间、重复承诺和资源原因延期。

先让一项资源决策变得透明、可解释、可追溯，再扩大资源池范围。制度设计不靠字段数量证明成熟，而靠组织能否在真实冲突中作出清晰选择，并愿意承担选择带来的机会成本。