容量规划

资源负载 Capacity 看起来像一道除法题：把一个人的可用工时分给项目，算出利用率。但产品经理真正容易踩的坑，恰恰是把它当成一道除法题。团队计划表显示每个人只排了 80% 的时…

资源负载工作负载教程：产品经理制度设计，避坑指南 一个团队看起来每个人都排满了，项目却仍然延期，这通常不是“人手不够”这么简单：有人被会议、支持和临时需求切碎，有人的计划工时被重复…

Capacity制度最容易失真的时刻，往往不是团队没有排期，而是每个人都已经被排满：产品经理表格里有四个“高优先级”项目，研发计划却只承认其中两个；临时需求不断插入，月底复盘时又发…

产品经理的资源负载表上，所有人看起来都只占了 80%；项目却连续两周延期，关键评审没人参加，研发负责人还在周会上说“团队已经没有余量”。这类冲突通常不是算术错误，而是把人天、任务、…

Capacity（容量规划）不是把每个人的工时填进表格，再用红色标出超载的人。真正让产品经理头疼的，通常是这样的场景：路线图上有三个“本季度必须完成”的项目，团队名义上有十几个人，…

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

资源负载做得好，不是把每个人的日历塞满，而是让承诺的工作量、可用产能和交付风险在同一张图上对得起来。产品经理最容易踩的坑，是看到团队“还有空档”就继续接需求，直到测试、设计或某位关…

资源负载 Capacity 最容易算错的地方，不是加法，而是把“可用工时”误当成“可承诺产能”。一个团队看起来有 20 人、每人每月 160 小时，表格里便出现 3,200 小时容…

项目计划里写着“研发团队还有 20% 余量”，项目却连续两个月延期；PMO 拉出一张资源负载表后才发现，所谓余量来自把同一位架构师在三个项目里的投入分别按 30%、40%、50% …

PMO做完资源负载表后，最常见的尴尬不是“没有数据”，而是数据看起来很精确，项目负责人却仍在会上追问：下个月谁能接活？这个人已经被三个项目同时预订，为什么表里还是只有 80%？我判…