产品经理 · 项目管理 - 深度专业内容
产品经理圈有一个持续了十年的争论：「敏捷还是瀑布？」敏捷派认为瀑布是「老古董」——需求变更在瀑布中成本高昂，而敏捷的迭代节奏让「拥抱变化」成为可能。瀑布派认为敏捷是「借口」——没有完整需求文档和里程碑的严格管控，项目会变成「今天改一个明天改一个但永远没有上线日」的无底洞。这两种立场的共同盲点是假设「所有项目适合同一种方法论」。在大型企业（银行和保险和制造业央企）的软件交付中，真实世界的最佳实践往往是「敏捷加瀑布的混合模式」——在项目的不同阶段使用不同的方法论。
混合模式将项目拆分为两个阶段。第一阶段：瀑布式总体规划（项目启动到需求冻结）。大企业项目有四个天然适合瀑布模式的约束：预算是按年度批复的（不能「迭代着看需要多少钱」——你必须在项目启动时申报一个明确的总预算）；上线日期通常是「硬性的」——比如为了配合新监管法规的生效日期、为了赶上双11大促或为了在领导公开承诺的截止日前交付；外部依赖需要提前锁定——和ERP系统做接口对接和第三方厂商的硬件采购和监管报批等「长周期外部依赖」无法按两周一次迭代的模式来排期。这些约束决定了项目的「范围框定」阶段最适合用瀑布模式——制定一份清晰的需求范围说明书、WBS（工作分解结构）和里程碑甘特图——这个阶段的目标不是「把需求定死不许变」，而是「为后续的敏捷迭代建立一个清晰的边界——在这些边界之内你可以灵活调整」。
第二阶段：敏捷式开发执行（需求冻结后到交付上线）。在总体规划阶段确定了「这个版本要实现的核心用户故事清单」（约50至200条故事）之后，开发阶段进入敏捷节奏——按两周一Sprint将故事池中的用户故事按优先级排序逐个交付。每个Sprint结束都有可演示的增量，每3至4个Sprint做一次Sprint Review向业务方展示进度并收集反馈。这个阶段的关键是：总体规划划定了「这个版本做什么」，敏捷迭代解决「用什么样的顺序和细节做」。如果业务方在这个阶段有新增需求——产品经理不是直接拒绝，而是引导对方走「变更评审」流程：评估新需求对时间和预算和已规划故事的影响，由项目治理委员会决定是否接受变更。
混合模式对产品经理的要求比纯敏捷更高——你需要同时具备「长线规划能力」和「短线迭代执行力」。在瀑布阶段你需要像一个「经典项目管理师」——能画WBS、能排关键路径、能识别依赖风险。在敏捷阶段你需要像一个「Scrum产品负责人」——能拆分用户故事、能维护产品待办列表、能在每个Sprint结束时冷静地说「这个Sprint没有完成预期的3条故事，原因是什么，下个Sprint如何调整」。
混合模式不是「在两个极端之间取一个中间值」——它在「需要确定性」的地方使用确定性（瀑布），在「需要灵活性」的地方使用灵活性（敏捷）。这种「战略性混合」才是企业级产品交付的真实面貌。
方法论是为项目服务的，不是反过来。如果你的项目在一个高度不确定的创业环境中——纯敏捷是你的朋友。如果你的项目在一个预算和上线日期和合规要求都锁死了的大企业环境中——不要硬要用纯敏捷，也不要退回纯瀑布。混合模式可能是你工具箱中最有力但最少被讨论的一把武器。
更多深度内容，请关注微信公众号：
abc6789122
每日更新，不错过任何精彩内容