容量管理

资源负载看起来像一道除法题：团队可用工时除以需求工时，得到一个百分比。但我在研发计划复盘中更常看到的情况是，团队总负载只有 82%，关键后端工程师却连续三周超过 120%；报表显示…

资源管理里最反常识的一幕是：团队看起来人人都很忙，项目却仍然延期；与此同时，排期表上又能找到几个“空闲”的人。问题通常不在于人不够努力，而在于组织把资源负载误读成了工时占用率。产品…

资源负载管理里最危险的数字，往往不是“某人排了 120%”，而是团队把可用工时当成了承诺产能。产品经理看到迭代容量还有 18 人天，便继续接入需求；到测试阶段才发现关键开发者同时承…

团队把 12 人都排到“满负荷”，不代表 12 人都能按期交付。需求评审、线上故障、跨团队依赖和请假会不断侵蚀可用时间；如果产品经理只按人数乘工作日排计划，表格看起来饱满，交付却常…

不少 PMO 做完第一版资源负载表后，会发现一个反常识的问题：表格更完整了，项目却没有更准时。原因通常不是缺少工时数据，而是负载数字没有进入决策流程。某团队把成员未来 12 周的工…

Capacity 看板上“利用率 92%”并不一定代表资源管理做得好：如果其中 30% 的工时来自临时插单、跨项目切换和未登记的支持任务，团队可能仍会频繁延期。PMO 真正要提升的…

项目经理把每个人的任务排满，项目却仍然延期，通常不是团队“不够忙”，而是容量（Capacity）被算错了：把工作日当成可交付工时，把已分配任务当成真实需求，又把会议、支持、返工和技…

资源负载表上每个人都只有八成工作量，项目却连续两周延期，这类现象并不少见。问题通常不在于团队“不够忙”，而在于 Capacity（容量）被误当成工时总和：会议、支持工作、技能差异、…

投入比例落地方案真正难的地方，不是把某个人的工时从“100%项目A”改成“60%项目A、40%项目B”，而是让业务负责人、职能经理和员工对这组数字采用同一口径，并在需求变化时及时修…

可用工时计划最容易失真的地方，不是公式算错，而是把“员工一个月有多少工作日”直接当成“团队能承诺多少交付”。在一类跨部门产品项目的制度梳理中，我们把一个由产品、研发、测试、设计和运…