需求变更管理

项目规划做得好不好，有一个很朴素的检验方法：把项目核心成员叫到一起，问三个问题，这个项目做成什么样算成功、谁对最终结果负责、下周必须交付什么。如果三个人给出三个答案，问题就不在执行…

三年前我接手一个 120 人的研发中心做流程改造。启动会上我把一份 23 页的《研发项目计划管理规范》投到屏幕上，台下没人提意见。六个月后复盘，版本准时交付率 41%，里程碑达成率…

2023年11月，我参与复盘一个延期了47天的中台重构项目。复盘会上，团队给出的原因排在第一位的是“需求变更太频繁”，第二位是“测试环境不稳定”，十几个人里没有一个人提到“计划本身…

去年第四季度，我陪同一个 40 人规模的研发团队做版本复盘。连续三个版本，计划承诺 6 周上线，实际都落在第 8 到第 9 周，偏差稳定在 33% 到 38% 之间。团队的第一反应…

核心结论：计划调整的能力，不体现在改得快，而体现在改得少而准 带研发团队这些年，我做过一个粗略统计：一个 6 周左右的版本，从排期冻结到正式上线，平均会发生 3 到 5 次计划调整…

我接手过一个 28 人的研发团队，接手第一周做的最重要的一件事，不是开动员会，而是把过去两个季度的项目计划表全部翻出来，逐条比对"计划完成时间"和"实…

2024年三季度，我接手了一个已经延期两个月的中台重构项目。复盘会上，业务方说"我们只加了三个小需求"，研发说"排期一开始就压得太紧"，测试…

去年 7 月，我接手的一个 B 端权限中台版本，原计划 3 周上线，实际用了 7 周零 2 天。复盘时我把聊天记录、需求变更单和排期表全部翻了一遍，发现真正"卡在技术难点…

我经历过一次很难看的版本发布。产品经理在发布前 48 小时往版本里塞了一个"老板临时要的"功能，研发连熬两夜，测试只来得及跑主流程，上线当天下午支付回调出现异常…

上周三下午，我在一个 140 人研发组织的季度复盘会上，听到一句几乎每年都会出现的话："这个版本延期三周，主要是因为需求老在变。"会议室里没人反驳。但我把过去 …