开发模式：定错节奏，好方案也做砸

三种模式的真实面貌

瀑布适合需求稳定、合规要求高的项目：文档全、责任清，代价是灵活性差。敏捷适合需求演化中的产品：快速试错、持续交付，代价是对团队成熟度要求高。混合模式是多数综合包网项目的现实选择：底层（账户、权限）按瀑布走稳，上层（运营、内容）按敏捷走快。

里程碑设计的两个原则

• 每个里程碑都要有「可验证的交付物」，不是「完成了 80%」这种进度话术。
• 里程碑间隔别超过四周，间隔越长，问题发现越晚，返工越大。

验收节奏怎么定

两周一次功能演示，比一个月一次书面汇报有效得多——看得到的东西才谈得上验收。演示环境尽量用接近生产的配置，「演示能跑、上线就崩」的悲剧大多栽在环境差异上。涉及外部系统的部分，验收前先过接口规范里的联调检查。

变更管理

变更不可怕，失控的变更才可怕。所有变更走登记：改什么、为什么、影响哪些模块、谁批的。综合平台的模块关联多，一个「小改动」波及三个模块的例子太常见了。变更成本要在选型阶段就有预期，参考选型指南里控制权维度的分析。

节奏定了，上线前对照上线流程检查点逐项过。