投入比例怎么做？跨部门团队协同管理：人力资源计划从0到1

投入比例不是把员工姓名填进甘特图，再把每个人的工时加到100%。跨部门项目真正需要回答的是：某个角色在什么时间段、为哪个交付物投入多少可用产能；这项投入是否经过部门负责人确认；发生冲突时，谁有权调整优先级。我的判断是，人力资源计划的核心不是“算得精确”，而是让容量、承诺、风险和取舍都可见。下面从零搭出一套可执行的计划，并用一个明确标注为情景模拟的中型企业案例说明如何校准投入比例。

一、先讲核心结论：投入比例要从交付物和可用产能推导

1. 投入比例不是个人意愿的百分比

项目计划里常见的“测试工程师投入20%”，看起来明确，实际信息却不完整。20%是每周一天，还是某几周集中投入？是项目负责人已经确认的产能，还是项目经理希望得到的资源？工程师同时承担多少日常工作？如果这些问题没有答案，这个比例更像愿望，不是计划。

我会把一项有效投入定义为四个要素：角色或具体人员、时间窗口、目标交付物、确认状态。比如“测试工程师A在第5至第8周每周投入1.5天，负责接口回归与上线验收，部门负责人已确认”，这才足以支持排期、风险判断和后续复盘。

核心公式可以这样理解：可承诺投入比例＝项目可用人天÷该角色同期可用人天。项目可用人天不能超过实际可用产能；实际可用产能也不能简单等同于合同工时，因为会议、支持、休假、运维和其他项目都会占用时间。

2. 先定交付物，再定角色，再谈比例

如果先问“每个部门能给多少人”，很容易得到一个平均分配的资源表，却无法判断这些人能否完成关键工作。更稳妥的顺序是：先确认项目范围和里程碑，再拆出交付物；根据交付物识别所需角色；最后核实这些角色在具体时间窗口内的容量。

我通常要求每个投入条目至少能回答三个问题：本阶段要交付什么？谁对交付结果负责？如果这个人当周只能投入一半，项目会延迟什么？答不出来的比例，先不要当作已确认资源。

3. 计划必须同时写明“承诺”和“余量”

人力计划不是把每个角色排到100%。部门团队需要留出处理线上问题、紧急需求、内部协作和不可预见工作的空间。若把所有可用时间都预先分配，表格会显得利用率很高，但项目一旦遇到返工或紧急事项，就只能通过加班或挤占其他项目来消化。

对跨部门项目，我更关注关键岗位的峰值负荷，而不是团队平均利用率。整体看似只占60%，如果唯一的安全评审人员在同一周同时承担三个项目的发布审核，仍然可能形成单点瓶颈。

二、背景和真实场景：跨部门资源为什么容易“计划时有、执行时无”

1. 项目经理负责结果，部门经理掌握资源

跨部门项目常见的结构性矛盾是：项目经理对里程碑负责，却未必能决定业务、研发、数据、法务或测试人员的工作优先级；部门负责人掌握人员安排，却不一定能看到项目延期会带来的整体影响。两边各自做了合理决定，合在一起却可能让关键交付物没有人接。

例如，产品团队认为需求评审已排定，研发团队认为本迭代先处理生产问题，业务团队则认为需求细节还未确认。每个部门都有自己的局部计划，但项目计划里仍然显示“按期”。问题不是成员态度不积极，而是资源承诺没有连到具体工作和决策机制。

2. 平均投入掩盖了时间冲突

假设一个数据分析师每周投入项目25%，在季度计划表上看起来相当于每周一天。但项目的关键需求可能集中在第2周的字段梳理、第5周的指标验收和第9周的上线核对。若把25%平均摊开，关键周可能没有足够时间，非关键周反而留下闲置。

因此，投入比例至少要有时间粒度。早期方案可以按月估算，进入立项和排期后，应细化到周；对发布、验收、迁移、合规评审等峰值工作，必要时按天确认。粒度并非越细越好，而是要细到足以暴露冲突。

3. 跨部门计划的难点通常不在人数，而在稀缺技能

在一个十余人的项目团队里，普通执行岗位可能有多个替代者，架构评审人、数据权限审批人、特定系统维护人或唯一熟悉旧流程的业务专家却未必有替代者。增加普通成员数量，无法自动消除稀缺角色形成的排队。

我会把资源表中的角色分成“可替代角色”和“稀缺角色”。前者关注工作拆分和交接成本，后者关注可用窗口、备份安排和决策时限。对稀缺角色，投入比例只是开始，还必须记录谁能替代、缺席时如何升级、最晚什么时候需要确认。

4. 计划变化是常态，未经治理的变化才是问题

需求变更、突发故障、人员休假和管理层临时任务都会改变可用容量。把计划冻结不动并不能消除变化，只会让实际工作与计划表越来越脱节。有效的计划应当明确变更入口、更新频率、影响评估方式和批准人。

对中大型组织，100人以上团队往往存在多个并行项目和共享职能，资源冲突不能只靠群聊临时协调。若项目数量、依赖关系和审批链已经超过人工维护能力，可以通过某项目管理平台统一维护任务、责任人、时间窗口和风险状态。以PingCode为例，这类平台适合把项目任务和组织协作信息放在同一工作视图中；但工具本身不会替代部门负责人做资源承诺，也不会自动解决优先级冲突。

三、常见误区：为什么表格做得很细，计划仍然不可靠

1. 把编制人数当成可用人数

“团队有10名开发人员”只说明组织名册上有10个人，不代表10个人都能进入这个项目。有人承担线上值班，有人负责旧系统维护，有人已被其他项目锁定，还有人需要处理技术债。使用编制人数直接计算项目产能，会系统性高估可用容量。

改进方式是逐人或逐角色询问同期承诺，至少列出已有项目、固定职责、休假和不可调度工作。若启动阶段拿不到个人明细，可以先用角色级容量估算，并明确这是低置信度估计，而非最终承诺。

2. 把“投入25%”当作每天均匀可用

工作往往无法按比例切成等长小块。跨部门沟通、上下文切换、环境准备和评审排队，都会让低比例投入产生额外损耗。每周投入半天的专家，可能要花更多时间重新熟悉上下文；把任务分散到每周几个小时，不一定比连续安排两天更省时。

对需要深度工作的岗位，我会先问能否形成连续工作块，再决定比例。若任务需要连续完成，应该约定具体时段或里程碑窗口，而不是只写月度百分比。

3. 把总人天当成排期依据

总工作量相同，不等于项目周期相同。10人天可以由两人一周完成，也可能因为依赖关系、环境准备和评审等待拖成三周。人天估算描述的是工作量，排期还必须描述先后关系、并行条件和等待时间。

我会将估算拆成“执行工时”和“日历等待”。例如，接口开发需要4人天，但测试环境开通要等5个工作日，安全评审要排队3天。只把4人天加进总量，会把项目上线日期算得过于乐观。

4. 把部门口头支持当作资源确认

“我们会支持”“这个项目优先”并不等于某个人在某个时间段有空。口头承诺没有资源对象、时间范围和冲突处理规则，项目启动后往往会被其他紧急任务覆盖。

资源确认至少应包含确认人、确认日期、投入范围、有效期限和重新确认条件。若承诺仍待审批，应明确标成“待确认”，不能与已确认资源混在同一列。

5. 把高利用率误认为高效率

如果计划利用率长期接近100%，项目表面上没有闲置，实际却失去吸收波动的能力。一个小故障、一轮返工或一名关键人员休假，都可能把后续任务整体推迟。高利用率也可能意味着工作被不断切换，最终增加协调成本。

管理者需要区分两类余量：一类是可以被更高优先级任务临时使用的容量，另一类是为了保障交付而保留的保护性缓冲。两者都不应被误读为“浪费”，但也要明确归属和动用规则。

6. 用平均比例掩盖关键路径上的峰值

一个角色整月平均投入20%，并不能说明每一周都够用。关键工作集中在少数节点时，月平均会掩盖峰值。如果发布验收只在月底发生，项目经理需要确认月底的具体可用时间，而不能用整月平均比例替代。

对每个关键里程碑，我会做一次峰值检查：同一周有多少项目争用该角色？该角色的审批或执行任务是否有先后顺序？如果发生延误，是否存在可调度的备份人员？

四、专业判断逻辑：从范围到可承诺容量的七步法

1. 固定计划边界，先说清楚这次不做什么

资源计划的起点不是人员名单，而是项目边界。范围模糊时，团队无法估算工作量，部门负责人也无法判断资源承诺是否合理。我会先确认本阶段交付物、验收标准、时间约束、外部依赖和明确排除项。

如果需求还处于探索阶段，就不要把人员计划包装成精确排期。可以给出范围假设、估算区间和验证活动，例如“先投入产品、业务和技术角色完成两周可行性验证，验证后再确认建设期资源”。这比提前锁定整季度投入更诚实，也更便于调整。

2. 将交付物拆成可估算的工作包

工作包应当足够具体，能估算角色、工作量和依赖关系。比如“完成数据迁移”还不够，应拆为字段映射、历史数据清洗、迁移脚本、试迁移、核对、正式迁移和回滚演练。每个工作包都要说明输入、完成条件和责任角色。

拆分并不是为了把任务切得越小越好。过度拆分会带来维护成本，尤其在需求尚未稳定时。我的判断标准是：一项工作是否需要独立估算、独立验收或有独立风险；如果答案都是否，先保留在较高层级。

3. 用角色矩阵识别责任和参与程度

每个工作包至少要明确最终负责者和实际执行者。参与者可以协助评审、提供资料或完成审批，但不能让多个部门都“共同负责”而没有单一结果负责人。跨部门事项尤其要写清谁提供输入、谁批准、谁接受交付。

我常用精简版责任矩阵，避免把每个成员都拉进所有任务。一个任务原则上应有一名最终负责者；涉及审批的任务应记录审批人及期限；有多个执行者时，仍需指定一人负责汇总结果。

4. 计算角色容量，而不是机械套用工时

容量测算可以从工作周开始，再扣除固定事项和已有承诺。计算时至少区分日历工时、可排产工时、项目计划工时和已确认工时。四者混在一起，会让“理论可用”被误当成“已经承诺”。

例如，一名员工每周名义工作40小时，扣除固定会议、支持职责和既有项目后，可能只剩20小时可排产。若项目希望占用其中一半，申请的投入比例是每周10小时，而不是直接写成50%全职。实际确认还要由部门负责人检查周期内的峰值任务。

跨部门项目的角色容量表可按周滚动更新。早期估算可以使用区间，例如每周6至10小时；临近关键路径时再收敛为具体时间窗口。区间不是含糊，而是对不确定性的诚实表达。

5. 把工作量转换为时间窗口和投入节奏

一项工作可能是连续集中投入，也可能分散参与。需求澄清、评审和验收通常是间歇性的；开发、数据清洗和迁移准备通常需要较连续的工作块。投入节奏应匹配任务性质，而不是让所有角色按同一比例平均摊开。

我会在计划中区分“稳定投入”“峰值投入”和“按需支持”。稳定投入适合持续交付工作；峰值投入适合联调、迁移、上线等短时密集阶段；按需支持则必须设定响应时限和触发条件，否则很容易变成无人优先处理的隐性队列。

6. 记录不确定性和资源承诺置信度

项目启动时，许多数据都不可能精确。与其伪装精确，不如给关键岗位标记估算置信度。可采用高、中、低三级：高表示责任人、时间窗和工作量都经过确认；中表示范围已知但资源尚待确认；低表示需求或依赖仍有较大不确定性。

置信度不是绩效分数，而是提醒团队哪里需要进一步验证。低置信度的工作不一定不能做，但不应被当作确定性里程碑对外承诺。对于低置信度事项，计划中应加上验证动作、负责人和截止日期。

7. 建立变更、冲突和复核机制

资源计划需要规定何时复核、谁能改动、改动后影响哪些交付物。常见做法是每周检查未来两至四周的资源峰值，每月重新核实更远期承诺；当需求、优先级、人员或上线日期发生变化时，立即触发专项评估。

出现冲突时，不能只要求两名员工自行协调。冲突的本质通常是两个项目争夺同一稀缺容量，应该由掌握优先级的负责人决策。协调前先列出选项：调整范围、移动时间、增加替代能力、降低服务水平，或者暂停较低优先级事项。

五、案例与数据观察：一个模拟的跨部门系统改造项目

1. 案例边界：先说明哪些数据是推演

以下案例是基于常见组织协作问题构造的情景模拟，不代表某一家企业的真实业绩，也不是行业平均值。它用于展示测算过程：一家约300人的企业计划在12周内改造客户服务流程，涉及业务、产品、研发、数据、测试和安全评审。

项目要求保留现有系统正常运行，同时完成新流程配置、数据映射、接口改造、回归测试和上线验收。项目发起人最初希望所有团队“每周投入20%”，但检查后发现，业务专家在第3周和第10周存在峰值，测试人员在第8至第11周会被另一个项目占用。

2. 先按工作包估算，而不是直接给部门分比例

项目组把工作拆成需求确认、流程设计、接口改造、数据映射、测试与验收、上线准备六类工作。估算采用人天区间，并记录工作量的主要不确定性。这里的工作量是计划示例，不是已完成工时。

3. 发现关键瓶颈：业务专家和测试人员集中在少数周

若只看总人天，项目似乎可以在12周内完成。逐周排布后，问题才显现：业务专家不仅要确认需求，还必须在数据映射和验收阶段解释历史规则；测试人员的工作集中在后半程，而同期还承担其他项目的回归测试。

项目组据此采取两项调整。第一，在第1至第4周集中整理业务规则，安排备份业务代表参与访谈并形成可复用的确认记录。第二，把测试活动前移：接口开发过程中逐步准备测试用例，减少第8周才开始集中发现问题的风险。

4. 用负荷率看趋势，不用单个比例替代管理判断

情景模拟中，项目组把每周角色需求除以该角色经部门负责人确认的项目可用容量，得到计划负荷率。负荷率超过100%意味着计划需求大于承诺容量；它不一定表示员工超时工作，也可能表示计划还没有经过范围、时间或资源调整。

负荷率低于100%也不代表风险消失。若该角色是关键路径上的唯一审批人，等待时间仍可能造成延期；若任务依赖其他团队的输入，角色有空闲也未必能够提前完成。因此，负荷率需要与依赖关系和等待时间一起看。

5. 把资源冲突转成管理选项

对测试资源峰值，项目组没有直接要求员工加班，而是比较了四种方案：延长测试窗口、降低非关键功能范围、借用具备相应能力的测试人员、调整其他项目的测试顺序。每个方案都要说明对成本、质量、日期和其他项目的影响。

对业务专家峰值，解决方法不是简单增加会议，而是把知识转移到业务规则文档、数据样本和验收清单中。文档不能完全替代专家判断，但可以减少重复解释，把稀缺专家的时间留给真正需要决策的例外情况。

6. 复盘要看偏差原因，而不只看计划兑现率

如果项目结束时发现实际投入高于计划，不能简单归结为估算不准。至少要区分范围增加、需求等待、返工、资源被挪用、技术风险、协作开销和人员能力差异。不同原因对应的改进动作并不相同。

例如，若偏差主要来自需求迟迟未冻结，应该改善决策时限和范围治理；若来自关键人员被临时调走，应该改善资源确认和升级机制；若来自反复返工，则要检查验收标准、评审质量和测试前移。复盘的价值在于修正下次计划的假设，而不是给个人贴标签。

六、不同情况下的行动建议：从粗估到滚动计划

1. 项目目标已知，但需求细节尚不稳定

此时不适合按周锁定所有成员，也不适合把粗略估算写成确定承诺。建议先安排短周期发现和验证活动，聚焦范围、技术可行性、关键依赖和主要风险。投入比例可以按角色给区间，并约定何时复核。

例如，先确认产品、业务和技术负责人在两周内的可用窗口，完成流程访谈、样本数据检查和技术验证；到期后再判断是否进入建设阶段。这样做的取舍是短期投入更集中、前期计划精度有限，但能避免过早占用大量资源。

2. 项目里程碑固定，关键路径清楚

如果发布日期受监管窗口、合同节点或市场活动约束，计划应从固定里程碑倒推，而不是先平均分配人员。先找出关键路径，再检查每个关键节点所需角色、最长等待项和峰值容量。对于不能压缩的审批或迁移窗口，应提前预约。

这种情况下，项目经理应每周检查未来几周的关键角色负荷，并把资源冲突升级到有优先级决策权的人。代价是管理节奏更密、部门需要提前暴露冲突；好处是问题出现得更早，而不是临近上线才发现关键角色无法到场。

3. 关键岗位只有一人，且短期无法补充

单点专家的容量规划不能只写“投入30%”。要拆分其工作中必须亲自判断的部分和可由他人执行的部分，提前准备资料、决策记录、检查清单和替代方案。关键评审尽量集中预约，减少临时打断。

如果项目依赖该人员做全部审批，团队应安排知识转移或培养副手。短期内培养替代者会增加工作量，但长期能降低单人缺席导致项目停摆的风险。对于专家稀缺且决定权不可替代的环节，管理者应在项目计划中明确排队成本，而不是假设对方随叫随到。

4. 多个项目争用同一批共享资源

当多个项目同时争用测试、数据、安全或架构资源时，不能让每个项目都各自声称最高优先级。应建立共同的资源视图和决策机制，至少比较业务价值、时间约束、延期代价、合规风险和替代方案。

对于资源池，可以采用预约窗口、服务时限和优先级队列。需要特别注意：资源池不能只记录“已预约”，还要记录任务准备度。需求或环境未准备好的项目占着稀缺时段，会浪费真正可交付的容量。

5. 需求变化频繁，团队无法准确预估远期工作

需求频繁变化时，计划应采用滚动窗口：近端计划细化到周，远端计划保留区间和假设。每次滚动更新时，比较新增工作与已承诺容量，并决定是调整范围、延长时间还是补充资源。

这并不意味着不做计划，而是把确定性放在正确的时间范围内。对未来尚未明确的工作，明确下一次决策日期和触发条件，避免用虚假的精确数字制造确定感。

6. 团队规模较小，暂时不需要复杂管理系统

小团队用共享表格和固定例会也可能足够。前提是所有参与者能看到同一版本，变更有人维护，资源承诺能够追溯，冲突能及时升级。管理方式应与协作复杂度匹配，不要为了使用工具而增加重复录入。

当项目数量增加、跨团队依赖变多、资源频繁共享时，手工维护的成本会迅速上升。这时可以评估某项目管理工具或某项目管理平台，重点看是否支持角色与任务关联、时间窗口、责任确认、依赖追踪、权限控制和变更记录。选择时应先做小范围试点，验证数据是否能持续维护，再讨论全面推广。

七、如何取舍：时间、范围、资源和质量不能同时不变

1. 资源不足时，先确认真正受约束的是什么

“缺人”可能指总工时不足，也可能指特定技能不足、关键时间窗冲突、决策等待过长，或任务切分方式不合理。不同问题的解法不同：总工时不足可讨论增加资源或缩减范围；技能不足可考虑培训、外部支持或重新排序；时间窗冲突可调整里程碑；决策延迟则要优化治理流程。

在提出补人前，我会先检查瓶颈是否位于关键路径。如果新增成员无法减少等待、无法替代稀缺技能，或者需要较长熟悉期，新增资源可能不会缩短周期。更有效的动作有时是降低并行度、尽早确认规则或把非关键工作移出关键路径。

2. 时间固定时，优先保护关键路径和验收底线

如果发布日期不能变，首先识别哪些功能直接影响业务流程、合规、安全和数据正确性，哪些属于可以延后交付的体验优化或低频场景。范围调整必须由有权的业务负责人确认，并同步更新验收标准。

不应通过跳过必要测试、压缩安全评审或让关键人员长期超负荷来“守住日期”。这类做法只是把当前计划风险转换成上线质量和运营风险。确需缩短周期时，应明确新增风险、监控方式和回滚条件。

3. 范围固定时，评估日期和资源的真实成本

范围不能删时，团队需要比较增加资源与延长周期的总成本。增加资源可能带来招募、交接和沟通成本；延长周期可能影响市场窗口、合同条款或其他项目。决策应基于组织层面的损失，而不是只看单个项目的局部计划。

如果新增资源能分担清晰、可并行的工作，且有足够交接时间，扩充能力可能有效。如果工作高度耦合或必须等待单一决策者，增加成员的效果会有限。管理者需要把这些边界写进方案，而不是只呈现新增人数。

4. 质量底线不能靠模糊表述来压缩

“质量不变、时间不变、范围不变、资源不变”不是计划，而是对团队提出无法验证的要求。质量标准应转化为可检查的验收条件，例如关键流程覆盖、数据核对范围、故障恢复演练和审批完成状态。若要调整质量活动，必须明确调整对象和风险承担方。

我通常建议保留不可压缩的底线，把可选体验、低风险场景和后续优化列为可调整项。这样既避免把质量当作抽象口号，也为发生资源冲突时提供可讨论的取舍空间。

5. 用决策记录避免同一冲突反复争论

每次调整资源、范围或日期，都要记录为什么调整、谁批准、影响哪些交付物、哪些风险被接受，以及何时重新评估。记录不需要写成长篇报告，但应能让后来加入的成员理解当前计划为什么这样安排。

这类决策记录对跨部门项目尤其重要，因为冲突往往不是一次性消失，而是在不同阶段以不同形式出现。没有记录，团队会反复讨论同一个问题，也容易把此前已接受的风险误认为是执行疏漏。

八、从零到一的落地模板与管理节奏

1. 建立一张足以支持决策的资源计划表

资源表不必追求字段繁多，但必须能支持容量判断、责任确认和冲突升级。建议先从以下字段开始，再根据项目复杂度增加依赖、成本或风险信息。

• 工作包：描述需要完成的交付，而不是只写部门名称。
• 角色与责任人：记录执行角色、最终负责者和必要审批人。
• 工作量区间：标明估算范围及其主要假设，不把粗估伪装成精确值。
• 时间窗口：写清开始、结束、峰值周或需要预约的评审日期。
• 可用容量：记录扣除固定职责和既有承诺后的可排产时间。
• 计划投入：使用小时、人天或明确的比例，并注明统计口径。
• 承诺状态：区分已确认、待确认和有条件确认。
• 依赖与风险：说明前置输入、等待事项、替代人选和升级路径。
• 更新日期与确认人：让资源承诺有时间戳和责任归属。

2. 用三层节奏管理计划，而不是频繁全量重做

项目层面：每个里程碑检查范围、交付物、依赖和总体资源缺口。此层关注项目是否仍然可行，不负责逐小时排班。

团队层面：每周滚动检查未来两至四周的关键角色负荷、待确认资源和高风险工作。会议重点是做决策，不是逐行朗读表格。

个人或角色层面：只对关键路径、稀缺岗位和峰值周进行更细的时间确认。普通、稳定工作不需要过度追踪，以免计划管理本身吞掉交付时间。

3. 资源冲突会议只讨论选择，不追问谁“更努力”

有效的冲突会议应先提供事实：冲突角色、涉及项目、时间范围、容量差额、延期影响和可选方案。然后由有决策权的人明确优先级，或授权项目负责人选择范围调整、顺序调整和替代能力方案。

如果会议只讨论“大家能不能再想办法”，结论往往是所有项目都不变、所有人员都更忙。对资源冲突，至少应形成一项明确决策：谁先做、什么延后、哪个范围缩减、何种风险被接受，以及下一次复核时间。

4. 区分计划偏差和计划失真

计划偏差是实际情况与合理估计有差异，例如新增需求导致增加工作量。计划失真则是关键假设从未确认，却在表格里被当作事实，例如把待审批人员写成已承诺、把专家口头支持写成固定容量。

两者的处理方式不同。偏差需要调整计划、分析原因并更新估算；失真需要修复资源治理和信息质量。复盘时只看“计划和实际差多少”，容易错过更根本的问题：计划中的承诺是否真实存在。

九、结尾：把投入比例当作一项可追溯的管理承诺

1. 从一张表开始，但不要止步于填表

要从零启动人力资源计划，不需要先购买复杂系统，也不必等所有需求完全确定。先选一个真实项目，拆出交付物和关键角色，核实未来几周的可用容量，把未确认的承诺明确标记出来。只要团队能基于同一份信息讨论冲突，计划就已经开始产生价值。

2. 下一步先做三件事

1. 列出未来一个阶段的交付物、验收标准和不包含的范围。
2. 为每个工作包确定责任角色、时间窗口、工作量区间和确认人。
3. 检查未来四周的稀缺角色峰值，针对超载列出调整范围、调整时间或补充替代能力的选项。

3. 我的最终判断

真正可靠的投入比例，不是看起来精确到个位数，而是能解释它从哪里来、由谁确认、适用于哪个时间段，以及发生冲突后如何改变。对跨部门团队而言，最有价值的资源计划不是一张“每个人都很忙”的图，而是一套让组织尽早发现容量缺口、明确取舍并持续兑现承诺的机制。

如果团队当前只能做一件改进，我建议先把“待确认”从“已确认”中分开，并为每个稀缺角色标出未来四周的峰值任务。很多项目并不是缺少更多工时，而是太晚才看见工时无法在需要的时间、由需要的人提供。