容量管理

迭代容量看起来像一道乘法题：团队人数乘以迭代天数，再乘以每天可投入的工时。但我在梳理多团队迭代计划时发现，真正让计划失真的，通常不是算术，而是把“名义人数”当成“可交付能力”：有人…

迭代容量不是把团队人数乘以工作日，也不是把上个迭代完成的故事点原样复制到下个迭代。一个中型产品团队曾按“8人×10天”估出80人日，计划排满后却连续三个迭代延期；复盘发现，会议、值…

迭代计划会上，团队把每个人的“可用工时”加起来，得出 240 小时容量；两周后，实际交付却只有 150 小时，延期原因还被归结为“估算不准”。这类偏差往往不是团队不会估算，而是把容…

Sprint实操方法：项目成员提升敏捷项目效率的入门指南方法与模板 不少团队的 Sprint 看起来很忙：每天开站会、任务栏不断移动、迭代结束也按时发布，但成员仍然觉得事情做不完，…

资源冲突管理最容易被误判为“谁的优先级更高”，但企业里真正造成延期的，往往不是员工不够努力，而是同一位关键人员被多个项目同时按满负荷预订，且没人拥有权力及时改范围、调顺序或补资源。…

可用工时不是员工合同工时减去周末后的简单结果。一个团队即使每人每周名义上有 40 小时，也可能只有 24 至 30 小时能稳定投入计划工作；如果管理者把 40 小时全部排满，最先暴…

Sprint 开始得很热闹，结束时却发现“做了很多、交付很少”，问题通常不在团队不够努力，而在承诺的工作量超过了团队真实产能。我的判断是：Sprint 的效率不该用任务关闭数衡量，…

产品经理做季度人力规划，最容易犯的错不是少算一个人，而是把“需要多少人”当成规划的起点。真正有效的起点，是先把业务目标拆成可验证的交付结果，再判断哪些工作必须由什么能力、在什么时间…

可用工时表上写着“产品经理本月有 160 小时”，并不意味着团队真的能拿出 160 小时做项目。节假日、例会、跨团队沟通、线上故障、评审等待和临时需求，都会把账面时间逐步吃掉。可用…

资源冲突怎么做？产品经理制度设计的起点，不是画一张“谁负责什么”的表，而是回答三个更难的问题：需求进来时谁有权排优先级，资源不足时谁承担延期代价，以及承诺变动后如何让所有人看到影响…