资源管理技能教程：项目成员协同管理，避坑指南

项目延期，很多时候不是成员不够努力，而是同一个人被三个项目同时按“全职”排进计划：项目经理看到的是承诺工时，成员经历的是日历冲突，管理者看到的则是任务状态仍然显示“进行中”。资源管理技能的关键，不是把每个人的空闲时间填满，而是让团队对“谁在什么时间以什么投入，交付什么结果”形成可验证的共同约定。

本文从项目成员协同管理出发，拆解资源计划、任务分配、跨团队协调、负荷预警和复盘方法。我会区分可以直接采用的管理规则与需要按组织规模调整的参数；案例中的数值均为明确标注的情景模拟，不代表行业统计或某个企业的实际经营数据。读完后，你可以用一张资源负荷表、一套冲突升级规则和一次每周校准会议，判断团队究竟缺人、缺决策，还是缺少对可用时间的共识。

一、核心结论：资源管理不是把人填满

1. 先管承诺，再管利用率

我判断资源管理是否有效，通常不先看成员利用率，而先看计划承诺是否可信。利用率只能说明时间被安排了多少，不能说明安排是否合理：一个人每周被分配四十小时，看起来没有空闲，但如果其中包括会议、支持工作、突发任务和跨项目切换，这四十小时很可能并不能转化成四十小时的项目产出。

团队需要管理的是“可承诺容量”，而不是日历上的全部工作时间。可承诺容量，是扣除固定会议、值班、维护、休假和预留缓冲之后，团队能够相对稳定地投入项目工作的时间。它不等于成员每天坐在电脑前的总时长，更不应成为鼓励加班的指标。

资源计划的目标也不是让每个人的负荷都达到百分之百。对于知识工作，短期满负荷可能让表格更好看，却让计划更脆弱：只要一个需求变化、一场关键评审延期或一名成员请假，整个依赖链就会被挤压。我的实践判断是，计划越接近满载，越需要主动说明风险和变更代价。

2. 一个可执行的资源计划要回答四个问题

资源计划不是一张“某人负责某任务”的静态表格。它至少要让团队回答以下问题：

• 谁负责结果：每个交付物有明确的最终负责人，而不是只列一串协作人。
• 何时可以投入：团队对关键成员的可用时间、固定职责和休假有一致认知。
• 哪些工作不能并行：识别串行依赖、评审等待和必须由特定技能完成的任务。
• 冲突如何处理：资源撞车时，有清楚的决策人、优先级依据和变更记录。

如果一个管理表只回答“任务分给谁”，却没有投入时段、依赖关系和冲突处置规则，它更像任务通讯录，不是资源管理计划。

3. 先建立容量口径，再谈人员紧缺

不同团队对“一个人可投入多少项目时间”常有不同理解。有的按工作日计算，有的把所有工时都当作项目产能；有人把支持工作看成零碎事务，有人则每周固定承担故障响应。口径不一致时，招聘、排期和项目优先级讨论都会建立在不同的分母上。

建议先统一一个简单口径：明确统计周期、工作日、固定职责、会议、休假和缓冲如何计算；再用实际记录校准，而不是直接把标准工时当作产能。关于工时和利用率的数字，本文不把它们当行业基准，而将其作为内部规划的估算工具。组织应结合本地劳动法规、岗位性质与公司制度设定上限，并避免用超时工作弥补不现实的计划。

二、真实场景：项目成员为什么总在“救火”

1. 典型场景：三个项目共用关键成员

考虑一个情景模拟：一家中大型组织有产品、研发、测试和运营团队。一个资深后端成员同时被三个项目列为核心负责人。项目甲预计他投入每周二十小时，项目乙预计十八小时，项目丙预计十二小时。三份计划分别经过各自项目经理确认，却没有人汇总这个成员的总承诺。

账面上，他的周负荷达到五十小时。更重要的是，他还要参与例会、代码评审、线上问题响应和临时需求。项目经理看到的是“本项目已经排到他”；成员看到的是每个项目都认为自己优先；业务负责人看到的则是进度不断被解释为“人员不足”。

这个例子的问题不是单纯工时超标，而是组织没有一个共同的决策视图：没有统一记录各项目承诺，没有说明哪类工作可被暂停，也没有人在冲突出现时拥有最终取舍权。结果是，所有项目都按最乐观的假设运行，最终由关键成员用加班去填补系统没有处理的矛盾。

2. 先区分四种“资源不够”

当团队说“缺人”时，我会先追问缺的是哪一种资源。把所有问题都交给招聘解决，通常会延长解决周期，也可能把原有的排期和决策问题一并带进新团队。

• 容量不足：关键工作量确实超过可承诺容量，且没有可调整的范围或时间。
• 技能不足：总工时未必超限，但缺少特定技术、领域知识或授权资格。
• 时间错配：成员有空余，但可投入窗口与任务依赖节点不匹配。
• 决策阻塞：工作已经分配，却卡在需求确认、评审、权限或跨部门决定上。

这四种情况的处置方式不同。容量不足，先比较缩范围、调顺序、延后日期和增加资源；技能不足，考虑培训、结对或引入专业支持；时间错配，重新排布依赖或设置交接；决策阻塞，则要缩短等待链条并指定决策责任人。若不先分类，团队会把“等待决策”误报为“人手不够”，把“稀缺技能”误当成“所有岗位都缺人”。

3. 成员协同的难点往往在接口，不在任务本身

跨团队项目的工作通常不是一条简单的任务清单，而是一组相互依赖的交付接口。例如，产品团队要在某个时间点确认验收规则，研发据此完成实现，测试团队需要稳定版本，运营则要提前准备发布材料。只排“各团队开始日期”，不排“上游何时给出什么可用输入”，计划就会隐藏等待时间。

我更愿意把协同拆成“输入，工作，输出，验收”四段。每段都标明负责人和完成条件，尤其要写清楚交接物是什么。诸如“研发完成后给测试”不够具体；“测试环境已部署、关键配置已记录、测试数据可用、版本号已标记”才便于双方判断是否可以接手。

三、常见误区：看起来有管理，实际上在制造噪声

1. 误区一：把满负荷当作高效率

利用率高，不能单独证明管理有效。成员的计划时间填满后，任何突发支持、任务返工和跨团队求助都只能挤占原有工作。团队如果把“没有空闲”视为目标，成员就会倾向于隐藏风险、延迟暴露冲突，或者把必要的恢复时间从计划里抹掉。

我会把利用率当作诊断信号，而非绩效结论。若某岗位连续数周负荷超过团队内部设定的警戒区间，应先检查工作来源、依赖和优先级，而不是马上要求成员提升效率。若工作量很低，也需要区分是真实闲置，还是关键输入尚未到位。

2. 误区二：一个任务列多个负责人

“产品、研发、测试共同负责”听起来协作充分，却经常造成责任边界模糊。任务延迟时，每个人都可能以为另一个角色还没完成前置工作；交付物有缺陷时，也难以判断谁有义务组织验收。

更清楚的做法是指定一名对交付结果负责的负责人，再列出需要协作、审核或提供输入的人。协作不是把责任平均分散，而是让每个人知道自己在何时提供什么。对于必须多人共同完成的工作，可以拆分可验收的子任务，分别设定负责人。

3. 误区三：按人头分任务，不看技能和上下文

把任务平均分配给团队成员，能快速让列表看起来公平，却不一定符合交付要求。熟悉系统的人可能需要处理复杂变更，新加入的成员可能需要完成学习成本更高的基础任务；只看任务数量，会忽略难度、风险、熟悉度和协作成本。

技能匹配也不是简单给每个人贴“高级”或“初级”标签。我会把能力拆成具体场景：能否独立设计方案，能否排查某类故障，是否熟悉业务规则，是否有权限进行发布。一个成员在某个领域经验丰富，不代表他可以无成本地承担所有相邻工作。

4. 误区四：把工时记录当作资源管理的全部

时间记录有用，但它只能说明工作投入的一部分。相同的八小时，可能用于稳定交付、等待依赖、重复返工或处理紧急事件。若管理者只看工时总数，容易把高投入误认为高产出，也容易用记录精度替代工作定义质量。

记录颗粒度也要适度。对大多数团队而言，为每个短任务逐分钟计时，会显著增加填写成本，并引导成员花时间维护数据。建议先以周为周期、按工作类型或项目记录必要信息；只有在计费、合规、支持负载分析等明确场景下，再增加细度。

5. 误区五：资源冲突靠私聊解决

项目经理之间私下协调，在小团队中可能很快；但如果协调结果没有同步到共享计划，冲突只是从表面消失。某个项目获得了关键成员，却没有记录另一个项目因此延后什么；后续团队仍会以旧日期对外承诺。

每次资源冲突解决后，都应留下最小必要记录：冲突涉及哪些任务、谁作出决定、优先级依据是什么、哪些日期或范围因此变化、受影响方何时确认。记录不是为了追责，而是避免同一问题每周重谈，并让决策后果可见。

四、专业判断逻辑：从工作量估算到冲突决策

1. 先定义容量口径，不从理想工时起步

估算容量时，建议从可观察的工作周开始，而不是直接把合同工时全部分配给项目。一个便于团队讨论的公式是：

可承诺项目容量 = 约定工作时间 − 固定职责 − 已知休假 − 团队预留缓冲。

例如，在情景模拟中，成员每周约定工作时间为四十小时，固定会议与轮值占六小时，已知培训和团队事务占两小时，团队为突发支持预留四小时，那么该成员的项目计划容量约为二十八小时。这里的数字只是演示算法，实际参数要依据岗位工作特征、历史中断和组织制度校准。

预留缓冲不应被看成“可以随便塞任务”的空白。一旦缓冲被占用，团队应说明触发原因以及对后续承诺的影响。否则，计划中写了缓冲，实际运行却把它视为额外产能，缓冲就只剩形式。

2. 再按工作类型估算，不迷信单一工时数

对任务的估算，最好能说明估算范围和依据。对已重复多次的工作，可以参考历史完成数据；对新技术、新依赖或需求仍在变化的工作，应使用区间和假设，而不是给出一个看似精准的数字。

我通常建议把工作分为几类后分别观察：计划交付、维护支持、会议协作、返工和等待。把它们全部塞进“项目开发工时”，会掩盖真实的资源结构。支持工作占比升高时，计划交付量自然需要调整；如果团队只看到项目任务变慢，往往会误判为执行能力下降。

估算的目的不是证明团队能把每周每小时排满，而是暴露不确定性。对于关键任务，可以写清楚估算区间、风险假设和触发重新估算的条件，例如“接口方案确认后重新估算”“第三方环境未按期开放则调整测试窗口”。

3. 把资源表从“人员清单”升级为“交付网络”

建议为每个关键交付物至少记录：负责人、协作角色、计划投入、起止窗口、前置依赖、验收条件和冲突等级。对于跨项目共享的稀缺技能，还要有一张汇总视图，按成员而不是只按项目看总承诺。

同一个成员的工作安排应当能看见重叠时间。若团队使用项目管理平台，可以通过项目、成员、任务和时间区间的关系汇总负荷；若暂时依赖表格，也应保证每个项目使用统一人员名称、统一周期和统一状态口径。工具不能替代资源规则，但共享视图能减少重复询问与信息滞后。

当组织规模达到数百人、项目数量较多或需要跨部门组合排期时，PingCode一类项目管理平台可以用于集中管理项目工作项、成员计划和协作进度。PingCode主要服务中大型企业及一百人以上组织；是否适合具体团队，仍要看组织能否先统一项目层级、人员口径、权限和流程。平台可以让冲突更容易被看见，却不会自动替管理者决定哪个项目让路。

4. 用“关键路径＋稀缺技能＋风险暴露”判断先后

资源冲突不能只按谁先提出需求来解决，也不能简单按项目级别或管理者声音大小排序。我会先判断冲突影响的是不是关键路径，再确认所需技能是否稀缺，最后看延迟会带来什么可验证的业务后果。

1. 确认任务是否影响关键路径：任务延迟是否会直接推迟整体交付，是否存在可并行的工作。
2. 确认技能是否不可替代：是否能通过结对、拆分或交接降低单点依赖。
3. 比较延迟影响：检查客户承诺、合规窗口、依赖项目和业务收益，而不是只比较项目名称。
4. 显式选择代价：决定优先级后，明确哪个日期、范围或支持承诺需要调整。
5. 记录决策与复核点：写清责任人、决策理由及何时重新评估。

这样做的核心，是把隐性冲突变成显性取舍。若管理者不愿说明哪个项目延后，组织就会默认所有项目都不延后，最后由成员用不可持续的加班承担取舍成本。

5. 设定可解释的负荷预警，而不是机械红黄绿

红黄绿看板容易理解，但颜色背后的逻辑必须清楚。比如，连续两周的计划承诺超过团队设定的可承诺容量，就触发复核；关键成员的任务重叠覆盖关键交付窗口，也触发协调；任务连续多个周期无法推进，则检查依赖与验收条件。具体阈值应依据团队实际数据设定，不能把某个百分比当成所有行业通用标准。

预警要有动作对应。黄色代表需要在本周确认是否调整顺序或拆分任务；红色代表必须由有决策权的人明确范围、日期或人员取舍。若报警只产生通知、不产生决策，团队很快会忽略预警。

五、案例与数据观察：用一周的冲突把计划校准回来

1. 案例设定：不是加人，而是先看承诺总账

以下为情景模拟，目的在于展示诊断过程，不代表实际客户案例或外部调研数据。某数字化项目团队有一名熟悉核心服务的后端工程师、一名测试工程师和一名产品负责人。团队同时推进两个项目，并承担线上支持。连续两周，后端任务按期率下降，项目经理提出增加一名开发人员。

团队先把该成员两周内的全部安排合并，发现原计划包含项目甲二十小时、项目乙十四小时、线上支持八小时、例会与评审六小时，合计四十八小时。实际记录显示，线上支持并非偶发，而是每周稳定存在；项目乙还需要等待产品确认接口规则。问题既有容量超配，也有决策等待，不能只靠招聘处理。

团队采用三项调整：由业务负责人确认两个项目的先后顺序；把项目乙拆成不依赖接口规则的准备工作与依赖确认的实现工作；将固定支持安排轮值，并把值班容量纳入计划。新成员招聘仍进入评估，但不再被当作解决本周延期的唯一办法。

2. 用可核对的指标观察，而不是只看“忙不忙”

这类情景中，建议跟踪少量且能触发行动的指标。第一，计划负荷与可承诺容量的差值；第二，关键任务等待决策或依赖的时间；第三，跨项目切换次数或被打断的工作段；第四，交付日期变更与返工原因。指标的作用是引导复盘，不是给成员排名。

以下图表使用情景模拟数据，且统计口径是团队内部的计划观察，不应外推为行业平均。它展示的是调整前后可能出现的变化关系：当支持工作被纳入计划、依赖被拆清后，计划承诺趋于可执行，任务按期情况可能改善。真实团队应在连续多个周期中用自己的数据验证，不应把模拟值当作效果保证。

3. 把改善拆到过程节点，避免归因过度

如果调整后按期完成率提高，不能立即断言是资源管理动作单独造成的。同期可能发生了需求变更减少、工作难度下降或人员经验提升。更稳妥的做法，是记录每次任务延迟的主要原因，再比较调整前后的原因分布。

例如，若“等待决策”减少，但“返工”上升，说明决策速度变快并不代表交付质量变好；若计划承诺下降、未完成任务却没有改善，可能是拆分方式不合适或阻塞未解除。指标需要成组解释：一个指标负责描述结果，另一个帮助解释原因。

4. 从复盘记录中寻找真正的资源约束

复盘时不要只问“为什么没完成”，还要问“在什么时候已经可以看出不会完成”。前者容易把讨论带向个人解释，后者能定位预警机制是否缺失。例如，需求确认延迟在计划开始前已经发生，团队却仍保留原交付日期；那么问题就不是成员执行慢，而是计划更新机制没有响应新的事实。

我建议每次复盘只选择一到两个最值得改善的机制，不要同时推出十几条规定。团队可以先从“关键人员跨项目承诺可见”“阻塞超过某个周期必须升级”“支持工作设置轮值”中选一项，执行两个周期后再看是否减少了重复冲突。

六、落地方法：从一张表到每周校准

1. 第一步：建立最小资源台账

不需要一开始就购买复杂系统，也不要先追求精确到小时的全员工时。先建立一份最小台账，统一项目、成员、周期与工作类型；选取影响关键交付的岗位作为试点，验证信息是否能支持决策。

• 项目或交付流名称。
• 成员姓名与主要技能类别。
• 计划周期和可承诺容量口径。
• 任务负责人、协作角色与预计投入区间。
• 依赖关系、验收条件和已知风险。
• 冲突决策人、决定日期和受影响承诺。

如果同一人跨三个项目工作，台账必须能按人汇总，而不只是按项目查看。否则，每个项目都能看到自己的排期，却没有人看到总负荷。

2. 第二步：用滚动周期而非一次性年度排满

长期计划适合表达方向、阶段和关键里程碑，但人员细排越远越不可靠。距离当前较近的工作可以更具体，远期工作保留区间、依赖和待验证假设。随着需求、技术方案和人员情况变化，逐步把未来计划细化。

采用滚动规划时，每次更新要区分“已承诺”“有条件预计”和“待决策”三种状态。否则，计划上的远期日期容易被当作不可变承诺。团队要明确：什么时候重新评估资源，哪些变化会触发调整，以及谁有权限改变对外日期。

3. 第三步：召开短而有决策的资源校准会

资源会议不应逐条读任务状态。有效会议围绕冲突、依赖和取舍展开，建议控制参会范围，邀请真正能决定优先级或调整日期的人。会前由项目负责人更新数据，会议上只讨论需要跨团队决策的问题。

1. 查看下一周期的关键交付和依赖变化。
2. 检查共享成员是否出现承诺重叠或容量超限。
3. 确认高风险任务的替代技能与缓冲安排。
4. 对每个冲突作出明确选择，记录被调整的范围或日期。
5. 复核上次决策是否执行，记录尚未解除的阻塞。

如果会议结束时每个人都只说“回去再协调”，说明缺少有决策权的参与者，或议题没有聚焦到可选择的方案。下次应先明确决策人，而不是延长会议时间。

4. 第四步：建立交接和替补机制

对于单点技能依赖，不应只给成员贴上“不可替代”标签。先拆解具体工作：哪些部分必须由资深人员完成，哪些可以由他人准备、验证或维护；再通过结对、代码评审、文档和演练逐步降低依赖。

替补安排不是要求每个人都精通所有领域，而是确保关键工作不会因某人休假或临时抽调就完全停摆。对于低频、高风险的工作，至少应明确操作步骤、权限路径和升级联系人；对于高频核心工作，则考虑培养第二责任人。

5. 第五步：选择工具前先确认管理问题

表格、协作平台和企业项目管理系统各有适用边界。团队如果只有一个项目、成员少且依赖简单，共享表格配合固定校准机制通常足够；如果项目多、权限复杂、跨部门协作频繁，手工维护容易出现重复数据、版本冲突和统计延迟，才需要评估更集成的管理平台。

评估时不要只看有没有资源视图或工时字段，还要测试日常管理是否能闭环：项目如何关联成员和任务，跨项目负荷能否汇总，冲突如何留痕，权限如何配置，数据能否按组织现有口径导出，团队是否需要大量额外录入。工具效果最终取决于这些细节是否被真实工作流程采用。

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

1. 小团队：优先控制并行工作数量

小团队常常没有专职资源经理，成员身兼多岗。此时，建立复杂的工时体系可能弊大于利。先限制同时进行的重点工作数量，明确每周谁负责支持、谁负责交付，并在团队例会上暴露冲突。

这种做法的取舍是：短期内可能看起来“开工项目变少”，但正在做的工作更容易完成。若组织仍要求所有项目同时启动，就要明确接受延期、降低范围或追加资源中的一种代价，不能把冲突留给成员自行消化。

2. 多项目组织：建立组合优先级，而非各项目单独排期

多个项目共享相同岗位时，单个项目的资源计划不足以保证整体可执行。组织需要一个能够比较项目重要性与交付代价的组合视图，至少定期审视项目之间的依赖、资源峰值和关键技能容量。

这样做会增加前期协调成本，也会让某些项目的等待变得更明确。但明确等待通常比假装并行更有价值。若项目无法排在当前容量中，负责人要说明是延期、缩小范围，还是申请外部资源，避免计划持续处于“都已启动、都未完成”的状态。

3. 高不确定性项目：使用区间和阶段性承诺

新产品探索、技术验证和需求变化频繁的项目，过早做精确的人天承诺，容易产生虚假的确定性。更合适的做法是分阶段设置投入上限、验证目标和继续投入条件：先确认关键假设，再决定是否扩展团队或进入更完整的交付计划。

它的代价是早期计划不够“漂亮”，也不适合直接用单一固定日期对外承诺。但如果项目假设还未验证，给出过度精确的工时只会让后续变更更难解释。应当把未知事项明确列出，并设置最迟决策时间。

4. 强依赖专才的工作：优先降低单点风险

如果任务必须由极少数人完成，增加普通人力可能无法立刻提高产能。先判断哪些工作需要专家亲自处理，哪些可以通过准备、测试、文档或拆分交给其他成员；再规划知识转移和替补能力。

这类安排会在短期内占用专家时间，甚至让当期交付略微放慢。但如果团队长期把所有关键工作压在一人身上，个人休假、调岗或突发事件都会变成项目风险。缓解单点依赖属于风险投资，不应只按本周产出评估。

5. 需求频繁变更的团队：先治理入口，再扩充计划

如果临时任务不断插入，团队每周重新排期仍然救不了资源管理。需要先设置需求入口、紧急级别和授权规则，让新任务进入时同步说明谁决定插入、挤掉什么工作、影响哪些承诺。

设置入口会增加需求提出者的等待和说明成本，但能避免所有工作都以“紧急”为名进入队列。对于真正的突发事件，可以保留专门的响应机制；对于普通需求，应进入明确的优先级排序，而不是通过私聊绕过计划。

6. 资源调整时，把隐性成本也纳入取舍

增加人手不等于马上增加产出。新成员需要理解业务、熟悉系统、配置权限，并与现有成员建立协作方式。对于工作已经接近完成的短周期任务，临时增加人员可能带来更多沟通成本；对于长期稳定、可拆分的工作，补充能力才更可能形成持续收益。

延期也有不同成本。若项目存在客户承诺、监管窗口或外部依赖，延期代价可能很高；若只是内部目标日期，缩小范围或延后未必比让团队长期加班更差。每次取舍都应把实际影响写出来，而不是默认“交付日期不可动、范围不可动、资源也不可动”。

八、常见问题：把资源管理真正落到日常

1. 资源管理必须统计每个人的工时吗？

不一定。若目标是发现跨项目冲突和排期风险，按周记录容量区间、任务承诺和阻塞原因可能已经够用。只有在计费、法规、支持成本核算或特定经营分析需要时，才有必要提升工时记录的细度。任何记录机制都应衡量它带来的决策价值与填写负担。

2. 可承诺容量应该设置成多少？

不存在适用于所有岗位的固定比例。研发、客户支持、销售协同和合规审查的中断特征不同。建议先回看若干个真实周期，区分计划交付、固定职责、临时支持、会议和返工，再按团队性质设定内部规划参数。数字需要定期修正，不能演变成个人绩效配额。

3. 项目经理没有权力调整人员优先级怎么办？

项目经理可以把冲突整理成可决策方案，但不能替没有授权的管理者作出组织取舍。提出问题时，至少同时提供冲突任务、影响日期、可选方案和每种方案的代价，并要求明确的决策负责人及答复时间。若始终无人决策，这本身就是组织治理风险，应升级到有权安排优先级的层级。

4. 资源表和项目管理平台哪个更重要？

先有统一口径和管理规则，再选择承载工具。小团队用表格也能有效管理；大型组织即使使用专业平台，如果项目结构、权限和成员信息不一致，数据仍会失真。选型时要用真实协作流程做验证，而不是只看功能清单或演示画面。

5. 怎样判断团队真正缺人？

先确认计划范围和优先级已经明确，固定职责与支持工作已计入，关键任务估算有依据，等待和返工没有被误报为执行时间。若在这些条件基本成立后，核心工作仍持续超过可承诺容量，并且无法通过调整范围、顺序、流程或技能替代解决，才有更充分的证据讨论增员。

九、结语：把冲突提前暴露，比让计划看起来完整更重要

1. 资源管理的价值，是让取舍变得可见

项目成员协同管理最容易被误解为排班、分工和统计工时。真正有价值的资源管理，是让组织看见所有工作承诺的总和，识别哪些依赖和技能限制正在影响交付，并让有权的人对优先级、范围和日期作出明确选择。

我的判断是：一份不漂亮但写明风险、依赖和缓冲的计划，远比一份满载、准时、却没人相信的计划有用。资源冲突不可能彻底消失，管理成熟度体现在团队能否早发现、快分类、敢取舍，并把调整后的承诺同步给所有受影响的人。

2. 下一步：用一个周期完成最小验证

下周可以从三件事开始：选出最常被多个项目争用的关键成员，汇总其固定职责和项目承诺；为最容易延期的交付物补充负责人、依赖和验收条件；在每周校准会上让决策人对冲突作出明确选择。先运行一个计划周期，再依据真实延误原因修正规则。

不要先问“怎么把每个人排得更满”，先问“哪些承诺没有共同确认，哪些冲突没人有权处理”。这两个问题往往比新增一张工时表，更接近项目成员协同管理的起点。