两周一个迭代的节奏在政企项目里推行，最常见的反对意见是「需求会变，锁了基线没法干」。这句话把需求冻结理解错了。我们说的锁基线，不是不让人改需求，而是让每一次改动都留下影响评估与成本记录——改可以，改多少、动谁、谁买单，要写清楚。
需求基线锁定的是什么
每个迭代开始时，本迭代的需求范围被锁定为基线。基线锁定的是「这一周做什么」，不是「这个项目最终长什么样」。范围内的工作不打折扣地完成，范围外的新想法进入变更池，下个迭代排期。这个机制让「两周」这个承诺变得可信——团队不用在迭代中途消化未经评估的需求。
变更的影响评估写什么
变更池里的每一条需求，由交付负责人在排期前完成三问：影响哪些已完成的模块？增加多少工作量（按人天计）？如果挤占本迭代，会推迟哪些已承诺内容？三问的答案写在变更记录里，与甲方确认后再进基线。争论因此从「能不能做」转移到「值不值得现在做」，讨论质量完全不同。
变更池的优先级排序
变更池里的需求不是先到先得。每个迭代排期前，把池内条目按业务价值与依赖关系重排一次：影响后续开发结构的变更优先，可延后的锦上添花靠后。排序过程邀请甲方一起参加，十几分钟的对齐能把排期分歧消化在迭代开始之前，而不是验收阶段爆发。
成本记录是信任的积累
每一次变更都留下成本记录，短期看是约束，长期看是信任。项目收尾时，这份记录回答了甲方最关心的问题：为什么交付周期是这么长、钱花在哪了。我们的项目里，变更记录完整的团队，验收阶段几乎不发生扯皮；记录缺失的团队，验收就是重新谈判。
两周不是教条
两周一个迭代是我们的默认节奏，不是教条。关键是节奏本身的稳定性——甲方知道什么时候提需求、什么时候看结果、什么时候拍板变更。有了这个节奏，需求基线才有锁的意义。
延伸：基线会议的议程模板
基线会议控制在十五分钟内，议程固定三段：上迭代完成对照基线逐条确认、变更池按价值与依赖重排、下迭代范围与验收标准当场确认。会议产物就是更新后的基线文档与变更记录，会后不发长篇邮件。议程固定的好处是参与方都会提前准备——基线会议开成自由讨论，两周节奏就被会议本身拖垮了。