混合项目管理：如何在同一项目中使用瀑布+敏捷

同一项目里同时存在两种节奏，是很多团队的日常。整体上线时间写进了合同，还要留痕备查；但其中一部分功能的需求，直到开发动手前还在变。全按瀑布走，变更成本高；全按敏捷跑，外部节点和审计要求又难以满足。

混合项目管理要解决的正是这个问题。它不是把两种方法各用一半，而是给性质不同的工作分配不同的管理方式：该稳的部分按阶段和里程碑管，该变的部分按迭代交付。

全文按落地顺序展开四件事：先判断项目值不值得混合，再划清边界，然后把两种节奏接起来运行，最后用可观察的信号检验它是不是真的跑起来了。

混合项目管理到底混的是什么

先把概念说清楚，后面的判断才有依据。

《PMBOK 指南》在讨论开发方法时，把预测型、迭代与增量型、适应型、混合型并列。混合不是对瀑布或敏捷的折中，而是一种有明确位置的开发方法选择。

两种方法的分工逻辑

瀑布的核心是范围在前期确定，按阶段推进，每个阶段结束时都有明确的交付物和评审。它的成本优势来自"想清楚再动手"，代价是一旦进入执行期，改动会牵动整条链路。

敏捷的核心是把范围按优先级切开，用短迭代交付可用增量，靠反馈修正方向。它的优势是响应快，代价是长期预测和跨团队协同需要额外的机制支撑。

混合的三种常见形态

• 阶段混合：项目整体按阶段和里程碑推进，其中某个阶段内部用迭代交付。
• 工作流混合：不同性质的工作走不同流程，例如软件功能走迭代，硬件采购、第三方认证、合规评审走里程碑。
• 层级混合：项目层用阶段、里程碑和基线对外汇报，团队层用迭代和看板组织日常执行。

三种形态可以叠加。选哪一种，取决于不确定的部分出现在"某一阶段""某类工作"还是"某些团队"。

混合的边界要分明，不是一半一半

判断一项工作该归哪一边，看两个问题：范围在开工前能不能写清楚？做错了返工代价有多大？

范围清楚、返工代价高的，走预测型管理；范围看不清、需要尽快看到效果再调整的，走迭代管理。这两类工作在同一个项目里并存，才是混合。

什么项目适合混合，什么情况别用

适合混合的四个信号

• 外部有硬节点：合同交付、上线窗口、备案时间不能挪。
• 有留痕和审计要求：需要基线、评审记录和变更追溯。
• 需求局部不确定：整体目标清楚，但部分模块的实现方式还在探索。
• 协作方节奏不一致：内部团队能按迭代交付，外部供应商或硬件方按合同节点交付。

不适合混合的信号

• 需求稳定、流程成熟、周期短：直接按瀑布排计划，管理成本更低。
• 团队规模小、职责单一：纯敏捷的沟通成本更低。
• 组织无法投入阶段评审：没有评审人和评审标准，阶段门会退化成形式。

判断维度

这张表的用法不是逐条打分，而是找出哪些维度指向不同方向。指向不一致的地方，就是需要在项目里划出的边界。

划分边界：哪些走瀑布，哪些走敏捷

边界划分决定了混合能不能落地。常见有三种划法，选一种作为主轴。

按阶段划分

需求梳理、架构设计、方案评审这类前期工作走预测型：这些环节返工代价高，需要稳定的基线。

功能开发、界面调整、需求优化这类执行工作走迭代：短周期交付能更快暴露问题。

这种划法适合整体目标清楚、实现路径还在摸索的项目。

按工作流划分

软件功能走迭代，硬件采购、外购组件、第三方认证、合规评审走里程碑。

这种划法适合软硬件并行或存在外部依赖的项目。关键是明确交接点：迭代产出的成果什么时候交给外部流程，外部流程的结果什么时候反哺迭代。

按层级划分

项目层用阶段、里程碑和基线对外汇报，团队层用迭代和看板安排日常执行。

这种划法适合多团队协作、管理层与执行层关注点不同的组织。

把边界写成一张表

表里每一行都要能回答三个问题：谁负责、变更怎么提、完成的标准是什么。写不出来的行，说明边界还没划清。

有一点需要提醒：不要按人来划边界。同一个团队在不同时间段里分别按阶段和按迭代工作没有问题，但要求同一批工作在同一个时间点满足两套流程，只会产生双份记录。

落地步骤：在同一项目里把两种节奏接起来

第一步：定项目层基线

• 动作：明确项目范围边界、关键里程碑、验收标准，以及必须受控的交付物清单。
• 成功信号：任何人问"这个项目什么时候算完成"，得到的答案一致。

第二步：圈出可以迭代的部分

• 动作：把需求拆到能在两到四周内产出可验证增量的粒度；拆不动的大块工作留在阶段里，不要硬塞进迭代。
• 成功信号：迭代结束时能拿出可演示或可测试的成果，而不是一句"完成了 60%"。

第三步：给每个阶段配置节奏

• 动作：定义阶段内迭代的起止时间、评审方式和参与者。同时明确迭代评审与阶段门的关系：迭代评审确认增量是否满足需求，阶段门确认项目是否进入下一阶段。
• 成功信号：团队知道下一次评审是哪天、要交什么。

第四步：打通变更通道

• 动作：需求变更走同一个入口，先评估对范围基线、里程碑和当前迭代的影响，再决定进当前迭代、进下一个迭代，还是走正式变更审批。
• 成功信号：每条变更记录都能追到提出人、决策人和对计划的影响。

第五步：对齐质量与发布

• 动作：迭代内完成单元验证和功能验证，阶段末做整体验证；发布窗口与阶段里程碑绑定，避免迭代交付的成果卡在发布环节。
• 成功信号：每一次发布都能追溯到对应的迭代和阶段。

第六步：统一数据与汇报口径

• 动作：用同一份数据同时产出里程碑视图和迭代视图，不要为不同受众维护两套台账。
• 成功信号：管理层看到的进度偏差，与团队看到的迭代状态指向同一件事。

用工具承载两种节奏

边界和规则定下来之后，还需要一个能同时装下阶段和迭代的系统。如果阶段进度记在文档里、迭代情况记在另一个工具里，前面说的统一口径就无从谈起。

禅道在项目管理上的设计围绕这一点展开。它内置项目集、项目、产品、执行四个核心管理结构，有机融合业内九大主流项目管理模型框架和方法，提供稳态与敏态双模管理：稳态承接瀑布的规范管控，敏态承载敏捷的灵活迭代。

具体到项目建模，禅道提供 Scrum、瀑布、看板等项目模型，也提供融合敏捷、融合瀑布这类组合模型。融合瀑布在瀑布项目管理的基础上支持创建迭代与看板，用来承载"项目整体按阶段推进、阶段内按迭代交付"的形态；瀑布项目的阶段支持按层级拆分，便于把大阶段拆成可管理的子阶段。

在流程层面，禅道把过程定义、交付物管理、评审流程、项目基线、项目变更、质量保证集中在同一套项目流程里。阶段门需要的评审记录、基线版本和变更台账可以由流程产生，不必靠人工事后补文档。

视图方面，甘特图呈现里程碑和阶段进度，燃尽图、累积流图呈现迭代节奏，仪表盘汇总整体状态。同一组需求、任务和 Bug 数据生成不同视角，管理层和团队不需要各维护一套数据。禅道已为国内 100 万+ 团队提供项目管理工具支持，多模型并存的项目场景是它的主要使用场景之一。

不过工具解决的是承载问题，不是判断问题。哪些工作走阶段、哪些走迭代，仍然要在项目层面先定清楚。

常见坑与验证信号

四种常见失败形态

1. 伪混合：文件里写了混合，实际只跑一种。表现是迭代照常开，阶段门从不评审；或者阶段评审照旧，迭代开成了周报会。
2. 两套账：阶段用一套表格，迭代用另一个工具，数据对不上，汇报时口径打架。
3. 变更绕行：迭代内直接改需求，不评估对基线和里程碑的影响，等到阶段末才发现偏差。
4. 权责错位：团队被要求自组织，但排期、发布、验收的决定权仍在职能部门，每次决策都要等。

判断混合是否真的跑起来

• 迭代结束有可验收的增量，而不是进度百分比。
• 里程碑出现偏差时，能指出是哪个迭代的哪项工作导致的。
• 每条需求变更都能追到提出、评估和决策记录。
• 阶段评审有明确结论：通过、有条件通过或调整计划。
• 复盘产出的改进项，在下一个迭代有对应动作。

发现偏差时的纠偏动作

• 边界失效：回到边界表，重新确认哪些工作真的需要阶段管控。
• 口径打架：先统一数据源，再统一汇报模板。
• 变更失控：把变更入口收敛到一个，明确未评估的需求不得进入迭代。
• 等待过多：把审批权限按影响范围分级下放，只保留高影响变更的评审。

常见问题

混合项目里的估算和排期怎么做

两个层级用两套口径，并且不要互相换算成硬承诺。迭代内用相对估算或团队的历史速率判断一轮能完成多少，结果只用于排期取舍；项目层用里程碑、关键路径和资源投入来对外承诺交付时间。把单轮速率乘上轮数直接推出一个交付日期，是混合项目中常见的一种失误。

阶段门没有通过，正在进行的迭代怎么办

先区分原因。如果缺的是评审材料或跨部门确认，迭代不必停，可以继续交付增量，同时把补齐材料作为阶段门的阻塞项跟踪；如果缺的是关键技术方案是否可行的结论，就先停止扩大范围，把资源转向验证。无论哪种情况，阶段门未通过都需要一份阻塞项清单、明确的责任人和下一次评审的时间点，而不是一句口头提醒。

混合项目要不要做复盘，怎么做

要做，而且建议分开做。迭代复盘关注执行：节奏是否合适、协作是否顺畅、技术实践要不要调整，改进项通常下一个迭代就能验证。阶段复盘关注决策：范围是否还成立、风险有没有变化、下一阶段要不要换方式。两者合并成一次大会，容易出现结论空泛、改进项无人跟进的情况。

混合模式是过渡方案吗

不一定。对同时存在硬性外部节点和高不确定性需求的业务，混合是可以长期使用的方式。对需求逐渐稳定、流程成熟的业务，也可以逐步简化管控。方法跟着项目性质走，不必追求一步到位。

从下一个项目的一个阶段开始

不必一上来就改造整个组织。选一个正在进行的项目，做三件事：

1. 按前面的判断维度，确认它确实需要混合。
2. 画出边界表，把工作分成阶段管控和迭代交付两类，并写清责任人和完成标准。
3. 统一数据源，让两种节奏的进度从同一份数据里读出来。

跑完一个完整阶段，再决定是否扩大范围。混合项目管理的难点不在方法本身，而在边界是否清楚、规则是否被执行。