需求优先级

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

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

去年年底，我帮一家做企业服务的公司做年度研发复盘。他们全年发布了 14 个版本，其中只有 3 个按原计划日期上线，版本内的需求完成率平均 68%，而研发团队的平均加班时长同比上升了…

去年底我陪一家做工业设备运维服务的客户复盘季度排期会，他们研发约 340 人，分 6 个小组。一个季度里排期会开了 11 次，最后定稿的版本和第一次相比，前 20 条需求里有 14…

去年下半年，我参与了一家 400 人规模 SaaS 公司的需求治理项目。第一次把他们的需求池全量导出来时，池子里躺着 1147 条需求，其中 62% 的需求创建超过 90 天没有任…

管理层提出“下季度把三个重点需求都排进去”时，最容易出错的不是排期表，而是把“有人名、有日期”误当成“资源已经可用”。我评估需求时，先追问四件事：它要解决什么经营问题，最晚何时产生…

需求排期最容易出问题的地方，往往不是团队估算不准，而是管理层把“想做的需求”误当成“已经承诺的计划”。当销售、产品、研发和客户成功分别拿着一份优先级清单，会议上看似排出了日期，实际…

需求排期最容易失真的时刻，往往不是团队估不准工期，而是管理层把“已经同意做”误当成“已经具备开工条件”。我复盘过一类典型项目：季度会上承诺了十几项需求，开发团队按功能点排出迭代后，…

需求排期会上，最容易造成延期的决定，往往不是“做不做”，而是把一项看起来重要、却没有明确收益和交付边界的需求，提前塞进了有限的研发容量。优先级不是需求池里的标签，而是一套把业务价值…

管理层说“这个需求下个版本必须上”，业务负责人说“客户已经等了两个月”，研发负责人却发现同一团队接下来六周的容量早已被承诺填满，这不是排期表不够细，而是组织没有规定谁能承诺、按什么…