团队交付能力

迭代计划里写了 80 个故事点，不代表团队真能交付 80 个故事点。容量管理最容易犯的错，是把“估算出来的工作量”当成“可以承诺的产能”；真正决定迭代能否按期完成的，往往是可用人天…

迭代计划排得满满当当，到了评审会却发现承诺的功能只完成一半：这通常不是团队“执行力不够”，而是容量计算把可用工时误当成了可交付能力。做好迭代容量管理，产品经理需要回答的不是“这两周…

迭代计划看起来排满了，到了中途却不断插入线上问题、需求变更和跨团队等待，最后承诺的功能只完成一半。容量管理失灵，往往不是团队“估得不准”，而是把可用工时误当成可交付容量。要让迭代管…

迭代计划看起来排得很满，到了评审时却只交付一半，问题往往不是团队“不够努力”，而是把容量误当成了可承诺的产出。迭代容量管理真正要回答的，不是“这两周能塞进多少需求”，而是“在已知人…

产品经理团队的产能表看起来经常很满：每个人都有项目、每个项目都有排期，季度计划甚至精确到周；但到了迭代中段，需求仍然延期，关键评审无人参加，紧急事项不断插队。问题通常不是团队“不够…

资源负载产能教程最容易被讲错的地方，是把“每个人有多少工时”当成“团队能交付多少”。我在做 PMO 资源盘点时，反复看到同一种情况：计划表里每个人都只排了 80% 的时间，项目却仍…

需求排期最容易出问题的时刻，通常不是需求不够，而是管理层在评审会上同时承诺了“必须按期上线”“范围不能减少”“团队不能增加”。这三句话放在同一张计划里，最终往往变成版本延期、质量下…