资源负载

项目成员看起来“每天都很忙”，项目却仍然延期，常见原因不是人手绝对不足，而是负荷被错误地计算、分配和复盘：有人同时接了六项任务，有人手里只有一项但被关键依赖卡住，团队表格却把两者都…

2023 年下半年，我参与了一家约 400 人软件公司的资源管理复盘。他们在前一年上线了一套相当"完整"的资源负载制度：26 个填报字段、按半天粒度的工时登记、…

“团队有十几个人，为什么排期表看起来人人有空，关键任务还是一再延期？”做资源负载 Capacity 规划时，我最先检查的通常不是成员是否“忙”，而是项目计划把多少可用时间当成了可承…

资源负载表上每个人都没有超过 100%，项目却仍然延期：一个关键工程师被三个项目各自预订了 40% 的时间，合计看似只有 120%，但真正的问题不是算术，而是三个项目都把同一段连续…

去年复盘一个 180 人规模的研发组织时，我看到一张"看起来毫无问题"的资源负载表：所有项目成员占用率 96%，几乎没有空白格。但同一个季度的交付准时率只有 6…

项目成员“利用率只有 65%”时，管理者最容易做出的决定，是再塞进一项任务；但如果成员已经连续两周每周工作 50 小时，继续加活只会把低利用率变成延期、返工和离职风险。《超负荷实操…

Capacity 管理最容易失真的地方，不是团队不知道每个人有多少工时，而是计划表把“可用时间”误当成“可交付产能”：一名成员看起来每周有 40 小时，扣除会议、支持、休假、切换任…

产能管理最容易犯的错，是把“每个人有多少空闲时间”当成“项目还能承接多少工作”。一个成员本周看起来还有两天空档，但如果他是三个项目都依赖的测试负责人，这两天未必能完整投入任何一个项…

去年第四季度，我帮一家做工业软件的公司做交付复盘。他们有 217 名研发和交付人员，年度项目 43 个，管理层一直认为"人力不够"，因为几乎每个项目组都在喊缺人…

资源平衡落地方案真正要解决的，不是把每个人的工时填满，而是让关键工作在正确的人手里、以可持续的节奏完成。一个常见反常识是：团队看起来人人都很忙，项目仍然延期；原因往往不是总人力不足…