团队容量管理

迭代管理迭代进度全流程：管理层落地方案与一文讲清 迭代计划看起来完成率很高，到了发布前两天却突然冒出一批“未完成”；项目会上每个人都报绿灯，管理层仍然无法回答版本能否按期交付。问题…

迭代计划看起来排得很满，迭代结束却总有一批需求顺延；团队每周都在加班，管理层仍然说不清“还能不能再接一个需求”。这通常不是团队不够努力，而是把迭代容量误当成了开发人数乘工作日。真正…

迭代计划排得满，并不代表团队有足够容量完成它。管理层真正需要回答的不是“这次能不能再多接三项需求”，而是“扣除支持、缺陷、休假和不确定性后，团队还能稳定交付多少”。我把迭代容量管理…

迭代计划排得很满，到了评审时却发现一半需求没做完、另一半做完也没人验收，这通常不是团队“不够努力”，而是迭代管理把“排期”误当成了“交付”。从零开始建立迭代机制，关键不是先买工具或…

计划工时最容易被误解成“项目经理先估一个数字，团队再按数字填报”。真正棘手的情况往往发生在数字看起来都合理的时候：计划工时 1,200 小时，实际填报 1,190 小时，项目却延期…

项目计划里写着“团队每周可投入 200 人时”，但到了周三，关键开发仍在等评审，测试被临时需求挤走，项目负责人却看到排期表上每个人都没有超负荷，这就是 Capacity（团队容量）…

工作负载怎么做？项目负责人最容易犯的错，不是不会算工时，而是把“每个人有多少空闲时间”当成“项目还有多少交付能力”。我做资源盘点时，常见一种表面健康的情况：团队成员每周排得刚好，项…

跨部门团队出现“超负荷”，往往不是每个人都忙到没有空档，而是关键岗位的需求超过可用产能，其他岗位却仍在等待输入。一个常见场景是：产品、研发、测试和运营同时承诺多个项目，周会上每个负…

跨部门团队做资源负荷，最容易得出一个看似合理、实际却误导人的结论：把每个人的任务工时加起来，再除以可用工时，超过百分之百就说“超载”，低于百分之百就说“还有空”。我在梳理项目计划时…

资源负载（Capacity）规划最容易出错的地方，不是把工时算少了，而是把“有人”误当成“有能力交付”：一位设计师本周看起来还有 20 小时空闲，实际可能被两个发布节点、临时评审和…