资源管理人员教程：产品经理最佳实践，避坑指南

资源管理人员教程：产品经理最佳实践，避坑指南

产品团队最常见的资源管理错误，不是“人手不够”，而是把每个人的日历排满，就误以为项目有了保障。一个看似有 8 名工程师的团队，扣掉会议、支持、休假、跨项目协作和返工后，真正能投入新需求的产能可能不到计划值的六成。产品经理要管理的不是一张满格排期表，而是需求、能力、时间和不确定性之间的约束关系。本文会用一个明确标注为情景模拟的产品团队案例，拆解如何估算可用产能、安排优先级、识别资源风险，并在不同组织条件下做出可执行的取舍。

一、先讲核心结论：资源管理不是把人排满，而是让承诺可信

1. 资源管理要回答四个问题

我做资源规划时，先不问“谁还有空”，而是依次问四件事：团队在目标周期内实际上能投入多少时间；哪些能力是交付所必需的；当前需求之间有什么依赖；当预测发生偏差时，团队准备牺牲什么。四个问题都有答案，排期才有讨论价值。

如果只看工时，常见结果是计划上有充足人力，执行中却卡在稀缺能力上。例如，前端工程师尚有余量，但唯一熟悉支付对账逻辑的后端工程师同时承担两个项目。此时整体团队看上去并不忙，关键路径却已经超载。

我判断资源计划是否靠谱，核心看它能否解释“为什么这件事现在能做、由谁做、遇到变化时怎么调整”。如果计划只包含负责人和日期，没有容量假设、依赖关系及变更规则，它更像愿望清单，不是管理工具。

2. 先区分需求、容量与承诺

需求是想完成的工作；容量是某个周期内团队可用于交付的有效投入；承诺则是在已知约束下，团队愿意对外承担的结果。三者不能画等号。产品经理可以提出需求，管理者可以确认容量，团队需要参与承诺，任何一方单独拍板都容易制造虚假的确定性。

一个实用原则是：先确认容量，再排序需求；先确定关键路径，再承诺日期。顺序反过来，团队通常会靠加班、压缩测试或推迟其他工作来填补计划缺口，表面上没有调整范围，实际代价却被藏起来了。

3. 资源管理的目标是降低交付风险

资源管理不是追求每个人每天都有任务。若每个岗位都长期处于满负荷状态，突发线上问题、需求澄清和技术风险都会变成排期事故。适度留出缓冲，不是浪费资源，而是为不可预见工作购买韧性。

在许多产品团队的规划实践中，我会把“容量是否可解释、优先级是否可比较、依赖是否显性、变更是否有代价”作为四项基本检查。这里的“检查”是管理方法，不代表行业统一标准。组织可以根据工作类型、历史交付记录和风险承受能力调整阈值。

二、背景和真实场景：为什么团队看起来人不少，项目仍然延期

1. 情景模拟：八人团队同时承接三类工作

下面用一个情景模拟说明资源错配的形成过程。假设某产品团队有 8 名工程师、2 名测试人员和 1 名产品经理，计划在未来四周完成新用户引导、账单异常修复和一项管理端改造。数字仅用于演示计算方式，不代表任何企业的真实项目记录。

计划表上，8 名工程师每人每周按 40 小时计算，团队四周总工时是 1,280 小时。但其中包含例会、代码评审、线上支持、内部沟通和假期。若按示意假设，将每人每周 40 小时中的 8 小时用于固定协作、4 小时用于支持与维护，并预留 10% 的容量缓冲，那么新增需求可计划容量大约为：8 人 × 4 周 ×（40－8－4）小时 × 90%，即约 806 小时。

这个数仍只是团队总量，并不意味着每个岗位、每类技能都有 806 小时。账单修复可能依赖一名熟悉财务数据链路的后端工程师；新用户引导可能依赖前端、数据埋点和设计评审；管理端改造可能需要权限系统维护者确认接口边界。总工时充足，不等于关键技能可用。

2. 日历容量与有效容量是两种口径

日历容量通常是人数乘以工作时间，适合做理论上限；有效容量则要扣除固定协作、已承诺工作和计划缓冲，更适合做项目决策。两种口径都可以保留，但不能混用。若团队习惯以“每人每周 40 小时”承诺开发量，实际上等于把会议、支持与协调工作假设为零。

我会把容量分成三层：理论容量、可规划容量、可承诺容量。理论容量用于快速判断规模；可规划容量扣除已知固定投入；可承诺容量再考虑风险、依赖和验收工作。项目越不确定，后两者之间的差距通常越大。

3. 资源冲突常常是结构问题，不是个人不努力

如果同一位工程师连续几周被三个项目同时标记为“核心成员”，问题通常不在他的效率，而在组织没有明确资源决策权。矩阵式协作中，多个负责人可以同时提出需求，但没有人负责比较这些需求对同一岗位的竞争影响。

另一个容易被忽略的来源是“隐性工作”。线上缺陷、数据核对、合规评审、客户问题和临时分析往往没有进入项目计划，却持续占用同一批人的时间。若它们长期不计入容量，团队每次延期都会被解释成执行不力，而不是计划输入失真。

三、常见误区：看似提高利用率，实际降低交付可靠性

1. 误区：把排满日历当成资源利用率高

排满日历只能证明任务被分配，不证明任务能完成。工作切换、等待反馈、环境阻塞和返工都会拉长周期。若每位成员同时处理多个高优先级任务，任何一个任务获得连续专注时间的机会都会下降。

我更愿意观察工作在制数量、阻塞时间和交付周期，而不是单独追求个人忙碌程度。忙碌是活动，交付是结果。把利用率做成唯一目标，还会让团队不愿意接手探索、文档和维护等短期不显眼但长期必要的工作。

2. 误区：用人数相加推导项目可行性

“我们有十个人”不是项目容量结论。十个人可能只有一个人掌握特定系统，也可能缺少测试、数据分析或安全评审能力。对资源计划来说，岗位结构、熟练度、协作成本和连续投入时间，往往比人数本身更能解释交付结果。

评估前应把需求拆成可验证的工作包，并标注必要角色、估算区间、前置条件和验收人。估算尚不清楚时，不应伪装成精确排期；应先安排澄清或技术验证，并把它们作为计划的一部分。

3. 误区：用“优先级高”代替明确取舍

当所有需求都被标为高优先级时，优先级就失去区分作用。产品经理要推动业务负责人说明：如果这项工作插队，哪一项工作后移；如果截止日期不可变，范围可以缩到什么程度；如果范围不可变，哪些资源或风险需要补充。

优先级不是标签，而是资源冲突中的取舍规则。没有被延后的事项清单，所谓“提高优先级”往往只是把延期风险转移给团队。

4. 误区：估算精确到小时，输入却模糊不清

需求的验收条件、数据口径或外部依赖尚未确定时，给出“需要 37 小时”并不会让预测更准确。它只是让不确定性看起来更具体。早期估算最好用区间，并明确区间背后的假设；信息逐渐完善后，再缩小区间。

我会把未知项单独列出来，例如“外部接口是否支持批量查询”“历史数据是否需要补录”“权限规则是否沿用旧逻辑”。这些问题若可能改变方案，就应先用小规模验证减少不确定性，而不是让开发在错误假设上继续投入。

5. 误区：把关键人员的超负荷当成短期解决方案

关键人员承担多项并行工作，短期看似能推动多个项目，长期却会形成单点故障。休假、离职、线上事故或需求变化都可能让所有依赖同时停摆。超负荷还会让知识无法传递，团队越来越依赖某个“只有他知道”的人。

资源计划需要记录关键技能的备份情况，并为知识转移、结对处理或文档补齐预留投入。若某项能力确实无法替代，应将依赖暴露给决策者，而不是悄悄把风险写进某位员工的加班时间。

6. 误区：把临时插单视为免费变更

任何新增工作都会消耗容量，即使它很小，也会带来沟通、切换、测试和重新排序成本。插单是否值得，应该看新增价值与被挤占工作的代价，而不是只比较需求本身的开发时长。

对紧急事项，我会要求记录提出时间、原因、影响范围、替代项和决策人。这样做不是设置流程门槛，而是让团队知道谁批准了变更、谁承担其后果，以及原有承诺要如何修订。

四、专业判断逻辑：从容量测算到资源决策

1. 先定资源规划的时间粒度

资源规划并非所有层级都用同一粒度。季度层面适合讨论目标、能力缺口和重大依赖；月度层面适合调整项目组合；迭代或周度层面适合安排具体工作。若用季度预测精确到个人每天，假设会多到无法维护；若只用季度目标却不检查短周期负荷，又可能错过早期预警。

我建议保持两种视图：一张是团队或角色层级的容量预测，用来观察供需；另一张是近周期任务安排，用来推进执行。前者不必过早指定每个人，后者则必须清楚任务负责人、验收方式和依赖条件。

2. 容量测算要把已知工作和未知工作分开

团队有效容量可以先按以下逻辑估算：计划工作日乘以可投入工时，扣除休假、固定会议、支持维护和已承诺事项，再对剩余容量应用风险缓冲。每项扣除都应注明来源和口径，避免一边用净工时估算需求、一边又把固定工作重复扣减。

未知工作不必全部猜一个数字。可以按历史记录估算常见支持工作，也可以为尚未明确的部分保留容量池，并约定由谁批准使用。关键是透明：缓冲不是隐形闲置，应该写明它服务于哪些风险，以及何时可以重新分配。

3. 需求排序不能只看价值，也要看时效与成本

我通常用五类信息辅助比较需求：预期业务价值、错过窗口的代价、实现与维护成本、依赖风险、证据可信度。它们不是一套适用于所有公司的固定评分公式，而是一种防止讨论只围绕“谁的声音大”的结构。

比如，价值预期很高但依据只是未经验证的内部猜测，应该先安排验证；收益中等但涉及法规期限的事项，可能有明确时间约束；成本很低但会占用稀缺专家数周的工作，也不能只看工时数字。排序的目标是让不同类型的理由可以被看见和质疑。

4. 识别关键路径，而不是平均分配人力

项目总周期通常由相互依赖的工作链决定。若设计评审必须先于接口开发，接口又必须先于集成测试，那么缩短非关键路径上的工作时间，未必能让项目提前完成。产品经理应与技术、设计和测试负责人共同画出主要依赖，找出一旦延迟就会推迟整体验收的节点。

关键路径上要重点确认三件事：责任人是否可用；前置输入何时确定；有无替代方案或缓冲。如果关键节点依赖外部团队，就要记录响应时间和升级机制，不能只把外部协作写成一项无时长的任务。

5. 资源决策要把范围、日期、容量和风险放在一起谈

当项目出现缺口时，不应只问“能不能再加一个人”。新增人员需要了解背景、环境和代码，未必能立刻增加有效产出；有些任务甚至会因协作成本上升而变慢。更有效的讨论，是同时比较缩小范围、延后日期、增加合适能力、降低验收风险或拆分交付等选项。

我会把选择写成清楚的决策句：为了保住某个结果，团队接受什么代价；为了控制风险，哪些事项不在本次范围内；若前置条件未满足，何时触发重新评估。把代价说清楚，比“大家再努力一下”更能保护项目关系。

五、具体案例与数据观察：从计划偏差中找出真正的资源问题

1. 情景案例：账单异常修复为何拖慢了其他项目

继续使用前述情景模拟。团队同时推进新用户引导、账单异常修复和管理端改造。新用户引导需要前端、埋点与设计评审；账单修复需要后端、数据核对与测试回归；管理端改造需要前端、权限规则确认和接口调整。计划初稿按总工时分配，账单项目只占团队约三分之一容量。

进入执行后，团队发现账单异常与一段历史数据逻辑相关，需要唯一熟悉该链路的后端工程师参与定位。此人还负责管理端改造的接口评审。结果并不是账单项目的总工作量突然翻倍，而是同一个稀缺岗位成了两个项目的共同瓶颈，其他岗位即使有空也无法完成集成。

如果只看项目状态，管理者可能会误以为团队开发效率变差；如果看资源依赖图，就能发现主要问题是关键技能集中、前置判断过晚。可行的调整包括：先安排短时诊断确认影响范围；将管理端中不依赖该接口的部分先行交付；由另一位工程师结对学习数据链路；必要时重排项目顺序。

2. 用区间估算比单点承诺更诚实

假设账单修复的初步估算为 4 至 8 人天，区间较宽，说明风险尚未收敛。此时可先投入 1 人天完成日志核查和数据样本验证，再根据结果重新估算。若验证后范围收敛到 5 至 6 人天，团队获得的不是“更漂亮的数字”，而是更明确的决策依据。

对于范围较大、依赖复杂的事项，我会把工作拆成“发现问题、验证方案、实现、回归、上线观察”几个阶段。每阶段结束都要产生可检查的结果。这样做可以尽早停止错误方向，也能避免把全部不确定性藏在最后的验收日期里。

3. 用滚动预测识别偏差，而非等待周期末总结

资源预测不是一次性审批。每周或每个迭代都应检查计划投入与实际投入的差异，尤其是支持工作、等待时间和返工是否偏离假设。出现偏差时，先判断是估算误差、范围变化、依赖阻塞还是容量被临时工作占用，再决定调整计划还是改进流程。

下表中的数字为示意数据，用于说明预测复盘的结构，不代表实测团队表现。某团队连续三个周期发现支持工作高于预留值，合理的下一步不是简单提高所有人工作强度，而是分析支持来源、减少重复问题，或在未来规划中调整支持容量。

4. 数据观察的边界：不要用小样本伪装规律

少数几个迭代的数据适合帮助团队提出问题，不足以证明某种管理方法必然有效。需求类型、团队熟练度、系统复杂度和发布流程都会影响结果。比较前后变化时，应尽量保持口径一致，并标注样本范围、统计周期和同期发生的重大变化。

例如，某次迭代交付周期缩短，可能来自范围变小，也可能来自并行项目减少，不能立即归因于工具或流程调整。资源管理数据的用途是支持讨论和试验，不是给个人贴效率标签。若数据被用于绩效排名，成员通常会优化数字，而不是改善真实协作。

六、不同情况下的行动建议：按组织条件选择管理动作

1. 小团队：先减少并行，再补齐预测

小团队通常没有完整的项目管理职能，也缺少可互换的专业能力。此时最有效的第一步往往不是建立复杂的评分模型，而是限制同时启动的工作数量，明确谁负责处理线上支持，并为关键技能设置备份计划。

如果团队只有一名设计师或一名测试人员，可以在排期前确认其参与节点，而不是等到开发完成才发起评审。把少数关键角色的可用时间提前透明化，通常比给所有人分配更多任务更能改善交付。

2. 多项目团队：建立跨项目容量视图

当多个产品线竞争同一批工程、测试或数据能力时，单个项目经理的局部排期容易互相冲突。团队需要在项目之间建立统一的容量视图，至少显示关键岗位在各项目上的承诺、时间窗口和依赖关系。

跨项目决策应有明确的负责人或固定评审机制。产品经理可以提出优先级建议，但不能默认自己有权改变其他项目的承诺。冲突无法通过局部协调解决时，应升级到能调整项目组合的人，而不是要求个人在多个截止日期之间自行承担责任。

3. 中大型组织：把资源治理与组合决策连接起来

中大型组织的资源问题常常不只是排期工具问题，还涉及业务单元目标、共享平台能力、合规责任和多层审批。此类组织需要让项目组合决策与团队容量信息相互衔接，否则每个项目都可能各自合理，整体却超过组织承载能力。

例如，超过 100 人的产品研发组织可以用某项目管理平台作为信息协作载体，集中维护项目目标、依赖关系、责任角色和周期状态。以 PingCode 为例，团队可以围绕需求、计划与进度建立协作视图；但平台无法替代优先级决策，也不能自动判断某位关键人员是否被多个项目重复占用。先定义资源口径和治理规则，再配置工具；不要期待工具替组织解决取舍问题。

4. 工作高度不确定：把探索工作纳入资源计划

新产品探索、复杂技术改造和早期需求验证都存在较高不确定性。此时不宜用完整项目的精确日期管理所有工作，而应先划分探索阶段的时间盒，明确要验证的假设、可接受的投入上限和继续投入的判断条件。

例如，先安排一段短周期来验证关键技术路径，交付结果可以是实验结论、风险清单或原型，而不是承诺完整功能上线。探索工作同样占用稀缺能力，必须进入资源计划，否则它会以“临时帮忙”的形式挤占正式项目。

5. 维护工作很多：单独管理支持容量与产品工作

对于线上问题频繁或历史系统复杂的团队，将维护工作完全排除在计划外会造成持续透支。可以按服务轮值、固定支持窗口或单独维护队列处理，但要有明确的分诊规则，区分故障、缺陷、改进和用户咨询。

如果支持工作长期占据计划容量的大部分，团队应进一步分析重复根因，例如监控盲区、流程缺陷、配置错误或培训不足。单纯增加支持轮值可能只能缓解短期负担，无法减少问题总量。

6. 截止日期不可变：优先讨论范围和风险边界

当发布日期由合同、监管或外部活动确定时，日期可能确实无法移动。但日期固定不代表功能范围也不可变。产品经理应与业务方区分“必须上线的最小结果”和“可后续补齐的增强项”，并明确延期或降级时的用户影响。

若范围同样不能调整，就应公开说明资源缺口和风险，而不是把计划建立在持续加班上。对于可能影响安全、数据准确性或合规要求的工作，不能以减少必要验证作为默认补救方案。

七、不同情况下的取舍：资源不够时，怎样选才不把风险藏起来

1. 价值高、时间窗口短：先确认窗口是否真实

业务方提出“必须本月上线”时，我会先确认日期来自哪里：合同、法规、市场活动、客户承诺，还是内部期待。不同来源的约束强度不同。若日期只是希望值，重新讨论范围或窗口可能比压缩质量更合理；若确属硬约束，则应明确哪些资源可以调动，以及其他项目会受到什么影响。

真实的紧急事项应有可说明的后果和决策责任。若没有人能解释错过日期会发生什么，就不宜把它自动排在所有工作之前。

2. 价值高、证据弱：先买信息，不要直接买产能

需求价值尚未验证时，扩大开发投入可能只是更快地做出一个错误答案。可以优先安排用户访谈、数据分析、原型测试或技术试验，并设置停止条件。信息获取本身也占用资源，但它通常比完整实现后才发现方向不成立更可控。

判断是否继续时，关注新证据是否改变了决策，而不是只看验证活动是否按时完成。没有改变任何判断的研究，可能是问题定义不清，也可能是研究结果没有进入资源决策。

3. 关键岗位缺失：比较等待、替代与拆分

遇到稀缺能力瓶颈，可以评估三种路径：等待当前负责人完成；培养或调入替代能力；拆分任务，让其他成员先完成不依赖该岗位的部分。选择哪种方案，要看延迟成本、培养时间、知识风险和后续需求量。

若某项能力只在当前项目出现一次，临时调配可能比长期扩编更合适；若多个项目持续依赖同一能力，人员培养、内部轮岗或系统解耦就值得进入中长期规划。不要仅因为某个项目急，就把结构性缺口长期推给同一位成员。

4. 加人、减范围、延日期：没有零成本选项

加人可能增加协调与熟悉成本；减范围可能影响体验完整度；延日期可能错过市场窗口或合同节点。比较时要把成本写清楚，而不是把某个选项包装成“没有影响”。

5. 不能把质量、安全和合规当作普通缓冲

资源紧张时，减少文档、测试范围或评审环节看似能省时间，但有些工作承担的是风险控制责任。是否可以调整，应由相应责任人基于影响范围决定，而不是产品经理单方面把它们当成可压缩项。

如果计划只有通过省略必要检查才能按期完成，就应重新讨论范围、日期或资源。把高影响风险留给上线后的用户和运维团队，并不是真正解决资源不足，只是把成本推迟并转移。

八、落地方法：让资源管理进入每个规划周期

1. 周期开始前：统一需求与容量口径

在计划会议前，先把候选需求整理成团队能估算的工作包。每个工作包至少说明问题、目标用户、验收条件、主要依赖、负责人候选和估算范围。还不具备这些信息的事项，应标记为待澄清，而不是硬塞进承诺列表。

同时更新团队可用容量：休假、固定活动、支持轮值、既有承诺和关键角色可用时间都要纳入。容量口径应该由团队共同确认，避免产品、工程和管理者各自使用不同的“可用工时”。

2. 计划会议中：先处理瓶颈，再分配剩余工作

会议中先看稀缺能力和关键依赖，例如测试窗口、数据分析、接口负责人或设计评审时间。瓶颈明确后，再把其他工作填入可用容量。反过来先平均分配所有任务，最后才发现唯一瓶颈超载，往往会引发大范围返工。

计划结束前，团队应能回答：本周期最重要的结果是什么；哪些事项明确不做；哪些依赖可能导致延迟；发生变化时谁有权调整。若这些问题没有结论，会议只是完成了任务分派，没有完成资源决策。

3. 执行过程中：使用明确触发条件，而非频繁救火

设置少量有意义的预警信号，例如关键依赖逾期、支持工作连续超出预留、阻塞超过约定时间、验收条件发生变化。触发后要执行对应动作：缩小范围、升级依赖、重新估算或调整承诺。

预警指标不宜过多，否则团队会忙于填报而不是解决问题。每项指标都应对应一个决策动作；如果数值变化不会改变任何决定，就要考虑是否真的需要采集。

4. 周期结束后：复盘预测质量，不只复盘完成率

完成率可以显示计划结果，却不一定解释为什么发生偏差。复盘时，我会比较原始假设和实际情况：容量预留是否合理，工作包是否过大，支持工作是否被低估，等待时间是否来自外部依赖，返工是否源于验收条件模糊。

复盘要输出可验证的改进动作，例如将某类支持问题纳入固定容量、将关键设计评审提前、为单点能力安排结对，而不是泛泛写“加强沟通”。下一周期再看这些动作有没有改变相应指标，才能形成学习闭环。

5. 建立最小可用的资源信息集

不必一开始就建立复杂的人力模型。以下信息通常足以支撑一个团队的基础决策：周期、可用角色、计划容量、已承诺事项、支持工作、工作包估算、关键依赖、风险和决策记录。

• 周期与工作日：统一规划范围，避免不同项目使用不同时间口径。
• 角色与技能：记录必要能力和备份情况，不只记录姓名。
• 有效容量：区分理论工时、固定投入和可规划余额。
• 工作包与估算：注明区间、假设和验收条件。
• 依赖与阻塞：写明责任方、所需输入和最晚反馈时间。
• 决策记录：记录范围、日期、优先级变化及其影响。

九、避坑检查清单：计划发布前逐项确认

1. 容量是否有可追溯依据

检查排期是否使用了扣除休假、会议、支持和既有承诺后的容量。若估算只来自标准工时，必须标明它是理论上限，而不是交付承诺。若不同角色有不同可用时间，也要避免用团队平均数掩盖关键岗位缺口。

2. 每个高优先级事项是否对应真实取舍

确认新增事项进入计划后，是否有另一项工作后移、范围减少或容量调整。没有被替换的任务，往往仍会以隐性加班或延期的形式存在。优先级变化需要同步影响相关项目负责人，而不是只更新一张局部表格。

3. 关键依赖是否有责任人和时间点

“等待接口”“等业务确认”“等测试环境”都不是可操作的依赖描述。应写明谁提供什么输入、何时需要、逾期后如何处理。依赖方不在同一团队时，还要确认沟通和升级路径。

4. 不确定性是否被标注，而非藏在日期后面

对于需求范围、技术路径或外部条件尚未确定的工作，要列出假设和验证计划。估算区间过宽时，先安排缩小不确定性的工作。不要因为管理层需要日期，就把尚未验证的假设写成确定交付日。

5. 变更是否有明确的影响评估机制

检查插单、范围扩大和需求替换是否会触发重新评估。变更流程不必复杂，但必须让被挤占的工作、承担风险的人和批准决策的人都清楚。否则每次改动都会被说成“小调整”，最终累积成整体延期。

6. 质量与维护投入是否真正进入计划

确认测试、上线观察、缺陷修复、文档交接和必要维护是否被纳入工作范围。只计划功能开发而不计划验证与上线后的责任，会低估真实投入，也会让“完成”的定义在不同角色之间不一致。

十、结尾：资源管理的价值，在于让团队敢于说出约束

1. 最重要的判断不是谁最忙，而是哪里限制了整体交付

我认为产品经理做资源管理，最重要的能力不是把排期表填得更精细，而是识别系统里的真实约束：需求是否清楚，关键能力是否单点，外部依赖是否可控，计划是否包含维护成本，团队是否有空间应对意外。

这些约束被看见后，管理者才能在范围、日期、能力和风险之间做明白的选择。约束被隐藏时，计划看起来整齐，团队却只能靠个人透支维持它。

2. 下一步从一个周期、一个瓶颈开始

如果你准备开始改进，不必先设计一套庞大的资源治理体系。选择接下来的一个计划周期，统一容量口径，标出关键技能和依赖，记录支持工作与临时插单，并在周期结束后对照预测和实际投入。

下一次资源评审时，带上三个具体问题：我们真正能投入多少有效容量；哪些工作共享同一瓶颈；如果新增事项进入，哪项工作会退出或延后。能清楚回答这三个问题，资源管理就从“排满人”开始转向“管理真实承诺”。