需求排期

需求排期最容易出问题的时刻，往往不是需求太多，而是管理者在容量尚未核实、依赖关系尚未暴露时，就先对外承诺了版本日期。我见过一类典型场景：计划会上每个部门都拿到了“确定排期”，开发开…

版本规划失控，往往不是因为需求太多，而是因为团队把“有人提出”误当成“应该承诺”，把“排进版本”误当成“已经具备交付条件”。我做版本评审时，最先检查的不是路线图画得多漂亮，而是每项…

需求排期最容易失真的时刻，往往不是团队估算不准，而是管理者把“提出需求的时间”误当成“应该交付的时间”。我见过一类典型场景：季度初排了二十多项工作，过半后紧急插入不断，最后按时交付…

去年九月，我陪一家做工业软件的公司做季度复盘。会议室里挂着一张很漂亮的甘特图，四十五条泳道，每条都按周切好，颜色分层清清楚楚，看上去像是把未来三个月完全驯服了。CTO 指着图说了一…

去年 11 月，我陪一家做工业控制软件的公司做年度交付复盘。180 名研发，9 个小组，服务 40 多家制造业客户。CTO 见我的第一句话是：“我们的估算太不准了。” 我把他过去三…

去年第四季度，我陪一家 260 人的软件公司做季度复盘。研发负责人打开项目管理系统，指着首页的一个数字说：这个季度计划交付 47 个需求，实际按时交付 19 个，按时率 40%。但…

需求排期会上，管理者最常听到的不是“这件事要做几天”，而是“研发说两周，测试说还要一周，业务希望下周上线”。如果只把这些承诺填进甘特图，计划看起来完整，交付风险却没有消失。资源评估…

去年我陪一家 320 人的 SaaS 公司做季度复盘，研发负责人把那份改了 11 版的排期表摊在桌上，指着其中一行说：这个需求 1 月 8 日排进来，承诺 3 月底上线，最后 7 …

我见过最典型的一次排期崩盘，发生在一家 300 人的 SaaS 公司。产品总监周一在晨会白板上写下"本季度交付 8 个版本"，没人反对；季度末实际交付 5 个，…

去年 Q3，我陪一家 400 人规模的 SaaS 公司做季度排期复盘。他们把上一季度的排期表打印出来贴在会议室墙上：237 条需求，每条都标了起止日期、负责人、预估人天，颗粒度精确…