净可用工时

去年冬天，我帮一家 620 人的软件企业做年度资源复盘。CEO 开场第一句话是"我们人不够"，要求明年扩编 80 人。我把过去 12 个月的工时记录、项目计划和…

很多产品经理第一次做排期时，都会犯同一个错误：把团队每人每天 8 小时都算成可以投入需求的时间，然后用“需求点数 ÷ 人数”推出上线日期。结果到了迭代中段，计划明显落后，团队却说“…

资源负载分析最容易犯的错，是把“每个人这个月有多少工时”当成“项目能不能按期交付”的答案。一个研发团队的月度排期表显示，成员平均负载只有 78%，看上去还有余量；但进一步拆到技能、…

实施团队做人力资源计划时，最容易被误认为“效率低”的，往往不是人不够，也不是排期表不够细，而是计划里的投入比例无法解释：一个人被写成同时投入多个项目，合计却超过 100%；项目负责…

可用工时不是把员工每周 40 小时乘以人数，就能得到的人力供给。一个 12 人团队看起来有 480 小时周产能，扣除会议、支持、休假、跨项目协作和技能不匹配后，真正能用于某项计划的…

人力资源计划投入比例教程：PMO流程优化，避坑指南 一个项目的工期从 6 个月延长到 8 个月，团队人数却从 12 人涨到 19 人，最终延期原因仍然是“关键岗位人手不够”，这类看…

资源负载流程做得不准，问题往往不是“人不够”，而是项目经理把工时当成了可直接相加的数字：某位工程师本周排了 40 小时，看起来刚好满负荷；但其中可能有 8 小时会议、6 小时线上支…