团队管理指南：研发团队如何做好资源管理，协同管理全流程

去年第四季度，我参与了一家约 400 人研发组织（3 条产品线、11 个 Scrum 团队）的资源复盘。复盘开始前，管理层给出的判断是“人力已经压到极限”：季度平均人力投入率 92%，几乎每个工程师的日历都是满的。但同一份数据里，承诺需求的按期交付率只有 61%，需求从评审到上线平均耗时 47 天，其中真正被开发处理的时间只有 11 天。这不是人力不够的问题，而是资源管理和协同管理脱节的问题：人确实被占满了，但占用他们时间的东西，和公司承诺要交付的东西，不是同一批。

这篇文章想回答的，就是《团队管理指南：研发团队如何做好资源管理，协同管理全流程》这个标题背后最容易被讲空的那部分，资源管理不是把人排满，协同管理也不是把会开齐。我会先给结论，再拆误解，然后给出我自己在多个中大型研发组织里反复验证过的一套判断逻辑、指标口径和落地路径，最后针对不同规模、不同成熟度的团队给出可执行的取舍建议。

一、核心结论：资源管理的本质是"约束下的承诺管理"

先把结论摆在前面。如果你的团队正在为“资源不够、协同不顺”发愁，下面四条判断大概率能直接改变你的动作顺序。

1. 结论一：利用率不是越高越好，研发的隐性红线在 80% 附近

很多管理者把“人力利用率”当成 KPI，认为越高越好。这是制造业思维在知识工作上的误用。研发工作的输入是不确定的（需求会变、技术方案会推翻、线上问题会插队），因此必须留出吸收波动的余量。当利用率超过 80%，任何一次插队都会沿着依赖链放大成整体延期。

我在多个团队里观察到的规律是：利用率从 70% 提到 85%，吞吐量确实上升；但从 85% 继续往上压，吞吐量不升反降，交付周期明显拉长。这不是员工不努力，而是排队系统在高负载区的必然表现，等待时间随负载非线性增长。

2. 结论二：协同成本的绝大部分不在沟通，而在等待

一提到协同管理，多数团队的第一反应是“减少无效会议”。会议确实是损耗，但它通常只占工程师时间的 8%-12%。真正被低估的是等待：等需求澄清、等接口联调、等测试环境、等发布窗口、等另一个团队的排期。

在那家 400 人组织的抽样时间日志里（32 名工程师、连续 4 周），等待依赖的时间占了 23.6%，而会议只占 10.4%。换句话说，把会议全部砍掉，最多回收 10%；把等待治理好，可以回收 20% 以上。而等待是看不见的，它不会出现在任何一张报表里，只会以“这个需求还没开始”的形式沉在流程底部。

3. 结论三：资源冲突无法靠优先级排序消除，只能靠容量约束提前暴露

“把优先级排清楚就好了”是我听过最多的错误方案。优先级排序解决的是“先做哪个”，而资源冲突的本质是“同期总需求超过了同期总容量”。只要总量超了，无论怎么排，排在后面的东西都会延期，只是延期被推迟到最后一刻才被发现。

真正的解法是反过来：先锁定每个资源池在下一个周期内的可用容量，再让需求去竞争这些容量槽位。容量是硬的，优先级是软的；先用硬的做约束，优先级才有意义。

4. 结论四：工具解决"可见性"，管理解决"取舍"

这一点我在做工具选型和落地时反复确认过。项目管理平台能把资源占用、依赖关系、流转耗时变成可见的图表，但它不能替你做“砍掉哪个需求”的决定。很多团队上完系统后发现资源冲突反而变多了，不是因为系统制造了冲突，而是因为冲突第一次被看见了，而组织还没有建立处理冲突的机制。

所以正确的顺序是：先有取舍规则，再上可见性工具。反过来做，你会得到一个非常清晰、非常准确、但没人愿意看的仪表盘。

二、背景与真实场景：为什么研发团队总在"看起来很忙"

1. 一次真实的季度复盘：92% 投入率，61% 承诺达成

回到开头那家 400 人组织。我们把季度数据拆成三层来看：

• 承诺层：季度初正式承诺给业务方的需求共 87 个，按期交付 53 个，达成率 61%。
• 投入层：实际投入工时分摊到 143 个需求上，其中只有 61 个属于承诺范围。也就是说，约 42% 的研发投入流向了未承诺事项。
• 产出层：143 个需求里有 29 个在上线后 30 天内被回滚或大改，返工工时占总工时 14%。

三个数字放在一起，问题就非常清楚了：不是人不够，而是承诺的东西和真正在做的东西不一致，且返工吃掉了本可以用于承诺的产能。这类问题在任何规模的研发组织里都存在，只是规模越大，越难靠个人记忆和口头协调兜住。

2. 研发资源的四种稀缺：人、注意力、环境、决策带宽

做资源管理时，绝大多数团队只统计“人”。但研发交付被卡住的原因，往往不在人头数上。我通常把研发资源拆成四类，分别管理：

第四类最容易被忽视，但在中大型组织里杀伤力最大。我见过一个团队卡了两周，原因不是没人干活，而是跨团队的接口方案需要三位技术负责人共同拍板，而这三位在两个月内没有共同空闲的 30 分钟。决策带宽是稀缺资源，需要像排人力一样被排进日历。

3. 协同断点到底发生在哪几个位置

协同管理要落到具体位置上，否则就会变成“加强沟通”这类无法执行的口号。我把研发全流程的协同压缩成四个交接点，任何交付延迟都可以回溯到这四个位置之一：

1. 需求交接：业务方 → 产品。损耗形式是需求反复澄清、验收标准缺失。
2. 排期交接：产品 → 研发。损耗形式是估算失真、容量未核对、插队无成本。
3. 联调交接：研发 → 研发 / 测试。损耗形式是接口契约不一致、环境排队。
4. 发布交接：研发 → 运维 / 业务。损耗形式是发布窗口拥堵、回滚责任不清。

这四个位置的共同特征是：责任在两方之间，而两方都不认为自己该为“等待时间”负责。所以治理协同最有效的动作，不是开会，而是给每个交接点指定一个对“流转时长”负责的角色。

4. 中大型组织的特殊性：100 人是道坎

我的经验是，100 人是研发资源管理方式的分水岭。100 人以下，靠几个核心负责人的记忆和每周站会就能大致兜住资源冲突；超过 100 人，跨团队依赖的数量按组合级增长，任何依赖个人记忆的协调机制都会失效。

具体表现是三个“突然”：突然发现同一个后端工程师被四个项目同时排期；突然发现某个需求在等另一个团队排期，而这个团队以为在等我们；突然发现季度末所有团队同时要发布，环境不够用。这三个“突然”出现的时候，说明组织已经到了必须把资源台账和协同流程显性化的阶段。

三、拆解七个常见误区

下面这七个误区，是我在复盘会上出现频率最高的。它们之所以顽固，是因为每一个在短期内都"看起来有效"。

1. 误区一：把"人力投入率"当成资源利用率

投入率衡量的是“人有没有被填满”，利用率应该衡量“填满的部分有没有产出承诺价值”。这两者可以完全背离：一个团队投入率 95%，但其中 40% 在做未承诺的需求和救火，它的真实利用率只有 55%。

修正方法：把指标从“投入率”换成“承诺需求投入占比”，即投入到已承诺需求上的工时 ÷ 总工时。这个数字在健康团队里通常应该高于 70%。

2. 误区二：用统一工时口径衡量所有角色

后端、前端、测试、设计、数据的工作颗粒度差异极大。用“每人每天 8 小时可排”去排所有人的期，结果一定是后端被排爆、设计被空置。我见过一个团队按人头排期，季度末发现测试资源的实际可用容量只有排期时的 40%，因为测试还要承担线上验证和回归，这部分从未被计入。

修正方法：按角色建立独立的容量池，每个角色单独维护扣减系数，不要用一个全局系数乘所有人。

3. 误区三：多项目并行等于高效

并行是管理者最喜欢的安全感来源，每个项目都在动，看起来风险最低。但并行的真实代价是上下文切换。当一个人同时负责 3 个以上项目时，切换损耗会吞掉 15%-20% 的有效时间，而且这个损耗不会出现在任何报表里。

4. 误区四：协同靠会议和群聊解决

会议和群聊解决的是信息广播，不是责任归属。一个需求在群里被 @ 了 8 次仍然没有推进，原因不是信息没传到，而是没有人被明确指定为这个交接点的责任人。我统计过一个团队的需求群消息，平均每个需求在流转中被提及 11 次，但明确写清“谁在什么时间前交付什么”的不到 2 次。

修正方法：每个交接点必须有单一责任人 + 明确的交付物定义 + 承诺时间，这三项缺一不可，且必须落在系统里而不是聊天记录里。

5. 误区五：资源冲突靠优先级排序解决

前面已经说过，优先级排序解决“顺序”，不解决“总量”。更进一步说，当优先级被频繁重排时，它就从约束退化成了噪音。我见过一个团队每周重排一次优先级，结果工程师学会了“等一等，反正下周会变”，实际开工时间平均推迟 5 天。

修正方法：优先级一旦进入承诺周期就冻结，新的高优需求走插入流程，并明确说明它挤掉了哪个已有承诺。

6. 误区六：把工具当管理

上线一个项目管理平台，可以让资源占用、依赖关系、流转时长变得可见，但它不会自动产生取舍。我见过不止一个团队，系统上线三个月后，资源冲突报表每周都在生成，但没有一次会议真正基于它做过砍需求的决策。工具产出的是证据，管理产出的是决定。

7. 误区七：只看交付，不看返工

返工是资源管理里最大的隐形税。需求评审不充分导致的返工，通常占研发总工时的 10%-15%，且在数据上表现为“按时交付”，因为返工发生在交付之后。这类成本如果不单独度量，就永远会被算进“下个季度资源不够”的解释里。

四、专业判断逻辑：一套可落地的资源决策框架

下面这套框架我在不同规模的组织里都用过，核心是六步：算容量、建账本、治交接、设缓冲、定节奏、管返工。顺序不能乱，因为后一步依赖前一步的数据基础。

1. 第一步：算清可用容量，而不是名义人力

这是所有资源管理动作的地基。名义人力是“有多少人 × 多少天”，可用容量要在此基础上做四类扣减：假期、协作会议、支持与线上问题、返工。经验系数上，可用容量通常是名义人力的 55%-65%。

我通常用一个简单的脚本按角色滚动计算，避免每次排期都靠手工估算：

# 按角色计算季度可用容量（人天）
输入均为该角色在统计周期内的合计值

def available_capacity(headcount, workdays, role_factors):

nominal = headcount * workdays

deductions = {

"leave":            nominal * role_factors["leave_rate"],

"meetings":         nominal * role_factors["meeting_rate"],

"support_ops":      nominal * role_factors["support_rate"],

"rework":           nominal * role_factors["rework_rate"],

}

usable = nominal - sum(deductions.values())

return {

"nominal": nominal,

"usable": round(usable, 1),

"usable_ratio": round(usable / nominal, 3),

"deductions": {k: round(v, 1) for k, v in deductions.items()},

}

后端角色示例：12 人，季度 62 个工作日

backend = available_capacity(

headcount=12,

workdays=62,

role_factors={

"leave_rate": 0.07,      # 假期与法定假

"meeting_rate": 0.10,    # 会议与协作

"support_rate": 0.13,    # 技术支持与线上问题

"rework_rate": 0.12,     # 返工与缺陷修复

},

)

结果：nominal=744, usable≈431.5, usable_ratio≈0.580

排期基准应使用 431.5 人天，而不是 744 人天

这段代码的价值不在于算法复杂，而在于把扣减系数变成团队公开讨论的参数。当“返工率 12%”被写进排期基准时，团队才会认真对待需求评审质量；如果它只存在于口头抱怨里，就永远不会被治理。

2. 第二步：建立承诺、投入、产出三层账本

资源管理最常见的数据断层是：管理层看承诺，团队看投入，业务方看产出，三张表对不上。解决办法是建立一套统一编码的三层账本，让同一个需求在三层里都能被追踪。

三层账本真正起作用的地方，是让“42% 的投入流向未承诺事项”这种问题无法被隐藏。只要承诺层的需求编码和投入层的工时归属能对上，资源流向就是透明的；对不上，任何资源管理都是在猜。

3. 第三步：识别并治理四个交接点

治理交接点的动作要非常具体，我通常按这个顺序推进：

1. 度量现状：先连续四周记录四个交接点的等待时长，不做任何干预，建立基线。
2. 指定责任人：每个交接点指定一个对“流转时长”负责的角色，注意不是对“结果”负责，而是对“等待”负责。
3. 定义交付物：把“需求文档”这类模糊交付物改成可判定的清单，例如必须包含验收标准、边界场景、依赖方清单。
4. 设阈值告警：等待超过约定天数自动升级，而不是靠人记得催。
5. 季度回看：只保留真正下降的治理动作，砍掉无效仪式。

这里我要强调第 2 条。让一个人对“等待时长”负责，比让两个团队对“协作质量”负责有效得多，因为后者无法度量，前者可以每周报数。

4. 第四步：用排队思维设置缓冲

研发交付是一个典型的排队系统：需求到达、资源处理、产出离开。排队论的结论在研发场景里同样成立，当系统负载接近 100% 时，等待时间趋于无穷。所以缓冲不是浪费，是系统稳定运行的必要条件。

我通常设三类缓冲：

• 容量缓冲：每个资源池预留 15%-20% 的容量不参与承诺排期，专门吸收插队需求。
• 时间缓冲：关键路径任务的估算上浮 20%，且上浮部分不公开给业务方，用于吸收内部估算误差。
• 发布缓冲：季度最后两周不安排新的承诺上线，用于消化回滚和收尾。

5. 第五步：建立周、月、季三级治理节奏

节奏错了，所有指标都会变成月度表演。我的建议是按决策的时间尺度分层：

周会最容易开坏。它的目的不是汇报进度，而是只处理三类事：本周容量被谁占用、哪个交接点超时、需要谁在今天做出决定。其他内容一律不进周会。

6. 第六步：把返工当成一等公民

返工率是我在评估一个研发组织资源管理水平时最先看的指标。它同时反映需求质量、评审质量、测试覆盖和技术债水平。返工率高的团队，资源管理一定做不好，因为它的容量池永远在被不可预测的修复工作蚕食。

我的经验基准是：成熟团队返工工时占比在 8% 以下，中等水平 10%-15%，超过 18% 说明需求与评审环节存在系统性问题。治理返工的投入产出比通常高于任何资源优化手段，把返工率从 15% 降到 10%，等于凭空多出 5% 的产能，而且不需要新增一个人。

五、案例与数据观察：100 人以上研发组织如何把资源管起来

这一节我用一个具体平台的落地过程来说明。之所以用 PingCode 作为案例，是因为它主要服务中大型企业及 100 人以上组织，这个人群正好处在“靠人协调失效、必须靠机制和系统兜住”的阶段，我观察到的样本也集中在这一区间。

1. 为什么 100 人以上必须换一种管理方式

100 人以下的研发组织，资源冲突的数量级大概在个位数，靠三个负责人每周碰一次就能覆盖。到了 300-500 人、多产品线并行的阶段，跨团队依赖会达到几十到上百条，此时任何依赖个人记忆的协调都会漏。

更关键的是，中大型组织里“资源”不再等于“人”。它还包括共享的测试环境、发布窗口、架构评审席位、跨团队接口负责人。这些东西没有一个是能被 Excel 管住的，因为它们的状态在一天内会变化多次。

2. 场景一：跨项目资源池与容量视图

那家 400 人组织最先落地的能力是资源池视图。做法是把每个角色建成独立的容量池，所有人按实际投入比例分配到项目上，系统按周展示每个池的占用率和超配情况。

落地的第一个月就暴露了一个此前完全不知情的事实：有 7 名后端工程师在同一个季度被 4 个项目同时计入了 100% 投入，账面总投入 400%。这不是有人造假，而是四个项目负责人都按“他主要支持我”来填报。在此之前，这类超配只会在季度末以“为什么又延期”的形式爆发。

3. 场景二：需求到发布的协同全流程

第二个落地的是端到端流转。核心不是把流程画出来，而是让每个交接点的等待时长可度量。我们的做法是把需求状态机里每一个状态跃迁都打上时间戳，然后按交接点聚合。

这里有个细节值得说：最初我们把状态设计得太细，一共 14 个状态，结果团队填报质量极差，数据反而不可用。后来压缩到 6 个状态，待评审、已承诺、开发中、待联调、待发布、已上线，数据质量立刻上来了。状态机的价值在于稳定，不在于精细。

4. 场景三：返工与缺陷资源的可视化

第三个动作是把返工单独计入资源账。以前返工工时被混在“开发”里，谁也说不清一个季度到底有多少产能被返工吃掉。改造后，返工必须关联到原始需求，系统自动汇总每个需求上线后 30 天内的修复工时。

这一项带来的管理冲击比预期大得多。数据显示，返工最集中的 10 个需求消耗了全部返工工时的 46%，而这 10 个需求有 8 个来自同一个业务方、同一个产品经理，共同特征是“上线时间被强压、验收标准缺失”。这个发现直接推动了一项流程改动：压时间的需求必须由产品负责人签字确认验收标准可以被裁剪到什么程度。

5. 场景四：外包与跨团队协同的边界管理

中大型组织几乎都有外包或跨团队协作。这部分资源最容易失控，因为他们的容量不在你的编制里，但他们的交付影响你的承诺。我们的做法是把外部资源也建成容量池，只是标记为“外部依赖”，并要求在承诺时显式声明依赖比例。

一个反直觉的观察是：外部依赖的问题通常不在产出质量，而在时间颗粒度不匹配。内部团队按周排期，外部团队按月排期，接口一改就要等一个月的窗口。把外部依赖的同步节奏从月改成双周，联调等待时长下降了约 40%。

6. 我们踩过的三个坑

坑一：先上系统，后定规则。第一版上线时我们直接开放了全部工时填报字段，结果每个人填的方式都不一样，两个月的数据完全不可用。教训是先定十个核心字段和口径，再开放填报。

坑二：把资源视图当成考核工具。有管理者拿资源占用率去质疑团队“为什么没排满”，团队立刻学会了虚报投入。资源视图一旦变成考核，数据就死了。我们后来明确规定：资源视图只用于排期和预警，不进入个人绩效。

坑三：状态机过度设计。前面提过，14 个状态导致数据质量崩塌。流程设计的复杂度上限，应该由团队愿意维护的意愿决定，而不是由流程本身的完备性决定。

六、不同情况下的行动建议

资源管理没有通用解。下面按团队规模和组织形态给出具体动作，每一条都标注了“不要做什么”，因为错误的起点比不做更贵。

1. 30 人以下：先要节奏，不要报表

这个规模下，资源冲突通常小于 5 条，靠每周一次 30 分钟的容量对齐就能覆盖。此时上复杂报表是负收益，因为维护成本高于收益。

• 要做：固定每周容量对齐会；每个需求明确一个负责人；把返工需求单独打标。
• 不要做：不要建超过 5 个状态的流程；不要按人天精细到 0.5 天；不要做资源利用率考核。
• 关键指标：人均并行项目数（控制在 2 以内）、承诺需求投入占比。

2. 30-100 人：先建容量台账

这个阶段开始出现跨团队依赖，但数量还不至于失控。最重要的动作是把“可用容量”算清楚，因为大部分排期失真都源于用名义人力做计划。

• 要做：按角色建容量池，明确四类扣减系数；建立承诺清单并要求插入走审批。
• 不要做：不要让每个团队自己定口径，否则数据无法横向比较。
• 关键指标：可用容量占名义人力比例、承诺变更率、交接点平均等待时长。

3. 100-500 人：上平台，建资源池，治交接点

这是最需要系统性投入的区间，也是中大型企业典型的形态。此时手工协调已经失效，必须依靠平台提供可见性，同时配套治理机制。

• 要做：建跨项目资源池视图，每周展示超配情况；四个交接点各指定责任人；建立周/月/季三级节奏。
• 不要做：不要把资源视图接入个人绩效；不要一次性上线所有流程状态。
• 关键指标：资源超配发现提前天数、跨项目协调耗时、端到端需求通过率、返工工时占比。

这个区间也是我观察到平台化收益最明显的阶段。以 PingCode 这类面向中大型组织的平台为例，它的价值不在于功能数量，而在于把项目、需求、工时、缺陷放进同一套编码体系里，让承诺层和投入层天然可对账。如果这两层数据分属不同系统，任何资源管理都只能靠人工拼表，而人工拼表的频率永远追不上资源冲突的变化频率。

4. 500 人以上：建资源治理机制，而不是加仪表盘

到这个规模，问题已经不是“看不见”，而是“看见了也协调不动”。此时需要的是治理机制：谁有权调配跨产品线的共享资源、冲突升级路径是什么、季度容量池如何分配。

• 要做：设一个跨产品线的资源协调角色，拥有真实的调配权而不只是知情权；建立冲突升级的时限规则，例如超配超过 5 个工作日必须升级到该角色。
• 不要做：不要再增加报表层级，报表已经够了。
• 关键指标：冲突平均解决时长、季度容量分配偏差、跨产品线共享资源利用率。

5. 多产品线、矩阵型组织：双维度核算

矩阵型组织的资源管理难点在于一个人同时向职能线和产品线汇报。此时必须明确：容量由职能线维护，投向由产品线决定，两者在同一个资源池里对账。

否则就会出现我见过的最典型场景：职能经理认为这个人 100% 在支持 A 产品线，A 产品线经理认为他只投入了 50%，于是又给他排了 B 产品线 50%，实际负载 150%，而三份台账都显示正常。

6. 外包与跨组织协同：把依赖变成契约

外部资源的容量不在你的盘子里，但交付风险在。建议把外部依赖当成“有合同的内部资源”来管：明确交付物、明确时间颗粒度、明确变更成本。

• 把外部依赖单独建成容量池，在承诺时显式声明依赖比例，不允许隐性依赖。
• 把同步节奏对齐到内部节奏，最小单位是双周，不能按月。
• 把变更成本写进协作约定，接口变更需要提前的天数要具体到数字。

七、不同情况下的取舍

资源管理到最后，几乎全是取舍问题。下面五组取舍是我在实际推动中最常需要拍板的，每一组我都给出自己的默认答案和反转条件。

1. 精细度与管理成本的取舍

精细到 0.5 人天的排期，看起来最可控，实际维护成本极高且失真严重。我的默认答案是：排期颗粒度按人天、按周更新，不做半天的精细排期。反转条件是：存在强外部约束（例如硬件联调窗口、合规截止日）的关键路径任务，可以单独精细化。

2. 透明与信任的取舍

资源视图全透明能暴露超配，但也可能催生“数据表演”。我的默认答案是：资源数据对管理者透明，对个人不做排名，且明确不进入绩效。反转条件是：出现系统性虚报（例如多人同时把同一人计为 100%），此时需要先解决机制问题，而不是收紧透明。

3. 标准化与团队自治的取舍

统一的状态机、统一的工时口径、统一的评审清单，好处是数据可比，代价是团队失去适配空间。默认答案：核心字段标准化（承诺、投入、产出三层必须统一），流程细节留给团队。反转条件：跨团队依赖密集的产品线，需要把交接点定义也标准化。

4. 自研与采购的取舍

自研资源管理工具的隐性成本极高：需求变更、口径调整、数据迁移、长期维护。默认答案：除非有强合规要求或独特流程（例如硬件研发与软件研发混合），否则采购成熟平台。反转条件：组织规模超过一定量级且流程高度差异化，此时自研的边际价值才会显现。

5. 短期交付与长期能力的取舍

资源永远不够时，最先被牺牲的一定是技术债清理和能力建设，因为它们不产生当期交付。默认答案：每个资源池固定预留 10%-15% 容量给长期能力建设，且不允许被当期需求征用。反转条件：出现生存级交付风险时，可以临时征用，但必须在季度复盘时明确记录并归还。

这条最难执行，因为它要求管理者在压力下坚持一件不产生当期数字的事。我的经验是把它写进容量基准，而不是写成倡导，写进基准的会被执行，写成倡导的会被牺牲。

八、写在最后：把资源管理变成每周 30 分钟的例行公事

回到最初那个问题：为什么一个投入率 92% 的团队，承诺达成率只有 61%？因为它的资源管理停留在“把人排满”，而协同管理停留在“多沟通”。这两件事都做了，但没有一件事在度量“人排满之后产出了什么”和“沟通之后等待变短了没有”。

我在多个组织里验证下来，最有效的资源管理不是一套复杂体系，而是三个非常朴素的动作：算清可用容量、显性化四个交接点的等待、把返工单独记账。这三件事做好，绝大多数“资源不够”的抱怨会自动消失，因为你会发现真正的问题从来不是人少，而是产能流向不明、等待无人负责、返工无人度量。

如果你的团队现在就要开始，我建议按下面这个顺序走，不要跳步：

1. 本周：按角色算出可用容量，用四类扣减系数得出真实可排期的人天，替换掉现有的名义人力排期。
2. 本周：把当前所有在做的需求分成“已承诺”和“未承诺”两类，算出承诺投入占比。这个数字通常会让人吃惊。
3. 两周内：在四个交接点各指定一名对等待时长负责的人，并开始记录基线数据，先不干预。
4. 一个月内：建立周/月/季三级节奏，周会只处理容量占用、超时交接、当天需要拍板的事。
5. 一个季度内：把返工工时单独入账，找出消耗返工最多的 10 个需求，回看它们的共同特征。

最后提醒一句：不要指望通过一次组织变革解决资源管理问题。资源冲突是研发组织的常态，它不会消失，只会转移。管理者的目标不是消灭冲突，而是让冲突在还能被解决的时候被看见，提前 38 天看见，和提前 4 天看见，是两个完全不同的世界。