容量管理

需求排期资源评估最常见的失误，不是把工时估少了，而是把“管理层想要的日期”当成“团队能兑现的日期”。排期制度真正要解决的，不是让每个部门报出一个看似精确的数字，而是让组织在需求价值…

需求排期最容易失真的时刻，往往不是团队不会估工时，而是所有人都把“重要”当成了“现在必须做”。销售承诺、客户投诉、合规期限、技术债和管理层想法一起进入待办列表，最后排期会议变成争抢…

需求排期迭代规划最容易失控的时刻，往往不是研发效率低，而是团队把“排了日期”误当成“做了规划”：需求没有统一入口，承诺日期先于容量测算，临近迭代又不断插单，最后每个人都很忙，版本却…

需求排期最常见的失误，不是把工期估短了，而是把“需求什么时候做完”误当成“开发什么时候完成”：需求还在变、测试环境尚未就绪、关键人员被多个项目共享，排期表却已经给出了精确到日期的承…

三年前我接手一个 1200 人研发组织的 PMO 流程改造，做的第一件事就是把 PMO 集中派单改成任务认领制。当时我的判断很朴素：让最了解自己节奏的人自己挑活，效率一定会上升。三…

我见过最离谱的一次优先级事故，发生在一家约 200 人的 SaaS 公司。季度复盘会上，产品负责人打开需求列表，标着 P0 的条目有 76 条，而团队当时真正在并行开发的需求只有 …

我带过一个 12 人的 PMO 小组，同时服务 7 个事业部，峰值时在跑 43 个项目。真正让项目失控的从来不是进度表上那几行红色，而是我在一次资源评审会上发现的怪事：一位核心架构…