全文约 2496 字，阅读约 6 分钟。
重点内容：多项目管不下来，根子不在进度表，而在资源排队的先后顺序。三组数据最说明问题：多数公司资源需求是容量的 1.2 到 1.5 倍；一个人同时挂五个项目只有 20% 的脑力在真正干活；澳洲一家 MSP 把在制品数量卡成硬上限后，超预算项目从 130% 降到 71.6%。
卡住项目的从来不是进度表
大型集团做多项目管理，最常见的动作是先搭项目集看板，把里程碑画上去，然后发现看板很干净，现场还是乱。看板管事情，管不了人。两项目都写着 3 月交付，都要同一个架构师，进度表三行全绿，架构师那周的日历已经排满了。哪个项目延期，取决于谁在电梯里先碰到产品总监，不取决于看板。
排队论里有个定律能解释大部分现象，Little's Law：周期时间等于在制品除以产出速率。同时开工的项目越多、每个项目挂的人越多，单个项目从进队列到交付的周期就越长。这条定律不需要人变懒，只需要你在产能固定时往系统里塞更多活。所以主战场是资源队列的先后顺序，不是甘特图上那根关键路径。
大部分公司的多项目，都死在 130% 这个数字上
「人不够就加人」这个说法不太经得起算账。5 个人每人每周可用 36 小时，一共 180 小时。并行挂 6 个项目、每个按 60 小时承诺，需求就是 360 小时，需求容量比 2.0。这不是缺人，是已经把两倍的活承诺出去了。实际做过的 IT 部门里，这个比值很少低于 1.2，多数落在 1.2 到 1.5 之间，也就是超卖 20% 到 50%。1.3 倍超卖的公司，是在全额付项目成本，同时只拿回分数级的项目产出。
落到个人身上更明显。纸面上某人被分配到 120%，实际交出来的大概率不到 100%，剩下的就是切换成本。要命的是这 20% 偏差你看不见，系统里没有一个人的真实时间去向。
澳洲一家 MSP 的数字最能说明改动的价值。这家公司的工程师习惯同时挂在多个项目上，客户一催就开工，结果没有一项做完。老板 Steve Psaradellis 后来做了件反直觉的事，给在制品设硬上限，5 名工程师的在制任务最多 5 到 7 个，超了不许开新。六个月后，原来跑在预算 130% 的项目降到了 71.6%，项目效率平均提升 58.4%。
一个人挂五个项目，只有 20% 的脑力在干活
卡梅隆大学有一项研究被引用得很多：同时处理五个项目的开发者，真正用在工作上的认知能量只有 20%，另外 80% 消耗在切换的心理开销上。切换代价有多具体，加州大学欧文分校 Gloria Mark 那组研究给出 23 分 15 秒这个数：人被拉走后回到原来那个任务平均要 23 分钟。回复一条消息花 30 秒，回到原来的活要 20 多分钟。
算到人身上，一天被打断 4 次、每次恢复 25 分钟，一天损失约 100 分钟，一年按 250 个工作日算是 400 到 500 小时，接近三个月只花在重新进入状态上。还有一组跟踪 50 名开发者两周的数据，日均被打断 47 次，8 小时里深度工作只有 2.3 小时。人不是无限可替换的容器，长期倦怠的员工主动找下一份工作的概率高 74%。
排队这件事往往比你想的贵
PMI 上有一篇讲多任务环境的文章，里面有个案例我印象很深。某大型保险公司的 IT 部门 170 人，PMO 只有 5 个项目经理。部门原本要支持多个事业部独立的需求，后来做整合。PMO 摸底一圈发现，队列里躺着 100 多个项目，优先级各不相同还一直在变，主机团队正在做系统升级，借不走人。然后出现了那句最扎心的话：没有一个人说得清自己的资源到底在干什么。
这个信号你在自己公司也能看到。一个技术上看很简单的小需求，业务方问要多久，答复是 6 到 8 周。原因是能干的人全在已批项目上排队。这时候最该做的不是催，是去量需求容量比。影子项目也是同一类：业务方等不及正式流程，自己找人做，做完再回来要集成，这部分工时在正式组合里看不见。展开的部分我写在项目管理的坑与方法里。
我一般怎么排：先排资源，再排日期
常见的错误是先锁交付日期，再看谁去干。日期是承诺，资源是约束，先定承诺再找约束，必然靠加班和切换来补。我的顺序是：先把每个项目要什么角色、要多少人、要多久，按周铺到资源日历上，不看已有日程只看需求；再把同一个人的需求叠在一起，超 100% 的标红，这就是超卖；然后看哪条是死线。死线不可动的时候用时差去平滑，把非关键任务挪到有余量的时段，日期不动；时差不够用只能平移，也就是资源平衡，先砍范围不砍日期是默认取舍。看起来飞快但要求同一个人同时出现在两个地方的计划不是计划。监控上我设一条 80% 的警戒线，超过就挪活或者降承诺。
在制品上限是少数被数据验证过的解法
前面那家 MSP 的做法叫 WIP 限流，逻辑跟看板不一样：看板让所有人看到所有事在流动，限流是主动关住入口。规则简单到粗暴，5 个人最多 5 到 7 件事在进行中，超过就是不加。有人说我们有 20 个紧急项目怎么办，答案是你只有 20 个项目，不是 20 个紧急项目。并行度降下来，切换次数就降下来，那笔账直接省掉。另一家澳洲 MSP Allixo 用看板重构工单状态后，工单年龄从几周到几个月降到几天。
配套动作里，效果比软件更明显的是每周一次 15 到 20 分钟的数字会，只看四个数：可用小时、已分配、在制数量、最高优先级。瓶颈是技能时加人没用，我做过一次市场团队调整，唯一能做活动素材的设计师在 110%，两个文案在 50%，做法是交叉培训一个文案掌握素材模板，设计师回到 85%。矩阵式组织里最难的也从来不是排期，是把职能部门全拉进同一张图还能算清谁超了。
落地这套东西，智序项目管理系统和智序项目管理软件对应的顺序也是这四步：先铺需求日历，再看谁超红线，然后拿时差平滑，最后才允许平移延期，不用人肉在表格里对。
系统层面你至少要能看到这四样
这四条拿去对照。
| 能力 | 没有它会怎样 | 它给你的判断 |
|---|---|---|
| 负载视图 | 超卖看不见 | 谁在 120% 以上 |
| 资源日历 | 承诺和排期两张皮 | 本周还能接什么活 |
| 在制数量上限 | 并行项目无限开 | 哪个项目该先放一放 |
| 工时去向 | 没人说得清资源在干什么 | 运维和项目各占多少 |
智序项目管理系统在负载和排期这两块按角色做，资源日历直接挂在项目和人上面，看板能按周看负载分布。智序项目管理软件的免费版不限人数，这点多项目场景很关键，因为要拉通资源往往意味着要把职能部门全拉进同一个系统，按人收费的模型在这个动作上会卡住。数据敏感的还要看部署方式，智序 ORDR 支持私有化部署，记录不出内网。PMI 2025 年对 2841 位从业者的调查里有组对比：高商业敏锐度的项目经理带的项目，83% 达成业务目标，失败率 8%，对照组是 11%；同一份报告里 47% 的项目有预算超支。
别等季度末才发现
如果只能改一件事，我建议从这周开始：拉一张表，把在手项目要的资源和团队实际可用容量算一遍，算出需求容量比，超过 1.0 就按优先级砍，而不是等月底看延期了再复盘。多项目管理不是把项目管住，是把排队管住。队列对了，日期自己会顺下来。
如有侵权请与我们联系